[Gllug] Do not be frightened VERY OFF TOPIC

Jackson, Harry HJackson at colt-telecom.com
Mon Nov 19 10:50:51 UTC 2001


Please go to the bottom

> -----Original Message-----
> From: Nix [mailto:nix at esperi.demon.co.uk]
> 
> On Fri, 16 Nov 2001, Simon Stewart stated:
> > I thought that g++ generated non-optimal code (Nix will prolly know
> > more)
> 
> Depends what you mean. G++-2.95 was missing a (fairly large) bunch of
> optimizations that the C side had, but this is no longer the 
> case as of
> GCC-3.0, as they share more code now.
> 
> C++ compilers may well generate less-optimized code for a 
> given lump of
> C-compatible code than a C compiler would, because they have 
> to consider
> the way exceptions may affect control flow &c.
> 
> The biggest problems with G++ right now are the horrible parser (which
> Mark Mitchell is fixing, but it might not be ready in time 
> for GCC-3.1),
> the compilation speed and memory consumption (which everyone is trying
> to fix), and the lack of support for `export'.
> 
> Optimization across GCC will get a big boost when we add more 
> levels of
> intermediate representation for the source than the portable-assembler
> RTL, but as of yet no higher-level IR has been written, so we're
> basically kludging optimizations into RTL when they should 
> really sit at
> higher levels (SSA in particular suffers from this).
> 
> >       Last time I had a root through the KDE sources, the key
> > libraries seemed to make sense in the way that they were designed. I
> > also hear rumblings about the speed of the signals/slots Troll Tech
> > extensions to C++, especially where extensive use is made 
> of them. But
> > IANAC++ guru.
> 
> Startup time of big C++ programs is damaged by two things
> 
> - GCC generates more relocations than is strictly necessary. The
>   binutils have just acquired the ability to merge and sort 
> them, see the
>   -z combreloc option; you need a new glibc (maybe only 
> 2.2.4) to get much
>   startup-time advantage from this though.
> 
> - ELF's LD_PRELOAD combines with C++ virtual function 
> indirection in an
>   ugly way, requiring multiple relocations per virtual function. In a
>   big C++ program this can require tens or hundreds of thousands of
>   relocations at every startup. `ELF prelinking' can fix this (at the
>   cost of breaking LD_PRELOAD for prelinked applications); again, you
>   need a very new binutils for this (and perhaps a new GCC too).
>   You also need a new kernel (2.2.20 or late 2.4.x).
> 
> (IIRC.)
> 
> > OTOH, I just added the FISH KIO-slave, and suddenly the entire
> > environment can make use of SSH. Which is v. cool. :)
> 
> Does SSH here mean the secure shell? If so, I can't parse 
> this sentence
> at all :)


I agree with all of the above but the kick start for the racing turkey
snapped just before the race and we needed the Mechatronic Engramatic
Interpreter to get the photon particle analyser working at 105%. This is
before we found that the Quark fusion reactor was a bit warm and we needed
to jury-rig the blackhole containment intake to draw some of the heat away
from it. Then after we got the whole thing humming like a camel the driver
says that he's got a stomach bug and I quote "I ain't racin".


For all people new to Linux etc please do not let any of the above scare
you. There are a few very scary people on the list and when they go off on
one its like Clingon "rough, hard to understand, and only a select few speak
it". If you are like me then you will look at the above and it might as well
be the Matrix screen saver as English. 

So do not feel disheartened 
or scared to make a post
You wont truly be on the list 
till flamed like a slice of toast.


Harry














 


**********************************************************************
COLT Telecommunications
Registered in England No. 2452736
Registered Office: Bishopsgate Court, 4 Norton Folgate, London E1 6DQ
Tel. 020 7390 3900

This message is subject to and does not create or vary any contractual
relationship between COLT Telecommunications, its subsidiaries or 
affiliates ("COLT") and you. Internet communications are not secure
and therefore COLT does not accept legal responsibility for the
contents of this message.  Any view or opinions expressed are those of
the author. The message is intended for the addressee only and its
contents and any attached files are strictly confidential. If you have
received it in error, please telephone the number above. Thank you.


**********************************************************************


-- 
Gllug mailing list  -  Gllug at linux.co.uk
http://list.ftech.net/mailman/listinfo/gllug




More information about the GLLUG mailing list