Linked by Thom Holwerda on Sat 16th Dec 2006 16:58 UTC, submitted by Hakime
Thread beginning with comment 193379
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[4]: Congrats, Mac Guys!
by John Blink on Sat 16th Dec 2006 23:08
in reply to "RE[3]: Congrats, Mac Guys!"
RE[5]: Congrats, Mac Guys!
by rayiner on Sat 16th Dec 2006 23:26
in reply to "RE[4]: Congrats, Mac Guys!"
No desktop version of Windows has ever had adequate interactive performance under high I/O and VM loads. OS X isn't as good as Linux in this regard, but its still better than Windows (which will hiccup even without heavy load).
I've never used a 2k3-based Windows, so it could very well be better. However, good VM and I/O performance still won't fix the brain damage of the UI...
Edited 2006-12-16 23:29
RE[4]: Congrats, Mac Guys!
by StephenBeDoper on Sat 16th Dec 2006 23:08
in reply to "RE[3]: Congrats, Mac Guys!"






Member since:
2005-07-06
I'm afraid an article like that would just invite a flame-fest. But I'd be happy to summarize some of the most glaring problems that I've encountered.
1) The toolchain is just weird. If Apple was going to use the GNU toolchain, they should have done it properly, by adding support for Mach-O to BFD, and fixing the GNU tools so they could target Mach-O, just as they can target PEF for Windows. However, Apple chose to instead ship custom hacked-up versions of the GNU tools. While that is a solution, for people writing software, Darwin's "almost GNU but not really" toolchain is a complication that could've been avoided. In an ideal world, they would've used ELF like everyone else and avoided the problem entirely, but that's probably too much to ask.
2) Darwin's shared library infrastructure is... strange. Mach-O just isn't as clean a format as ELF. There are fairly arbitrary distinctions between loadable modules and shared libraries, restrictions on section types in dynamic libraries, etc. The linker is also slow, and startup of programs with extensive shared library dependencies is pokey.
3) The Mach/BSD API schism is not entertaining, to say the least. Their tracking of the FreeBSD API has stagnated since 5.x. Darwin is BSD... almost.
4) The system does not handle huge VM loads gracefully. Giant compiles won't even cause Linux to blink, while they'll cause Darwin to have very noticable hiccups.
5) I/O performance, and general system performance under high I/O loads is not steller.
6) Many primitive UNIX operations (process/thread creation, page-fault handling, etc) are much slower on Darwin than on Linux. This has been documented repeatedly, and extensively.
In the grand scheme of things, Darwin just isn't very good, at anything, except maybe low-latency audio. It just doesn't deliver what I'd expect from a modern, high-performance UNIX kernel. It's not as scalable as Solaris, its not as fast as Linux, its not as stable as FreeBSD, its not as clean and elegant as NetBSD, etc, etc, etc. It's merely "good enough", what Apple inherited when it bought NeXT, and what they surely realize is behind all of the major competition, but what they (rightly) think is not enough of a handicap in their target market to be worth the trouble of replacing.