Re: [gentoo-dev] Optimizing performance

[Chris Gianelloni <wolf31o2@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 3972 bytes --]

On Thu, 2005-12-15 at 13:48 +0100, Patrick Lauer wrote:
> - don't overtweak CFLAGS. "-O2 -march=$your_cpu_family" seems to be on
> average the best, -O3 is often slower and can cause bugs

-O2 -march=$your_cpu_family -pipe -fomit-frame-pointer

-pipe
        Use pipes rather than temporary files for communication between
        the various stages of compilation. This fails to work on some
        systems where the assembler is unable to read from a pipe; but
        the GNU assembler has no trouble.

-O also turns on -fomit-frame-pointer on machines where doing so does
not interfere with debugging.

(However, x86 is not one of these machines, so you can turn it on if you
are not a developer doing debugging for a slight additional speed
increase)

-fomit-frame-pointer
        Don't keep the frame pointer in a register for functions that
        don't need one. This avoids the instructions to save, set up and
        restore frame pointers; it also makes an extra register
        available in many functions.

> - don't do anything with ASFLAGS, LDFLAGS. This causes weird random
> breakage (e.g. LDFLAGS="-O1" causes prelink to fail with "absurd"
> errors) and doesn't give a noticeable performance boost

Correct.

Also, running prelink can improve speed at the cost of disk space.

> - check that all IDE disks use DMA mode, otherwise they are limited to
> ~16M/s with a huge CPU usage penalty. Sometimes (application-specific)
> increasing the readahead with hdparm gives a huge throughput boost.

I typically use the same hdparm settings as listed in the Handbook:

disc0_args="-d1 -A1 -m16 -u1 -a64 -c1"
cdrom0_args="-d1 -c1"

> - kernel tweaks like preempt may increase the responsiveness of the
> system, but often reduce throughput and may have unexpected sideeffects
> like random audio stutter as well as random kernel crashes ;-)

This is especially true on non-x86 architectures.

> - kernel tweaks like setting swappiness or using a different I/O
> scheduler (CFQ, deadline) should help, but I'm not aware of any "real"
> benchmarks except microbenchmarks (can create 1M files 10% faster!!!!! -
> yes, but how does it behave with a normal workload?)

CFQ is much worse for a desktop system.  I tend to like deadline for
playing games.  These can probably make a bit more difference than a new
-fomg-itsofast-and-broken-math added to CFLAGS.

> - using a "smarter" filesystem can dramatically improve performance at
> the potential cost of reliability. As data on FS reliability is hard to
> find from unbiased sources this becomes a religious issue ... migrating
> from ext3 to reiserfs makes "emerge sync" extremely much faster, but is
> reiserfs sustainable?

Well, reiserfs 3 isn't so bad on architectures where it doesn't vomit
all over itself immediately.  Also, resierfs loses much of its luster if
you're running ext3 with dir_index.  There was a tip in the GWN about
turning on dir_index on an already formatted file system.  If formatting
a new one, just use mkfs.ext2 -J -O dir_index /dev/$whatever to create
your file system.

> Are there any application-specific tweaks (e.g. "use the prefork MPM
> with apache2")? What is known to break things, what has usually
> beneficial behaviour? Are there any useful benchmarks that show the
> performance difference between different settings?

Well, turning on SBA and Fast Writes on Nvidia always helps.  As for
benchmarks, I think the issue is it depends entirely on usage.  Having
something that is 30% faster on paper isn't very useful if you never do
it the way the benchmark does.  I wish I had more numbers/examples here,
but there isn't really much in the way of decent benchmarks published
and readily available.  Hopefully some other people will know of more of
them than I do.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]