[linux-elitists] Nobody's favorite language? C++ and free software

Jason Spence jspence@lightconsulting.com
Tue Mar 25 14:19:08 PST 2003


On Tue, Mar 25, 2003 at 11:25:08AM -0800, Don Marti wrote:
> 5. GNU tools are slower at building C++ projects than those in C.

I'm using the Intel compiler on Linux for my network visualization
project, which is more than 50% floating point code by scalar variable
type.  Icc's ability to automatically generate the appropriate mix of
SSE, SSE2, x87 FP, and MMX instructions has improved the speed of
certain routines quite a bit.  In some cases, it caused the routines
to take essentially no time since it automatically pipelined them in
such a way that they executed concurrently on different parts of the
processor than an adjacent section of code.  And it's the only
compiler for Linux and *BSD that knows enough about hyperthreading to
make binaries go as fast as they should on a HT enabled P4.

I'm very happy with the C++ support.  I just symlinked g++ to icc and
things worked fine, since the command line options are the same for
both compilers.  Among other things, it's noticibly faster than g++
during builds (and it supports most of the gcc extensions, so stuff
actually DOES build - they claim they can compile a kernel if they
remove nested functions and stuff) and it's c++ error messages feel
like they were written by UI people instead of some random gcc hacker.
As a result, I end up with something like 10x the number of lines in
my error messages file (make 2>fixthis), but I think I'm fixing them
faster than I do with g++, especially when I start using a C++ feature
I'm not very familiar with, such as the rules for using references in
virtual functions.  Oh, and most of my icc compiled C++ objects link
with g++ compiled objects, although using obscure C++ features is
supposed to break it; the inter-compiler C linkage has been flawless
so far for me, and I haven't managed to break the C++ linkage yet.
Intel claims they're "C++ ABI conforming", too.

Intel has their own C++ libraries (which I suspect are from
dinkumware), so you either have to add 500K of stuff to a statically
compiled binary or distribute the runtime dlls with your project.
However, I think they're faster and more core-efficient than the ones
that come with g++, *especially* the block copies done in the STL and
elsewhere.  They use the features of the vector co-processor so you
get double quadword copies, something I've felt has been lacking in
most open software.  32 bit MOVs waste processor cycles and clutter up
the microop pipeline unnecessarily, as well as reduce the available
number of GP registers (and we don't have enough on x86 to start
with!)  I suspect that it may be the support infrastructure and not
the compiled object code itself that's responsible for g++'s bad speed
reputation, since I've disassembled enough g++ generated objects to
know that I get exactly the same results compared to gcc when
compiling the same code (they generate MC out of the same AST), and
gcc's output isn't bad at all.  There's overhead for class
instantiation and stuff, but any programmer who decides to instantiate
300,000 Vector classes to draw a polygon needs help anyway.

The other thing is that icc will generate multiple symbols for a
section of code if you ask it to, enabling a multiplatform binary that
will use features of modern processors, yet execute on a 386 too since
the binaries do runtime processor detection at startup.

ICC 7 is free for non-commercial purposes, but someone really ought to
examine the license before we start distributing a SSE2 enabled Mesa
with Debian or something, since there's parts in there that say things
like "cannot be performed or produced for the benefit of other parties
for a fee, compensation, ..." blah blah blah.  BTW, some of the MP3
stuff absolutely FLIES when compiled with icc.  There's some magic
juju you need to do to install it on Debian or other non-RPM
distributions, so let me know if you want my installation notes.

http://www.intel.com/software/products/compilers/clin/noncom.htm

Oh yeah, and it supports Itanium, but who cares - I'm dynlinking all
my vector code with gcc compiled Opteron objects for 64-bit :) I
really feel sorry for the Intel group that did this compiler, since I
suspect a lot of Linux people are going to move to x86-64 once it
becomes widely available.  I'm really happy with the Opteron/Athlon 64
stuff in AMD's devel lab so far, and some of the stuff that the
OpenBSD guys have been talking about doing make me a lot more bullish
on the white hat vs. black hat war (the main reason I think Linux
people will begin adopting (once the features get ported to Linux,
that is)).

--
 - Jason                   Currently at: Home, Downstairs (Fremont, CA) (Fair)

One thing the inventors can't seem to get the bugs out of is fresh
paint.



More information about the linux-elitists mailing list