site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Bingo, I think this is what is happening. Godfrey On 12/04/2007, at 06:16 , Mark F. Murphy wrote: It might give a glue if the two ports are vastly different. mark _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... 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. At 12:41 PM -0700 4/11/07, jmzorko@mac.com 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? -- ---------------------------------------------------------------------- ----- Mark F. Murphy, Director Software Development <mailto:markm@tyrell.com> Tyrell Software Corp <http:// www.tyrell.com> ---------------------------------------------------------------------- ----- _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/gvdl%40mac.com This email sent to gvdl@mac.com This email sent to site_archiver@lists.apple.com