Optimized kernel builds: the straight dope [fp extensions]

[John Richard Moser]

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



Krzysztof Lichota wrote:
> Matt Zimmerman napisał(a):
>> On Tue, Aug 15, 2006 at 05:26:03PM +0200, Pavel Rojtberg wrote:
>>> Matt Zimmerman wrote:
>>>> I'm interested to hear (objective, reasoned) feedback on this data and my
>>>> conclusions from the members of this list.
>>> it would be interesting to see a i386 vs k7 comparison.  Since the
>>> architectural difference is bigger; the k7 architecture has some floating
>>> point extensions(3D Now) which usually have a big impact on performance.
>>> Therefore we should look if the kernel can handle these well enough
>>> dynamically.  Perhaps it would make sense to leave one optimized kernel on
>>> i386 for newer CPUs.  This could be SSE optimized then to be more generic
>>> (AthlonXP+, Pentium3+)
>> I'll add to what Ben has already said that 3DNOW, SSE, MMX and friends are
>> not general-purpose extensions which make your system faster.  They are in
>> fact very specialized, and specialized for operations that the kernel
>> doesn't do.  The kernel very nearly doesn't use floating point at all, much
>> less floating point extensions for 3D graphics!
> 
> AFAIR gcc uses SIMD instructions for faster memcpy & friends and
> probably in some other places. So it could have some effect on
> performance (unless this is switched at runtime).

What the hell?  SIMD?  I'm seeing movsb, movs, addl, decl, and jz, all
of which are i286 instructions that I used in DOS.

I've been told that using SSE (the SIMD floating point extension that
Intel developed) takes ~17 cycles to load an SSE register because it's
not standard IEEE 754 floats and thus has to be converted from the FPU
registers.  Also the SIMDs are all floating point, it makes no sense to
copy data back and forth like that; a MOV, MOVS, or MOVSB instruction
would be faster and more appropriate.

(To be fair, the MOVS and MOVSB instructions start at an address and go
until they hit a 0 or until they step through a certain number of bytes,
respectively.  By definition these are single instruction, multiple
data.  They're just not SIMD extensions added after the 286)

> Using prefetch instructions also can speedup some routines (encryption,
> compression, etc.).
> However, I am not sure it is enabled in kernel compilation.
> 
> IMO getting rid of these optimized kernels should be done after much
> broader testing than 2 randomly chosen desktops. Think of people using
> encrypted filesystems, compressed filesystems, etc.
> 

You're very conservative.  This is a good stance; nobody wants to jump
in and oops I broked it :(

> 	Krzysztof Lichota
> 
> 

- --
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

iQIVAwUBROYhsAs1xW0HCTEFAQJxFxAAoBaYeeA/s0eXgSEquPlNh9lEOa32ZSZM
IUM++43T9HKIfPcPugivW2A/Xmv9imoSxzzSq1Q9Mhau86NEFslPR1gEnzs/ya7u
Gi5HxfWEuMXOKVTC5Ps/bqgFQhQGBz0ENCUCLe+1Ip0l73wjIcZHaOz2Y/zcKVYV
aq+utlWeLbNdtaF/AJ6JmuDRZV+TsUgS5zkLRKIkZwvFmGq42gw2eq25VQ/++0IO
c2+Yju2rT4SvRIw6AbAi1xnopDOi8lFKi4ODzDVi+XUIAdnMCRSJ2r1XD7sKBCzp
b0+Jv6yEwAtnRSOWqOwfLQEogh6v7QZRdRGkhYqxgwKBHLuYBIpNoo+rZJXl2lRv
/RLsTcfVOQMCbznK4SkuWuEp2+39LW8mWH8pwqSiKbewDB8b7LBHJcQwj9J5CehV
PmqfZ4t0j9/7tVWs53jACf4wCI5t64vG1dcFu1LHCqQbbVah9AcpgQwen+YmjOwa
SLBQA5L2r7a5MDb0zxYAeDWn/hG27KvXXtKW4PEZQan064bGKAXnDJ/8xDskhhOk
2O+bbd9obkfyu8NQNGCv/MwVYfpNSu2+BzolG/lEv29YpJmjAkb9FYyj2pEwKMV2
OXUJqDTHqFFO7TeB+JvSdCUi8oqzeNPRitP7qsf+3vL1BgPot3apCo1QgeGMvtu6
0uUGHpT6kB8=
=v8wH
-----END PGP SIGNATURE-----