Results 1 to 4 of 4

Thread: The final frontier - new in development

  1. #1
    Guest

    The final frontier - new in development

    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

  2. #2

    Re: The final frontier - new in development

    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 ..


  3. #3
    Associate
    Join Date
    Mar 2002
    Posts
    13

    Re: The final frontier - new in development


    i hope that other applications will then be able to use this as well
    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 it

    .. at the moment i think only kde and qt are using objprelinking ..
    they're not really using it
    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

  4. #4
    Guest

    Re: The final frontier - new in development

    too bad we'll have to wait so long...

Similar Threads

  1. Software development using QT3 or QT4
    By lsatenstein in forum Linux - Software, Applications & Programming
    Replies: 0
    Last Post: 09-11-2011, 12:24 PM
  2. Arrested Development
    By countach44 in forum General Chat
    Replies: 1
    Last Post: 11-15-2005, 12:15 PM
  3. The Fifth & Final
    By stryder144 in forum General Chat
    Replies: 24
    Last Post: 10-15-2004, 05:37 AM
  4. RH9 can't add development tools?
    By cgchris99 in forum Linux - General Topics
    Replies: 7
    Last Post: 05-06-2003, 07:49 PM
  5. QT3 Development Files
    By Ashcrow in forum Linux - Software, Applications & Programming
    Replies: 6
    Last Post: 08-10-2002, 06:28 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •