site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Platon Fomichev writes:

As another side-note I am constantly in question why does ./configure like scripts take an exceptionally big amount of time on even most powerful Mac Pro's compared to FreeBSD? Is this related to fork()/exec () or sh port itself or something else? Anyone ever did some research on this?

Ah, one of my pet peeves :) It is at least partially because most system calls take roughly between a factor of two and an order of magnitude longer on MacOSX than they do on other *nix platforms on the same hardware. Run lmbench and compare the results between MacOSX and Linux (or Solaris, or FreeBSD) on the same hardware if you don't believe me. At least part of the reason for this is the decision to use a 32-bit kernel with a 4GB address space rather than a 64-bit kernel on 64-bit hardware. Every syscall to the kernel takes a bit longer because copying the syscall arguments is no longer just a simple bcopy with a fault handler. This is because, unlike on most other *nixes, the kernel and the application don't share an address space. I'm pointing my finger at this because I've seen similar slowdowns running 32-bit linux with the 4G/4G kernel/user address space patch applied. The thing is, Apple really doesn't seem to care about performance at this level. I think this is because Apple's bread and butter is the "desktop experience", and such things, by and large, are lost in the noise to 99.9% of their customers. Eg, how often do Mac users start Mail.app or Safari.app? Will they notice an extra few milliseconds once every few months? Probably not. Speeding things up other ways (pre-linking, faster booting via launchd) tend to speed things up more in the user's eyes. Where such performance problems impact the desktop experiance, they've worked very hard to speed things up by several orders of magnitude using clever workarounds. For example, many threaded apps like to call gettimeofday() often (sometimes seemingly in a tight loop). To speedup gettimeofday, they started reading or caching the time in userpace inside the C library, so that the vast majority of gettimeofday() calls ended up just going into the library, rather than all the way down to the kernel. Look at the commpage stuff to see what I mean. Drew _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com