sjakkes

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?

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


xp-cpu-utilization-not-equal-max-cpu-utilization

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.

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

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


> 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 

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 

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 

nick rothwell -- composition, systems, performance -- 

> 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.

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


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 

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.

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.

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 

It would be quite useful if Max could include an indicator of CPU usage 

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

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?

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.


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

> It would be quite useful if Max could include an indicator of CPU 

Perhaps, but there are already widgets provided by both OS X and 

(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.)

> 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.)

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.

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. 

> 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 

There is a small bit of overhead for each instantiation, but nothing 

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.

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/ 

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"?

Peter Castine +---> Litter Power & Litter Bundle for Jitter

Interface Building for |home | chez nous|

Max/MSP Extremely cool |bei uns | i nostri|

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.

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"?

--------------    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

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

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

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

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


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 

if it's on in all the pwindows in your example patch, it definitely 

ps. i think graphics are for a big part processed on the GPU (not the 

CPU), so you would actually neet a GPU meter ;-)

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...

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

> if it's on in all the pwindows in your example patch, it definitely 

> 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:

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.

> 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 ;-)

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

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.


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 

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?

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.

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

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

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

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


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 

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?

fredrikolofsson.com klippav.org musicalfieldsforever.com

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?

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


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 

> ps. the main reason we bought this quad g5 was to push up the 

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 

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

>
> 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...

> also have to deal with the scheduler issues. What kind of machine 

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.

https://cycling74.com/story/2005/5/2/133649/9742

> 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.

> 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.

> 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?

> 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.

> 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. 

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

> 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

> Perhaps a good time to plug my article on scheduler + low priority 

> queue. Recommended reading for all maxers.

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.

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

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 

Xp Cpu utilization not equal Max cpu Utilization