C When pthreads will work properly on FreeBSD?

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.
 
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 ;)
 
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.
At least in my case I can exclude macros for sure. I did a 4 way experiment (auto-scientific habit):

(1) -pthread only on the link command line, and no -(l|)pthread option when compiling the sources
(2) -lpthread only on the link command line, and no -(l|)pthread option when compiling the sources
(3) -pthread while linking and compiling
(4) -lpthread while linking and compiling

(1) & (3) give exactly the same output and (2) & (4) does as well. However, as noted earlier, wile the output of (1)/(3) got exactly the same size of (2)/(4), the hashes are different between the two groups, probably because of linking order.
 
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.
 
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.
 
"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? ;)
 
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?
 
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, 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
 
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).
 
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.
 
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.
 
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?
 
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 :D

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
 
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 :D
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)
 
  • Like
Reactions: JAW
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.
 
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
 
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.


FQckALf.png
 
then you are lucky, because i like this kind of rivalization :D
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... :)
 
Back
Top