[nzlug] Kernel squared

[Daniel Pittman]

Michal Ludvig <michal at logix.cz> writes:
> Daniel Pittman wrote:
>> "Phillip Hutchings" <sitharus at sitharus.com> writes:
>>> How about running an VIA EPIA CPU. They have a small cache and don't
>>> implement all of the i686 instruction set.
>> 
>> They don't implement an *optional* portion of the i686 instruction set
>> as documented.  Intel did choose to implement them[1] leading to the
>> mistaken belief that VIA had an incomplete system.
>
> It was certainly a bad decision from VIA.  

I don't agree; I feel that the assumption that all i686 implementations
would either be from Intel, or would implement exactly what Intel did,
was a bad call on the part of the software developers.

After all, what if Intel had decided to omit the optional instructions
themselves in some 686 line CPU?

> However recent VIA CPUs already have full i686 instruction
> set. Definitely true for core Nehemiah and newer, perhaps for some
> older as well. And Nehemiah was out some ... two years ago? Maybe
> three?

...and these days Linux systems sensible use the actual hardware
capabilities, rather than assumptions, to decide which code to run, so
things would work correctly even if the cmov stuff was omitted again. :)

>>> You do notice performance increases if you target this CPU rather than
>>> sticking with 386 packages.
>> 
>> I wasn't aware of that.  Where do the VIA EPIA systems benefit?
>> 
>> Is it instruction scheduling, cache awareness, alignment, or something
>> else?
>
> Cryptography. OpenSSL optimized for these CPUs is NNN-times faster ;-)

OpenSSL does that by having hard-written assembly code optimized to the
CPU.  While this is an optimization targeting the CPU it isn't a
*compiler* optimization -- which was the "target" we were discussing.

>> What sort of performance gain are we talking about; have you some
>> performance numbers to show the gains you see there?
>
> http://www.logix.cz/michal/devel/padlock/bench.xp (not yet updated with
> VIA Esther results for SHA1/SHA256).
>
> Indeed, that's a somewhat specific usecase and it's disputable to call
> it "optimization" afterall ;-)

Well, that looks to be using the hardware implementation of the code. 

Anyway, yes: this is an optimization that targets the CPU and benefits
significantly.


It isn't anything to do with the compiler, though.  You can't set any
switch for gcc to have it use the padlock stuff -- it needs help there.

Even if you target i386 with gcc, OpenSSL will still use the custom
assembly code, as will libc6.  The CPU target for gcc is mostly
irrelevant there, as it has little measurable effect on speed.

Optimizing for size, as pointed out elsewhere, can make a difference --
not just on the VIA systems, but everywhere.  Sadly it also has more
bugs, because traditionally it was never used. :/

Regards,
	Daniel
-- 
Digital Infrastructure Solutions -- making IT simple, stable and secure
Phone: 0401 155 707        email: contact at digital-infrastructure.com.au
                 http://digital-infrastructure.com.au/