Forums > MaxMSP

Xp Cpu utilization not equal Max cpu Utilization

June 14, 2006 | 3:55 pm

Hello,
at this moment I’m debugging a file.
One part of it costs a lot of cpu usage (xp Task manager). 80 – 90%
When I switch off the audio the usage drops down to 5%. So there must be a bug somewhere.
What i’ve noticed when i was looking to the Max dsp status, that there was quite a difference between the % of Xp (80) and max’s dsp status (only 8%).
The "processes" tab of the Task Manager shows the same % to Max.exe. ( (no other program is using cpu)
Did anyone of you notice the same problem?
thank sJacques


June 14, 2006 | 3:59 pm

I experienced something similar when I was building my application. It wont actually run on my 2.54Ghz 1GB RAM XP laptop, although I can have Nuendo + Reason Rewired with Photoshop open all at the same time and still use each sufficiently.

However when building the patch Max would freeze + crash even though its CPU stood at around 4-6% so am not sure if that was just a bug or what.

Will


June 14, 2006 | 4:10 pm

What do you think is the right indicator. The max (in the dsp status window or the xp (window Task Manager)Difference 1:10
Jacques


June 14, 2006 | 4:19 pm

On 14 Jun 2006, at 16:55, sjakkes wrote:

> What i’ve noticed when i was looking to the Max dsp status, that
> there was quite a difference between the % of Xp (80) and max’s
> dsp status (only 8%).

That sounds reasonable. You’re using 80% of the CPU, but are managing
to process each set of signal vectors in 8% of the vectors’ elapsed
time.

Max’s CPU usage is purely a measure of the time taken to assemble
each set of signal vectors per timeslice. It’s quite possible to eat
up a whole lot more CPU in the Max message-passing world (either at
interrupt or in the GUI thread). As an example, Jitter runs outside
the DSP cycle, and it’s quite possible to chew CPU doing video
processing.

– N.

nick rothwell — composition, systems, performance — http://
http://www.cassiel.com


June 14, 2006 | 4:30 pm

Task Manager will be correct. Do you have lots up quickly updating UI
objects? The CPU usage is only for MSP, not for control rate stuff or
Jitter. Try running your patch with almost all of the UI objects
disabled or replaced with non-graphically updating objects, like int
or float rather than number and flonum.

v a d e //

http://www.vade.info
abstrakt.vade.info


June 14, 2006 | 7:08 pm

Thanks a lot of sharing your ideas.
I was a bit worried about the cpu lost.
The application has to work on different laptops.
It is based on a fiddler~ with 10 samplers.
It sounding beautiful. So now i’m breaking some things down:
The samplers (10) are all with groove~, now i’m going to let them work with sfplay.
Delet the nice graphic sliders etc.
I’ll let you know.
Jacques


June 14, 2006 | 7:41 pm

It would be quite useful if Max could include an indicator of CPU usage
not limited to MSP.

Roald Baudoux


June 14, 2006 | 7:43 pm


June 14, 2006 | 9:06 pm

Now i’ve got 10 subpatches… so also 10 buffers and 10 grooves
It seems to me all the buffers have to load in the working memory.
Sfplay plsys from the harddisk.Loading small pieces. Am I right or is it not working like that?
Thanks for the tip,Roald.


June 14, 2006 | 9:31 pm

On 14 Jun 2006, at 20:41, Roald Baudoux wrote:

> It would be quite useful if Max could include an indicator of CPU
> usage not limited to MSP.

Perhaps, but there are already widgets provided by both OS X and
WinXP which do that…

(On the other hand, some other bits of internal Max/MSP
instrumentation – such as lengths of queues of deferred messages –
would be useful. I go through qelem overflow hell from time to time.)

– N.

nick rothwell — composition, systems, performance — http://
http://www.cassiel.com


June 15, 2006 | 2:55 am

Quite a lot of UI elements induce such a thing. Pluggozized plugins in particular using breakpoint or envi functions come to mind, aslo highlighting the text in textedit… and so on and so forth. I haven’t seen it affect audio playback at all (as adstatus cpu is just related to MSP, as mentioned), but i certainly have seen some fuck ups with control related functions.

Hopefully you understand what I mean…

binez0r


June 15, 2006 | 8:24 am

On 14-Jun-2006, at 23:06, sjakkes wrote:
> Now i’ve got 10 subpatches… so also 10 buffers and 10 grooves
> It seems to me all the buffers have to load in the working memory.

If the buffer~s have the same name, they share the same memory for
the audio data. Ditto for all of buffer~’s friends. One name, one
address.

There is a small bit of overhead for each instantiation, but nothing
to lose sleep over.

—-

About the thread’s original subject: it seems a little surprising
that people tend, almost universally, to ignore the fact that the
"CPU Utilization" display appears in the DSP Status… window.

Think about that.

DSP Status…

If you look inside the inspector, you’ll even see that the data is
generated by an object called adstatus. "AD" presumably as in analog/
digital or something.

There are a lot of cues indicating that this is talking about the CPU
Utilization required by the *DSP Engine* (not least the fact that no
information is generated when DSP is off).

Nonetheless, gazillions of people assume it’s the whole potato.
Browse the archive a bit and you’ll see what I mean.

Given the almost universal confusion about this, a request to C74 (if
anyone’s reading): any chance of a more specific label in the DSP
Status window? Maybe something like "CPU Utilization of DSP Engine"?

– P.

————– http://www.bek.no/~pcastine/Litter/ ————-
Peter Castine +—> Litter Power & Litter Bundle for Jitter
Heavy-Duty Mathematics for Everyday Use
iCE: Sequencing, Recording &
Interface Building for |home | chez nous|
Max/MSP Extremely cool |bei uns | i nostri|
http://www.dspaudio.com/ http://www.castine.de


June 15, 2006 | 12:09 pm

About threading and cpu utilization; there is something else I don’t understand: sometimes jitter framerate is at 10% of its maximum while the cpu monitors of my computer indicate there is plenty of cpu room left.

This is best illustrated by two screenshots I made:
http://www.oli.tudelft.nl/avdl1064/previews-disabled.png

http://www.oli.tudelft.nl/avdl1064/previews-enabled.png

Look at the fps counter middle left and at the cpu monitors top right.

This was the only running patch and max was the only running application. This is on a G5 quad 2.5, 1.5 Gb ram, Jitter 1.5, Max 4.5.6

Mattijs

ps. the main reason we bought this quad g5 was to push up the jitter framerate.. :/


June 15, 2006 | 12:27 pm

hoi matthijs,

i f you are using jit.pwindows that are smaller than the original
movie dimensions, make sure that you switch the jit.pwindow’s ‘use
onscreen’ attribute off.
if it’s on in all the pwindows in your example patch, it definitely
would explain the low framerate…

good luck,
jan

ps. i think graphics are for a big part processed on the GPU (not the
CPU), so you would actually neet a GPU meter ;-)


June 15, 2006 | 1:59 pm

Hey jan, thanks for your reaction

> if it’s on in all the pwindows in your example patch, it definitely
> would explain the low framerate…
> i think graphics are for a big part processed on the GPU (not the
> CPU), so you would actually neet a GPU meter ;-)

That would mean that the GPU is used to resize/interpolate the movies. In that case I understand the framerate drop. But now consider this case:

http://www.oli.tudelft.nl/avdl1064/1.png
http://www.oli.tudelft.nl/avdl1064/2.png

http://www.oli.tudelft.nl/avdl1064/3.png

In this case (screenshot 3) the GPU is not used -and- the CPU has plenty of room, but still the framerate is very low.

I hope my efforts to make my point clear are helpful ;) Pasting the patch wouldn’t be a good idea because it contains over 1000 numboxes.


June 15, 2006 | 4:16 pm

The numberboxes may be hidden, but they are still THERE, and max
still has to update them incase you open the window

try replacing the number boxes with the [int] object? Realize you
also have to deal with the scheduler issues. What kind of machine is
this on?

v a d e //

http://www.vade.info
abstrakt.vade.info=


June 15, 2006 | 5:02 pm

Hi vade,

Quote: vade wrote on Thu, 15 June 2006 18:16
—————————————————-
> The numberboxes may be hidden, but they are still THERE, and max
> still has to update them incase you open the window

I don’t think that should be necessary. Max could update the numboxes graphics when I open the window, no? At least I’d say this should have nothing to do with the GPU, causing the jitter framerate to drop. And I wonder what causes the sudden drop of CPU usage at the moment that I close the numboxes window.. appearantly hiding the numboxes has some influence somewhere.

>
> try replacing the number boxes with the [int] object? Realize you
> also have to deal with the scheduler issues.

I agree, it is definitly better not to use numboxes when you can use [int]s. But in a lot of cases I do need numboxes or other UI elements, although of course not this ridiculous amount.

> What kind of machine is this on?

G5 dual 2.5, 1.5 ram, max 4.5.6, jitter 1.5, mac os 10.4



f
June 15, 2006 | 5:38 pm

imo, specially for jitter patches one should avoid constantly updating
gui objects at all cost. numberboxes, sliders, jsui(!) etc. also the
hint and print objects. be these guis deeply hidden in subpatches or
not. all my osx patches now have a global switch for when to update
the few gui objects i’ve got left. that still requires many many gates
which makes a mess, but it does save me fps. this was not needed in
the os9 days.

also sad that i thereby can’t use the lovely pattr objects. do an
pattr-interpolation with a couple of numberboxes and framerate drops by
half. and i meant to ask earlier… did someone actually use pattr
interpolation within a big jitter performance patch? any experiences?

_f0

#|
fredrikolofsson.com klippav.org musicalfieldsforever.com
|#


June 15, 2006 | 7:24 pm

On Jun 15, 2006, at 5:09 AM, Mattijs Kneppers wrote:

>
> About threading and cpu utilization; there is something else I
> don’t understand: sometimes jitter framerate is at 10% of its
> maximum while the cpu monitors of my computer indicate there is
> plenty of cpu room left.
>
> ps. the main reason we bought this quad g5 was to push up the
> jitter framerate.. :/

Only certain tasks in Jitter dispatch across multiple CPUs. Almost
all of the pointwise operators like jit.op, jit.charmap,
jit.chromakey, jit.clip, etc. will make use of multiple processors,
and a multiprocessor machine can improve performance for these cases,
if the bottleneck does not lie elsewhere. Drawing to the screen, or
spatial operations like jit.rota on the other hand all takes place in
one thread, and will not exploit mulitple processors. In your patch,
I would recommend (as has been mentioned on the list many times
before) to turn off the jit.pwindow onscreen attribute for improved
performance for small instances of jit.pwindow as when downscaling,
Apple uses a high quality, but *slow* downsampling algorithm.

Note that you can also create multiple instances of MaxMSP and run
them side by side, in which case each process can exploit it’s own
CPU even in the single threaded case. You can communicate between
instances of MaxMSP with jit.net.send/recv, breaking up your larger
patch inot several smaller tasks…

Hope this helps.

FWIW, this sort of thing is better posted to the Jitter list

-Joshua


June 15, 2006 | 7:27 pm

On Jun 15, 2006, at 9:16 AM, vade wrote:

> The numberboxes may be hidden, but they are still THERE, and max
> still has to update them incase you open the window
>
> try replacing the number boxes with the [int] object? Realize you
> also have to deal with the scheduler issues. What kind of machine
> is this on?

Ja. Would recommend *never* using UI elements which are not
necessary. There is always a cost w/r/t the low priority queue, even
if they are not drawing. Also, don’t forget the queuethrotle an
schedthrotle settings which in the case of *many* UI elements.

Perhaps a good time to plug my article on scheduler + low priority
queue. Recommended reading for all maxers.

http://www.cycling74.com/story/2005/5/2/133649/9742

-Joshua


June 16, 2006 | 9:23 am

Thanks Joshua,

> Drawing to the screen, or
> spatial operations like jit.rota on the other hand all takes place in
> one thread, and will not exploit mulitple processors.

..as shown in the screenshots, none of the 4 processors uses more than 20%. That makes me believe the CPU is not the bottleneck.

Jan made me believe the graphics card must be the bottleneck. But if the pwindows are slow due to apple’s downsampling algorithm (which, I assume, takes place on the cpu, not on the graphics card), I am at complete loss again.

In your patch,
> I would recommend (as has been mentioned on the list many times
> before) to turn off the jit.pwindow onscreen attribute

I don’t understand why people keep on bothering me with the onscreen attribute. I know, I know, I know! This patch is only to -illustrate- my problem. Why would I ever seriously want to make a patch with 24 pwindows?

.. sorry, nothing personal ;)

> Note that you can also create multiple instances of MaxMSP and run
> them side by side, you can communicate between
> instances of MaxMSP with jit.net.send/recv

Actually I have already implemented that idea as a work-around for this problem, using two G5′s, which results in awesome framerates. Still I just can’t get my mind around the cause of this problem.

Mattijs


June 16, 2006 | 9:31 am

> Perhaps a good time to plug my article on scheduler + low priority
> queue. Recommended reading for all maxers.
>
> http://www.cycling74.com/story/2005/5/2/133649/9742
>
> -Joshua

It is a great article! I read it at least twice, carefully. It never mentions jitter and framerate though. It would be great if you added a few words about the relation between low priority queue excecution and framerates and perhaps introduce the concept of the qmetro.

I might sound a little demanding. Forgive me(.. or employ me ;) for that.

Mattijs


June 16, 2006 | 6:20 pm

On Jun 16, 2006, at 2:23 AM, Mattijs Kneppers wrote:

>
> ..as shown in the screenshots, none of the 4 processors uses more
> than 20%. That makes me believe the CPU is not the bottleneck.

Well, keep in mind the OS takes one thread and alternately runs the
single thread on 4 different processors, balancing the load. If you
total them, it should be roughly close to one processor running at
full speed.

> Jan made me believe the graphics card must be the bottleneck. But
> if the pwindows are slow due to apple’s downsampling algorithm
> (which, I assume, takes place on the cpu, not on the graphics
> card), I am at complete loss again.

This is correct. The GPU is not the bottle neck in this case. The
queuethrottle setting (or rather how the queue is serviced) is
probably the bottle neck with many UI objects.

-Joshua


June 17, 2006 | 8:38 am

Quote: jkc wrote on Fri, 16 June 2006 20:20
—————————————————-

> Well, keep in mind the OS takes one thread and alternately runs the
> single thread on 4 different processors, balancing the load. If you
> total them, it should be roughly close to one processor running at
> full speed.

Okaay! Finally a light shines through, thanks! ..so in practice the maximum capacity per thread is limited to the total of 1 processor’s capacity, even if there are 4 of them in your machine?

So do we have to be very angry at Apple now? This is probably a naive approach but if the OS is capable of alternately running a single thread on multiple processors, why wouldn’t it be able to let this thread use more than 100% if 400% is available?

> The GPU is not the bottle neck in this case. The
> queuethrottle setting (or rather how the queue is serviced) is
> probably the bottle neck with many UI objects.

UI objects and Jitter gl objects I assume? So if I understand correctly, this is because more events per servicing means less cycles are wasted during sleep. On a 4-cpu machine the low priority thread would never have to wait for the scheduler, right? Hmm.. multiprocessor programming is a whole separate issue.

Mattijs


June 19, 2006 | 11:57 am

Quote: mattijs@samplemadness.nl wrote on Sat, 17 June 2006 10:38
—————————————————-

> This is probably a naive approach but if the OS is capable of alternately running a single thread on multiple processors, why wouldn’t it be able to let this thread use more than 100% if 400% is available?

I gave it some thought: this is definitly a naive approach. The link I missed is that when the OS runs a single thread alternately on multiple processors, the process still uses only one chip at a time and this chip of course has a maximum of 100%.

The thing that misled me was the cpumeter, that shows the avarage usage. This creates the impression that the processor is constantly used 25%, while it is actually used 100%, then 0%, then 0%, then 0% (with 4 processors).

The only way to make adequate use of all processors would be to split the process in multiple threads. And as Joshua said, this has been done for some jitter objects, but not for the opengl and UI objects.

Soo.. now I understand why multiple instances of max is the only option to use your multiple processors when dealing with a lot of UI objects. Thanks again!

Mattijs


Viewing 25 posts - 1 through 25 (of 25 total)