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 1Emu6d-0006ua-8Q for garchives@archives.gentoo.org; Thu, 15 Dec 2005 14:29:15 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id jBFESVX9015481; Thu, 15 Dec 2005 14:28:31 GMT Received: from mail.twi-31o2.org (66-191-187-123.dhcp.gnvl.sc.charter.com [66.191.187.123]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id jBFEQgSs004707 for ; Thu, 15 Dec 2005 14:26:43 GMT Received: from localhost (localhost [127.0.0.1]) by mail.twi-31o2.org (Postfix) with ESMTP id CB2F9248022 for ; Thu, 15 Dec 2005 09:16:52 -0500 (EST) Received: from mail.twi-31o2.org ([127.0.0.1]) by localhost (gravity.twi-31o2.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04845-02 for ; Thu, 15 Dec 2005 09:16:43 -0500 (EST) Received: from vertigo.twi-31o2.org (vertigo.twi-31o2.org [192.168.0.10]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.twi-31o2.org (Postfix) with ESMTP id 7287D248021 for ; Thu, 15 Dec 2005 09:16:41 -0500 (EST) Subject: Re: [gentoo-dev] Optimizing performance From: Chris Gianelloni To: gentoo-dev@lists.gentoo.org In-Reply-To: <1134650885.4634.57.camel@localhost> References: <1134650885.4634.57.camel@localhost> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-MIiV4bhCF9TkaoYS11ML" Organization: Gentoo Linux Date: Thu, 15 Dec 2005 09:13:34 -0500 Message-Id: <1134656014.21439.28.camel@vertigo.twi-31o2.org> 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.4.2.1 X-Virus-Scanned: amavisd-new at twi-31o2.org X-Archives-Salt: e222b623-5ed1-4b8c-9bce-961ddddb5259 X-Archives-Hash: 9c312aff7b23cffc0bb9d09f4e93472d --=-MIiV4bhCF9TkaoYS11ML Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2005-12-15 at 13:48 +0100, Patrick Lauer wrote: > - don't overtweak CFLAGS. "-O2 -march=3D$your_cpu_family" seems to be on > average the best, -O3 is often slower and can cause bugs -O2 -march=3D$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=3D"-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=3D"-d1 -A1 -m16 -u1 -a64 -c1" cdrom0_args=3D"-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. --=20 Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux --=-MIiV4bhCF9TkaoYS11ML 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 (GNU/Linux) iD8DBQBDoXoOkT4lNIS36YERAswHAJ99y9auROn/VN09l96wWVOj4Whk9wCfUdvG 6YBUByScTBRBT5Dr/IZkzdI= =Dp0M -----END PGP SIGNATURE----- --=-MIiV4bhCF9TkaoYS11ML-- -- gentoo-dev@gentoo.org mailing list