C/C++ When pthreads will work properly on FreeBSD?

[obsigna]

Do we have a quick & dirty binary diff in the base?

I found textproc/vbindiff, and a quick run on the two binaries suggests that the difference is the result of a different link order.

 

[Zirias]

Still, -pthread does other stuff as well, like e.g. predefining some macros that might be required for everything to work as expected, so you should always use that flag instead of linking yourself.

 

[kpedersen]

so you should always use that flag instead of linking yourself.

I see this all the time with CMake.

target_link_libraries(myapp SDL2 pthread GL)

In theory this would pull into the linker, -lpthread rather than -pthread

 

[Zirias]

It's not that uncommon and probably most of the time harmless. What -pthread does additionally depends on the target platform. Still, it should be used to be safe

 

[Zirias]

Afaik, that was somewhere around FreeBSD 5.

Probably a bit later, libmap.conf(5) still contains an example that suggests libthr and libpthread are different.

Anyways, probably a very long time ago. If this whole thread isn't just a troll attempt, the most likely issue is that a libpthread.so was used back then, when it still defaulted to PTHREAD_SCOPE_PROCESS, and PTHREAD_SCOPE_SYSTEM wasn't explicitly set.

Still, blaming your tools (yep, including an OS) for your own mistakes.

 

[shkhln]

Probably a bit later, libmap.conf(5) still contains an example that suggests libthr and libpthread are different.

Keep in mind, that man page still contains an example for https://www.freshports.org/www/linuxpluginwrapper/. Wikipedia (https://en.wikipedia.org/wiki/Thread_(computing)#History_of_threading_models_in_Unix_systems) claims: "FreeBSD 5 implemented M:N model. FreeBSD 6 supported both 1:1 and M:N, users could choose which one should be used with a given program using /etc/libmap.conf. Starting with FreeBSD 7, the 1:1 became the default. FreeBSD 8 no longer supports the M:N model." I'm too lazy to verify that, though.

Still, blaming your tools (yep, including an OS) for your own mistakes.

Oh, I just want to see some code from OP because I'm curious what that might be. Too bad OP is… unreasonable.

 

[Zirias]

"FreeBSD 5 implemented M:N model. FreeBSD 6 supported both 1:1 and M:N, users could choose which one should be used with a given program using /etc/libmap.conf. Starting with FreeBSD 7, the 1:1 became the default. FreeBSD 8 no longer supports the M:N model." I'm too lazy to verify that, though.

This sounds reasonable enough to just believe it. So on any FreeBSD since 6, OP could have gotten what he wanted. End of this pointless thread then?

 

[Bobi B.]

Geri, that is a bold claim, care to share a sample code to demonstrate your issue? Have you verified if process or threads are not bound to a single core?

 

[kpedersen]

which uses software rendering, therefore threads are required to have a good experience on modern computers

Modern computers generally have GPUs. You could consider using OpenCL. That still counts as software rendering (kinda) and would result in vastly superior performance to even the most modern Ryzen CPU.

 

[Geri]

Geri, that is a bold claim, care to share a sample code to demonstrate your issue? Have you verified if process or threads are not bound to a single core?

once i have installed downloaded freebsd, i will post more details.

after seeing all of these overheated posts, i am also becoming more interested to see it again, so instead of waiting for the next month to continue these tests, i have started downloading freebsd, which will probably be finished this night, and then i will install it to a qemu virtual machine

 

[kpedersen]

qemu virtual machine

Great. Then install a Linux to the same qemu virtual machine and compare performance.

I am fairly certain you will receive consistent underwhelming performance on both operating systems (unless KVM is used perhaps).

 

[Geri]

Modern computers generally have GPUs. You could consider using OpenCL. That still counts as software rendering (kinda) and would result in vastly superior performance to even the most modern Ryzen CPU.

on computers where opencl is not supported by hardware (and the runtime is not present on anywhere by default, unless people install its runtimes from a vendor) would be an economic suicide, and the speed of opencl is very anemic compared to hand crafted integerheavy c code anyway. for example my code is fluid up to a few 1000 polygons even on a pentium mmx. imho using opencl would be an economical suicide in any serious project besides cryptocurrency mining and AI, merely serves more purpose than to impress the developers mom and ideologize the fact that someone have spent $1000 on a plastic children toy called gpu.

 

[Geri]

Great. Then install a Linux to the same qemu virtual machine and compare performance.

I am fairly certain you will receive consistent underwhelming performance on both operating systems (unless KVM is used perhaps).

i have debian in virtual machine, there is about 20-30% speed drop compared to the host, and ofc pthreads are working fine as they was intended to.

 

[kpedersen]

on computers where opencl is not supported by hardware (and the runtime is not present on anywhere by default, unless people install its runtimes from a vendor) would be an economic suicide, and the speed of opencl is very anemic compared to hand crafted integerheavy c code anyway. for example my code is fluid up to a few 1000 polygons even on a pentium mmx. imho using opencl would be an economical suicide in any serious project besides cryptocurrency mining and AI, merely serves more purpose than to impress the developers mom and ideologize the fact that someone have spent $1000 on a plastic children toy called gpu.

Good luck. After all Michael Abrash and John Carmack managed to get Quake working on a Pentium mmx. I am sure you can too.

i have debian in virtual machine, there is about 20-30% speed drop compared to the host, and ofc pthreads are working fine as they was intended to.

So it is using KVM?

someone have spent $1000 on a plastic children toy called gpu.

Might not be modern but an Intel GMA 915 from early 2000's is probably enough to beat a lot of software renderers written today. Unless yours plans to have better performance than LLVMpipe?

 

[Geri]

Good luck. After all Michael Abrash and John Carmack managed to get Quake working on a Pentium mmx. I am sure you can too.



So it is using KVM?

hehe, are you jelly? i was living from writing game engines for about 15 years, while you were probably sitting in sorrow with your imaginary opencl renderer

my last game engine is called Maker4D, here is a game its powering: http://users.atw.hu/gerigeri/maker4d/ufok_fulen.zip

Maker4D is the game engine i was referring to in the first post, which i want to make the freebsdd runtimes for, i just didnt wanted to spam it

 

[Jose]

...would be an economical suicide in any serious project besides cryptocurrency mining and AI...

Things that make you go hmmm...

 

[kpedersen]

hehe, are you jelly? i was living from writing game engines for about 15 years, while you were probably sitting in sorrow with your imaginary opencl renderer

Hah, not really. I can generally crack out a software renderer in C++ during a 24hr games jam
https://github.com/osen/software-3d-renderer

Will be interesting to see how it compares with yours.

(whilst I am flexing, I also wrote the 3D engine for a few of the LEGO games on PSX, PC, etc)

 

[Geri]

Hah, not really. I can generally crack out a software renderer in C++ during a 24hr games jam
https://github.com/osen/software-3d-renderer

Will be interesting to see how it compares with yours.

then you are lucky, because i like this kind of rivalization
mine can push about 1+ million polygons playable on a third gen 4 core i7 in full hd
i am curious, how well your performs?

 

[ralphbsz]

imho using opencl would be an economical suicide in any serious project besides cryptocurrency mining and AI, merely serves more purpose than to impress the developers mom and ideologize the fact that someone have spent $1000 on a plastic children toy called gpu.

A lot of people in the computer industry disagree with you, and think that GPUs (and their close relatives) are highly efficient and fast, and not just a "children's toy". Your claim that they are "anemic" compared to hand-crafted integer-heavy C also disagrees with the state of the art.

 

[Geri]

A lot of people in the computer industry disagree with you, and think that GPUs (and their close relatives) are highly efficient and fast, and not just a "children's toy". Your claim that they are "anemic" compared to hand-crafted integer-heavy C also disagrees with the state of the art.

i have never asked anyone to agree with me, i explained why i am not going to use it. you write code whatever you want to write in, and what i write code in is not something you can vote about

 

[Geri]

maybe i am too retarded to install freebsd, but this is the newest 64 bit freebsd disk image i have downloaded this afternoon
yes, the time and date is correct.

 

[Geri]

lol, funny, but a reboot fixed it
after googling a bit, it turns out that this bug exists for 7 years at least https://forums.freebsd.org/threads/signature-is-not-valid-pkg.47200/

 

[JAW]

then you are lucky, because i like this kind of rivalization
mine can push about 1+ million polygons playable on a third gen 4 core i7 in full hd
i am curious, how well your performs?

/me grabs large bag of popcorn...

 

[Zirias]

So, this is a troll thread after all…

 

[kpedersen]

lol, funny, but a reboot fixed it
after googling a bit, it turns out that this bug exists for 7 years at least https://forums.freebsd.org/threads/signature-is-not-valid-pkg.47200/

Looks like it was fixed in 2018.
https://github.com/freebsd/pkg/issues/1676

/me grabs large bag of popcorn...

Heh. If you disable binary space partitioning and occlusion culling, it could make a fun test. Generally you would also start needing a fairly hefty multi-core CPU just to copy the sheer number of pixels to a HD resolution framebuffer.