[boring] optimizing with shark output
I'm looking at the shark output from running a video patch, and it looks like most of the cpu usage (37%, according to shark) is a result of
ml_set_interrupts_enabled from the mach_kernel library.
Like a bureacrat looking at education and entitlement programs to "balance" the budget, I'm looking at slimming down the big part of this pie.
I searched Google for more information on what this might point to...but not much was deciperable. Are there some general guidelines to tune my patch to reduce this massive cpu usage, or is that just a natural part of having a complex patch, or is there really no way to tell without looking at a patch?
curious...
Peter.
On Aug 23, 2007, at 5:13 PM, pnyboer wrote:
>
> I'm looking at the shark output from running a video patch, and it
> looks like most of the cpu usage (37%, according to shark) is a
> result of ml_set_interrupts_enabled from the mach_kernel library.
This is the operating system blocking on some thread waiting for
something to happen. This could be resultant from any number of
things and might not even be limiting performance. If on a dual core
machine could be something like the audio thread or something just
waiting to run, on another processor which has open cycles to keep
letting the thread spin (harmless). It might be parallel processing
threads waiting for the threads on the other processor to finish,
spinning with the available extra CPU cycles to spare (harmless). It
might be jit.window waiting for the monitor to sync (test with
jit.window @sync 0). It might also be the result of using too much
VRAM or RAM in general and waiting for the operating system to page
Virtual VRAM or RAM (try quitting other apps and closing extra
windows lying around in the background). Or any number of other
possibilities.
If you don't get big differences from things like the last two
suggestions, I'd actually focus your optimization on other areas,
especially if you're on a multi-processor machine.
-Joshua
thanks for the input.
here's a bit more info...
Activity viewer shows a cpu usage of about 48% (though I'm guessing that's just one processor of my dual core mbp).
I ran shark to only give a time profile on the Max/MSP Process, so I'm assumming that other things weren't affecting the results. However, I did quit all other apps and windows, just to be safe.
Turning off sync didn't make a difference.
Flattening the mach_kernel Library in the shark display reveals "find_user_regs"
There is quite a bit of virtual memory used by Max/MSP: Real is at 252MB, virtual 675MB, those these numbers are quite stable, indicated to my little brain that there isn't a lot of paging happening at the moment. (..., I have 690 MB free. So I'm not sure how I can take advantage of "real" memory, as it seems quite availble for use)
So is it really "harmless", given that Activity viewer reports high cpu usage, with 37% taken up by these interrupts?
Anyway, I'll keep looking around for other places to improve...
P
On Aug 29, 2007, at 5:26 PM, pnyboer wrote:
> Activity viewer shows a cpu usage of about 48% (though I'm guessing
> that's just one processor of my dual core mbp).
Yes.
> I ran shark to only give a time profile on the Max/MSP Process, so
> I'm assumming that other things weren't affecting the results.
> However, I did quit all other apps and windows, just to be safe.
Good.
> Flattening the mach_kernel Library in the shark display reveals
> "find_user_regs"
This developer mentioned restarting the computer solved this issue,
but never got a response on the performance-dev list:
Looking further at find_user_regs(), it looks like it's used when
threads are switching from one to another, and saving their state. If
restarting your machine doesn't help this, you can do a few things to
see:
1. disable Jitter Java support. The Java runtime spawns some extra
threads (but they shouldn't really be doing much of anything)
2. disable Jitter parallel processing support. Sounds like you're
probably performance bound by something which is not processor aware
anyways.
3. disabling overdrive.
4. disable the MSP audio driver (can even select NRT driver, which
might remove a silent audio thread spinning in the background)
Then I suppose report your findings if any of this seems to have
relevant impact on your patch.
> There is quite a bit of virtual memory used by Max/MSP: Real is at
> 252MB, virtual 675MB, those these numbers are quite stable,
> indicatesd to my little brain that there isn't a lot of paging
> happening at the moment. (..., I have 690 MB free. So I'm not
> sure how I can take advantage of "real" memory, as it seems quite
> availble for use)
You can't explicitly tell it to use more RAM. The virtual memory
management in OS X is pretty good though. I'd just let it do its work
(and maybe restart the machine more often).
> So is it really "harmless", given that Activity viewer reports high
> cpu usage, with 37% taken up by these interrupts?
Don't know exactly. Can't speculate further without taking the time
to shark your patch myself (which unfortunately, I don't have the
time to do).
Good luck.
-Joshua
One more thing to add would be to try a patch without jit.qt.movie
(use jit.qt.grab or jit.noise or whatever). jit.qt.movie spawns a
worker thread per object.
jb
Am 30.08.2007 um 03:18 schrieb Joshua Kit Clayton:
> 1. disable Jitter Java support. The Java runtime spawns some extra
> threads (but they shouldn't really be doing much of anything)
>
> 2. disable Jitter parallel processing support. Sounds like you're
> probably performance bound by something which is not processor
> aware anyways.
>
> 3. disabling overdrive.
>
> 4. disable the MSP audio driver (can even select NRT driver, which
> might remove a silent audio thread spinning in the background)