Re: Road to 80 cores ( Was Re: Grand Central Details)
Re: Road to 80 cores ( Was Re: Grand Central Details)
- Subject: Re: Road to 80 cores ( Was Re: Grand Central Details)
- From: "Kyle Sluder" <email@hidden>
- Date: Wed, 18 Jun 2008 14:19:28 -0400
On Wed, Jun 18, 2008 at 1:50 PM, Pierce T. Wetter III
<email@hidden> wrote:
> The problem is that creating a thread, destroying a thread, and switching
> threads in and out have a LOT of overhead. The above thread is going to
> spend most of its time waiting for I/O, but the OS has no way of knowing
> that really. So the OS swaps in the thread, which looks at its mutex and
> says "I have nothing to do", and then gets swapped out.
I'm sorry but I have to take issue with this. Are you saying that the
scheduler is not intelligent enough to keep the apps on a blocked
queue until a packet comes in for that handle, at which point the
process is awoken and sent a signal?
> Trivia: Apache 1.x is even worse then this, it forks off a whole new
> _process() per connection so you have even more overhead. That's one of the
> reasons people tend to put caches in front of apache for performance
> (webperfcache on OSX Server, squid on others).
I'd say the fact that this model is still the default points towards
its persistence as an engineering tradeoff.
But overall I agree with you 100%. Threads are most useful when you
have a major task (calculate pi) and a minor task (print digits as
they're computed), and do not want or cannot have the minor task
suffer for the major task. You still want to consume your entire
timeslice with performing the single, heavy task. Web serving, on the
other hand, is a bajillion tiny tasks, and better methods exist to
accomplish that goal.
--Kyle Sluder
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden