[linux-audio-dev] Intel C Compiler & RedHat 8.0 , Pentium 4 FPU performance

Steve Harris S.W.Harris at ecs.soton.ac.uk
Tue Nov 12 10:06:01 UTC 2002

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
> 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

- Steve

More information about the Linux-audio-dev mailing list