The time span between original submission and update suggests that
contributors were planning the update, meaning that the code was
considered work in progress all along. If so, why it went into stable
branch?
I understand that two different implementations were developed in
parallel,
So they didn't know for sure if update would be required, but it still
hardly makes an argument for putting it into stable branch. The work was
(and as it turns out still is:-) *ongoing*.
and in the end it was found that the one finished later
was found to provide better performance.
As mentioned earlier, I don't see improvement, rather contrary. I can
imagine they benchmark on some particular platform, which might explain
why I see degradation on particular different elder P4 of "mine." I mean
it's known fact that what appear beneficial for one platform, might turn
out nearly devastating for another. We should strive for implementation
which provides best *all-round* performance. Say it's 13% faster on AMD,
but twice slower on PIII, what do we choose? This is real-life example
from rc4-586.pl. Well, it's kind of extreme, as you're unlikely to see
such swings in C, yet you *can* find yourself in similar situation. Or
take size vs. performance. Say you improve benchmark by few percent by
increasing footprint several times. But how would it perform in real
life, when caches are "cold"? No, we don't really know that, but I'd say
few percents on benchmark result is hardly worth size blow-up.
Update appears as if they were trying to
improve performance, but I observe over 30% *degradation* on x86...
The stated reason for switching to the new implementation was
performance, however I don't know what specific platforms this applies
to.
Well, I find it hard to believe it's confidential, so let's ask them to
tell all about it:-) I'm under impression at least one of them is on the
list, if not - please forward. Which platform and what was improvement?
I observe over 30% degradation on elder 2.4GHz P4. "Elder" refers to
value of 0xF2? in eax register after cpuid(1).
A new patch taking into account the compliation problems found so far
(including the ones pointed out by Gisle Vanem) should be on the way ...
Once again I want to point out that I see no reason for making code so
platform dependent, that say DJGPP would require special treatment:-)
Cheers. A.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [EMAIL PROTECTED]
