You are not logged in.
Pages: 1
On every distribution I am using I try to have kernel compiled for my processor architecture (usually athlon-xp)... but does it speed up or have any effect if the whole distro is compiled for i686?
I remember that MPlayer in early versions wanted you to use kernel compiled for your real proc architecture...
Does anybody have an idea how to benchmark system (if there is any increase in speed)?
Wojciech Szlachta
"Earth is the cradle of humanity, but one cannot live
in a cradle forever." Konstantin E. Tsiolkovsky
Offline
well on my amd XP 1800+ it never realloy made any noticable differences having it optimized athlon-xp.
AKA uknowme
I am not your friend
Offline
I played with this long ago when I first came to arch. I ditched it and stayed with i686 optimizations for custom kernels because in my experience it was a tad faster. As far as I could tell/imagine arch was faster with a i686 kernel because all the packages on the system itself matched the kernel config. So basically the kernel might have run a tad smoother but all the other software on the box ran a tad slower as they "clashed" with the kernel config and their optimizations. Unless you want to compile every package yourself (ignoring the point of arch imho) it seemed to be a pointless exercise to compile a kernel specifically for your cpu.
This was just my experience though and I have no real way of benchmarking other thank my perception of how it all ran.
Offline
ok, but then why a lot of other distros - debian, red hat, etc have their kernel packages for many different architectures?
"Earth is the cradle of humanity, but one cannot live
in a cradle forever." Konstantin E. Tsiolkovsky
Offline
ok, but then why a lot of other distros - debian, red hat, etc have their kernel packages for many different architectures?
i should have expanded. i don't disagree that there are benefits but noticable ones they weren't to me. Most optimaizations usually do not have speed bumps , instead they allow for your processor to be used to its full design specifications (hopefully).
i just can't be bothered. thats my preference and i think you should use what ever preference you are drawn to. you may want to optimize the majority of base to your upgraded kernel, if you should do so.
AKA uknowme
I am not your friend
Offline
i agree with LavaPunk on this one. we had a discussion on irc about it a few months back.
before i upgraded my comp recently, i was running a duron 800. it was not fast enough to render the highest resolution matrix revolutions trailer (quicktime) with mplayer.
i tried compiling mplayer with different CARCH settings (i686, athlon), and to my surprise, i686 ran better. this wasn't simply a perception in performance. the audio was many seconds more out of sync when mplayer was compiled for athlon. it was a repeatable test.
the reason for this was that my kernel was compiled for i686.
if you wish to squeeze out every last bit of performance, you could compile your kernel and all 'important' apps with your architechture in mind, but it is not worth the effort in my opinion. The benefit simply isn't there. Stick to i686, it will make things simpler.
Perhaps the only place where you would find benefit to compiling for your architechture is if you have an amd64 chip, but then not all programs are tested in 64-bit and may be buggy. If you ask me, this is more the realm of the Gentoo distro. Arch is meant to be simple and fast, in that order.
Offline
Recompiling kernel is good idea...
I add to kernel some patches to improve desktop experiences :> (like staircase scheduler, alsa from snapshot, hirex posix timer and sth), and I also turn on -Os optimalisation instead of -O2 that is default.
Gnome - The weakest link!
Linux, *not* GNU/Linux!
Offline
I have a very customised kernel and there is no doubt in my mind that is is faster than the stock Arch kernel. It is much faster.
I don't trust these opinions on i686 kernel meshing with an i686 optimised system too much. But I spose you can't argure with experience.
For me, compiling my own kernel and compiling my own KDE sped up my system a lot. Thoroughly pleased I was and still am
Offline
...and compiling my own KDE...
Only KDE? Or you compile Qt also?
:: / my web presence
Offline
Well, I have to recompile my kernel anyway, because I apply some patches and therefore I change my kernel architecture to athlon-xp. Hmm, it is the first time I ever heard that it can actually cause a slow down of my system... and to be honest I don't believe it. I thing that there must be an increase in speed, the question is if it is noticeable... some people say yes, others say no...
If somebody could suggest a benchmark I would be glad to perform it and send the results here... but I have no idea how to perform it so that it won't be biased...
What about:
dd if=/dev/urandom of=/file bs=1M count=1000
and than using different kernels:
time gzip file
however that won't use any of the special instructions that athlon-xp can use and i686 cannot...
hmm, encoding mp3 or a movie?
I have never done either of these before...
Wojciech Szlachta
"Earth is the cradle of humanity, but one cannot live
in a cradle forever." Konstantin E. Tsiolkovsky
Offline
I'm curious about this too. I have an AMD64 waiting to be loaded and I want the 32-bit binary plugins to work for Firefox(Flash, etc.) so I'm wondering if an AMD64 kernel would break/interfere with i686/32-bit binaries(!?).
-- Linux! Isn't it time?
Offline
I tried a customized kernel not so long ago, 2.6.7-ck5. It really felt faster and more responsive. On the other hand, it caused XMMS to skip whenever CPU usage got high (i.e. while browsing) which was a real annoyance, so I had to go back to the stock kernel.
I guess my point is that customized kernels may improve one thing and degrade another. But I doubt selecting your own CPU architecture will trigger that.
Some PKGBUILDs: http://members.lycos.co.uk/sweiss3
Offline
your optimizations can make a difference. i have never used -O3 optimization but my understanding from LOTS of people that have use such settings is that they can slow applications because they create bigger binaries.
with this specific box i have tried several different setups in the end i always went back to generic -i686 optimizations because for my system the extra maintenance of a different kernel was a waste of time.
i also did not want to unduly affect packages when i was a maintainer.
AKA uknowme
I am not your friend
Offline
I don't compile my own Qt currently, but plan to. I have heard it said that profiling KDE apps tends to suggest the bottle-necks are mostly at the Qt level.
With regard to compiling O3, I generally have found that the bloated binary rumour is not strictly true. The O3 optimisation works, in part, by inlining more aggresively, and with c++ especially this can bring good performance improvements. I'd say it's a pretty rare function that when inlined would cause performance degradation or even serious bloating of the binary size.
I also mostly experience O3 producing smaller binaries than Os for mid-sized binaries. I only tested this with c++ applications though. The reason, presumably, is the inlining.
Offline
Pages: 1