[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On Sunday 17 September 2006 09:11, Neil Williams wrote: > I never did understand the appeal of gentoo. The idea of spending ALL > that time rebuilding from source, yuk. Under most circumstances, i would say that optimisation is not worth the hassle involved (unless it's a simple matter of editing a file, typing a command, and waiting x hours like in the case of Gentoo) - only limited applications really benefit massively from optimisation, and it's not always down to -O2 -mtune=xx - there are ltos of other things that can improve performance (or at least the perceived speed in the case of preemption :)) It is a very limited example that is not true for most binaries, but we (work) get > 500% speed improvement using *all* code compiled with gcc 4.1 and -O3 compiled for nocona on a custom system compared to compiling it and running on a bog standard Debian 3.1 install on the same machine. However, $work_product is C++, heavily templated and threaded, so does gain //massively// from GCC 4.1's new sexy optimisation subsystem (as does firefox and most of KDE) - but you will not notice such improvements in performance with a lot of other things, and it's not only down to your compiler and compile flags, a lot of other things can come into play, depending on the applications profile: Optimising just a single binary (like firefox) will provide some limited optimisation, but you really need to also optimise all runtime dependencies if you're going to bother - and even then i doubt you'd notice it being that much faster after 10 minutes of using it until you go back to thinking "my god this is sloooooooow" :) Also, with firefox, you chop a whole load of startup time by prelinking the binary, as it pulls in a scary amount of libs at runtime: ldd /opt/firefox/firefox-bin | wc -l 51 NPTL is a lot faster than linuxthreads in my experience (and a lot less buggy), so glibc using NPTL is, in my opinion, much preferred over linuxthreads. obvously this only applied to applications that make use of threads heavily, which is probably not most. ensuring your environment supports fast system calls (sysenter) will also *massivly* improve system call speed over int 0x80 with modern CPUs (infact, the newer the CPU, the slower they are [1]). Fast system calls involve nothing more than a fairly new (2.6 kernel and glibc > 2.3.1 *iirc*), and will massivly improve the perfomance of aplpications that make a lot of system calls. Of course, vendors have probably backported most of the above, and ensure binaries are optimised (and potentially prelinked on install) - however debian seems to miss all of the optimisations mentioned (for good reasons, i'm sure), and most dists will not be using gcc 4.1 yet which is where perforrmance improvements for C++ binaries REALLY shows. note you can host optimised applications (with a modern version of gcc) and their dependencies in a chroot. If you statically compile them you can run them outside of the chroot while keeping the same optimisations - this is how we do it with $work_product. re gentoo: I prefer it for the simple fact that the only other dist i like (debian) is only useful for about 3 months every 3 years until it's out of date, and *i* can choose my compile time configuration. keeping it up to date is most certianly a complete pita, but that's what pookey is for, right? :) i've been tempted to look at ubuntu, however, i couldn't imagine being forced to use the vendors choice of compile time configuration ever again (and i don't mean compiler optimisation) ... ~ Theo - very, very tired. 1 - http://lkml.org/lkml/2002/12/9/13 -- Theo P. Zourzouvillys http://www.crazygreek.co.uk theo@xxxxxxxxxxxxxxxx -- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/linux_adm/list-faq.html