Optimized kernel builds: the straight dope

[John Richard Moser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Matt Zimmerman wrote:
> On Fri, Aug 18, 2006 at 04:11:02PM -0400, John Richard Moser wrote:
>> Matt Zimmerman wrote:
>>> On Mon, Aug 14, 2006 at 09:50:38PM -0500, Scott White wrote:
>>>> Regardless this makes sense to me and I'm in favor of it.  Having run Ubuntu
>>>> on several different architectures, Intel 686, Intel SMP + AMD64, I can't
>>>> say I've seen any obvious difference.  My only question is that it doesn't
>>>> seem that benchmarks were done in applications that wouldn't leverage many
>>>> instructions opened up in recent architectures or applications (such as
>>>> multimedia) or that are SMP driven such as MySql or high-end graphics work
>>>> (even games).
>>> The use of newer instruction sets by applications is irrelevant to this
>>> test; you can still run i686 instructions regardless of which kernel you
>>> use.  We are only measuring the impact of building the kernel differently,
>>> not applications.  I would very much like to see similar data for that, of
>>> course, but so far no one has taken up the challenge.
>>>
>> https://wiki.ubuntu.com/ubuntu-i686
> 
> Unlike with the kernel, it should be straightforward to benchmark real
> workloads as well as artificial benchmarks.  For example, a web server
> benchmark, system boot process, graphics benchmarks...this would require
> rebuilding many system components in order to construct a compelling test,
> but that's mostly a matter of CPU cycles.
> 

Are you volunteering an i[56]86 build of all world?

I don't know how to do real-world benchmarks.  Microbenchmarks work
because you can say "wow a 686 shows up 0.2% faster, it's probably just
memory bus access creating variation" vs "Wow, this microbenchmark shows
a 50% increase in performance for these operations."  You can even
instrument microbenchmarks to take many samples and do a statistical
analysis that you can use to compare and see if two benches are
reasonably identical.

With something like Firefox, you are watching wall-clock time for short
operations and don't have the resolution to say there's any increase
unless you DO get something over 20% ("wow this HUGE page rendered in 24
seconds instead of 30").  Other things never really hit 100% CPU usage,
and it's hard to measure the minor fluctuations in CPU usage the
optimizations cause.

If you have any ideas, I'm open to hearing them.  I'm going to
conjecture two things ahead of time though:

 1)  Any real gains will be useless; if GNOME loads in 0.2 seconds less,
     that's great, but we're not keeping GNOME-686 around in the repos.

 2)  The most people will see is a placebo effect, because for most
     stuff it just won't matter.  Shaving 1mS off getting to the desktop
     is "faster" but doesn't feel faster; thinking everything is
     super-optimized however WILL feel faster even if it's a half second
     slower.

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

    Creative brains are a valuable, limited resource. They shouldn't be
    wasted on re-inventing the wheel when there are so many fascinating
    new problems waiting out there.
                                                 -- Eric Steven Raymond

    We will enslave their women, eat their children and rape their
    cattle!
                  -- Bosc, Evil alien overlord from the fifth dimension
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIVAwUBROi22Qs1xW0HCTEFAQIvGg//XJpVYPh9bXScOW5bhA5PJL/4MmLH96Dv
RSkrgn0AIiyCBh6NJu2RRnfiRW/zhw9Ajta5Kuc3xSQxAF0gqHh548V7yKiq3b4b
Xm3qd0QkM5N5JgrQqwW3USSpSkbsAuPWSPUpwKZO3nI2iloom/3PGRDhcYlvY/0/
iP2YUGGPR/IyqyxJnKNDkT/qBP7gcFZSEq0acfv/ATPNtqNd+BefOnF2f+fk2Phy
buaqxUQVCFz3GvFASFybDEAg/c9AqHnewIJ8Ubix1gE87BkOo47M8D5CD0UJwZle
JTKoqjc7QQ/Ptrg3aFyZyrnJoQ+h3rAezZsuZZCeTVA2UGnqBvKROVH1JCJ/iN5L
BygPOcLCpAVWTmIL+kP5JsHCT1Mmyu24pLAEXYDFhUbdosVCyykeGAS78UFV4tJR
jMi1H3dq6o4JmtCL5yWfW+5ss7ZD0NcJ/yPslZfTnVyqd1A7MCK3nwpJXOAXT4nr
QnPeOh6KZa67R6e/uj+DVEvutsPpXJcRMxCywIjneImSctIRbm3KkwCHS7GVga03
X+XcEdm/nAFQ4OL/jbssg2JK0Zj4s3uHrwq/nRSJlB/qJiXAw7sh9jv7ip0MXg5z
KovDg32DRNfwbOqMVBmD3bcAGbEmhRAfx8tcglVFDJQYvcOQtg5z0c+Jk2sVWToO
5k7O8IEVkRs=
=gFGa
-----END PGP SIGNATURE-----