Re: ::select() and threads question, hopefully posed better :-)
Re: ::select() and threads question, hopefully posed better :-)
- Subject: Re: ::select() and threads question, hopefully posed better :-)
- From: Godfrey van der Linden <email@hidden>
- Date: Sun, 15 Apr 2007 21:35:46 +1000
Bingo, I think this is what is happening.
When you see a lot of time spent in 'ml_set_interrupts_enabled' it
usually means that a use app is spinning across the kernel
boundrary. When you trap into the kernel the system need to disable
interrupts a couple of times, since shark still tries to sample these
times it looks like we are spending a lot of time enabling
interrupts, when actually shark is just blinkered and its eyes are
uncovered when interrupts are re-enabled.
Now X doesn't really spend an extraordinary amount of time with
disabled interrupts, in fact for X to hit its multimedia targets we
spent quite some time tracking down and exterminating such cases. In
OSX unlike Linux and Windows, drivers rarely disable any interrupt
but there own and most of the IOFilterInterruptEventSources::filters
are quite short, I believe the longest on a default system is USB
when high-performance isoch is enabled.
When you are running your App I'd like to see what happens to the
interrupt latencies, you can measure that with '/usr/bin/latency'.
If it shows long paths the Apple will want to know because it will
destroy CoreAudio's very low jitter.
Godfrey
On 12/04/2007, at 06:16 , Mark F. Murphy wrote:
At 12:41 PM -0700 4/11/07, email@hidden wrote:
I've a bunch of C++ code that runs on Windows and OSX. 99% of the
code is portable, and the 1% that isn't mostly has to do with file
operations (seeking the POSIX way is slow on Windows, so we had to
use the Win32 APIs for that stuff). Anyway, with such a large
majority of our code the same across both operating systems, I was
expecting to see more-or-less-comparable CPU usage. However, when
I run the code, I see the OSX version taking up 4-5x (or more,
sometimes 10x) as much CPU as it does under Windows -- this is on
my dual 2ghz G5 as well as my 2ghz Core Duo MacBook.
Usually when porting apps of this nature and run into issues such
as this, you have to look to see if calls are executing in the same
way on the new target environment.
My guess without seeing your code (and it seems others are guessing
this as well)... is that your call to select() is returning a lot
more on Mac OS X than it does on your Windows version.
Usually when you see CPU being churned in this way, it means
there's a tight loop occurring (which may or may not be valid
depending on your app). The loop that might be occurring is a
return from select() in Mac OS X when such a return would not occur
in Windows.
In other words, Windows is blocking where as Mac OS X shows
different behavior, is not blocking, and returns.
Have you compared how many times you're calling select() in Mac OS
X versus how many times you call it in Windows?
It might give a glue if the two ports are vastly different.
mark
--
----------------------------------------------------------------------
-----
Mark F. Murphy, Director Software Development
<mailto:email@hidden>
Tyrell Software Corp <http://
www.tyrell.com>
----------------------------------------------------------------------
-----
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden