OSNews

That is one of the greatest problems with generally open source world. It usually takes care about Linux, everything else seems to be forgotten.

There is a noticeable slowdown on the "desktop". I suspect the main culprits are a) userthreads and b) malloc.

a) Using userthreads means a huge multithreaded program is running on a single cpu core wasting all the threading overhead.

b) OpenBSD malloc is pretty complex and has many features - most importantly ASLR which consumes high quality random numbers on a regular basis. There is no way it could outperform a decent performance-optimized malloc. Huge multithreaded programs tend to allocate and deallocate thousands of objects every millisecond so it ends up adding up.

On the command line, most programs a) use SMP-enabled processes instead of threads and b) are written in C which means all allocations are planned. It is perfectly possible they could outperform an out of the box Linux with many daemons half-idling in the background.

I certainly don't have any complaint about make -j 6 in /GENERIC.MP.

OpenBSD 5.2 will include SMP-enabled rthreads by default so I expect to see a boost in "desktop" performance. malloc is less likely to improve but memmap is getting reworked, which could lead to a faster implementation.

NOTE: The network stack runs in kernel and thus it won't scale over 1 core until the kernel itself becomes multithreaded.