Linked by Thom Holwerda on Fri 2nd Sep 2005 09:44 UTC
Talk, Rumors, X Versus Y "We will shed more light on the whole Apple versus x86 PC, IBM G5 versus Intel CPU discussion by showing you what the G5 is capable of when running Linux. This gives us insight on the strength and weakness of Mac OS X, as we compare Linux and Mac OS X on the same machine."
Thread beginning with comment 26802
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Deceiving.
by bryanv on Fri 2nd Sep 2005 18:51 UTC in reply to "RE: Deceiving."
bryanv
Member since:
2005-08-26

Thank God. I was hoping I was wrong. :-)

So what we're seeing is terrible thread creation times, scheduling problems, and perhaps even leftovers of the BGL?

Reply Parent Score: 1

RE[3]: Deceiving.
by japail on Fri 2nd Sep 2005 19:01 in reply to "RE[2]: Deceiving."
japail Member since:
2005-06-30

I think that it's likely a combination of the coarse locking (which Apple has been improving continually, but it's a long complicated process as Linux and the BSDs will attest to) and also Mach (which suffers from various performance problems remedied by modern microkernels like L4).

Reply Parent Score: 1

RE[4]: Deceiving.
by hurdboy on Fri 2nd Sep 2005 23:44 in reply to "RE[3]: Deceiving."
hurdboy Member since:
2005-09-02

Pretty good discussion of it here:

http://lists.freebsd.org/pipermail/freebsd-smp/2004-September/00061...

Of course, the situation in OSX is far better than what it was with NeXTSTEP. It's better than it was on FreeBSD 4, for that matter. Apple has taken an approach somewhat similar to FreeBSD's; whether it works remains to be seen. OSX 10.4 is very stable for me, while FreeBSD 5 has left much to be desired (including simply refusing to boot on several of my machines, and hard crashes on others).

The other route is that which the DragonFly developers are taking -- making essentially everything rely upon in-kernel messaging. That makes distributing the LWKTs among processors very easy.

The reason, of course, that Apple stuck with Mach is because the Cocoa/ObjC frameworks are designed to use Mach IPC natively. On any kernel that doesn't support them, the message calls have to be emulated by libraries and translated to native system calls (see: OpenStep for Solaris or Win32 and GNUStep). At the time that Apple was updating NeXTSTEP to become OSX, nothing that wasn't Mach supported them. NetBSD has added Mach IPC support, but that was in order to provide Darwin binary compatibility.

Reply Parent Score: 1