[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Free Intel C++ compiler
From:       Allan Sandfeld Jensen <kde () carewolf ! com>
Date:       2004-10-03 12:47:33
Message-ID: 200410031447.33504.kde () carewolf ! com
[Download RAW message or body]

On Sunday 03 October 2004 13:19, Fergus Morrow wrote:
> On Sun,  3 Oct 2004 13:15:39 +0200 (CEST), Marc Espie
>
> <espie@quatramaran.ens.fr> wrote:
> > In article <415AC885.1070506@telegraph-road.org> you write:
> > >Allan Sandfeld Jensen wrote:
> > >> The 7.0 version was good. Unfortunatly the 8.x series discriminates
> > >> unfairly against AMD processors, and is therefore completly unsuitable
> > >> for free software development.
> > >
> > >If you have an Intel CPU, then what's the problem ?
> >
> > You're kidding, right ?
> > If you distribute any kind of binaries, then you will distribute stuff
> > that runs poorly on AMD, and thus reflect badly on the processor.
> >
> > So, the kind of stuff for which you can fairly use the Intel compiler
> > is:
> > - for your own development;
> > - not for distributing any kind of binaries;
> > - as long as you don't get paid.
> >
> > sounds very restrictive to me.
> >
> > I don't know about you, but using a compiler that is obvious set up to
> > slam the competition doesn't strike me as ethical either...
>
> That is the point I was trying to make, but I was told Intel C++
> compiler was better than GCC. HOw the hell can it be better if it runs
> poorly on AMD systems?
>
It doesnt run _poorly_ on AMD systems. It just disables a few optimizations. 
It runs unfairly (as in benchmark cheats), not poorly. The exact extent of 
this bias is unknown, but it basically means that for Intel processors the 
Intel compiler is often faster than gcc (especially in benchmarks), but for 
other processors it is usually the same, if it doesnt just crash and refuse 
to run (see below).

For instance; the Intel compiler can autovectorize programs to automatically 
use SSE and MMX instructions (gcc only have experimental support for this). 
Before running programs that have been optimized that way, they have code 
that checks 1) that the processors supports it, and 2) that it is an Intel 
processor. Depending on how you have compiled the program, it will then 
either fall-back to a slower unoptimized version, or quit with an error 
message.

Btw. If you are really stubborn you can still fool the compiler to run the 
fast code on an AMD processor. There is an small fix that removes the second 
"is Intel processor check", but you also just compile a library with the 
Intel compiler, and then call the library from a small binary compiled with 
gcc.

Also note that the new gcc 3.4 and gcc 4.0 in many areas has cought up with 
the Intel compiler, and in a few cases is even faster. The Intel compiler 
wins however when it comes to simple computional loops like those in SPEC 
benchmarks.

`Allan
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]