SEO

Everything is done. I have a fully working KDE desktop, and the whole
system was compiled with GCC 4.3.0, CFLAGS="-O2 -march=core2
-fomit-frame-pointer -pipe" and LDFLAGS="-Wl,-O1 -Wl,--as-needed".

One thing didn't compile though: kde-base/arts (an "undefined
identifier" error, due to a missing #include). So I had to do
USE="-arts" for now.

End-result: it's *damn* fast. Well, at least compared to openSUSE 10.3.
No, it's not 5% faster. Everything seems more like 100% faster.
Well, perhaps openSUSE is "bloated", not sure. But anyway, I must say
I'm more than just impressed. "startx" fires up KDE almost in an
instant. Every application starts immediately. This is insane

PS:
It took me 2 days to get there though :P

On Apr 5, 8:46*am, Nikos Chantziaras <rea...@arcor.de> wrote:
> Everything is done. *I have a fully working KDE desktop, and the whole
> system was compiled with GCC 4.3.0, CFLAGS="-O2 -march=core2
> -fomit-frame-pointer -pipe" and LDFLAGS="-Wl,-O1 -Wl,--as-needed".
>
> One thing didn't compile though: kde-base/arts (an "undefined
> identifier" error, due to a missing #include). *So I had to do
> USE="-arts" for now.
>
> End-result: it's *damn* fast. *Well, at least compared to openSUSE 10.3.
> * No, it's not 5% faster. *Everything seems more like 100% faster.
> Well, perhaps openSUSE is "bloated", not sure. *But anyway, I must say
> I'm more than just impressed. *"startx" fires up KDE almost in an
> instant. *Every application starts immediately. *This is insane
>
> PS:
> It took me 2 days to get there though :P

Damn, sounds great.

Can you give a little more of a rundown of how it was done. What
version of GCC were you running (meaning compiled from source or from
a opensuse repo)..
I may have to try this on a test machine before I do it on my
production machine, but man.. sounds good.

ben.kevan@gmail.com wrote:
> On Apr 5, 8:46 am, Nikos Chantziaras <rea...@arcor.de> wrote:
>> Everything is done. I have a fully working KDE desktop, and the whole
>> system was compiled with GCC 4.3.0, CFLAGS="-O2 -march=core2
>> -fomit-frame-pointer -pipe" and LDFLAGS="-Wl,-O1 -Wl,--as-needed".
>>
>> One thing didn't compile though: kde-base/arts (an "undefined
>> identifier" error, due to a missing #include). So I had to do
>> USE="-arts" for now.
>>
>> End-result: it's *damn* fast. Well, at least compared to openSUSE 10.3.
>> No, it's not 5% faster. Everything seems more like 100% faster.
>> Well, perhaps openSUSE is "bloated", not sure. But anyway, I must say
>> I'm more than just impressed. "startx" fires up KDE almost in an
>> instant. Every application starts immediately. This is insane
>>
>> PS:
>> It took me 2 days to get there though :P
>
> Damn, sounds great.
>
> Can you give a little more of a rundown of how it was done. What
> version of GCC were you running (meaning compiled from source or from
> a opensuse repo)..
> I may have to try this on a test machine before I do it on my
> production machine, but man.. sounds good.

Uhm, the above is on a Gentoo box. I mentioned openSUSE because that's
my main system, and now it seems slow compared to Gentoo.

I never compiled openSUSE from source; that's just too hairy to do.

Nikos Chantziaras wrote:

> ben.kevan@gmail.com wrote:
>
>> Can you give a little more of a rundown of how it was done. What
>> version of GCC were you running (meaning compiled from source or from
>> a opensuse repo)..
>> I may have to try this on a test machine before I do it on my
>> production machine, but man.. sounds good.
>
> Uhm, the above is on a Gentoo box. I mentioned openSUSE because that's
> my main system, and now it seems slow compared to Gentoo.
>
> I never compiled openSUSE from source; that's just too hairy to do.

Binary distribution kernels and libraries - the most important one
being /glibc/ - are typically compiled for generic architectures - the same
is true for everything in the system, actually, but the kernel and /glibc/
have the biggest footprint on the performance curve.

Even with /x86_64,/ they make use of generic "optimizations" that will run
equally well - or equally poor, depending on how you value it - on AMD and
Intel.

Gentoo is a source-based distribution and will thus most of the time be
compiled for your specific hardware, unless you stick to the pre-compiled
binary packages, which is what a lot of n00bs do - that way, they can brag
about running Gentoo without having to get their hands dirty <grin> - and
thus Gentoo will always have a faster feel than any other distro - LFS not
included. ;-)

--
Aragorn
(registered GNU/Linux user #223157)

Aragorn wrote:
> Nikos Chantziaras wrote:
>
>> ben.kevan@gmail.com wrote:
>>
>>> Can you give a little more of a rundown of how it was done. What
>>> version of GCC were you running (meaning compiled from source or from
>>> a opensuse repo)..
>>> I may have to try this on a test machine before I do it on my
>>> production machine, but man.. sounds good.
>> Uhm, the above is on a Gentoo box. I mentioned openSUSE because that's
>> my main system, and now it seems slow compared to Gentoo.
>>
>> I never compiled openSUSE from source; that's just too hairy to do.
>
> Binary distribution kernels and libraries - the most important one
> being /glibc/ - are typically compiled for generic architectures - the same
> is true for everything in the system, actually, but the kernel and /glibc/
> have the biggest footprint on the performance curve.
>
> Even with /x86_64,/ they make use of generic "optimizations" that will run
> equally well - or equally poor, depending on how you value it - on AMD and
> Intel.

Although that's true (and makes sense), the biggest speed-ups I have are
with X11/KDE. I could be wrong, but I think the LDFLAGS play the major
role here. `ldd` reports much less linked-to libraries on Gentoo (I use
-O1 as well as --as-needed). The speed difference of the apps
themselves isn't that dramatic (though they *are* a bit faster, like
Konqueror displaying complex pages somewhat faster), but their loading
time is really decreased a lot; Konqeueror pops-up instantly on Gentoo,
but needs about 2 seconds on openSUSE (both have the "Preload an
instance of Konqueror" disabled in the control center).

Now one might argue if those 2 seconds are worth the trouble. Well,
call me a geek, but they are for me :P The grin on my face when a
friend boots the system and is presented with a full eye-candy KDE
desktop in no-time is priceless

RAM requirements are also nice; due to Gentoo's way of handling
dependencies, I don't have to drag-in all the useless stuff I don't
need. For example, on Gentoo I have about 15MB RAM usage on fresh boot
without X11, while on openSUSE it's about 70MB. With KDE fired up for
the first time, my Gentoo setup uses about 80MB, while it's 150+ on
openSUSE. But with 2GB RAM in my case, and today's machines in general
this isn't really a problem, so this is probably not a strong argument.
Still, I think it's very nice to only have stuff you actually need
instead of stuff the dependencies need.

Now I'm not bashing openSUSE here! It's a very nice distro (the best
binary distro for Desktops IMHO; I run away screaming when seeing
Ubuntu). But I start to like Gentoo a lot and I use it more and more often.


> Gentoo is a source-based distribution and will thus most of the time be
> compiled for your specific hardware, unless you stick to the pre-compiled
> binary packages, which is what a lot of n00bs do - that way, they can brag
> about running Gentoo without having to get their hands dirty <grin>

Not much point in running Gentoo at all in this case :P But still, it
makes a *bit* of sense due to "emerge"; that's a hell of a tool to have.

Nikos Chantziaras wrote:

> Although that's true (and makes sense), the biggest speed-ups I have are
> with X11/KDE. I could be wrong, but I think the LDFLAGS play the major
> role here. `ldd` reports much less linked-to libraries on Gentoo (I use
> -O1 as well as --as-needed).

I think it's not due to the LDFLAGS, but rather to Gentoo's USE flag
mechanism. Binary distros have no equivalent mechanism, so they end up
building every possible extension/feature for each program they package.
This, of course, means additional programs and libraries installed as
dependencies.
With Gentoo, otoh, you can selectively enable/disable only what you want,
depending on your actual system. With Gentoo you can easily avoid
building /lots/ of libraries and dependencies by simply doing (just some
examples) USE=-gtk, USE=-doc, USE=-samba, or even USE=-X if you don't have
X. This is something binary distros cannot do, and they are forced to
compile in every possible extension for a given package, even if 80% of the
stuff will sit there unused all the time.

Nikos Chantziaras <realnc@arcor.de> wrote:
[chop]
>
> Although that's true (and makes sense), the biggest speed-ups I have
> are with X11/KDE. I could be wrong, but I think the LDFLAGS play the
> major role here. `ldd` reports much less linked-to libraries on
> Gentoo (I use -O1 as well as --as-needed). The speed difference of
> the apps themselves isn't that dramatic (though they *are* a bit faster,
> like
> Konqueror displaying complex pages somewhat faster), but their loading
> time is really decreased a lot; Konqeueror pops-up instantly on
> Gentoo, but needs about 2 seconds on openSUSE (both have the "Preload an
> instance of Konqueror" disabled in the control center).

What seems to make the most difference for KDE speed is to install prelink,
and then prelink all libraries and binaries on the system, and then set the
flag that tells KDE that the system is prelinked. This is especially true
on systems with relatively slow CPUs.

Prelinking does give a nice overall speed boost to the system too, at the
expense of some disk space, and having to re-run prelink every time you
install something.

> RAM requirements are also nice; due to Gentoo's way of handling
> dependencies, I don't have to drag-in all the useless stuff I don't
> need. For example, on Gentoo I have about 15MB RAM usage on fresh
> boot without X11, while on openSUSE it's about 70MB. With KDE fired
> up for the first time, my Gentoo setup uses about 80MB, while it's 150+ on
> openSUSE. But with 2GB RAM in my case, and today's machines in
> general this isn't really a problem, so this is probably not a strong
> argument. Still, I think it's very nice to only have stuff you
> actually need instead of stuff the dependencies need.

No matter how much RAM you have, decreased usage is always a good thing.
If you keep your machine running, all the RAM will eventually be used for
disk caching. 70 MB less used then is the equivalent of adding a 70 MB
cache to your hard drives.
Unlike the typical Windows box, which will run slower and slower with time
and eventually requires a reboot, a Unix/Linux box will run better with a
long uptime, as it eventually will swap out pages that are loaded but never
used, and reclaim that RAM as disk cache instead.

> Now I'm not bashing openSUSE here! It's a very nice distro (the best
> binary distro for Desktops IMHO; I run away screaming when seeing
> Ubuntu). But I start to like Gentoo a lot and I use it more and more
> often.

There are other reasons to bash them, like their sleeping with Microsoft, or
not supporting SElinux. :-) I used to be a SuSE supporter myself, but
after they were bought by Novell, they have, IMhO, gone downhill. OpenSuSE
isn't much better, as it is limited by what the commercial parent distro
does.

> Not much point in running Gentoo at all in this case :P But still, it
> makes a *bit* of sense due to "emerge"; that's a hell of a tool to
> have.

"Hell" seems to be the right word, yes. It sucks. But it sucks far less
than many other installation tools. (Being a sysadmin, it's all about
picking the lesser evils.)

Regards,
--
*Art

Arthur Hagen wrote:
> [...]
> What seems to make the most difference for KDE speed is to install
> prelink, and then prelink all libraries and binaries on the system, and
> then set the flag that tells KDE that the system is prelinked. This is
> especially true on systems with relatively slow CPUs.

Does this have any ill effects with emerge? RPM-based distros are
hash-checking the executables, modifying them can have strange effects.
Is emerge immune to that?


>> Now I'm not bashing openSUSE here! It's a very nice distro (the best
>> binary distro for Desktops IMHO; I run away screaming when seeing
>> Ubuntu). But I start to like Gentoo a lot and I use it more and more
>> often.
>
> There are other reasons to bash them, like their sleeping with
> Microsoft, or not supporting SElinux. :-) I used to be a SuSE
> supporter myself, but after they were bought by Novell, they have, IMhO,
> gone downhill. OpenSuSE isn't much better, as it is limited by what the
> commercial parent distro does.

I'm not interested in political things, really. I couldn't care less
about Novell's business decisions; openSUSE is a stable and polished
distro, and that's it. Novell being Microsoft's b*tch is perhaps
important to Novell's commercial customers, not me. If they want to
become "evil", let them be; the software in openSUSE isn't.

With the other big commercially backed-up distro called Fedora, I was
downgraded to a Red Hat beta tester with many things breaking
constantly. This in not the case in all the years I use (open)SUSE. At
least it doesn't feel that way.

Nikos Chantziaras <realnc@arcor.de> wrote:
> Arthur Hagen wrote:
>> [...]
>> What seems to make the most difference for KDE speed is to install
>> prelink, and then prelink all libraries and binaries on the system,
>> and then set the flag that tells KDE that the system is prelinked. This
>> is especially true on systems with relatively slow CPUs.
>
> Does this have any ill effects with emerge? RPM-based distros are
> hash-checking the executables, modifying them can have strange
> effects. Is emerge immune to that?

It has no adverse effects on emerge or gentoo tools. It can have an effect
on some tripwire type tools which erroneously make the assumption that
binaries should be unchanged. prelink is a somewhat simplified cousin of
IRIX' "rqs" (requickstart) system. Since IRIX by default requickstarts
after installation, most tripwire type tools had to start doing the right
thing, and checksum an unlinked temporary copy, not the
quickstarted/prelinked code. Else they would be rather useless on IRIX
systems (and later, linux systems with prelink).

One caveat: You need to have "pic" enabled as a USE flag, system wide. But
having position independent code is usually a good idea anyhow.

Regards,
--
*Art

Arthur Hagen wrote:
> Nikos Chantziaras <realnc@arcor.de> wrote:
>> [...] Does [prelink] have any ill effects with emerge? RPM-based
>> distros are hash-checking the executables, modifying them can have
>> strange effects. Is emerge immune to that?
>
> [...] One caveat: You need to have "pic" enabled as a USE flag,
> system wide. But having position independent code is usually a good
> idea anyhow.

This:

http://www.gentoo.org/doc/en/prelink-howto.xml

Says: "Also make sure that you do *not* have -fPIC set in your
CFLAGS/CXXFLAGS."

Other pages say that on AMD64 (that's what I have) -fPIC *must* be
enabled on shared libs.

I don't have "pic" in USE, and I also don't have "-fPIC" in CFLAGS.
Adding "pic" to USE followed by an `emerge -pDN world` only results in:

[ebuild R ] media-libs/mesa-6.5.2-r1 USE="pic*"
[ebuild R ] app-arch/gzip-1.3.12-r1 USE="pic*"

I hereby announce that my confusion is complete :P