


Optimizing KDE 3.1.x 83
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."
mandatory gentoo user post... (Score:5, Informative)
Re:mandatory gentoo user post... (Score:2, Funny)
Re:mandatory gentoo user post... (Score:4, Insightful)
Re:mandatory gentoo user post... (Score:1)
The problem is most people think there's going to be an option/etc they missed and didn't know about and will be running a flawed/broken system. Heck, I can barely get the guys at work to watch me patch a kernel for real-time linux or something, they want it all pre-packaged.
Re:mandatory gentoo user post... (Score:1, Troll)
Re:mandatory gentoo user post... (Score:1)
Re:mandatory gentoo user post... (Score:2, Informative)
Re:mandatory gentoo user post... (Score:1)
Re:mandatory gentoo user post... (Score:1)
Re:mandatory gentoo user post... (Score:2)
But if these settings are breaking the software then surely it's the fault of the gcc compiler or the software in question?
Gentoo's ebuild are often just scripts, the actual software is often downloaded direct from the website of the actual developer of the software.
Re:mandatory gentoo user post... (Score:1)
Re:mandatory gentoo user post... (Score:2)
"I'm too stupid to understand that circular dependencies can be resolved by specifying BOTH
Actually, dependancy hell is when you download program X to try it out. rpm -i and it requires package Y... search around and find package Y only to
Mandatory RPM user post... (Score:2)
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?
prelink (Score:5, Interesting)
Re:prelink (Score:4, Informative)
This is done automatically by the libc and the dynamic linker.
Re:prelink (Score:4, Informative)
FYI, prelinking KDE is not easy. On Debian the QT package has OpenGL support compiled in. The OpenGL library is not prelinkable because it is not PIC (Position Independent Code). Since all KDE applications are linked to QT and thus to OpenGL indirectly, this also means that all of KDE isn't prelinkable. I don't know of any KDE app that actually uses QT's OpenGL support, so I don't know why it is compiled in. To prelink KDE I had to compile my own version of QT without OpenGL support. This works to allow prelinking, but using a a version of QT compiled with different options makes QT's style plugins not work and has other disadvantages. There are two real solutions:
Re:prelink (Score:5, Informative)
I looked at the discussion on prelinking in Debian, and it's not all such a straight forward issue.
When you have a binary, and run it, it loads all the libraries that the binary uses. When it loads the libraries, it basically puts it into memory, and then tells the binary the memory address of everything in the library. I think this is things like functions, data structures, etc.
Anyway, prelinking is when you now modify the binary, and tell it about the particular version of the libraries that it links (say version 1.0.3 or whatever) Now when you run the binary and use that particular version of the library, it loads the library into a specific memory address, and the binary already knows the memory address of all the functions and data structures.
This speeds up loading time and saves memory.
If the library version changes, then it falls back on the old method.
Now, the trouble is, when you update a library, you must update all the binaries. This means (as far as I see it) either you also update all the appropriate binaries by running prelink again on all the binaries, or you update the packages the binaries are in.
The second option would cause libraries to have huge number of dependancies, and would make minor upgrades of libraries horrendous for dial up users.
The first option has slightly more subtle problems. The problem is that it means when you update a library, it goes and unpredictably modifies binaries. This plays absolute havoc with things like tripwire, and any kind of security.
This is merely my understanding from 5 mins research, so take it as you will.
Re:prelink (Score:2)
Re:prelink (Score:4, Insightful)
Re:prelink (Score:2, Insightful)
Re:prelink (Score:1)
Thanks for the information !
portage ? (Score:1, Offtopic)
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.
Re:portage ? (Score:3, Interesting)
Absolutely. Using either of these technologies allows one to compile any piece of software using the best possible optimizations for your system.
Re:portage ? (Score:2)
People who use Gentoo are largely irresponsible with it; I migrated to Gentoo on my workstations coming from FreeBSD, so I know to be sparing with CFLAGS, etc.
The distribution does need significant policies with respect to how to compile things. FreeBSD will not let you impose unruly CFLAGS like -fignore-important-functions and then report bugs. It will even filter out -march and replace it with something the development team supports.
Gentoo definitely does need to mature.
Re:portage ? (Score:5, Interesting)
-march=athlon-tbird -Os -pipe -fomit-frame-pointer
Btw, compiling everything from scratch is hardly "unstable". That's what FreeBSD does. Furthermore, memory optimizations often-times increase system-stability, by reducing the likelihood of situations where there isn't enough RAM. Furthermore, some of the USE settings increase stability by eliminating compiled-in support for crap that you don't use. If you don't use something, and support for it is compiled in, it's just useless crap that has the potential to reduce stability.
Re:portage ? (Score:1)
Re:portage ? (Score:5, Informative)
the difference between a 386, 486, and pentium I-IV isn't just clockspeed and MMX, a handful of new instructions have been added. If you don't specify the arcitecture, you'll generate i386 compatable code.
so if (i == 0) i = 1234; will generate code like this:
cmp eax,0
jne L1
mov eax, 1234
L1:
A PII however, can do this:
cmp eax,0
cmove eax,1234
that might not look all that much better, but branches are a huge bubble in the pipeline, and are horrible for performance.
I do this with ALL my software, automatically. (Score:5, Interesting)
Gentoo... (Score:4, Insightful)
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.
Re:Gentoo... (Score:1, Offtopic)
Re:Gentoo... (Score:3, Informative)
I am also not talking about a 486. That was
Re:Gentoo... (Score:2)
That's somewhat weird, since I've done exactly that for years, with much less powerfull systems. Visual Studio running on Windows NT, 98, 2000: no problem.
These days I do the same on a P4 1.7 GHz, but Borland C++Builder instead of
Re:Gentoo... (Score:2)
I did not say that you can play games or encode OGG-files while compiling software and get good performance/responsiveness.
Sounds like something's wrong with your OS or setup if you can't do that on your 1.1GHz m
Re:Gentoo... (Score:2)
Re:Gentoo... (Score:1)
For the most part I'd agree with you. However, when there is a lot of disk IO, it will still bind up some. Not so bad with SCSI disks, but IDE drives, even with DMA you will run into problems.
When gentoo is doing the copying part it can still be pretty chunky on the desktop. Granted usually that is for a fairly short period of time. During the build its pretty reasonable, as it should be.
Re:QOTD (Score:1)
Re:QOTD (Score:1)
Re:QOTD (Score:1)
ie. The wise man knows about things like bugs and molecules etc, but the fool down the well can probably only see water and/or mud.
See, this is what I don't get... (Score:1)
Re:See, this is what I don't get... (Score:2, Informative)
Re:See, this is what I don't get... (Score:1)
hrm... (Score:1)
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...
Here's a script that works. (Score:5, Funny)
alias kde twm
You can substitute fvwm2 or some other window manager if you're not a tab enthusiast.
How much? (Score:3, Insightful)
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?
Re:How much? (Score:1)
Konstruct (Score:3, Informative)
KDE performance tips (Score:3, Informative)
Hmmmm (Score:1, Funny)
Re:Hmmmm (Score:1, Informative)
lwm [freshmeat.net]
PekWM [freshmeat.net]
WindowLab [freshmeat.net]
I doubt it makes noticeable difference (Score:1)
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 ma
Re:I doubt it makes noticeable difference (Score:1)
Re:I doubt it makes noticeable difference (Score:1)
Re:I doubt it makes noticeable difference (Score:2, Interesting)
Re:I doubt it makes noticeable difference (Score:1)
what about icc? (Score:1)
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
Re:what about icc? (Score:1)
Re:what about icc? (Score:3, Interesting)
That's only true for pre-GCC 3.1 releases. GCC 3.2 can produce code that rivals that of Intel C++. GCC 3.1 and 3.2 contain lots and lots of x86 optimization improvements.
Re:what about icc? (Score:2)
missing option (intel) (Score:1)