19 Aug
2009
19 Aug
'09
7:52 a.m.
Hello all,
i have written a channel class, which collects data from (file) sources and
copies it to a buffer. Jack will get this buffer and put it into his streams.
So far, I think, this is a normal design with the following code
for (unsigned int n = 0; n < nframes; ++n)
{
pBuffer[n] += pFrames[n];
pBuffer[n] *= volume;
}
i know, it's not really optimized. But it works as an example. as you can
think, pBuffer and pFrames are float* and volume is also a float.
now it happens, when the volume is 0, after 3-5 seconds, the CPU will run into
100%.
a workaround is the following before the loop
if(volume < 0.0000001)
volume = 0.0000001;
But i try to understand, what happens here. Is the compiler overoptimizing
zeros.
compiler is: $g++ -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-
c++,treelang --prefix=/usr --enable-shared --with-system-zlib --
libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --
enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --
enable-libstdcxx-debug --enable-mpfr --with-tune=i686 --enable-
checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
what puzzles me is, that this doesn't happen on my double core system.
Any ideas. Thanks c~
19 Aug
19 Aug
8:37 a.m.
[Conrad Berhörster]
i have written a channel class, which collects data
from (file) sources and
copies it to a buffer. Jack will get this buffer and put it into his streams.
So far, I think, this is a normal design with the following code
for (unsigned int n = 0; n < nframes; ++n)
{
pBuffer[n] += pFrames[n];
pBuffer[n] *= volume;
}
i know, it's not really optimized. But it works as an example. as you can
think, pBuffer and pFrames are float* and volume is also a float.
now it happens, when the volume is 0, after 3-5 seconds, the CPU will run into
100%.
a workaround is the following before the loop
if(volume < 0.0000001)
volume = 0.0000001;
But i try to understand, what happens here. Is the compiler overoptimizing
zeros.
It'd be a lot more helpful to see the full source but from what you're
writing I'd be willing to bet you're encountering denormals.
Cheers, Tim
8:55 a.m.
Hello Tim,
On Wednesday 19 August 2009 12:37:36 Tim Goetze wrote:
It'd be a lot more helpful to see the full source but from what you're
writing I'd be willing to bet you're encountering denormals.
geeh, good point. So there is no opponent in betting with you ;=)
anyway, as i have a quick read of http://ardour.org/node/139, my code with the
if wasn't a workaround, it is the solution, as long as the CPU isn't a SSE,
right?
bye c~
11:49 a.m.
[Conrad Berhörster]
On Wednesday 19 August 2009 12:37:36 Tim Goetze wrote:
Again, that is awfully hard to tell without seeing the full source. ;)
If you're coding for public consumption, it's probably better to
provide a CPU-agnostic solution anyway. That'll be either flushing
very small values to zero "by hand" or injecting inaudible noise.
Cheers, Tim
It'd be a lot more helpful to see the full source but from what you're
writing I'd be willing to bet you're encountering denormals.
geeh, good point. So there is no opponent in betting with you ;=)
anyway, as i have a quick read of http://ardour.org/node/139, my code with the
if wasn't a workaround, it is the solution, as long as the CPU isn't a SSE,
right?
1:42 p.m.
Hello Tim,
On Wednesday 19 August 2009 15:48:58 Tim Goetze wrote:
[Conrad Berhörster]
i have used
the afternoon to do some testing and reviewing my code.
Additionally i have read some things about denormals and SSE. It seems, that
the Problem only obtain on the AMD processor, which is a different machine as
my developing machine.
I try to understand the code, Jens had send. I found out, that it isn't the
volume parameter - it happened when i use only the sample at standard volume.
to be continued...
thanks c~
On Wednesday 19 August 2009 12:37:36 Tim Goetze
wrote:
Again, that is awfully hard to tell without seeing the full source. ;) It'd be a lot more helpful to see the full
source but from what you're
writing I'd be willing to bet you're encountering denormals.
geeh, good point. So there is no opponent in betting with you ;=)
anyway, as i have a quick read of http://ardour.org/node/139, my code with
the if wasn't a workaround, it is the solution, as long as the CPU isn't
a SSE, right? 
1:45 p.m.
On Wed, Aug 19, 2009 at 4:42 PM, Conrad
Berhörster<conrad.berhoerster(a)gmx.de> wrote:
Additionally i have read some things about denormals
and SSE. It seems, that
the Problem only obtain on the AMD processor
My impression was that Intel CPUs slow down more than AMDs for
denormal handling. But my experience is quite limited, my memory is
not always the best, and I haven't had an AMD for a few years. Am I
wrong?
Chris
5:35 p.m.
On Wed, 2009-08-19 at 17:42 +0200, Conrad Berhörster wrote:
I try to understand the code, Jens had send. I found
out, that it
isn't the volume parameter - it happened when i use only the sample at
standard volume.
Oh, sorry:
-8<------------------------------------------------------
MAN static int set_DAZ_and_FTZ(int /*bool*/ on);
When called with a non-zero argument at program start, kills bugs dead
arising from denormals by telling the processor to ignore them at best
of its ability.
Returns: SSE level on success, or zero if processor is very old.
Caveats: Intel architecture only.
to be continued...
thanks c~
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
9:06 a.m.
#include <xmmintrin.h>
#define CPUID(f,ax,bx,cx,dx) __asm__ __volatile__ \
("cpuid": "=a" (ax), "=b" (bx), "=c" (cx),
"=d" (dx) : "a" (f))
// denormal protection
static int set_DAZ_and_FTZ(int /*bool*/ on)
{
int sse_level = 0;
if(on)
{
unsigned long ax, bx, cx, dx;
CPUID(0x00,ax,bx,cx,dx);
CPUID(0x01,ax,bx,cx,dx);
if (dx & 0x02000000)
{
sse_level = 1;
// set FLUSH_TO_ZERO to ON and
// set round towards zero (RZ)
_mm_setcsr(_mm_getcsr() | 0x8000|0x6000);
if (dx & 0x04000000)
{
sse_level = 2;
if (cx & 0x00000001)
{
sse_level = 3;
// set DENORMALS_ARE_ZERO to ON
_mm_setcsr(_mm_getcsr() | 0x0040);
}
// we should have checked for AMD K8 without SSE3 here:
// if(AMD_K8_NO_SSE3)
// .. but I can't recall how to that :-/
}
}
} else
// clear underflow and precision flags
// and set DAZ and FTZ to OFF
// and restore round to nearest (RN)
_mm_setcsr(_mm_getcsr() & ~(0x0030|0x8000|0x0040|0x6000));
return sse_level;
}
On Wed, 2009-08-19 at 12:37 +0200, Tim Goetze wrote:
[Conrad Berhörster]
But i try to understand, what happens here. Is the
compiler overoptimizing
zeros.
It'd be a lot more helpful to see the full source but from what you're
writing I'd be willing to bet you're encountering denormals.
Cheers, Tim 
10:36 a.m.
On Wed, Aug 19, 2009 at 11:52:15AM +0200, Conrad Berhörster wrote:
for (unsigned int n = 0; n < nframes; ++n)
{
pBuffer[n] += pFrames[n];
pBuffer[n] *= volume;
}
i know, it's not really optimized. But it works as an example. as you can
think, pBuffer and pFrames are float* and volume is also a float.
now it happens, when the volume is 0, after 3-5 seconds, the CPU will run into
100%.
a workaround is the following before the loop
if(volume < 0.0000001)
volume = 0.0000001;
You are getting 'denormals' which are floating point
values that are not representable in the normal format.
In that case the FP processor will raise an exception
and the calculation is done in software instead, which
takes lots of CPU.
But this should not happen if the volume is exactly
zero, but when it is very close to it.
Anyway you should use somehting like
if (volume < 1e-10f) volume = 0;
for ( )
{
}
or even better:
if (volume < 1e-10f)
{
memset (pBuffer, 0, nframes * sizeof (float));
}
else
{
for () // etc.
}
If you still have this problem with the volume set
to exactly zero, then it is created not in the code
you've shown but by later parts of your processing.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
2:34 p.m.
Hello Fons,
On Wednesday 19 August 2009 14:34:45 Fons Adriaensen wrote:
if (volume < 1e-10f)
{
memset (pBuffer, 0, nframes * sizeof (float));
}
else
{
for () // etc.
}
this is a cool trick to save some CPU. thanks for that hint.
If you still have this problem with the volume set
to exactly zero, then it is created not in the code
you've shown but by later parts of your processing.
the rest i will answer in a forthcoming mail very soon.
bye c~
27 Aug
27 Aug
12:23 p.m.
Hello all,
just for the record,
I have fixed the problem.
On Wednesday 19 August 2009 11:52:15 I wrote:
Hello all,
i have written a channel class, which collects data from (file) sources and
copies it to a buffer. Jack will get this buffer and put it into his
streams. So far, I think, this is a normal design with the following code
for (unsigned int n = 0; n < nframes; ++n)
{
pBuffer[n] += pFrames[n];
pBuffer[n] *= volume;
}
yes - i was a denormal problem.
it wasn't in that code, i have posted. i was in a filter, i have wrote.
thanks to all, who had helped...
and to Chris:
if i recall http://ardour.org/node/139 right:
" The problem with denormals is that some processors (especially P4's but also
some AMD processors) cannot calculate so small numbers without going into a
special state."
so denormals should work on new intel processors, right?
and the Code, Jens had posted, is only for P4 intels, because it isn't written
for AMDs and not necessary for newer one, right?
bye c~
1:40 p.m.
On Thu, 2009-08-27 at 16:23 +0200, Conrad Berhörster wrote:
and the Code, Jens had posted, is only for P4 intels,
because it isn't
written for AMDs and not necessary for newer one, right?
Ehh no.
It works for anything that has SSE, survives a Pentium Pro but bails out
on 486 and Pentium Classic. The instruction used was not implemented yet
in those days.
The SSE level returned is wrong for a very tiny segment of AMD
processors when AMD couldn't make up their minds upon what kind of
product they wanted to be shipping. Still does the denormal trick
though.
5367
days inactive
5375
days old
linux-audio-dev@lists.linuxaudio.org
11 comments
5 participants
participants (5)
-
Chris Cannam -
Conrad Berhörster -
Fons Adriaensen -
Jens M Andreasen -
Tim Goetze