From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.54) id 1EmvKp-0001oN-JL for garchives@archives.gentoo.org; Thu, 15 Dec 2005 15:48:00 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id jBFFkjTe022411; Thu, 15 Dec 2005 15:46:45 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [134.68.220.30]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id jBFFhJj0006269 for ; Thu, 15 Dec 2005 15:43:19 GMT Received: from dslb-084-063-034-115.pools.arcor-ip.net ([84.63.34.115] helo=[10.0.0.13]) by smtp.gentoo.org with esmtpa (Exim 4.54) id 1EmvGI-0006ap-Cc for gentoo-dev@lists.gentoo.org; Thu, 15 Dec 2005 15:43:19 +0000 Subject: Re: [gentoo-dev] Re: Optimizing performance From: Patrick Lauer To: gentoo-dev@lists.gentoo.org In-Reply-To: References: <1134650885.4634.57.camel@localhost> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-D1skACkJ7AqfcMi6zKJX" Organization: Gentoo Date: Thu, 15 Dec 2005 16:43:16 +0100 Message-Id: <1134661396.4634.89.camel@localhost> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 X-Archives-Salt: 2b6f5e29-ac94-48b2-8665-94f483e50d36 X-Archives-Hash: 53c3897c4a7ecfa1f046aa05d28526f4 --=-D1skACkJ7AqfcMi6zKJX Content-Type: text/plain Content-Transfer-Encoding: quoted-printable 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. ) -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!) =20 > > - don't overtweak CFLAGS. "-O2 -march=3D$your_cpu_family" seems to be o= n > > average the best, -O3 is often slower and can cause bugs >=20 > A lot of folks don't realize the effect of cache memory on optimizations.= =20 > 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.=20 > 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.=20 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 afte= r > 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 b= oring ;-) > 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.=20 agreed > -frename-registers and -fweb may also be useful. (-fweb ceases to be so o= n > 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.=20 > 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 cache= s > 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, o= r > 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 "averag= e" users. > Again, a reasonable new-hardware suggestion. When purchasing a new syste= m > 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 i= s > 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. =20 latency is the same, but concurrent accesses can happen, thus throughput increases. Still memory > * ...=20 > 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, b= ut 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 --=20 Stand still, and let the rest of the universe move --=-D1skACkJ7AqfcMi6zKJX Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2-ecc0.1.6 (GNU/Linux) iD8DBQBDoY8UqER3hOUoZM4RAquVAJ905bDsTuIvAsLyGAnYQcdcZcDAZQCgjLzr C0HFou7/h10BjaIFCDC5MA4= =7S7q -----END PGP SIGNATURE----- --=-D1skACkJ7AqfcMi6zKJX-- -- gentoo-dev@gentoo.org mailing list