Hi Miller,
feeding audio into [bob~] and then going to zero will increase the CPU load by ca. 6%. Clearing the filter or adding a tiny amount of noise brings the CPU load back to its usual level immediately, so I guess it's a problem with denormals. My Pd load meter won't really show the increase, but it's clearly visibly on Process Explorer.
See my attached patch. Tried with Pd 0.47.1, Lenovo Thinkpad L440, Windows 7.
Christof
Hi all,if I understand correctly, using the [block~] and [switch~] objects to increase the blocksize for a given subpatch, means that the DSP computation for that subpatch is delayed until the moment when enough input samples have been collected, at which point the entire DSP stack for the subpatch is performed at once and the outputs are written to the output buffer.This means that the DSP load is not spread over time, rather it is concentrated in that single audio driver callback when the buffer for that subpatch happens to be ready to be processed.
Now, if what I say makes sense, then this approach has the disadvantage that the CPU load is not spread evenly across audio callbacks, eventually causing dropouts if whatever computation takes too long in that one callback, forcing you to increase the internal buffering of Pd (Delay'') to cope with this. At the same time, though, the CPU will be pretty much idle in all the other audio callbacks. If we could spread the load of the expensive, but occasional, computation (say fft) over multiple audio callbacks, then the CPU load would be more even, with no spikes and there would be no need to increase Pd's internal buffering.This would require to have the output of the fft available a few processing blocks after the one where it was started, while the current approach allows to have it immediately available. A fine tuning of the system would be required to understand how much this latency should be, and worst case it would be the number of overlap samples as set by [block~] (as in: if the system cannot process these blocks fast enough, then you should lower your requirements, as your system cannot provide the required throughput). Now this may seem a downside, but the actual overall roundtrip latency of the Pd subpatch would be <= the one currently achievable, with the added advantage that the rest of Pd could work at smaller blocksizes and without the additionalDelay'' required in the current configuration.The ultimate advantage would be to have a more responsive system, in terms of I/O roundtrip for most of the patch, except those subpatches where a longer latency is imposed by the algorithm. Think for instance of having a patch processing the live the sound of an instrument, which also uses [sigmund~] to detect its pitch to apply some adaptive effect. A low roundtrip latency could be used for the processed instrument while the latency imposed by [sigmund~] would only affect e.g.: the parameters of the effect. I see how this approach may be useful in many cases.Multi-core hardware would take extra advantage from this way of spreading the CPU usage.
I am in the situation where I hacked together a threaded version of [sigmund~] for use with libpd on Bela which works fine and I am wondering if it is worth going down the route of making threaded versions of all objects with similar requirements (which I really would not want to do) or I should rather try to create some higher-level objects (say [blockThread~] ) that perform the threading strategy mentioned above.It may be that [pd~] could probably(?) provide the solution requested, but it seems to me there is lots of overhead associated with it, and I do not see how to easily integrate it with our use of libpd.
So, probably this point has been discussed previously, I'd like to know:- are there any existing objects doing this already?- what are the pitfalls that prevented such an approach from making its way into Pd?- how can I help?
Best,Giulio
It looks like I am not very lucky in getting attention, so let me try to re-up this. Can we implement a threaded [block~] ? see details below
From: Giulio Moro <giuliomoro@yahoo.it>
To: Pd-List pd-list@lists.iem.at Sent: Sunday, 18 September 2016, 2:23 Subject: Threading in Pd/libpd
Hi all,if I understand correctly, using the [block~] and [switch~] objects to increase the blocksize for a given subpatch, means that the DSP computation for that subpatch is delayed until the moment when enough input samples have been collected, at which point the entire DSP stack for the subpatch is performed at once and the outputs are written to the output buffer.This means that the DSP load is not spread over time, rather it is concentrated in that single audio driver callback when the buffer for that subpatch happens to be ready to be processed.
Now, if what I say makes sense, then this approach has the disadvantage that the CPU load is not spread evenly across audio callbacks, eventually causing dropouts if whatever computation takes too long in that one callback, forcing you to increase the internal buffering of Pd (Delay'') to cope with this. At the same time, though, the CPU will be pretty much idle in all the other audio callbacks. If we could spread the load of the expensive, but occasional, computation (say fft) over multiple audio callbacks, then the CPU load would be more even, with no spikes and there would be no need to increase Pd's internal buffering.This would require to have the output of the fft available a few processing blocks after the one where it was started, while the current approach allows to have it immediately available. A fine tuning of the system would be required to understand how much this latency should be, and worst case it would be the number of overlap samples as set by [block~] (as in: if the system cannot process these blocks fast enough, then you should lower your requirements, as your system cannot provide the required throughput). Now this may seem a downside, but the actual overall roundtrip latency of the Pd subpatch would be not much larger than the one currently achievable (if at all larger), with the added advantage that the rest of Pd could work at smaller blocksizes, and with aDelay'' set to 0.The ultimate advantage would be to have a more responsive system, in terms of I/O roundtrip for most of the patch, except those subpatches where a longer latency is anyhow imposed by the algorithm. Think for instance of having a patch processing the live the sound of an instrument, which also uses [sigmund~] to detect its pitch to apply some adaptive effect. A low roundtrip latency could be used for the processed instrument while the latency imposed by [sigmund~] would only affect e.g.: the parameters of the effect. I see how this approach may be useful in many cases.Multi-core hardware would take extra advantage from this way of spreading the CPU usage.
I am in the situation where I hacked together a threaded version of [sigmund~] for use with libpd on Bela which works fine and I am wondering if it is worth going down the route of making threaded versions of all objects with similar requirements (which I really would not want to do) or I should rather try to create some higher-level objects (say [blockThread~] ) that perform the threading strategy mentioned above.It may be that [pd~] could probably(?) provide the solution requested, but it seems to me there is lots of overhead associated with it, and I do not see how to easily integrate it with our use of libpd.
So, probably this point has been discussed previously, I'd like to know:- are there any existing objects doing this already?- what are the pitfalls that prevented such an approach from making its way into Pd?- how can I help?
Best,Giulio
So, probably this point has been discussed previously, I'd like to know:> - are there any existing objects doing this already?
There is a creation argument to [coll] in Pd-l2ork that enables threading.
- what are the pitfalls that prevented such an approach from making its way into Pd?
The second biggest pitfall is that such an approach can easily (and subtly) break determinism. The biggest pitfall is overestimating the benefit of the performance gains to the detriment of determinism. Can you guarantee that the revisions you've implemented generate the same output as Pd Vanilla, for all cases?
- how can I help?
A good place to start might be regression tests for block~. I'd especially look at cases that use vline~ in conjunction with it, using very small delays, and make sure that you are getting the exact same samples output using your revised objects.
-Jonathan
Thanks Jonathan.
Also [readsf~] supports threading and so do [udpsend] and [udpreceive], for obvious reasons involving system calls.
Can you guarantee that the revisions you've implemented generate the same output as Pd Vanilla, for all cases?
I'd rather say it does not, in all cases. At the very least there is going to be a delay involved. But, if this brings to a different behaviour, yet still deterministic, would that be bad? After all, the above mentioned objects are not deterministic themselves, yet they are widely used, with a very high success rate. And what happens if you realize your [readsf~] glitches ? You change your code so that it sends the [open( message earlier on. As the objects I am talking about ( fft~, fiddle~, sigmund~) do not rely on system calls, I expect their behaviour to be more predictable than that of, e.g.: [readsf~]. I think I'll see if I can put together a [blockthread~] object which can do something useful.
Best, Giulio
From: Jonathan Wilkes jancsika@yahoo.com To: Giulio Moro giuliomoro@yahoo.it; Pd-List pd-list@lists.iem.at Sent: Tuesday, 27 September 2016, 18:35 Subject: Re: [PD] Threading in Pd/libpd
So, probably this point has been discussed previously, I'd like to know:
- are there any existing objects doing this already?
There is a creation argument to [coll] in Pd-l2ork that enables threading.
- what are the pitfalls that prevented such an approach from making its way into Pd?
The second biggest pitfall is that such an approach can easily (and subtly) break determinism.
The biggest pitfall is overestimating the benefit of the performance gains to the detriment of
determinism. Can you guarantee that the revisions you've implemented generate the same
output as Pd Vanilla, for all cases?
- how can I help?
A good place to start might be regression tests for block~. I'd especially look at cases that
use vline~ in conjunction with it, using very small delays, and make sure that you are getting
the exact same samples output using your revised objects.
-Jonathan
From: Giulio Moro giuliomoro@yahoo.it To: Pd-List pd-list@lists.iem.at Sent: Sunday, 18 September 2016, 2:23 Subject: Threading in Pd/libpd
Hi all, if I understand correctly, using the [block~] and [switch~] objects to increase the blocksize for a given subpatch, means that the DSP computation for that subpatch is delayed until the moment when enough input samples have been collected, at which point the entire DSP stack for the subpatch is performed at once and the outputs are written to the output buffer. This means that the DSP load is not spread over time, rather it is concentrated in that single audio driver callback when the buffer for that subpatch happens to be ready to be processed.
Now, if what I say makes sense, then this approach has the disadvantage that the CPU load is not spread evenly across audio callbacks, eventually causing dropouts if whatever computation takes too long in that one callback, forcing you to increase the internal buffering of Pd (``Delay'') to cope with this. At the same time, though, the CPU will be pretty much idle in all the other audio callbacks.
If we could spread the load of the expensive, but occasional, computation (say fft) over multiple audio callbacks, then the CPU load would be more even, with no spikes and there would be no need to increase Pd's internal buffering. This would require to have the output of the fft available a few processing blocks after the one where it was started, while the current approach allows to have it immediately available. A fine tuning of the system would be required to understand how much this latency should be, and worst case it would be the number of overlap samples as set by [block~] (as in: if the system cannot process these blocks fast enough, then you should lower your requirements, as your system cannot provide the required throughput). Now this may seem a downside, but the actual overall roundtrip latency of the Pd subpatch would be not much larger than the one currently achievable (if at all larger), with the added advantage that the rest of Pd could work at smaller blocksizes, and with a ``Delay'' set to 0. The ultimate advantage would be to have a more responsive system, in terms of I/O roundtrip for most of the patch, except those subpatches where a longer latency is anyhow imposed by the algorithm. Think for instance of having a patch processing the live the sound of an instrument, which also uses [sigmund~] to detect its pitch to apply some adaptive effect. A low roundtrip latency could be used for the processed instrument while the latency imposed by [sigmund~] would only affect e.g.: the parameters of the effect. I see how this approach may be useful in many cases. Multi-core hardware would take extra advantage from this way of spreading the CPU usage.
I am in the situation where I hacked together a threaded version of [sigmund~] for use with libpd on Bela which works fine and I am wondering if it is worth going down the route of making threaded versions of all objects with similar requirements (which I really would not want to do) or I should rather try to create some higher-level objects (say [blockThread~] ) that perform the threading strategy mentioned above. It may be that [pd~] could probably(?) provide the solution requested, but it seems to me there is lots of overhead associated with it, and I do not see how to easily integrate it with our use of libpd.
So, probably this point has been discussed previously, I'd like to know:
- are there any existing objects doing this already?
- what are the pitfalls that prevented such an approach from making its way into Pd?
- how can I help?
Best, Giulio
Thanks Jonathan.
Also [readsf~] supports threading and so do [udpsend] and [udpreceive], for obvious reasons involving system calls.
Can you guarantee that the revisions you've implemented generate the same output as Pd Vanilla, for all cases?
I'd rather say it does not, in all cases. At the very least there is going to be a delay involved. But, if this brings to a different behaviour, yet still deterministic, would that be bad? After all, the above mentioned objects are not deterministic themselves, yet they are widely used, with a very high success rate.
udpsend and udpreceive are special cases because the protocol itself rules out the kind of determinism we're discussing.
So let's focus on readsf~ instead. Suppose readsf~ is reading a sound file and outputs 3 blocks-- block 1, block 2, and block 3. The patch is outputting the sound file to the sound card, so we are listening to the sound file as Pd is running. Now, imagine this happens: 1st block: readsf~ perform routine finishes in time to output a block to the soundcard on schedule. 2nd block: perform routine takes longer to compute, and it misses the deadline set for the next block to be delivered to the soundcard. So we hear a dropout.3rd block: perform routine finishes in time to meet the deadline. Now, suppose we were debugging our patch by outputting each block of samples to the console. Here's the question, then: what gets printed for the 2nd block? Does Pd print out the samples from the sound file that missed the deadline, or does it print out 64 zeroes? -Jonathan
So having a look at the source code I'd say what would happen is that the second block prints the samples of the sound file. I guess the point you are trying to make here is that a threaded version of [fft~], the perform routing should block if the samples are not ready in time. That sounds perfectly plausible (and doable) to me.Or am I missing your point? I'd add that right now, if the system cannot compute an FFT on time and it causes dropouts, you have to solve that by increasing Pd's delay. With a threaded implementation, you could add a delay for that specific subpatch instead of the whole of Pd. Giulio
From: Jonathan Wilkes <jancsika@yahoo.com>
To: Giulio Moro giuliomoro@yahoo.it; Pd-List pd-list@lists.iem.at Sent: Wednesday, 28 September 2016, 23:00 Subject: Re: [PD] Threading in Pd/libpd
Thanks Jonathan.
Also [readsf~] supports threading and so do [udpsend] and [udpreceive], for obvious reasons involving system calls.
Can you guarantee that the revisions you've implemented generate the same output as Pd Vanilla, for all cases?
I'd rather say it does not, in all cases. At the very least there is going to be a delay involved. But, if this brings to a different behaviour, yet still deterministic, would that be bad? After all, the above mentioned objects are not deterministic themselves, yet they are widely used, with a very high success rate.
udpsend and udpreceive are special cases because the protocol itself rules out the kind of determinism we're discussing.
So let's focus on readsf~ instead. Suppose readsf~ is reading a sound file and outputs 3 blocks-- block 1, block 2, and block 3. The patch is outputting the sound file to the sound card, so we are listening to the sound file as Pd is running. Now, imagine this happens: 1st block: readsf~ perform routine finishes in time to output a block to the soundcard on schedule. 2nd block: perform routine takes longer to compute, and it misses the deadline set for the next block to be delivered to the soundcard. So we hear a dropout.3rd block: perform routine finishes in time to meet the deadline. Now, suppose we were debugging our patch by outputting each block of samples to the console. Here's the question, then: what gets printed for the 2nd block? Does Pd print out the samples from the sound file that missed the deadline, or does it print out 64 zeroes? -Jonathan
So having a look at the source code I'd say what would happen is that the second block prints the samples of the sound file.
I guess the point you are trying to make here is that a threaded version of [fft~], the perform routing should block if the samples are not ready in time. That sounds perfectly plausible (and doable) to me.> Or am I missing your point?
That's right. But on the broader scale I'm pointing out how easy it is to overlook determinism in these cases.
I'd add that right now, if the system cannot compute an FFT on time and it causes dropouts, you have to solve that by increasing Pd's delay. With a threaded implementation, you could add a delay for that specific subpatch instead of the whole of Pd.
I'm having trouble seeing how that would work in practice. Would the user specify the delay in ms/blocks as an argument?
Giulio
From: Jonathan Wilkes <jancsika@yahoo.com>
To: Giulio Moro giuliomoro@yahoo.it; Pd-List pd-list@lists.iem.at Sent: Wednesday, 28 September 2016, 23:00 Subject: Re: [PD] Threading in Pd/libpd
Thanks Jonathan.
Also [readsf~] supports threading and so do [udpsend] and [udpreceive], for obvious reasons involving system calls.
Can you guarantee that the revisions you've implemented generate the same output as Pd Vanilla, for all cases?
I'd rather say it does not, in all cases. At the very least there is going to be a delay involved. But, if this brings to a different behaviour, yet still deterministic, would that be bad? After all, the above mentioned objects are not deterministic themselves, yet they are widely used, with a very high success rate.
udpsend and udpreceive are special cases because the protocol itself rules out the kind of determinism we're discussing.
So let's focus on readsf~ instead. Suppose readsf~ is reading a sound file and outputs 3 blocks-- block 1, block 2, and block 3. The patch is outputting the sound file to the sound card, so we are listening to the sound file as Pd is running. Now, imagine this happens: 1st block: readsf~ perform routine finishes in time to output a block to the soundcard on schedule. 2nd block: perform routine takes longer to compute, and it misses the deadline set for the next block to be delivered to the soundcard. So we hear a dropout.3rd block: perform routine finishes in time to meet the deadline. Now, suppose we were debugging our patch by outputting each block of samples to the console. Here's the question, then: what gets printed for the 2nd block? Does Pd print out the samples from the sound file that missed the deadline, or does it print out 64 zeroes? -Jonathan
With a threaded implementation, you could add a delay for that specific subpatch instead of the whole of Pd.
I'm having trouble seeing how that would work in practice. Would the user specify the delay in ms/blocks as an argument?
Yes, that's the plan, by default I'd set it to the number of samples corresponding to the step determined by the specified overlap.
Giulio
From: Jonathan Wilkes jancsika@yahoo.com To: Giulio Moro giuliomoro@yahoo.it; Pd-List pd-list@lists.iem.at Sent: Thursday, 29 September 2016, 2:33 Subject: Re: [PD] Threading in Pd/libpd
So having a look at the source code I'd say what would happen is that
the second block prints the samples of the sound file.
I guess the point you are trying to make here is that a threaded version
of [fft~], the perform routing should block if the samples are not ready in
time. That sounds perfectly plausible (and doable) to me. Or am I missing your point?
That's right. But on the broader scale I'm pointing out how easy it is to overlook determinism in these cases.
I'd add that right now, if the system cannot compute an FFT on time and it
causes dropouts, you have to solve that by increasing Pd's delay. With a threaded implementation, you could add a delay for that specific subpatch instead of the whole of Pd.
I'm having trouble seeing how that would work in practice. Would the user specify the delay in ms/blocks as an argument?
Giulio
From: Jonathan Wilkes jancsika@yahoo.com To: Giulio Moro giuliomoro@yahoo.it; Pd-List pd-list@lists.iem.at Sent: Wednesday, 28 September 2016, 23:00 Subject: Re: [PD] Threading in Pd/libpd
Thanks Jonathan.
Also [readsf~] supports threading and so do [udpsend] and [udpreceive], for obvious reasons involving system calls.
Can you guarantee that the revisions you've implemented generate the same output as Pd Vanilla, for all cases?
I'd rather say it does not, in all cases. At the very least there is going to be a delay involved. But, if this brings to a different behaviour, yet still deterministic, would that be bad? After all, the above mentioned objects are not deterministic themselves, yet they are widely used, with a very high success rate.
udpsend and udpreceive are special cases because the protocol itself rules out the kind of determinism we're discussing.
So let's focus on readsf~ instead.
Suppose readsf~ is reading a sound file and outputs 3 blocks-- block 1, block 2, and block 3. The patch is outputting the sound file to the sound card, so we are
listening to the sound file as Pd is running.
Now, imagine this happens:
1st block: readsf~ perform routine finishes in time to output a block to the soundcard on schedule.
2nd block: perform routine takes longer to compute, and it misses the deadline set for the next block to be delivered to the soundcard. So we hear a dropout. 3rd block: perform routine finishes in time to meet the deadline.
Now, suppose we were debugging our patch by outputting each block of samples
to the console. Here's the question, then: what gets printed for the 2nd block?
Does Pd print out the samples from the sound file that missed the deadline, or
does it print out 64 zeroes?
-Jonathan
Yes, that's the plan, by default I'd set it to the number of samples corresponding to the step determined by the specified overlap.
What exactly gets computed in the separate thread? Is it only the revised [fft~] object? Or is it the entire subpatch? -Jonathan
The entire subpatch, which in principle can be used to wrap [fft~].My plan is to have a common way of wrapping these objects with threads so that I do not have to re-write all of them. Giulio
From: Jonathan Wilkes <jancsika@yahoo.com>
To: Giulio Moro giuliomoro@yahoo.it; Pd-List pd-list@lists.iem.at Sent: Saturday, 1 October 2016, 1:43 Subject: Re: [PD] Threading in Pd/libpd
Yes, that's the plan, by default I'd set it to the number of samples corresponding to the step determined by the specified overlap.
What exactly gets computed in the separate thread? Is it only the revised [fft~] object? Or is it the entire subpatch? -Jonathan
The entire subpatch, which in principle can be used to wrap [fft~].> My plan is to have a common way of wrapping these objects with threads so that I do not have to re-write all of them.
Would this potentially benefit any subpatch, or just ones that have a substantially larger block size than the parent patch?
Giulio
From: Jonathan Wilkes <jancsika@yahoo.com>
To: Giulio Moro giuliomoro@yahoo.it; Pd-List pd-list@lists.iem.at Sent: Saturday, 1 October 2016, 1:43 Subject: Re: [PD] Threading in Pd/libpd
Yes, that's the plan, by default I'd set it to the number of samples corresponding to the step determined by the specified overlap.
What exactly gets computed in the separate thread? Is it only the revised [fft~] object? Or is it the entire subpatch? -Jonathan
Subpatches with the same or smaller block size as the parent patch should not be threaded.Subpatches with larger blocksize should be threaded, but it's left up to the user to enable that.
From: Jonathan Wilkes <jancsika@yahoo.com>
To: Giulio Moro giuliomoro@yahoo.it; Pd-List pd-list@lists.iem.at Sent: Saturday, 1 October 2016, 6:08 Subject: Re: [PD] Threading in Pd/libpd
The entire subpatch, which in principle can be used to wrap [fft~].> My plan is to have a common way of wrapping these objects with threads so that I do not have to re-write all of them.
Would this potentially benefit any subpatch, or just ones that have a substantially larger block size than the parent patch?
Giulio
From: Jonathan Wilkes <jancsika@yahoo.com>
To: Giulio Moro giuliomoro@yahoo.it; Pd-List pd-list@lists.iem.at Sent: Saturday, 1 October 2016, 1:43 Subject: Re: [PD] Threading in Pd/libpd
Yes, that's the plan, by default I'd set it to the number of samples corresponding to the step determined by the specified overlap.
What exactly gets computed in the separate thread? Is it only the revised [fft~] object? Or is it the entire subpatch? -Jonathan
Subpatches with the same or smaller block size as the parent patch should not be threaded.
Subpatches with larger blocksize should be threaded, but it's left up to the user to enable that.
Do you have to revise every single signal object in order for this to work? -Jonathan
Just the opposite, the idea is actually to avoid revising all existing objects, that's why I'd rather want to create variations on [block~] / [switch~] that support threading for all of the objects in the subpatch. Giulio
From: Jonathan Wilkes jancsika@yahoo.com To: Giulio Moro giuliomoro@yahoo.it; Pd-List pd-list@lists.iem.at Sent: Monday, 3 October 2016, 16:56 Subject: Re: [PD] Threading in Pd/libpd
Subpatches with the same or smaller block size as the parent patch should not be threaded.
Subpatches with larger blocksize should be threaded, but it's left up to the user to enable that.
Do you have to revise every single signal object in order for this to work? -Jonathan
Hmmm... I compiled [bob~] myself with MinGW and pd-lib-builder and I noticed two things:
- the CPU rise is gone
- it needs only half the CPU. I put 20 [bob~] objects in a switched subpatch and measured the CPU load. The DLL which comes with the Windows binaries needs 15%, while my own DLL needs only 7%! That's quite a deal...
Christof
PS: I attached the DLL in case you wanna try it yourself.
Gesendet: Samstag, 17. September 2016 um 22:58 Uhr Von: "Christof Ressi" christof.ressi@gmx.at An: pd-list@iem.at, "Miller Puckette" msp@ucsd.edu Betreff: [PD] [bob~] denormals issue?
Hi Miller,
feeding audio into [bob~] and then going to zero will increase the CPU load by ca. 6%. Clearing the filter or adding a tiny amount of noise brings the CPU load back to its usual level immediately, so I guess it's a problem with denormals. My Pd load meter won't really show the increase, but it's clearly visibly on Process Explorer.
See my attached patch. Tried with Pd 0.47.1, Lenovo Thinkpad L440, Windows 7.
Christof_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Hi Christof,
Makefile.pdlibbuilder passes flags '-march=pentium4 -msse -msse2 -mfpmath=sse' for optimization to the compiler on Windows. You could try compiling without (some of) these flags to see if they are responsible for the different behavior. Makefile-defined optimization flags can be overriden with argument CFLAGS given on command line.
The effect of optimization flags on denormals varies per processor type, unfortunately. When we had denormals on Raspberry Pi ARMv6 they wouldn't go away no matter what flags, is what I remember. Even if your test reveals a beneficial effect from compiler flags, it is better when denormals are detected and flushed in the C code. Anyway, it is still interesting to know what makes the difference.
Katja
On Wed, Sep 21, 2016 at 12:32 AM, Christof Ressi christof.ressi@gmx.at wrote:
Hmmm... I compiled [bob~] myself with MinGW and pd-lib-builder and I noticed two things:
- the CPU rise is gone
- it needs only half the CPU. I put 20 [bob~] objects in a switched subpatch and measured the CPU load. The DLL which comes with the Windows binaries needs 15%, while my own DLL needs only 7%! That's quite a deal...
Christof
PS: I attached the DLL in case you wanna try it yourself.
Gesendet: Samstag, 17. September 2016 um 22:58 Uhr Von: "Christof Ressi" christof.ressi@gmx.at An: pd-list@iem.at, "Miller Puckette" msp@ucsd.edu Betreff: [PD] [bob~] denormals issue?
Hi Miller,
feeding audio into [bob~] and then going to zero will increase the CPU load by ca. 6%. Clearing the filter or adding a tiny amount of noise brings the CPU load back to its usual level immediately, so I guess it's a problem with denormals. My Pd load meter won't really show the increase, but it's clearly visibly on Process Explorer.
See my attached patch. Tried with Pd 0.47.1, Lenovo Thinkpad L440, Windows 7.
Christof_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Hi Katja,
Even if your test reveals a beneficial effect from compiler flags, it is better when denormals are detected and flushed in the C code.
definitely! Maybe using the PD_BIGORSMALL macro on each filter state at the end of the DSP routine does the trick, just like in all the other recursive filters in Pd.
Von: katja katjavetter@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: pd-list pd-list@iem.at, "Miller Puckette" msp@ucsd.edu Betreff: Re: [PD] [bob~] denormals issue?
Hi Christof,
Makefile.pdlibbuilder passes flags '-march=pentium4 -msse -msse2 -mfpmath=sse' for optimization to the compiler on Windows. You could try compiling without (some of) these flags to see if they are responsible for the different behavior. Makefile-defined optimization flags can be overriden with argument CFLAGS given on command line.
The effect of optimization flags on denormals varies per processor type, unfortunately. When we had denormals on Raspberry Pi ARMv6 they wouldn't go away no matter what flags, is what I remember. Even if your test reveals a beneficial effect from compiler flags, it is better when denormals are detected and flushed in the C code. Anyway, it is still interesting to know what makes the difference.
Katja
On Wed, Sep 21, 2016 at 12:32 AM, Christof Ressi christof.ressi@gmx.at wrote:
Hmmm... I compiled [bob~] myself with MinGW and pd-lib-builder and I noticed two things:
- the CPU rise is gone
- it needs only half the CPU. I put 20 [bob~] objects in a switched subpatch and measured the CPU load. The DLL which comes with the Windows binaries needs 15%, while my own DLL needs only 7%! That's quite a deal...
Christof
PS: I attached the DLL in case you wanna try it yourself.
Gesendet: Samstag, 17. September 2016 um 22:58 Uhr Von: "Christof Ressi" christof.ressi@gmx.at An: pd-list@iem.at, "Miller Puckette" msp@ucsd.edu Betreff: [PD] [bob~] denormals issue?
Hi Miller,
feeding audio into [bob~] and then going to zero will increase the CPU load by ca. 6%. Clearing the filter or adding a tiny amount of noise brings the CPU load back to its usual level immediately, so I guess it's a problem with denormals. My Pd load meter won't really show the increase, but it's clearly visibly on Process Explorer.
See my attached patch. Tried with Pd 0.47.1, Lenovo Thinkpad L440, Windows 7.
Christof_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
I'm curious to know if the flags do flush denormals on your processor. Forgot to mention that '-O3 -ffast-math' are also set, platform-independent. So if you have a chance to try which flag does something... It's just curiosity.
On Wed, Sep 21, 2016 at 10:34 PM, Christof Ressi christof.ressi@gmx.at wrote:
Hi Katja,
Even if your test reveals a beneficial effect from compiler flags, it is better when denormals are detected and flushed in the C code.
definitely! Maybe using the PD_BIGORSMALL macro on each filter state at the end of the DSP routine does the trick, just like in all the other recursive filters in Pd.
Von: katja katjavetter@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: pd-list pd-list@iem.at, "Miller Puckette" msp@ucsd.edu Betreff: Re: [PD] [bob~] denormals issue?
Hi Christof,
Makefile.pdlibbuilder passes flags '-march=pentium4 -msse -msse2 -mfpmath=sse' for optimization to the compiler on Windows. You could try compiling without (some of) these flags to see if they are responsible for the different behavior. Makefile-defined optimization flags can be overriden with argument CFLAGS given on command line.
The effect of optimization flags on denormals varies per processor type, unfortunately. When we had denormals on Raspberry Pi ARMv6 they wouldn't go away no matter what flags, is what I remember. Even if your test reveals a beneficial effect from compiler flags, it is better when denormals are detected and flushed in the C code. Anyway, it is still interesting to know what makes the difference.
Katja
On Wed, Sep 21, 2016 at 12:32 AM, Christof Ressi christof.ressi@gmx.at wrote:
Hmmm... I compiled [bob~] myself with MinGW and pd-lib-builder and I noticed two things:
- the CPU rise is gone
- it needs only half the CPU. I put 20 [bob~] objects in a switched subpatch and measured the CPU load. The DLL which comes with the Windows binaries needs 15%, while my own DLL needs only 7%! That's quite a deal...
Christof
PS: I attached the DLL in case you wanna try it yourself.
Gesendet: Samstag, 17. September 2016 um 22:58 Uhr Von: "Christof Ressi" christof.ressi@gmx.at An: pd-list@iem.at, "Miller Puckette" msp@ucsd.edu Betreff: [PD] [bob~] denormals issue?
Hi Miller,
feeding audio into [bob~] and then going to zero will increase the CPU load by ca. 6%. Clearing the filter or adding a tiny amount of noise brings the CPU load back to its usual level immediately, so I guess it's a problem with denormals. My Pd load meter won't really show the increase, but it's clearly visibly on Process Explorer.
See my attached patch. Tried with Pd 0.47.1, Lenovo Thinkpad L440, Windows 7.
Christof_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
the SSE optimizations don't seem to matter at all. skipping -ffast-math gives a slight overall CPU rise, while skipping -O3 gives me huge CPU rise (20 bob~ filters are already to much for one core). Even when skipping all of those flags, the denormals issue is still not present.
Maybe it has something to do with the compiler?
Gesendet: Mittwoch, 21. September 2016 um 22:47 Uhr Von: katja katjavetter@gmail.com An: "Christof Ressi" christof.ressi@gmx.at, "pd-list@lists.iem.at" pd-list@lists.iem.at Betreff: Re: Re: [PD] [bob~] denormals issue?
I'm curious to know if the flags do flush denormals on your processor. Forgot to mention that '-O3 -ffast-math' are also set, platform-independent. So if you have a chance to try which flag does something... It's just curiosity.
On Wed, Sep 21, 2016 at 10:34 PM, Christof Ressi christof.ressi@gmx.at wrote:
Hi Katja,
Even if your test reveals a beneficial effect from compiler flags, it is better when denormals are detected and flushed in the C code.
definitely! Maybe using the PD_BIGORSMALL macro on each filter state at the end of the DSP routine does the trick, just like in all the other recursive filters in Pd.
Von: katja katjavetter@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: pd-list pd-list@iem.at, "Miller Puckette" msp@ucsd.edu Betreff: Re: [PD] [bob~] denormals issue?
Hi Christof,
Makefile.pdlibbuilder passes flags '-march=pentium4 -msse -msse2 -mfpmath=sse' for optimization to the compiler on Windows. You could try compiling without (some of) these flags to see if they are responsible for the different behavior. Makefile-defined optimization flags can be overriden with argument CFLAGS given on command line.
The effect of optimization flags on denormals varies per processor type, unfortunately. When we had denormals on Raspberry Pi ARMv6 they wouldn't go away no matter what flags, is what I remember. Even if your test reveals a beneficial effect from compiler flags, it is better when denormals are detected and flushed in the C code. Anyway, it is still interesting to know what makes the difference.
Katja
On Wed, Sep 21, 2016 at 12:32 AM, Christof Ressi christof.ressi@gmx.at wrote:
Hmmm... I compiled [bob~] myself with MinGW and pd-lib-builder and I noticed two things:
- the CPU rise is gone
- it needs only half the CPU. I put 20 [bob~] objects in a switched subpatch and measured the CPU load. The DLL which comes with the Windows binaries needs 15%, while my own DLL needs only 7%! That's quite a deal...
Christof
PS: I attached the DLL in case you wanna try it yourself.
Gesendet: Samstag, 17. September 2016 um 22:58 Uhr Von: "Christof Ressi" christof.ressi@gmx.at An: pd-list@iem.at, "Miller Puckette" msp@ucsd.edu Betreff: [PD] [bob~] denormals issue?
Hi Miller,
feeding audio into [bob~] and then going to zero will increase the CPU load by ca. 6%. Clearing the filter or adding a tiny amount of noise brings the CPU load back to its usual level immediately, so I guess it's a problem with denormals. My Pd load meter won't really show the increase, but it's clearly visibly on Process Explorer.
See my attached patch. Tried with Pd 0.47.1, Lenovo Thinkpad L440, Windows 7.
Christof_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Without -O flags you get debug-level and all function inlining is disabled, depending on the code it can make a huge difference indeed. But Pd is probably compiled with at least -O2. So the flags don't make much difference. The compiler? Doesn't Miller compile with MinGW nowadays, I don't know. MinGW brings its own standard C libs, which may implement math functions differently than MS. But regarding denormals I guess they both respect the IEEE 754 standard.
You can check if you really have subnormals using attached patch denorm-test.pd you. The patch tests lop~, change it to bob~.
On Wed, Sep 21, 2016 at 11:18 PM, Christof Ressi christof.ressi@gmx.at wrote:
the SSE optimizations don't seem to matter at all. skipping -ffast-math gives a slight overall CPU rise, while skipping -O3 gives me huge CPU rise (20 bob~ filters are already to much for one core). Even when skipping all of those flags, the denormals issue is still not present.
Maybe it has something to do with the compiler?
Gesendet: Mittwoch, 21. September 2016 um 22:47 Uhr Von: katja katjavetter@gmail.com An: "Christof Ressi" christof.ressi@gmx.at, "pd-list@lists.iem.at" pd-list@lists.iem.at Betreff: Re: Re: [PD] [bob~] denormals issue?
I'm curious to know if the flags do flush denormals on your processor. Forgot to mention that '-O3 -ffast-math' are also set, platform-independent. So if you have a chance to try which flag does something... It's just curiosity.
On Wed, Sep 21, 2016 at 10:34 PM, Christof Ressi christof.ressi@gmx.at wrote:
Hi Katja,
Even if your test reveals a beneficial effect from compiler flags, it is better when denormals are detected and flushed in the C code.
definitely! Maybe using the PD_BIGORSMALL macro on each filter state at the end of the DSP routine does the trick, just like in all the other recursive filters in Pd.
Von: katja katjavetter@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: pd-list pd-list@iem.at, "Miller Puckette" msp@ucsd.edu Betreff: Re: [PD] [bob~] denormals issue?
Hi Christof,
Makefile.pdlibbuilder passes flags '-march=pentium4 -msse -msse2 -mfpmath=sse' for optimization to the compiler on Windows. You could try compiling without (some of) these flags to see if they are responsible for the different behavior. Makefile-defined optimization flags can be overriden with argument CFLAGS given on command line.
The effect of optimization flags on denormals varies per processor type, unfortunately. When we had denormals on Raspberry Pi ARMv6 they wouldn't go away no matter what flags, is what I remember. Even if your test reveals a beneficial effect from compiler flags, it is better when denormals are detected and flushed in the C code. Anyway, it is still interesting to know what makes the difference.
Katja
On Wed, Sep 21, 2016 at 12:32 AM, Christof Ressi christof.ressi@gmx.at wrote:
Hmmm... I compiled [bob~] myself with MinGW and pd-lib-builder and I noticed two things:
- the CPU rise is gone
- it needs only half the CPU. I put 20 [bob~] objects in a switched subpatch and measured the CPU load. The DLL which comes with the Windows binaries needs 15%, while my own DLL needs only 7%! That's quite a deal...
Christof
PS: I attached the DLL in case you wanna try it yourself.
Gesendet: Samstag, 17. September 2016 um 22:58 Uhr Von: "Christof Ressi" christof.ressi@gmx.at An: pd-list@iem.at, "Miller Puckette" msp@ucsd.edu Betreff: [PD] [bob~] denormals issue?
Hi Miller,
feeding audio into [bob~] and then going to zero will increase the CPU load by ca. 6%. Clearing the filter or adding a tiny amount of noise brings the CPU load back to its usual level immediately, so I guess it's a problem with denormals. My Pd load meter won't really show the increase, but it's clearly visibly on Process Explorer.
See my attached patch. Tried with Pd 0.47.1, Lenovo Thinkpad L440, Windows 7.
Christof_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
At the moment I'm compiling Pd using mingw but having to rely on Microsoft Visual C for "pd.lib" (apparently linker information) and all the eterns in "extra" - I never could get that part to work in mingw. I think it's time I tried again to get everything moved over to mingw, especially since it's apparently generating much faster code.
Probably wont be able to do and test this till I get back to a windows machine, perhaps January...
M
On Wed, Sep 21, 2016 at 11:47:14PM +0200, katja wrote:
Without -O flags you get debug-level and all function inlining is disabled, depending on the code it can make a huge difference indeed. But Pd is probably compiled with at least -O2. So the flags don't make much difference. The compiler? Doesn't Miller compile with MinGW nowadays, I don't know. MinGW brings its own standard C libs, which may implement math functions differently than MS. But regarding denormals I guess they both respect the IEEE 754 standard.
You can check if you really have subnormals using attached patch denorm-test.pd you. The patch tests lop~, change it to bob~.
On Wed, Sep 21, 2016 at 11:18 PM, Christof Ressi christof.ressi@gmx.at wrote:
the SSE optimizations don't seem to matter at all. skipping -ffast-math gives a slight overall CPU rise, while skipping -O3 gives me huge CPU rise (20 bob~ filters are already to much for one core). Even when skipping all of those flags, the denormals issue is still not present.
Maybe it has something to do with the compiler?
Gesendet: Mittwoch, 21. September 2016 um 22:47 Uhr Von: katja katjavetter@gmail.com An: "Christof Ressi" christof.ressi@gmx.at, "pd-list@lists.iem.at" pd-list@lists.iem.at Betreff: Re: Re: [PD] [bob~] denormals issue?
I'm curious to know if the flags do flush denormals on your processor. Forgot to mention that '-O3 -ffast-math' are also set, platform-independent. So if you have a chance to try which flag does something... It's just curiosity.
On Wed, Sep 21, 2016 at 10:34 PM, Christof Ressi christof.ressi@gmx.at wrote:
Hi Katja,
Even if your test reveals a beneficial effect from compiler flags, it is better when denormals are detected and flushed in the C code.
definitely! Maybe using the PD_BIGORSMALL macro on each filter state at the end of the DSP routine does the trick, just like in all the other recursive filters in Pd.
Von: katja katjavetter@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: pd-list pd-list@iem.at, "Miller Puckette" msp@ucsd.edu Betreff: Re: [PD] [bob~] denormals issue?
Hi Christof,
Makefile.pdlibbuilder passes flags '-march=pentium4 -msse -msse2 -mfpmath=sse' for optimization to the compiler on Windows. You could try compiling without (some of) these flags to see if they are responsible for the different behavior. Makefile-defined optimization flags can be overriden with argument CFLAGS given on command line.
The effect of optimization flags on denormals varies per processor type, unfortunately. When we had denormals on Raspberry Pi ARMv6 they wouldn't go away no matter what flags, is what I remember. Even if your test reveals a beneficial effect from compiler flags, it is better when denormals are detected and flushed in the C code. Anyway, it is still interesting to know what makes the difference.
Katja
On Wed, Sep 21, 2016 at 12:32 AM, Christof Ressi christof.ressi@gmx.at wrote:
Hmmm... I compiled [bob~] myself with MinGW and pd-lib-builder and I noticed two things:
- the CPU rise is gone
- it needs only half the CPU. I put 20 [bob~] objects in a switched subpatch and measured the CPU load. The DLL which comes with the Windows binaries needs 15%, while my own DLL needs only 7%! That's quite a deal...
Christof
PS: I attached the DLL in case you wanna try it yourself.
> Gesendet: Samstag, 17. September 2016 um 22:58 Uhr > Von: "Christof Ressi" christof.ressi@gmx.at > An: pd-list@iem.at, "Miller Puckette" msp@ucsd.edu > Betreff: [PD] [bob~] denormals issue? > > Hi Miller, > > feeding audio into [bob~] and then going to zero will increase the CPU load by ca. 6%. Clearing the filter or adding a tiny amount of noise brings the CPU load back to its usual level immediately, so I guess it's a problem with denormals. > My Pd load meter won't really show the increase, but it's clearly visibly on Process Explorer. > > See my attached patch. Tried with Pd 0.47.1, Lenovo Thinkpad L440, Windows 7. > > Christof_______________________________________________ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list > _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
#N canvas 129 301 620 382 10; #X symbolatom 18 351 72 0 0 0 - - -; #X obj 18 323 makefilename %.70f; #N canvas 0 50 190 245 nan 0; #X obj 45 17 inlet; #X obj 46 173 outlet; #X obj 45 74 t b f; #X msg 46 96 2; #X obj 46 143 * 0; #X obj 46 118 pow 1024; #X msg 45 49 1024; #X connect 0 0 6 0; #X connect 2 0 3 0; #X connect 2 1 5 1; #X connect 3 0 5 0; #X connect 4 0 1 0; #X connect 5 0 4 0; #X connect 6 0 2 0; #X restore 18 44 pd nan; #X obj 18 20 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #N canvas 0 50 168 259 inf 0; #X obj 45 17 inlet; #X obj 46 173 outlet; #X obj 45 74 t b f; #X msg 46 96 2; #X obj 46 118 pow 1024; #X msg 45 49 1024; #X connect 0 0 5 0; #X connect 2 0 3 0; #X connect 2 1 4 1; #X connect 3 0 4 0; #X connect 4 0 1 0; #X connect 5 0 2 0; #X restore 71 44 pd inf; #X obj 71 20 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X floatatom 18 181 8 0 0 0 - - -; #X msg 72 116 1; #X msg 72 86 0; #X msg 106 202 ; pd dsp 1; #X msg 106 241 ; pd dsp 0; #X obj 106 179 loadbang; #N canvas 0 50 200 224 unsig~ 0; #X obj 32 40 inlet~; #X obj 32 122 snapshot~; #X obj 61 89 metro 200; #X obj 61 62 tgl 15 1 empty empty empty 17 7 0 10 -262144 -1 -1 1 1 ; #X obj 32 153 outlet; #X connect 0 0 1 0; #X connect 1 0 4 0; #X connect 2 0 1 0; #X connect 3 0 2 0; #X restore 18 266 pd unsig~; #X floatatom 18 296 17 0 0 0 - - -; #X text 183 133 Small floats which can't be expressed with the bits of the datatype are also denormal , more specifically: subnormal. Computations with subnormal numbers are still possible , but very CPU intensive. Test: click 1 first , then 0 to see how small the numbers become. If all is OK , numbers smaller than ~1e-19 are flushed to zero. If not OK , numbers smaller than 1e-39 are seen. These are subnormals. Check CPU load difference. It is always possible to recover from subnormals by sending a normal number (like 1) in.; #X text 184 320 Katja Vetter Jan 2013; #X obj 18 216 lop~ 1; #X text 183 261 IIR filters have internal feedback delay lines , therefore objects like [lop~] , [hip~] and [biquad~] must be protected against denormals.; #X text 183 18 NaN and inf are denormal numbers. When inf or nan starts recirculating in a feedback delay line , the object can't do further calculations , even if the input goes back to normal. Therefore Pd must avoid writing nan or inf into a feedback delay line. Test: click nan or inf first , and 1 thereafter. If all is OK , the output returns to normal. If not OK , inf or nan will stay at the output and the patch must be reloaded to recover.; #X connect 1 0 0 0; #X connect 2 0 6 0; #X connect 3 0 2 0; #X connect 4 0 6 0; #X connect 5 0 4 0; #X connect 6 0 16 0; #X connect 7 0 6 0; #X connect 8 0 6 0; #X connect 11 0 9 0; #X connect 12 0 13 0; #X connect 13 0 1 0; #X connect 16 0 12 0;
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
I tried your patch with the [bob~] object shipped with the Windows binaries. I clearly get subnormals! It's actually no wonder because there isn't any protection against subnormals in the code (at least I couldn't spot it). But the weird thing is: the [bob~] I compiled myself would also show subnormals in your patch but the CPU load is not affected...
Gesendet: Mittwoch, 21. September 2016 um 23:47 Uhr Von: katja katjavetter@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: "pd-list@lists.iem.at" pd-list@lists.iem.at Betreff: Re: Re: Re: [PD] [bob~] denormals issue?
Without -O flags you get debug-level and all function inlining is disabled, depending on the code it can make a huge difference indeed. But Pd is probably compiled with at least -O2. So the flags don't make much difference. The compiler? Doesn't Miller compile with MinGW nowadays, I don't know. MinGW brings its own standard C libs, which may implement math functions differently than MS. But regarding denormals I guess they both respect the IEEE 754 standard.
You can check if you really have subnormals using attached patch denorm-test.pd you. The patch tests lop~, change it to bob~.
On Wed, Sep 21, 2016 at 11:18 PM, Christof Ressi christof.ressi@gmx.at wrote:
the SSE optimizations don't seem to matter at all. skipping -ffast-math gives a slight overall CPU rise, while skipping -O3 gives me huge CPU rise (20 bob~ filters are already to much for one core). Even when skipping all of those flags, the denormals issue is still not present.
Maybe it has something to do with the compiler?
Gesendet: Mittwoch, 21. September 2016 um 22:47 Uhr Von: katja katjavetter@gmail.com An: "Christof Ressi" christof.ressi@gmx.at, "pd-list@lists.iem.at" pd-list@lists.iem.at Betreff: Re: Re: [PD] [bob~] denormals issue?
I'm curious to know if the flags do flush denormals on your processor. Forgot to mention that '-O3 -ffast-math' are also set, platform-independent. So if you have a chance to try which flag does something... It's just curiosity.
On Wed, Sep 21, 2016 at 10:34 PM, Christof Ressi christof.ressi@gmx.at wrote:
Hi Katja,
Even if your test reveals a beneficial effect from compiler flags, it is better when denormals are detected and flushed in the C code.
definitely! Maybe using the PD_BIGORSMALL macro on each filter state at the end of the DSP routine does the trick, just like in all the other recursive filters in Pd.
Von: katja katjavetter@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: pd-list pd-list@iem.at, "Miller Puckette" msp@ucsd.edu Betreff: Re: [PD] [bob~] denormals issue?
Hi Christof,
Makefile.pdlibbuilder passes flags '-march=pentium4 -msse -msse2 -mfpmath=sse' for optimization to the compiler on Windows. You could try compiling without (some of) these flags to see if they are responsible for the different behavior. Makefile-defined optimization flags can be overriden with argument CFLAGS given on command line.
The effect of optimization flags on denormals varies per processor type, unfortunately. When we had denormals on Raspberry Pi ARMv6 they wouldn't go away no matter what flags, is what I remember. Even if your test reveals a beneficial effect from compiler flags, it is better when denormals are detected and flushed in the C code. Anyway, it is still interesting to know what makes the difference.
Katja
On Wed, Sep 21, 2016 at 12:32 AM, Christof Ressi christof.ressi@gmx.at wrote:
Hmmm... I compiled [bob~] myself with MinGW and pd-lib-builder and I noticed two things:
- the CPU rise is gone
- it needs only half the CPU. I put 20 [bob~] objects in a switched subpatch and measured the CPU load. The DLL which comes with the Windows binaries needs 15%, while my own DLL needs only 7%! That's quite a deal...
Christof
PS: I attached the DLL in case you wanna try it yourself.
> Gesendet: Samstag, 17. September 2016 um 22:58 Uhr > Von: "Christof Ressi" christof.ressi@gmx.at > An: pd-list@iem.at, "Miller Puckette" msp@ucsd.edu > Betreff: [PD] [bob~] denormals issue? > > Hi Miller, > > feeding audio into [bob~] and then going to zero will increase the CPU load by ca. 6%. Clearing the filter or adding a tiny amount of noise brings the CPU load back to its usual level immediately, so I guess it's a problem with denormals. > My Pd load meter won't really show the increase, but it's clearly visibly on Process Explorer. > > See my attached patch. Tried with Pd 0.47.1, Lenovo Thinkpad L440, Windows 7. > > Christof_______________________________________________ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list > _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Yeah, I want to find out more about that :)
M
On Thu, Sep 22, 2016 at 12:01:31AM +0200, Christof Ressi wrote:
I tried your patch with the [bob~] object shipped with the Windows binaries. I clearly get subnormals! It's actually no wonder because there isn't any protection against subnormals in the code (at least I couldn't spot it). But the weird thing is: the [bob~] I compiled myself would also show subnormals in your patch but the CPU load is not affected...
Gesendet: Mittwoch, 21. September 2016 um 23:47 Uhr Von: katja katjavetter@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: "pd-list@lists.iem.at" pd-list@lists.iem.at Betreff: Re: Re: Re: [PD] [bob~] denormals issue?
Without -O flags you get debug-level and all function inlining is disabled, depending on the code it can make a huge difference indeed. But Pd is probably compiled with at least -O2. So the flags don't make much difference. The compiler? Doesn't Miller compile with MinGW nowadays, I don't know. MinGW brings its own standard C libs, which may implement math functions differently than MS. But regarding denormals I guess they both respect the IEEE 754 standard.
You can check if you really have subnormals using attached patch denorm-test.pd you. The patch tests lop~, change it to bob~.
On Wed, Sep 21, 2016 at 11:18 PM, Christof Ressi christof.ressi@gmx.at wrote:
the SSE optimizations don't seem to matter at all. skipping -ffast-math gives a slight overall CPU rise, while skipping -O3 gives me huge CPU rise (20 bob~ filters are already to much for one core). Even when skipping all of those flags, the denormals issue is still not present.
Maybe it has something to do with the compiler?
Gesendet: Mittwoch, 21. September 2016 um 22:47 Uhr Von: katja katjavetter@gmail.com An: "Christof Ressi" christof.ressi@gmx.at, "pd-list@lists.iem.at" pd-list@lists.iem.at Betreff: Re: Re: [PD] [bob~] denormals issue?
I'm curious to know if the flags do flush denormals on your processor. Forgot to mention that '-O3 -ffast-math' are also set, platform-independent. So if you have a chance to try which flag does something... It's just curiosity.
On Wed, Sep 21, 2016 at 10:34 PM, Christof Ressi christof.ressi@gmx.at wrote:
Hi Katja,
Even if your test reveals a beneficial effect from compiler flags, it is better when denormals are detected and flushed in the C code.
definitely! Maybe using the PD_BIGORSMALL macro on each filter state at the end of the DSP routine does the trick, just like in all the other recursive filters in Pd.
Von: katja katjavetter@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: pd-list pd-list@iem.at, "Miller Puckette" msp@ucsd.edu Betreff: Re: [PD] [bob~] denormals issue?
Hi Christof,
Makefile.pdlibbuilder passes flags '-march=pentium4 -msse -msse2 -mfpmath=sse' for optimization to the compiler on Windows. You could try compiling without (some of) these flags to see if they are responsible for the different behavior. Makefile-defined optimization flags can be overriden with argument CFLAGS given on command line.
The effect of optimization flags on denormals varies per processor type, unfortunately. When we had denormals on Raspberry Pi ARMv6 they wouldn't go away no matter what flags, is what I remember. Even if your test reveals a beneficial effect from compiler flags, it is better when denormals are detected and flushed in the C code. Anyway, it is still interesting to know what makes the difference.
Katja
On Wed, Sep 21, 2016 at 12:32 AM, Christof Ressi christof.ressi@gmx.at wrote: > Hmmm... I compiled [bob~] myself with MinGW and pd-lib-builder and I noticed two things: > 1) the CPU rise is gone > 2) it needs only half the CPU. I put 20 [bob~] objects in a switched subpatch and measured the CPU load. The DLL which comes with the Windows binaries needs 15%, while my own DLL needs only 7%! That's quite a deal... > > Christof > > PS: I attached the DLL in case you wanna try it yourself. > > >> Gesendet: Samstag, 17. September 2016 um 22:58 Uhr >> Von: "Christof Ressi" christof.ressi@gmx.at >> An: pd-list@iem.at, "Miller Puckette" msp@ucsd.edu >> Betreff: [PD] [bob~] denormals issue? >> >> Hi Miller, >> >> feeding audio into [bob~] and then going to zero will increase the CPU load by ca. 6%. Clearing the filter or adding a tiny amount of noise brings the CPU load back to its usual level immediately, so I guess it's a problem with denormals. >> My Pd load meter won't really show the increase, but it's clearly visibly on Process Explorer. >> >> See my attached patch. Tried with Pd 0.47.1, Lenovo Thinkpad L440, Windows 7. >> >> Christof_______________________________________________ >> Pd-list@lists.iem.at mailing list >> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list >> > _______________________________________________ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list >
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Linux i386 bob~ produces subnormals as well and very high cpu load. It is not the slowly decaying signal that other filters tend to give, but a quick decay to a fixed small number.
It's weird indeed when subnormals cause different CPU load depending on how they are compiled. Since MinGW is a gcc port I would think it uses the same math implementation which produces such high CPU load for bob~ subnormals on my system.
On Thu, Sep 22, 2016 at 12:01 AM, Christof Ressi christof.ressi@gmx.at wrote:
I tried your patch with the [bob~] object shipped with the Windows binaries. I clearly get subnormals! It's actually no wonder because there isn't any protection against subnormals in the code (at least I couldn't spot it). But the weird thing is: the [bob~] I compiled myself would also show subnormals in your patch but the CPU load is not affected...
Gesendet: Mittwoch, 21. September 2016 um 23:47 Uhr Von: katja katjavetter@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: "pd-list@lists.iem.at" pd-list@lists.iem.at Betreff: Re: Re: Re: [PD] [bob~] denormals issue?
Without -O flags you get debug-level and all function inlining is disabled, depending on the code it can make a huge difference indeed. But Pd is probably compiled with at least -O2. So the flags don't make much difference. The compiler? Doesn't Miller compile with MinGW nowadays, I don't know. MinGW brings its own standard C libs, which may implement math functions differently than MS. But regarding denormals I guess they both respect the IEEE 754 standard.
You can check if you really have subnormals using attached patch denorm-test.pd you. The patch tests lop~, change it to bob~.
On Wed, Sep 21, 2016 at 11:18 PM, Christof Ressi christof.ressi@gmx.at wrote:
the SSE optimizations don't seem to matter at all. skipping -ffast-math gives a slight overall CPU rise, while skipping -O3 gives me huge CPU rise (20 bob~ filters are already to much for one core). Even when skipping all of those flags, the denormals issue is still not present.
Maybe it has something to do with the compiler?
Gesendet: Mittwoch, 21. September 2016 um 22:47 Uhr Von: katja katjavetter@gmail.com An: "Christof Ressi" christof.ressi@gmx.at, "pd-list@lists.iem.at" pd-list@lists.iem.at Betreff: Re: Re: [PD] [bob~] denormals issue?
I'm curious to know if the flags do flush denormals on your processor. Forgot to mention that '-O3 -ffast-math' are also set, platform-independent. So if you have a chance to try which flag does something... It's just curiosity.
On Wed, Sep 21, 2016 at 10:34 PM, Christof Ressi christof.ressi@gmx.at wrote:
Hi Katja,
Even if your test reveals a beneficial effect from compiler flags, it is better when denormals are detected and flushed in the C code.
definitely! Maybe using the PD_BIGORSMALL macro on each filter state at the end of the DSP routine does the trick, just like in all the other recursive filters in Pd.
Von: katja katjavetter@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: pd-list pd-list@iem.at, "Miller Puckette" msp@ucsd.edu Betreff: Re: [PD] [bob~] denormals issue?
Hi Christof,
Makefile.pdlibbuilder passes flags '-march=pentium4 -msse -msse2 -mfpmath=sse' for optimization to the compiler on Windows. You could try compiling without (some of) these flags to see if they are responsible for the different behavior. Makefile-defined optimization flags can be overriden with argument CFLAGS given on command line.
The effect of optimization flags on denormals varies per processor type, unfortunately. When we had denormals on Raspberry Pi ARMv6 they wouldn't go away no matter what flags, is what I remember. Even if your test reveals a beneficial effect from compiler flags, it is better when denormals are detected and flushed in the C code. Anyway, it is still interesting to know what makes the difference.
Katja
On Wed, Sep 21, 2016 at 12:32 AM, Christof Ressi christof.ressi@gmx.at wrote: > Hmmm... I compiled [bob~] myself with MinGW and pd-lib-builder and I noticed two things: > 1) the CPU rise is gone > 2) it needs only half the CPU. I put 20 [bob~] objects in a switched subpatch and measured the CPU load. The DLL which comes with the Windows binaries needs 15%, while my own DLL needs only 7%! That's quite a deal... > > Christof > > PS: I attached the DLL in case you wanna try it yourself. > > >> Gesendet: Samstag, 17. September 2016 um 22:58 Uhr >> Von: "Christof Ressi" christof.ressi@gmx.at >> An: pd-list@iem.at, "Miller Puckette" msp@ucsd.edu >> Betreff: [PD] [bob~] denormals issue? >> >> Hi Miller, >> >> feeding audio into [bob~] and then going to zero will increase the CPU load by ca. 6%. Clearing the filter or adding a tiny amount of noise brings the CPU load back to its usual level immediately, so I guess it's a problem with denormals. >> My Pd load meter won't really show the increase, but it's clearly visibly on Process Explorer. >> >> See my attached patch. Tried with Pd 0.47.1, Lenovo Thinkpad L440, Windows 7. >> >> Christof_______________________________________________ >> Pd-list@lists.iem.at mailing list >> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list >> > _______________________________________________ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list >
From a few posts ago it looks like -O3 is what causes denormals to stick around, but I don't really know what I'm talking about. RK4 (which is what bob~ uses to solve the system) will never 'naturally' bring the filter state exactly back to 0 unless forced to in some way so if the denormals aren't handled elegantly, they will abound with 0 input to the filter no matter what (once some input has gone into the filter that is). My guess is that a slow decay doesn't push the filter states down into that region.
It is stupid and certainly sub-optimal, but maybe:
x = (x<DENORMAL_THRESH ? 0 : x);
where DENORMAL_THRESH is some very, very small normal number? This would have to be done on the negative side of 0, too. 2x compares is probably not as bad as the potential 100x slowdown (according to Wikipedia) that denormal arithmetic might cause.
It should be the case that the same compiler flags (for plain C anyway) produce, within limits, the same behavior across different compilers but that probably isn't true. This would be an interesting check. I'd like to know if leaving off -03 has the same effect with gcc.
On 9/21/2016 3:26 PM, katja wrote:
On Linux i386 bob~ produces subnormals as well and very high cpu load. It is not the slowly decaying signal that other filters tend to give, but a quick decay to a fixed small number.
It's weird indeed when subnormals cause different CPU load depending on how they are compiled. Since MinGW is a gcc port I would think it uses the same math implementation which produces such high CPU load for bob~ subnormals on my system.
On Thu, Sep 22, 2016 at 12:01 AM, Christof Ressi christof.ressi@gmx.at wrote:
I tried your patch with the [bob~] object shipped with the Windows binaries. I clearly get subnormals! It's actually no wonder because there isn't any protection against subnormals in the code (at least I couldn't spot it). But the weird thing is: the [bob~] I compiled myself would also show subnormals in your patch but the CPU load is not affected...
Gesendet: Mittwoch, 21. September 2016 um 23:47 Uhr Von: katja katjavetter@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: "pd-list@lists.iem.at" pd-list@lists.iem.at Betreff: Re: Re: Re: [PD] [bob~] denormals issue?
Without -O flags you get debug-level and all function inlining is disabled, depending on the code it can make a huge difference indeed. But Pd is probably compiled with at least -O2. So the flags don't make much difference. The compiler? Doesn't Miller compile with MinGW nowadays, I don't know. MinGW brings its own standard C libs, which may implement math functions differently than MS. But regarding denormals I guess they both respect the IEEE 754 standard.
You can check if you really have subnormals using attached patch denorm-test.pd you. The patch tests lop~, change it to bob~.
On Wed, Sep 21, 2016 at 11:18 PM, Christof Ressi christof.ressi@gmx.at wrote:
the SSE optimizations don't seem to matter at all. skipping -ffast-math gives a slight overall CPU rise, while skipping -O3 gives me huge CPU rise (20 bob~ filters are already to much for one core). Even when skipping all of those flags, the denormals issue is still not present.
Maybe it has something to do with the compiler?
Gesendet: Mittwoch, 21. September 2016 um 22:47 Uhr Von: katja katjavetter@gmail.com An: "Christof Ressi" christof.ressi@gmx.at, "pd-list@lists.iem.at" pd-list@lists.iem.at Betreff: Re: Re: [PD] [bob~] denormals issue?
I'm curious to know if the flags do flush denormals on your processor. Forgot to mention that '-O3 -ffast-math' are also set, platform-independent. So if you have a chance to try which flag does something... It's just curiosity.
On Wed, Sep 21, 2016 at 10:34 PM, Christof Ressi christof.ressi@gmx.at wrote:
Hi Katja,
> Even if your test reveals a beneficial effect from compiler flags, > it is better when denormals are detected and flushed in the C code. definitely! Maybe using the PD_BIGORSMALL macro on each filter state at the end of the DSP routine does the trick, just like in all the other recursive filters in Pd.
> Von: katja katjavetter@gmail.com > An: "Christof Ressi" christof.ressi@gmx.at > Cc: pd-list pd-list@iem.at, "Miller Puckette" msp@ucsd.edu > Betreff: Re: [PD] [bob~] denormals issue? > > Hi Christof, > > Makefile.pdlibbuilder passes flags '-march=pentium4 -msse -msse2 > -mfpmath=sse' for optimization to the compiler on Windows. You could > try compiling without (some of) these flags to see if they are > responsible for the different behavior. Makefile-defined optimization > flags can be overriden with argument CFLAGS given on command line. > > The effect of optimization flags on denormals varies per processor > type, unfortunately. When we had denormals on Raspberry Pi ARMv6 they > wouldn't go away no matter what flags, is what I remember. Even if > your test reveals a beneficial effect from compiler flags, it is > better when denormals are detected and flushed in the C code. Anyway, > it is still interesting to know what makes the difference. > > Katja > > On Wed, Sep 21, 2016 at 12:32 AM, Christof Ressi christof.ressi@gmx.at wrote: >> Hmmm... I compiled [bob~] myself with MinGW and pd-lib-builder and I noticed two things: >> 1) the CPU rise is gone >> 2) it needs only half the CPU. I put 20 [bob~] objects in a switched subpatch and measured the CPU load. The DLL which comes with the Windows binaries needs 15%, while my own DLL needs only 7%! That's quite a deal... >> >> Christof >> >> PS: I attached the DLL in case you wanna try it yourself. >> >> >>> Gesendet: Samstag, 17. September 2016 um 22:58 Uhr >>> Von: "Christof Ressi" christof.ressi@gmx.at >>> An: pd-list@iem.at, "Miller Puckette" msp@ucsd.edu >>> Betreff: [PD] [bob~] denormals issue? >>> >>> Hi Miller, >>> >>> feeding audio into [bob~] and then going to zero will increase the CPU load by ca. 6%. Clearing the filter or adding a tiny amount of noise brings the CPU load back to its usual level immediately, so I guess it's a problem with denormals. >>> My Pd load meter won't really show the increase, but it's clearly visibly on Process Explorer. >>> >>> See my attached patch. Tried with Pd 0.47.1, Lenovo Thinkpad L440, Windows 7. >>> >>> Christof_______________________________________________ >>> Pd-list@lists.iem.at mailing list >>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list >>> >> _______________________________________________ >> Pd-list@lists.iem.at mailing list >> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list >>
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 2016-09-22 01:10, David Medine wrote:
x = (x<DENORMAL_THRESH ? 0 : x);
yay for x=-0.5 :-)
anyhow, there is a macro PD_BIGORSMALL() that includes a proper test for denormals, so no need to re-invent the wheel. as christof has pointed out, bob~ doesN#t use this macro (for whatever reasons).
fgamsdr IOhannes
-
Christof Ressi -
David Medine -
Giulio Moro -
IOhannes m zmoelnig -
Jonathan Wilkes -
katja -
Miller Puckette