Optimizing for system responsiveness

[helmers]

To increase your system responsiveness, you can lower the latency of the kernel scheduler. (with lolo-sources, you can set a numerical value. The default is 100, I use 1500 right now, which might be a bit too much.)

The second thing, is to set a shorter read-ahed value with hdparm. A value of 2 will be okay.

"hdparm -a2 /dev/hda", where /dev/hda is your hard drive.

You should be awere, that this increases system overhead, and overall speed. If you want it the other way, set read-ahed much higher, up to 255, which is max. 128 is a good value for servers.

"hdparm -a128 /dev/hda", where /dev/hda is your hard drive.

And finally, since the biggest slowdown in most systems is the hard drive, the "-Os" compiler flag is a very good one. It makes smaller executables, which means less memory and less to read from the HD. To prove that it is a good one, the gentoo-sources also uses this flag.

Please let me know if you have any comments, the reason I'm posting is because I've been wondering about these things myself, hope you find it useful.


--
Regards,
Helmers

[pjp]

Wouldn't compiling for speed, as opposed to Os, be more of an advantage with modern hardware?
_________________
Quis separabit? Quo animo?

[rac]

[borenson]

its set for -Os because it minimises the overhead due to cache invalidation of the kernel butting in 100 (or 1500!) times a second

[ghetto]

This is just my humble opinion but usual when it comes to such things the sensible path lies somewhere in the middle.

Options such as -funroll-loops and -O3 supposedly speed stuff up by optimizing the binarry itself, which has the sorry side effect of causing a great amount of bloat. The -Os optimization makes smaller binary's and thus they can load much faster because of the reduced footprint, but the program itself will not be as responsive when compared to something that is compiled with -O3. In either case, personally, i can barely "notice" the difference on a modern piece of hardware. Although i know there is a difference because I have experimented with different compiler options and compared the resulting binary sizes and compared how long it take to load the program, however judging the program responsivness once loaded is a bit harder as it would require some actual benchmarking.

Im not a compiler buff, feel free to refute me if im wrong. However please provide explaination if you do so.

my cflags:
"-march=athlon -O2 -pipe -frerun-loop-opt -frerun-cse-after-loop
-fexpensive-optimizations -fprefetch-loop-arrays -falign-functions=4
-Wno-deprecated"
With these options i believe ive managed to create a binary that is about 1/10th smaller but just as responsive once loaded(they even load faster) than something compiled with plain:
"-march=athlon -03 -pipe"
The flag im most suspicios of is '-falign-functions=4' ive read what it says about it in the manual but if someone could actually put it in simple terms and give an example of how this one works i would be much obliged, but i do know it is doing something good because my binarys are more responsive with out size increase.
_________________
Blizzard you suck.

[474]

1500 sounds a bit excessive. YMMV, but I wouldn't go above 1000 unless there's a strong indication that it is beneficial, and would recommend starting at around the 500 mark. Red Hat uses 512hz for i686 kernels and personally, I trust Red Hat to pick something sensible.

[idl]

You can also try using a different filesystem ReiserFS and XFS are fast popular alternatives to the extX filesystem.

[PhilCl]

to illustrate the point - I used all the optimisations I could. -funroll-loops etc inc options like foptimizesibling calls, It's great fome some samll routines but when applied to Xfree - It had a mem footprint of 80Mb - This all comes down to the tradeoff between cache size, cache architecture (hence alignment ) and the latency difference between registers cache memory and storage systems.

My feeling is that for a small function or program which fits onto a few cache lines - optimize it to hell but as soon as it becomes part of a larger program it causes more problems that it's worth, <it's only really better if the routine is run many times hence the advantage is worthwile otherwise the penalty for a cache miss is too large>

hope that makes a bit of sense - it's the computer architecture problem

[keratos68]

[red_over_blue]

Dazzle68,

You obviously seem to know what you are talking about. What cflags would you recommend for a 1.4GHz Athlon T-Bird with 512 megs of ram and 1024 megs of swap? I would like stability over speed, but currently only use

CFLAGS="-mcpu=i686 -O2 -pipe -fomit-frame-pointer"

since I was reading another post about -O3 introducing some kind of software/hardware performance deficiency as compared to -O2.

I know I could read the entire man page for gcc... but it is very cryptic to someone who is not a fulltime/hobby programmer. I have programing knowledge, but not to that extent.



Thanks for any reply.

[474]

[keratos68]