Hi, for me that's a really important topic, I often run into problems with slow machines not fast enough to play patches. I wonder if it is possible to calculate something like flops/ FLOating Point OPerations per object and have a list for all the pd objects. it really would be great to know the benchmarks of different hardwaresystems. marius.
You couldn't reasonably tag every object with a cost because that might change for many reasons, but you can know the load of an object or patch on your current CPU using the [cputime] object which shows a percentage scale. You can usually use it to work out the heavy offenders by "muting" DSP with [switch~] and seeing what is using up lots of cycles, but it's not really accurate benchmarking.
On Thu, 09 Nov 2006 00:34:16 -0500 Marius Schebella marius.schebella@gmail.com wrote:
Hi, for me that's a really important topic, I often run into problems with slow machines not fast enough to play patches. I wonder if it is possible to calculate something like flops/ FLOating Point OPerations per object and have a list for all the pd objects. it really would be great to know the benchmarks of different hardwaresystems. marius.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Thu, 9 Nov 2006, Marius Schebella wrote:
for me that's a really important topic, I often run into problems with slow machines not fast enough to play patches.
With video this happens often, even on fast machines, and especially with GridFlow: e.g. it's not possible to use [#fft] at 30fps unless your resolution is really small.
I wonder if it is possible to calculate something like flops/ FLOating Point OPerations per object
It wouldn't be just a count of flops; that's a rather useless unit of measure unless you know that all your flops take the same amount of time, and what you care about is the time. In Numerical Analysis, multiplications and additions are usually counted separately, because they're expected to be in two different classes of speed.
and have a list for all the pd objects.
This would have to be parametrized according to some things, like length of list arguments, block size, and possibly a lot of arguments.
Things like [fft~] does more work per sample when the blocksize is larger; i suspect that fiddle's situation is at least somewhat similar, but I haven't tested.
GEM/PDP would be harder due to framesize differences and to how the !@#$ one is supposed to measure time spent on the GPU.
I expect GridFlow to be a lot harder to measure; e.g. while pix_convolve will take time that's about the size of the picture (in pixels) times the size of the kernel (in pixels), in GridFlow you should only consider the number of nonzero entries in the kernel (!!). And then [#convolve] has special options like "op" and "fold" which aren't in any other implementation of convolution that I've seen in pd, and that can change the run time radically. And then [#convolve] supports *any* number of channels, while [pix_convolve] is up to only 4. And so on...
it really would be great to know the benchmarks of different hardwaresystems. marius.
Even though it's impossible to get a complete picture about the speed of each class, I think that it's worth trying. However, this may require some modifications to Pd. It's possible to make benchmarks in pure pd, but this would require a big mess of [timer] and [t] objects in order to prevent sent messages to be counted as part of the object's running time. If it were done in C in a similar way, it would be much faster, which would be important in order to have sufficiently accurate figures.
Even then, I fear that it wouldn't be that accurate, when lots of short operations are made. In that case, a statistical profiler would be more appropriate.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On 11/12/06, Mathieu Bouchard matju@artengine.ca wrote:
GEM/PDP would be harder due to framesize differences and to how the !@#$ one is supposed to measure time spent on the GPU.
With a profiler.
http://www.gremedy.com/ http://developer.apple.com/graphicsimaging/opengl/profiler_image.html
you are right, the big cpu eaters are graphics and fft-objects (which depend on the window size.) but for example, when I plan to use a minimac, I would like to know how many videos can I add with which resolution. I also know that with a good graphic card I can render more GEM objects than with some big cpus, but a crappy gfx card. I was also thinking of having a [dsp] object interact with the framerate within a patch. thanks, anyway for thinking about that problem! marius.
Mathieu Bouchard schrieb:
On Thu, 9 Nov 2006, Marius Schebella wrote:
for me that's a really important topic, I often run into problems with slow machines not fast enough to play patches.
With video this happens often, even on fast machines, and especially with GridFlow: e.g. it's not possible to use [#fft] at 30fps unless your resolution is really small.
I wonder if it is possible to calculate something like flops/ FLOating Point OPerations per object
It wouldn't be just a count of flops; that's a rather useless unit of measure unless you know that all your flops take the same amount of time, and what you care about is the time. In Numerical Analysis, multiplications and additions are usually counted separately, because they're expected to be in two different classes of speed.
and have a list for all the pd objects.
This would have to be parametrized according to some things, like length of list arguments, block size, and possibly a lot of arguments.
Things like [fft~] does more work per sample when the blocksize is larger; i suspect that fiddle's situation is at least somewhat similar, but I haven't tested.
GEM/PDP would be harder due to framesize differences and to how the !@#$ one is supposed to measure time spent on the GPU.
I expect GridFlow to be a lot harder to measure; e.g. while pix_convolve will take time that's about the size of the picture (in pixels) times the size of the kernel (in pixels), in GridFlow you should only consider the number of nonzero entries in the kernel (!!). And then [#convolve] has special options like "op" and "fold" which aren't in any other implementation of convolution that I've seen in pd, and that can change the run time radically. And then [#convolve] supports *any* number of channels, while [pix_convolve] is up to only 4. And so on...
it really would be great to know the benchmarks of different hardwaresystems. marius.
Even though it's impossible to get a complete picture about the speed of each class, I think that it's worth trying. However, this may require some modifications to Pd. It's possible to make benchmarks in pure pd, but this would require a big mess of [timer] and [t] objects in order to prevent sent messages to be counted as part of the object's running time. If it were done in C in a similar way, it would be much faster, which would be important in order to have sufficiently accurate figures.
Even then, I fear that it wouldn't be that accurate, when lots of short operations are made. In that case, a statistical profiler would be more appropriate.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Sun, 12 Nov 2006, Marius Schebella wrote:
but for example, when I plan to use a minimac, I would like to know how many videos can I add with which resolution. I also know that with a good graphic card I can render more GEM objects than with some big cpus, but a crappy gfx card. I was also thinking of having a [dsp] object interact with the framerate within a patch. thanks, anyway for thinking about that problem!
I need a global variable in pd, which gets maintained to contain a pointer to which object is the currently running object. This needs to intercept all message-passing and all perform-calls. All it needs is update that variable.
When I get that, I can make a profiler that is much more efficient than the one I had made for GridFlow, if I can use SIGPROF or SIGALRM or SIGVTALRM. (Windows programmers will have to figure out what the substitute is)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
-
chris clepper -
Marius Schebella -
Mathieu Bouchard -
padawan12