Re: mbuf_pullup practically useless
Re: mbuf_pullup practically useless
- Subject: Re: mbuf_pullup practically useless
- From: Andrew Gallatin <email@hidden>
- Date: Mon, 27 Aug 2007 08:58:12 -0400 (EDT)
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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden