Hello
I would like to thank You all for Your suggestions. But just for a small sample, by all arguments. Try to recomile a samba for a actual CPU plattform. When You run it as it comes with the dist, You will have around 1 MByte/second transfer performance. After recompile its around 6 MBytes/second. The same on KDE, Apache etc. It's more than 5% Alan hmm?
But I see, we could discuss weeks about this theme. The only thing i need is a properly howto for recomiling the distribution. Please...
Kind regards
Roland Kaeser
Andrew Farris wrote:
On Sun, 2004-10-24 at 21:42 +0200, Kyrre Ness Sjobak wrote:
søn, 24.10.2004 kl. 21.34 skrev Andrew Farris:
On Sun, 2004-10-24 at 18:40 +0200, Roland Kaeser wrote:Yes, but (being anything than a compiler specialist...) can't you
Hello
There is a mistake. I would like to completly rebuild the whole distribution rmps from the srpms iso's not just the kernel.
Kind regards
Roland Kaeser
Are you considering the amount of cpu time required to build this entire distro? It is not something I think you want to do on a workstation, I'd suggest rebuilding only those individual packages for apps you run constantly. Build firefox, the KDE packages, xorg-x11, and the kernel, perhaps a very few others.
If absolute optimization is your goal, go Gentoo, and experience that extra 5% Alan is talking about in his post. I've found rebuilding i686 for the constant use packages makes them 'feel' faster, but I am not positive it is more than illusion. Rebuilding FC2 will take longer than a complete build of Gentoo.
Why will it help very little? FC already used the best possible choice of instruction order for pentium-pro and up machines, which means unless your app is going to be using SSE instructions there isn't that much more you can do.
optimize specialy for a spesific CPU, not just an arch? And how can this
affect loading times?
I'm also not a compiler specialist, but here is a general overview of the situation as I understand it.
Yes, there are three main compiler setting choices of interest you could
change. What instruction set to use (march), what optimization level to
use (Ox), and what instruction ordering to use when optimizing (mtune).
Fedora uses march for i386 machines so that the code will work on old hardware, but optimizes O2 (the fastest considered stable and reliable) and an mtune for i686 (pentium pro) so that it runs the best order of instructions for a i686 it can. From there on up the architectures change most in ways that compiler optimizations do not capitalize on, or that the hardware does despite your code (some cpus actually disobey). You can optimize to a higher level (O3) but you see marginal gain and instability, or you can use higher instruction sets which will see gain but only for types of code that exploit the instructions (streaming media mostly).
As for load times, you will not see excessive change in that, what you'll see is lower cpu usage at peak load and lower latency when performing more tasks at once (jerky responsiveness).
Lower load times are most effected by Prelinking, so making sure that your system is not failing to complete the prelink is something you could do quickly.
