[rfc] improving 32bit user performance/experience...

[John Moser]

On Mon, May 18, 2009 at 7:24 PM, Daniel J Blueman
<daniel.blueman at 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.