Question about kdeinit

[Bo Thorsen]

On Tuesday 02 April 2002 15:32, David Leimbach wrote:
> I have no idea if gcc-3.1 can do pre-linking.  The objprelink program
> was able to accomplish some of these things so the kdeinit hack wasn't
> necessary.

I can give you some info on what's happening in the GCC camp. My employer 
considers me a GCC developer. I don't, so expect that there is some things in 
this that could be slightly wrong.

Basically there are two developments that are very interesting for KDE: 
prelinking and precompiled headers.

Prelinking is actually almost exclusively implemented in glibc and a 
standalone application that probably will end up in binutils. In the normal 
link situation, when you have a call (or other access) to a function in a 
library, the link time linker (the binutils app ld) makes a relocation entry 
for this call and just puts zeros in the function pointer slot. Then when the 
dynamic linker (/lib/ld-linux.so.2 on my linux system) sees the relocation 
entry, loads the necessary library and puts in the function pointer in the 
slot. This happens an insane amount of times when you load an application and 
is worsened by the way virtual tables describing class hierarchies of virtual 
functions in C++ is implemented.

Prelinking is done by assigning a slot in memory where the library is supposed 
to be placed and then filling in the slots at compile time instead of at 
runtime. This works if the linker can satisfy all the assigned positions for 
the libraries and in that case loading and runtime linking is reduced to 
almost no time. If the libraries can't be placed in the designated places in 
the virtual address space, normal linking will happen, so it would just look 
like it does now. Had linking been the only thing that slows startup times 
down, this scheme would obliterate the problem, but KDE does a lot of things 
after linking too. By now the glibc part is done, only the tool to make the 
relocation prelinking is missing. I think it should be usable in the fall.

Precompiled headers is a gcc only thing. It's basically just a mechanism to 
make gcc dump it's internal state after processing a header file, and making 
a load mechanism for this file. It means going over all the header files and 
compile each of these to a binary file which GCC will then include instead of 
the normal header file. There are some caveats to the situation like that the 
headers have to be compiled with the same set of flags as the object file 
etc. but in a normal KDE build from scratch, it will be good to have. 
Especially for template intensive header files this gives an incredible 
speedup. One guy on the GCC mailinglist said he usually got a factor of 10 to 
20 speedup when compiling KDE with this - not 10%, a factor 10! I don't know 
if it will be in GCC 3.2, but I doubt it. 3.1 won't have the patch.

Another thing worth mentioning is that with GCC 3.x the cost of using 
exceptions are now moved from the try catch block to the exception throwing. 
It's free (as in not a single cpu cycle used on it) to make a try catch 
block, if the code inside doesn't throw any exceptions. The cost is that 
throwing exceptions are a lot more expensive. But it should be performance 
safe to compile Qt and KDE without the -fno-exceptions flag. It will give you 
a larger binary file because the exception handling is done with DWARF2 
tables that are placed in the .eh_frame section. This won't matter to the 
loadtime of the application though, since modern linkers only loads the 
segments of the files on demand. I'd say that for KDE 4, exceptions will be 
fine to use.

Other than these, the architectural work on GCC 3 is starting to pay off. By 
now, performance of the compiler and the compiled applications are now 
approaching the 2.95.x levels. (Since 3.0 was a release that didn't pay 
attention to performance at all, this is reasonable.) If 3.2 doesn't produce 
as good code as 2.95.x, that would in most cases be considered a bug - unless 
the problem is only a percent or two. For 3.1 it will be interesting to know 
for the developers, but only in when the problem is big.

Bo.

-- 

     Bo Thorsen                 |   Praestevejen 4
     Free software developer    |   5290 Marslev
     SuSE Labs                  |   Denmark