Re: Rules of thumb
And you're right about Solaris too - not too bad, although it was considered to be slow enough that it was often called Slowlaris.
It depends on what aspect of it you think is slow. As far as I recall, the memory allocator in the C runtime on Solaris is of the old school - every malloc and free maps on to an OS call. Very BSD. But there's nothing preventing use of a GLIBC style memory allocator.
If one does that there's no particular reason why code running on Solaris would be slower than anything else on the same hardware.
If one considers the wider system aspects, I know that the Linux world has worked very hard on getting mutexes working faster, and Linus has always steered the philosophy of the scheduler towards throughput over everything else. That's pretty good. However it's only comparatively recently that Linux got rid of the big kernel lock. There's also a growing acknowledgment that the Linux network stack is a bad idea speed-wise, but it's such a massive change to do anything about it I can't see it happening. The BSDs of this world, which put the stack in user land, is the way to go. AFAIK Linux is the only OS to put a network stack in the kernel. Windows? No. Mac OS? No. *BSD? No. VxWorks, INTEGRITY? No. QNX? Dunno, probably not. See what I mean?.
So if one's code is heavy on the mutexes, threads and IO one would see, or would have seen, a difference.
Biting the hand that feeds IT
