12 Nov
2002
12 Nov
'02
7:35 a.m.
Hi,
does anyone know if it is possible to make the Free Intel C Compiler
work on Red Hat 8.0 ?
It used to work on RH7.3 but Jussi L. reported failure on RH8.0 too.
I would just be courious about Intel compiler's efficiency since I am
currently performing some resampling / mixing benchmarks using linear
and cubic interpolation and for example with cubic interpolation which
involves a few MULs/ADDs per sample, I get something like:
Celeron (PII-class) 71 cycles/sample , Athlon 61 cycles/sample,
Pentium 4 80 cycles / sample. (using gcc 3.2)
It seems the P4's FPU sucks quite since for some ops it needs more
cycles per instruction than the old Celeron.
I heard Intel's compiler is able to use SIMD to speed up FPU ops so I
would just be curious to see what is achievable given good quality code
that is targeted for the P4.
The innermost resampling/mixing loop is very short anyway so in that
case one could probably use a P4-specific asm version (or importing the
asm generated by icc) in order to achieve maximum performance.
But first tests seems to indicate (at least to me) that the Athlon is
20-30% faster for doing resampling/mixing stuff thus I guess an Athlon
machine will deliver more voices than a P4 running at the same
frequency ( or Pentium-frequency-equivalence-index).
Currently I am working only in the floating point domain, but Juan L. is
telling me about the wonders of integer math and pointed me to the
routines found in http://modplug-xmms.sourceforge.net/ but I am unable
to compile the package on RedHat 8.0 (am I a masochist insisting on that
distro ? :-) )
On the other hand Steve Harris says that in modern CPUs floating point
ops are more accelerated than integer ones and since integer involves a
lot of shifting, you might end up with longer execution times than the
integer version.
(FISTL takes 6 cycles but it is not that much compared to 70-80 cycles
in the case of cubic interpolation plus doing all in the FP domain saves
you from lots of hassles)
I will publish the benchmark and the results when I will have
implemented more test cases.
Anyway it is interesting to learn how sucky the x86 architecture can be
(the hard way of course :-) ).
PS: regarding the optimization options Steve H. suggested
-O6 -fomit-frame-pointer -fstrength-reduce -funroll-loops
-fmove-all-movables -ffast-math -mcpu=i686 -march=i686
Can gcc 3.2 target archtitectures higher than the PII ?
(I mean generating P3/P4 specific code ?)
thoughts ?
Benno
--
http://linuxsampler.sourceforge.net
Building a professional grade software sampler for Linux.
Please help us designing and developing it.
12 Nov
12 Nov
11:05 a.m.
On Tue, Nov 12, 2002 at 01:41:35 +0100, Benno Senoner wrote:
Hi,
does anyone know if it is possible to make the Free Intel C Compiler
work on Red Hat 8.0 ?
It used to work on RH7.3 but Jussi L. reported failure on RH8.0 too.
They need to releaqse one specifically for each glibc version (IIRC). They
will produce an RH8 one sooner or later, but it might take a while.
I have a RH7.3 machine with icc on if you want me to try anything.
I heard Intel's compiler is able to use SIMD to
speed up FPU ops so I
would just be curious to see what is achievable given good quality code
that is targeted for the P4.
gcc3.2 can do that too, -msse -mfarch=sse or something like that, not
vectorising, but the code I saw didn't look vectoriasable, and icc isn't
that good at it anyway. It didn't help to use the sse instead of 387 on
my athlon xp.
But first tests seems to indicate (at least to me)
that the Athlon is
20-30% faster for doing resampling/mixing stuff thus I guess an Athlon
machine will deliver more voices than a P4 running at the same
frequency ( or Pentium-frequency-equivalence-index).
I think this is generally accepted. Though the P4 is avialabel in higher
clockspeeds.
On the other hand Steve Harris says that in modern
CPUs floating point
ops are more accelerated than integer ones
More specifically the ia64 architecture can't do integer multiply, it
converts to float, does the mul and converts back.
Can gcc 3.2 target archtitectures higher than the PII
?
(I mean generating P3/P4 specific code ?)
Yes, you have to specify the use of sse explicity (I think I meantioned it
on IRC when we were benchmarking). It appeared to make zero difference on
the athlon, but I didn't check the assemler to see exactly what it was
doing. I've heard that just using sse instructions instead of 387 on the
P4 is quicker, but I've not tried it. Gcc will do that if you specify
-msse
- Steve
12:30 p.m.
> Can gcc 3.2 target archtitectures higher than the
PII ?
> (I mean generating P3/P4 specific code ?)
Yes, you have to specify the use of sse explicity (I
think I meantioned it
on IRC when we were benchmarking). It appeared to make zero difference on
the athlon, but I didn't check the assemler to see exactly what it was
doing. I've heard that just using sse instructions instead of 387 on the
P4 is quicker, but I've not tried it. Gcc will do that if you specify -msse
The sse instructions ought to be substantially faster. There are many more
registers available to support the flops, and they aren't organized into the
ridiculous 387 stack, so they're easier to reach. I believe they also
default
to round-to-nearest and flush-denormals, but if you care about such niceties
you should check.
-BobC
1:19 p.m.
On Tue, Nov 12, 2002 at 08:23:50 -0800, Bob Colwell wrote:
Yes, that is correct AKAIK. However the particular benchmark we are
talking about has a lot of memory access in it, and in that case it didn't
make any difference (or gcc was doing something stupid, I didn't check).
I dont understand processor issues well enough to know what the
bottleneck would be, but it doesn't appear to be the maths instrucitons.
I will check the effect of sse on my plugins as they are generally less
ram hungry, but I dont have a gcc3 machine around at the moment.
- Steve
Yes, you have
to specify the use of sse explicity (I think I meantioned it
on IRC when we were benchmarking). It appeared to make zero difference on
the athlon, but I didn't check the assemler to see exactly what it was
doing. I've heard that just using sse instructions instead of 387 on the
P4 is quicker, but I've not tried it. Gcc will do that if you specify -msse
The sse instructions ought to be substantially faster. There are many more
registers available to support the flops, and they aren't organized into the
ridiculous 387 stack, so they're easier to reach. I believe they also
default
to round-to-nearest and flush-denormals, but if you care about such niceties
you should check.
3:02 p.m.
On Tue, Nov 12, 2002 at 05:15:29 +0000, Steve Harris wrote:
I will check the effect of sse on my plugins as they
are generally less
ram hungry, but I dont have a gcc3 machine around at the moment.
I just tried that, but on the athlon xp at least the result is slightly
slower on average, I haven't tried it on a PIII yet. The pentiums
presumably have a better SSE implementation.
For reference the flags are -msse -mfpmath=sse, it just replaces the 387
instructions with sse equivalents where it can.
- Steve
8075
days inactive
8075
days old
linux-audio-dev@lists.linuxaudio.org
4 comments
3 participants
participants (3)
-
Benno Senoner -
Bob Colwell -
Steve Harris