On Mon, May 18, 2009 at 7:24 PM, Daniel J Blueman <daniel.blue...@gmail.com> wrote: > A number of benchmarks show a significant performance loss on 32bit > ubuntu over 64bit [1], on the same hardware. This is partially due to > restrictions on the instruction set and partially due to worse > instruction scheduling (others reasons include register width and > count, for moving data and calling convention). >
No Shinola, sherlock. 64 bit is faster for many reasons, such as built-in position independent (i.e. relative to base) instructions and a wider register set (16 GPRs instead of 8). Most code is position independent code in libraries and takes roughly a 1% hit for the privilege; having not nearly as many registers implies a bigger hit. > Just how much user experience do we trade away for i386/i486 legacy > compatibility these days? > > If (eg) 1.0% of 32bit Ubuntu users have i586-only processors, how > about setting the default compile flags to -march=i586 and > -mtune=pentium3 in principle? > > This seems like good value to tweak end-user performance/experience a > bit, am I missing something, or should we just not care? > The bigger concern here is why are we bothering with systems like i586 that will probably have around 64MB of RAM, when you need 192MB just to install? Anything under half a gig is going to give a horrible user experience. Ubuntu targets a lot of non-desktop platforms. You and I on GNOME or KDE will burn 512M a few minutes after boot, once Xchat and Firefox are running (and don't kid yourself, Evolution eats its gigs and gigs of RAM-- it's nowhere near as memory-friendly as Thunderbird, I haven't figured out why, but it hates huge multi-gigabyte mailboxes). That's fine for us, and we can go for -march-i686 easy enough; but Ubuntu for Netbooks, embedded stuff, and the like will probably fall back to a reduced instruction set. One branch even targets older platforms specifically. Even if we split up Ubuntu in i486 and i686, i686 gets its most major gains from the CMOV instruction family-- a conditional MOV instruction that acts as a branch-and-mov in one (compare, then either conditional branch and mov or use cmov). See discussion here: http://ondioline.org/mail/cmov-a-bad-idea-on-out-of-order-cpus Its most major gain is a wash. Also there's no guarantee any CPU supports CMOV (it's an option), and thus to guarantee 100% compatibility we'd have to add a kernel level illegal instruction handler that handles the CMOV instruction family rather than throwing a SIGILL at the process (yes this is doable), which is very slow. Mind you I'm not against abandoning anything below i686 on desktops eventually, but some embedded systems will need i586 and the like. Cost-benefit analysis here. > (does any of this apply to x86-64, eg -mtune=core2 or k8?) Yes but this becomes a mess. Leave it as is. gcc is good at tuning to general-purpose in an instruction set. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
