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: Ernesto Corvi <email@hidden>
- Date: Wed, 11 Apr 2007 16:18:23 -0400
A blocked thread by the OS, by means of select(), read(), recv(), etc
does not add up to the CPU cycles count
(it's effectively sleeping, waiting for an event to occur). So you
can probably safely ignore that result from Shark
and move on to the other routines that are consuming the other 40% of
the CPU time, and see what those routines
are. Then try to figure out why are them consuming that many cycles.
If the routines are OS routines, then trace back until you hit one of
your program's routines, and see what
calls it, and what could be wrong in that call.
Ernesto.
On Apr 11, 2007, at 3:41 PM, email@hidden wrote:
All,
While I appreciate the info on how to use select(), that's not the
nature of my question. I'll try to explain it better :-)
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.
So, I said to myself, "self, you should check out that nifty Shark
app that ships with OSX, and see if you can find out what is taking
all the CPU" So, I did. I launched Shark, pointed it at my
process, selected Time Profile, and pressed Start. A minute or so
later, it came back and showed me lots of cool stuff, but the most
interesting thing was that, according to Shark, something like 60%
of the time my program was running, it was in
ml_set_interrupts_enabled.
I said, "self, I don't know what that is, but let's see if it calls
something that I do know about." So I followed the arrows, and
this is what Shark told me:
ml_set_interrupts_enabled
thread_block_reason
thread_block
uiomove
selprocess
select
... so the nature of my question is this: if 60% of the time my
program is running is spent in the above, how can I optimize it?
Or am I interpreting the output of Shark correctly (for instance,
does ml_set_interrupts_enabled call thread_block_reason which calls
thread_block, or vice versa)?
Regards,
John
_______________________________________________
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