Re: [gentoo-dev] Re: Optimizing performance

[Patrick Lauer <patrick@gentoo.org>]

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

On Thu, 2005-12-15 at 07:43 -0700, Duncan wrote:
> > I was wondering if there are any sane ways to optimize the performance
> > of a Gentoo system.
> This really belongs on user, or perhaps on the appropriate purposed list,
> desktop or hardened or whatever, not on devel.  That said, some
> comments...  (I can't resist. <g>)
-user has the risk of many "use teh -fomglol flag, it si teh fast0r" ;-)
hardened doesn't have much to do with performance (although I'd be
interested what impact - if any - the different security features have!)
 
> > - don't overtweak CFLAGS. "-O2 -march=$your_cpu_family" seems to be on
> > average the best, -O3 is often slower and can cause bugs
> 
> A lot of folks don't realize the effect of cache memory on optimizations. 
> I'll be brief here, but particularly for things like the kernel that stay
> in memory, -Os can at times work wonders, because it means more of the
> working set stays in a cache closer to the CPU, and the additional speed
> in retrieving that code far outweighs the compromises made to
> optimizations to shrink it to size.  Conversely, media streaming or
> encoding apps are constantly throwing out old data and fetching new data,
> and the optimizations are often more effective for them, so they work
> better with -O2 or even -O3.
I've not seen any substantial benefits from -Os over -O2.
Also the size difference is quite small - ~5M on a "normal" install iirc

> There have been occasional problems with -Os, generally because it isn't
> used as much and gets less testing, so earlier in a gcc cycle series. 
> However, I run -Os here (amd64) by default, and haven't seen any issues
> that went away if I reverted to -O2, over the couple years I've been
> running Gentoo. 
I've seen some reproducable breakage, e.g. KDE doesn't like it at all
>  (Actually, that has been the case, even when I've edited
> ebuilds to remove their stripflags calls and the like.  Glibc and xorg
> both stripflags including -Os.  xorg seemed to benefit here from -Os after
> I removed the stripflags call, while glibc worked but seemed slower. Note
> that editing ebuilds means if it breaks, you get to keep the pieces!)
... which is exactly what I wanted to avoid. Ricing for the sake of it is boring ;-)

> For gcc, -pipe doesn't improve program optimization, but will make
> compiling faster.  -fomit-frame-pointers makes smaller applications if
> you aren't debugging.  Those are both common enough to be fairly safe. 
agreed
> -frename-registers and -fweb may also be useful. (-fweb ceases to be so on
> gcc4, however, because it is implemented differently.)  -funit-at-a-time
> (new to gcc-3.4, so don't try it with gcc-3.3) may also be worth looking
> into, altho it's already enabled by -Os. These latter flags are less
> commonly used, however, thus less well tested, and may therefore cause
> very occasional problems. (-funit-at-a-time was known to do so early in
> the 3.4 cycle, but those issues should have been long ago dealt with by
> now.)  I consider those /reasonably/ conservative, and it's what I run. 
> If I were running a server, however, I'd probably only run -O2 and the
> first two (-pipe and -fomit-frame-pointers).
on a server you'd not use omit-frame-pointers to keep debuggability I think.
> Do some research on -Os, in any case.  It could be well worth your time.
from my (limited) experience it isn't, especially on CPUs with larger caches

> This suggestion does involve hardware, but not a real heavy cost, and the
> performance boost may be worth it.
That's usually not an option :-)

>  Consider running a RAID system.  I
> recently switched to RAID, a four-disk setup, raid1/mirrored for /boot,
> raid6 (for redundancy) for most of the system, raid0/striped (for speed)
> for /tmp, the portage dir, etc, stuff that was either temporary anyway, or
> could easily be redownloaded. (Swap can also be striped, set equal
> partitions on each disk and set equal priority for them in fstab.) I was
> very pleasantly surprised at how much of a difference it made!
Yes. 4-disk raid5 delivers amazing performance with minimal CPU overhead (~10% @1Ghz)
But 4 disks at 100Euro + controller (100 Eur) is more than the price of
a "new" system for most people.
>  If you have
> onboard SATA and are buying new disks so can buy SATA anyway (my case),
> that should do just fine, as SATA runs a dedicated channel to each
> drive anyway.  SCSI is a higher cost option, ruled out here, but SATA
> works very nicely, certainly so for me.
SCSI does deliver better performance, but at a prohibitive cost for "average" users.

> Again, a reasonable new-hardware suggestion.  When purchasing a new system
> or considering an upgrade, more memory is often the most effective
> optimization you can make (with the raid suggestion above very close to
> it).
"The only thing better than a large engine is a larger engine" ;-)
Depending on workload 4G does wonders, but again - prohibitive for the
normal user.

>  Slower CPU and more memory, up to a gig or so, is almost always
> better than the reverse, because hard drive access is WAYYY slower than
> even cheap/slow memory.  At a gig of memory, running with swap disabled is
> actually a practical option,
but if you're investing anyway keep  1G per disk for swap just in
case ;-)
>  altho it might not be faster and there are a
> certain memory zone management considerations. Usual X/KDE desktop usage
> will run perhaps a third of a gig.  That means half to 2/3 gig for cache,
> which is "comfortable".
Agreed, although I wonder why we need so much memory in the first
place ...

>  Naturally, if you take the RAID suggestion above,
> this one isn't quite as critical, because drive latency will be lower so
> reliance on swap isn't as painful, and a big cache not nearly as critical
> to good performance.  
latency is the same, but concurrent accesses can happen, thus throughput
increases.
Still memory > * ... 

> A gig to two gig can still be useful, but the
> cost/performance tradeoff isn't as good, and the money will likely be
> better spent elsewhere.
No. The only thing better than memory is more memory ;-)

> I run reiserfs here on everything.  However, some don't consider it
> extremely stable.  I keep second-copy partitions as backups of stuff I
> want to ensure is safe, for that reason and others (fat-finger deleting,
> anyone?).
Backups are independent of drive speed ;-)
>  Bottom line, reiserfs is certainly safe "enough", if you have a
> decent backup system in place, and you follow it regularly, as you should.
> I can't see how anyone can reasonably disagree with that, filesystem
> religious zealousy or not.
In my experience it is as "safe" as ext3 and XFS, meaning it can go down, but usually just works.

> As I said, I run reiserfs for everything here, but I also have backup
> images of stuff I know I want to keep.
Always backup, what if your disk(s) die?
I've seen 6 out of 10 disks in a RAID die within a few hours ...

So while not completely related to software tweaks thanks for the
hardware upgrade info ;-)

Patrick
-- 
Stand still, and let the rest of the universe move

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