The 4/4 memory split only applies to 32 bit environments.

If OS X processes seem good at talking to one another - think VoiceOver, Spotlight, the window server, iLife's media sharing, even copy and paste - it's due in part to the fast, flexible IPC mechanisms enabled by Mach. So OS X gets a lot of mileage out of Mach messaging - AppleEvents, distributed notifications, run loops, etc. What's FreeBSD's answer to the Mach Inteface Generator? CORBA? Mach IPC makes signals, sockets, pipes, shared memory, SysV IPC, etc. There's a lot of historical decisions of dubious validity in retrospect, but there's also an excellent technical defense that can be made for Mach. How is supporting Mach and FreeBSD system calls an advantage? There seems to be a bug where a program doing linear I/O can monopolize the I/O system, which improves performance for that process but decreases apparent responsiveness. For a linear read of a huge file, this only hurts it can be turned off on a per descriptor basis, but code compiled naively for OS X won't have bothered to do that.ģ) Bugs. That's obviously going to incur a cost.Ģ) Unified buffer cache - cacheing reads in the VM system. There's a few things I've found that impact OS X's I/O negatively:ġ) Spotlight wants to index any file you opened for writing and then closed. I wrote some fairly I/O intensive code with a number of back ends. The slowest part of the system I have found is the VM subsystem, which absolutely crawls. OS X is unusual in that every library is always dynamically bound, which adds overhead for every call, but gives you all the benefits of non-static libraries (code sharing, security, etc.) Benchmarks often don't take this into account. I'm not sure about other UNIX flavors, but Linux in particular (usually) maps the kernel's address space into each process with a 3/1 split, which is faster but has an obvious downside - 25% less address space for the process and 75% less for the kernel!ģ) Dynamic library binding. A system call requires a context switch to and from the kernel's own address space. This is fixed overhead which will be especially apparent with 'fast' system calls.Ģ) 4/4 memory split. Determining which you have isn't cheap, but the win is apparent - how many Mach messages per second does your conventional UNIX benchmark at? Features don't come for free. OS X has to support both Mach and FreeBSD system calls through the same trap interface.

I'm not disputing this, but I'd like to provide some context so people aren't left with the impression that 'Apple's programmers are st00pid n00bs.' There's at least three decisions that negatively impact OS X's system call performance, but that provide wins in other areas.ġ) Mach/FreeBSD system call disambiguation. System calls are quite expensive (roughly 10x the cost on a conventional UNIX system), for example Some parts of OS X are much slower than others.

Running windows xp on macbook pro