18 Feb
2004
18 Feb
'04
4:58 a.m.
hi all,
i'm curious about your thoughts about the recent generation of amd's
64bit chip and the p4 ...
it seems, that the amd chip isn't as fast as the p4 if you compare the
floating point performance (what's essential for dsp), but on the other
hand it doesn't suffer from the denormal bug (and several pd / ladspa
object still suffer from denormal problems)
... i'd be really interested in your thoughts ...
Tim mailto:TimBlechmann@gmx.de
ICQ: 96771783
--
The only people for me are the mad ones, the ones who are mad to live,
mad to talk, mad to be saved, desirous of everything at the same time,
the ones who never yawn or say a commonplace thing, but burn, burn,
burn, like fabulous yellow roman candles exploding like spiders across
the stars and in the middle you see the blue centerlight pop and
everybody goes "Awww!"
Jack Kerouac
18 Feb
18 Feb
5:47 a.m.
On Wed, Feb 18, 2004 at 01:33:36 +0100, Tim Blechmann wrote:
hi all,
i'm curious about your thoughts about the recent generation of amd's
64bit chip and the p4 ...
it seems, that the amd chip isn't as fast as the p4 if you compare the
floating point performance (what's essential for dsp), but on the other
hand it doesn't suffer from the denormal bug (and several pd / ladspa
object still suffer from denormal problems)
I'm not up-to-date on benchmarks so I cant comment, but just to clarify
the denormal thing in P4's is not a bug, its how you handle denormals, the
only difference is that the P4 takes longer to handle them so you get away
with it less often.
Ideally DSP software would be written so that it never generates them,
but, erm, well, developers are lazy, y'know :)
On the P4 its possible that you can set some flags to use SSE instructions
instead of 387 and tell the SSE unit to never produce denormals, but
last time I tried it, gcc 3.something generated bad code (illegal
instructions).
- Steve
7:29 a.m.
I'm not up-to-date on benchmarks so I cant
comment, but just to
clarify the denormal thing in P4's is not a bug, its how you handle
denormals, the only difference is that the P4 takes longer to handle
them so you get away with it less often.
Ideally DSP software would be written so that it never generates them,
but, erm, well, developers are lazy, y'know :)
sure, denormals are not a bug,
but the behaviour on dsp systems that
aren't denormal-save is similar to a bug ;-)
On the P4 its possible that you can set some flags to
use SSE
instructions instead of 387 and tell the SSE unit to never produce
denormals, but last time I tried it, gcc 3.something generated bad
code (illegal instructions).
wait ... you imply that the sse unit doesn't
produce denormals, so that
a -march=sse _should_ solve all dsp user problems?
i heard that gcc 3.2 produces illegal instructions, but that it's solved
in gcc 3.3 ... can anyone confirm / deny this?
cheers...
Tim mailto:TimBlechmann@gmx.de
ICQ: 96771783
--
The only people for me are the mad ones, the ones who are mad to live,
mad to talk, mad to be saved, desirous of everything at the same time,
the ones who never yawn or say a commonplace thing, but burn, burn,
burn, like fabulous yellow roman candles exploding like spiders across
the stars and in the middle you see the blue centerlight pop and
everybody goes "Awww!"
Jack Kerouac
7:53 a.m.
On Wed, Feb 18, 2004 at 01:20:30 +0100, Tim Blechmann wrote:
I'm not
up-to-date on benchmarks so I cant comment, but just to
clarify the denormal thing in P4's is not a bug, its how you handle
denormals, the only difference is that the P4 takes longer to handle
them so you get away with it less often.
Ideally DSP software would be written so that it never generates them,
but, erm, well, developers are lazy, y'know :)
sure, denormals are not a bug,
but the behaviour on dsp systems that
aren't denormal-save is similar to a bug ;-)
> On the P4 its possible that you can set some flags to use SSE
> instructions instead of 387 and tell the SSE unit to never produce
> denormals, but last time I tried it, gcc 3.something generated bad
> code (illegal instructions). wait ... you imply that the sse unit doesn't
produce denormals, so that
a -march=sse _should_ solve all dsp user problems?
i heard that gcc 3.2 produces illegal instructions, but that it's solved
in gcc 3.3 ... can anyone confirm / deny this?
SSE /can/ be prevented from producing denormals, it probably doesnt by
default because it would violate the IEEE float spec.
- Steve
2:20 p.m.
On Wed, 2004-02-18 at 11:43, Steve Harris wrote:
Ideally DSP software would be written so that it never
generates them,
but, erm, well, developers are lazy, y'know :)
Writing it such a way would sometimes make it even slower.
Now the speed difference between Intel and AMD is that Intel is 10-100x
slower than AMD depending on routine. (other problem is performance
issues when memory is accessed on non-16-byte aligned address which is
about 2x slower than aligned)
However, there is a way to work around it.
On the P4 its possible that you can set some flags to
use SSE instructions
instead of 387 and tell the SSE unit to never produce denormals, but
last time I tried it, gcc 3.something generated bad code (illegal
instructions).
Best way is to code everything for SSE2 which has no denormal problems
(can treat denormals as zero). Writing code this way (and possibly using
E3DNow) will also make it run fast on AMD Opteron/Athlon64. x86-64
architecture _really_ needs asm to get a good kick out of it...
- Use SSE2
- Use prefetch
Here are some numbers for my 2.4 GHz Celeron.
C++ (Intel C++ 8.x):
10831.111 us / cross correlation on 44100 samples (single precision)
1060.100 ms / 181 tap FIR filter of 65536 samples (single precision)
6.390 ms / 5 biquad IIR filter of 65536 samples (single precision)
SSE2 (inline asm):
597.222 us / cross correlation on 44100 samples (single precision)
23.800 ms / 181 tap FIR filter of 65536 samples (single precision)
2.840 ms / 5 biquad IIR filter of 65536 samples (single precision)
--
Jussi Laako <jussi.laako(a)pp.inet.fi>
3:02 p.m.
On Wed, 2004-02-18 at 20:17, Jussi Laako wrote:
C++ (Intel C++ 8.x):
SSE2 (inline asm):
I forgot to mention that both of these work on single sample at a time..
So the results are comparable, there would possibly be about 2x increase
in performance for using parallelism.
--
Jussi Laako <jussi.laako(a)pp.inet.fi>
7586
days inactive
7586
days old
linux-audio-user@lists.linuxaudio.org
5 comments
3 participants
participants (3)
-
Jussi Laako -
Steve Harris -
Tim Blechmann