Slashdot Mirror
Optimizing KDE 3.1.x
David Lechnyr writes "This article goes into detail on optimizing KDE for speed. Typically, most distributions include pre-compiled binaries of KDE which are optimized for an Intel i386 computer. Chances are that you're running something faster than this; if so, this should help you tweak the compile process to speed things up a bit."
Gentoo does all this by default. To compile and install optimized binaries for kde, you just type "emerge kde"
use Gentoo or FreeBSD and you get to set compiler flags for everything to be best for your system.
Using prelink will also provide additional optimization.
Hey, all you need here is a decent port system such as FreeBSD's or Gentoo's portage. Not much to see here, i guess.
On the other hand compiling unpatched source with experimental optimization flags for your system is just asking for trouble.
See http://www.sourcemage.org/ All source, downloaded from the authors site and compiled to the settings and optimizations YOU choose.
"Does" this all for you. By "does", I mean that the install guide forcefully tells you to alter your /etc/make.conf file to include support for the features you want and the optimizations you want.
Btw, you don't just sit around for 8 hours waiting for something to compile. If you're in CLI-only, you do the following:
emerge screen
screen emerge kde
C^A C^C
Then you do whatever else you want to do. I recommend getting IRSSI and Lynx for internet-amusement.
If you already have Xfree86 setup, then you do the following:
emerge ratpoison
C^A C^C
Then run whatever graphical X-programs you want in your new ratpoison windows.
This is the beauty of a *modern day* multi-tasking OS like GNU/Linux. This isn't the same crap as Micro$oft. You can compile something AND do other things at the same time, since memory management is great as is multi-tasking (depending on your kernel and compile options for the kernel). Try compiling something using MS's compilers and doing something else at the same time. I compiled WindowMaker, for example, while doing other tasks in ratpoison.
As for compile-time optimizations, I recommend the following:
CFLAGS = -march=cpu_type -Os -pipe -fomit-frame-pointer
That will optimize for small-size binaries and minimal RAM usage. I recommend the -Os optimization for the vast majority of applications, most of which are not CPU-intensive. That includes WMs, DEs, word-processors, spreadsheets, internet browsers, e-mail programs, GIMP, etc. I recommend -O2 for things which are CPU-intensive, like video/sound players, video/sound encoders, DNA/AA sequence alignment, and bayesian phylogenies.
Make sure to
man gcc
So you know what your doing. Hint: once you hit a certain point with optimization, you can't have it both ways. Higher levels of optimization involve trading a memory/speed tradeoff, and you can go one way or the other. As I suggested before, I suggest memory optimizations for non-CPU intensive programs (the one's you'll probably be using all of the time, thus which'll be clogging up your memory); and speed optimizations for CPU-intensive programs, which you probably won't use as much.
social sciences can never use experience to verify their statemen
I know this is offtopic but, the quote at the bottom of the page:
A wise man can see more from a mountain top than a fool can from the bottom of a well.
This doesn't make sense does it?
Shouldn't the fool be on the mountain seeing less than the wise man in the well? may be I'm the fool.
Unfortunately, no one can be told what my sig is...
Why aren't more binary releases compiled for i686 or at least i586? For command-line applications, I can understand compiling for i386. Many of us have a 386/486 PC running as a router or for some other use. But you would think that with the horsepower required by KDE, binary releases would be i586 or i686 by default.
Quality or Quantity, don't tell me they're the same.
This optimizes the hell out of KDE, and it reduces the memory footprint as well. It's such a simple script that I include it right in my ~/.cshrc file:
alias kde twm
You can substitute fvwm2 or some other window manager if you're not a tab enthusiast.
How much performance increase are we talking here? Faster startup times? Better response times? Perceived better response?
There's no reason to work hard without knowing what the benefits are. For that matter, say I do all this and it doesn't seem to work any faster. How do I know if I did something wrong, or if there is nothing to measure?
2 dashes and a space, or just 2 dashes?
Why not use Konstruct instead of typing all this manually?
I don't see where this article is talking about optimizing other then self-compiling. Better read the KDE performance tips.
So far this is the best way I've found to speed up KDE.
The claim about distributions not optimizing for newer CPUs is not true. They usually use something like -march=i486 -mcpu=i686, which means it uses instructions that at least i486 knows, and optimizes them for i686 CPUs. I personally doubt recompiling KDE with better compile flags that those in distro shipped packages makes noticeable difference. Things like prelink, O(1) scheduler, better mapping of binaries into memory, or code optimizations of KDE are things that may make difference.
BTW, even this may make for sure more difference that recompiling : http://dforce.sh.cvut.cz/~seli/download/tips.html
Intel's compiler brags that it is totally compatible with gcc and gives a 30% speed increase to the final result on an Intel processor.
On my code I have seen that to be very true - but I have never bothered trying it on "other people's" code.
How much of it can you compile with that, and what sorts of speed increases (if any) do you see?
I would imagine there isn't much speed increase if it won't even successfully compile of course - but if it works, then is it noticably better?
And I suppose this is only applicable on Linux boxes that are using rpm since the icc installer seems to require that.
There are some odd things afoot now, in the Villa Straylight.
Why the hell does the user disable Xinerama? It seems negligent to disable it without even explaining why you might want it.
why not use the intel compiler while you at it, it's much better than GCC for intel processors?
thank God the internet isn't a human right.
Now that's just irresponsible. Specifying the correct architecture is the best thing you can do when compiling your software, aside from using the -O# settings and not the -frandom-crap flags. If -march=$$$ breaks the software, then the compiler is broken and a bug report needs to be filed. If setting -O3 breaks your software, file a bug report. If -Os breaks your software, file a bug report. If -ffast-math breaks your software, don't use -ffast-math ! It is specifically documented as unsafe for a reason. Why the hell do people think that they know better than the authors of their compiler what optimization settings are safe? The best options for compiling software, all software, is -march=$$$$$ -O#, where # is 1, 2, 3, or s. And remember too, there are no numbers beyond 3 anymore. And 3 is the same as 2 with code-bloating optimizations enabled, same as s is the same as 2 with code-constricting optimizations.
Don't forget -funroll-loops.
I don't get it, why are the instructions telling you to get the raw tarballs and 'make install'? Why not get the source packages from whatever distribution you use and rebuild them with different compiler flags?
It sure would be useful to have a single command equivalent to Gentoo's 'emerge' which means 'download the source packages, build them with my compiler switches and install'. Does any RPM- or dpkg-based distribution have this?
-- Ed Avis ed@membled.com
Durn, my RedHat9 CDs won't install on my Mac! So much for run on anything out of the box. ;-)
;-) Lindows/Xandros/Lycoris/Ark/etc. merge would be nice, since they all do the same thing but just fragment the market. Same goes for Mandrake/RedHat/SuSE/etc.
:(
I really don't agree with this one-Linux-fits-all approach. Separate RedHat's (or whatever) for Desktop and Server use would be great. Which they do now, I suppose; perhaps in RedHat X we'll see better optimizations for desktop usage.
Of course, as I advocate this splitting of distros, I also hate the way we have 20 distros to do the same thing, and they all do it half-assed...
One can argue they each have strengths and weaknesses, but that's mostly because they haven't merged. ~,^
I'd love to see one primary distro for each class of device/use, along with the plethora of hobby linuxes (which I rather enjoy using from time to time). In the commercial world, tho, the fragementation isn't helping with anything other than increased competition, but we all have enough of that from Microsoft/Sun/Apple already, don't we?
It'd also be great financially to have fewer commercial entities. Take Mandrake and SuSE for example; they both employ developers. How many of those developers end up doing the exact same thing for their companies? Two installer dev teams, two config tool teams, etc. Imagine, if they merged developers, they'd have the income from both companies to pay these developers, but now they can stop duplicating. You get more for the money. And Linux distros aren't exactly a high income source, they need to waste as little as possible.
Of course, why I'm wasting time to say this to a bunch of Slashdot users that will, over all, have absolutely no effect on the situation, is beyond me. ~,^