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

Jason Spence jspence@lightconsulting.com
Tue Mar 25 22:57:09 PST 2003

On Tue, Mar 25, 2003 at 08:36:22PM -0800, Alan DuBoff wrote: 

> > 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 I've seen the code it produces to be quite larger. I haven't 
> done any optimization with it yet, but for some stuff linked to shared 
> libraries it seems to produce a much larger binary.

Well I tried Hello World with iostreams and 'using namespace std' and
ended up with this:
                   .text/count   .data  count  total
test-g++-2.95               16       0     12   5287
test-g++-3.0.4             113     102     30  30244
test-icc7                   27      16     12  12602

Which surprised me quite a bit - my earlier figures were for a simple
threading app.

> Keep in mind that I'm mainly interested in the debugging capabilities right 
> now and want to write an article on using the debugger with shared libraries 
> and multi-threaded applications, an area that gcc/gdb has fallen short at in 
> the past.

Well I haven't tried their debugger yet since their packaging is kind
of screwy, and alien creates an idb deb which conflicts with the icc
deb.  *shrug* Threading support otherwise has been fine from my

> > 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.
> This is not so bad, but it would be nicer not to have to do that. For Linux 
> you mean runtime shared libraries though, I guess.
> libcxa.so.3 is only 250k, maybe I don't have it using everything yet.

Whoops, I meant > 1M:

-rwxr-xr-x    1 root     root       832393 Mar 25 21:43 /opt/intel/compiler70/ia32/lib/libcprts.so.3
-rwxr-xr-x    1 root     root       251673 Mar 25 21:43 /opt/intel/compiler70/ia32/lib/libcxa.so.3
-rwxr-xr-x    1 root     root        21467 Mar 25 21:43 /opt/intel/compiler70/ia32/lib/libunwind.so.3

I forget where I got the earlier 500K figure from.

> > 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.
> I'd like to hear what you did to install it, I didn't want to chance
> it so what I did was install Red Hat 7.3 and installed it on. BTW, I
> consider this a short coming to the distribution, because they
> didn't say it requires Red Hat to install properly, and it doesn't
> say it's dependent on RPM to install, but there was some problems
> with the Berkeley DB files that it didn't like on Debian either. To
> play it safe I installed it on Red Hat, then tar'd it up and moved
> it to Debian. This is exactly what I have done in the past with
> MontaVista's HardHat, but their stuff will now work with alien. In
> Intel's case since there is a binary install, I wasn't sure if I
> could just alien the files and/or which ones were to be used.

Yeah, that's what I did, and also what caused the mutually
incompatible icc and idb packages :)

> Additionally, I had a Red Hat 6.2 which was the last VA CD produced. It 
> didn't have a proper version of glibc, and Debian had the correct version, 
> but Berkeley DB errors and RPM problems.

Didn't have any problems running it on woody or sarge.

> It bothers me that it doesn't support the Athlon, and I don't expect it to. 
> Linux does support this processor well, and I don't need the hyperbole, err, 
> I mean hyperthreading support on my systems.

The vector code runs fine on my twin AMD development machines :) I
haven't done any benchmarks on the code produced, but the faster
compile times are well worth it.

> I'm not totally convinced there is a large market for 64 bit
> processors yet, and if we look at Sun's SPARC processor as an
> example there has been little convincing reason for people to move
> to 64 bit, so the majority still runs on 32 bit. 

Well I use a lot of very memory hungry graphics apps and a lot of
register hungry graph algorithms, and I can't see any of my vendors
porting their stuff to solaris.  Among other things (like porting
win32 apps to solaris and the cost (and availability) of solaris
progammers), their opengl support is quite a bit less, um, efficient
than on the PC :) I don't think you can even get NVidia or ATI
runtimes for either Solaris anymore.

The stuff I use that does run on PC platforms eats memory like there's
no tommorow.  The Unreal guys got quoted in the media as saying their
next generation tools will pretty much require 64 bit, and I can see
how adding a few features to my application (which would increase the
amount of stuff tracked for each node) might kick me over the 2G
barrier.  idSoft is also rumored to have said a few unsettling things
about the 2G barrier and large Doom III maps...

Although we don't see a lot of 64 bit apps really using 64 bitness on
Solaris, I don't think that means there isn't a (future) demand for
them on other platforms.  I seem to remember someone extrapolating
everquest memory usage or something and it ended up over 2G within a
few years.  And now they're talking about this even bigger star wars
mmorpg with textures the size of the operating system and other insane
things :P

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

Psychiatrists say that one out of four people are mentally ill.  Check
three friends.  If they're OK, you're it.

More information about the linux-elitists mailing list