Just thought I would share this VERY interesting mail I got from Ralinx this morning about the new stuff in development for GCC and the impact it will have on Linux development.
Subject: Re: Question about kdeinit
Date: Mon, 8 Apr 2002 17:51:32 +0200
From: Bo Thorsen <bo@sonofthor.dk>
To: kde-core-devel@mail.kde.org
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
hmm .. this prelinking stuff looks good , and if its going to be implemented into gcc - binutils it will be an advantage, i hope that other applications will then be able to use this as well .. at the moment i think only kde and qt are using objprelinking ..
it will no longer be up to the application to be able to use it, it will use it no matter what as long as the applications are compiled with the compiler that supports it, and linked with a binutils version that supports iti hope that other applications will then be able to use this as well
they're not really using it.. at the moment i think only kde and qt are using objprelinking ..
they allow it to be used but they don't recommend it at all... there's a difference
but yea, so far it's mostly QT and KDE that allow objprelinking, but in theory every C++ application should be able to use objprelinking. So u can actually hack every Makefile u want (as long as it's a C++ app) to make sure it'll use objprelinking. i wouldn't recommend it though because objprelinking is just a dirty hack. for a lot of people, it doesn't cause any problems with QT and KDE, but for a lot of other people, it does cause problems. It'll probably cause lot's of problems with other apps too
i suggest staying as far away from objprelinking as u can (except for QT and KDE if it doesn't cause problems for u) until it's properly implemented in gcc and binutils
Posting Permissions
Reply With Quote
Bookmarks