On Fri, Jun 16, 2017 at 01:36:13AM +0200, Ævar Arnfjörð Bjarmason wrote:

On Fri, Jun 16, 2017 at 12:41 AM, brian m. carlson
[off-list ref] wrote:

quoted

SHA-256 acceleration exists for some existing Intel platforms already.
However, they're not practically present on anything but servers at the
moment, and so I don't think the acceleration of SHA-256 is a
something we should consider.

Whatever next-gen hash Git ends up with is going to be in use for
decades, so what hardware acceleration exists in consumer products
right now is practically irrelevant, but what acceleration is likely
to exist for the lifetime of the hash existing *is* relevant.

The life of MD5 was about 23 years (introduction to first document
collision).  SHA-1 had about 22.  Decades, yes, but just barely.  SHA-2
was introduced in 2001, and by the same estimate, we're a little over
halfway through its life.

So I don't follow the argument that we shouldn't weigh future HW
acceleration highly just because you can't easily buy a laptop today
with these features.

Aside from that I think you've got this backwards, it's AMD that's
adding SHA acceleration to their high-end Ryzen chips[1] but Intel is
starting at the lower end this year with Goldmont which'll be in
lower-end consumer devices[2]. If you read the github issue I linked
to upthread[3] you can see that the cryptopp devs already tested their
SHA accelerated code on a consumer Celeron[4] recently.

I don't think Intel has announced the SHA extensions for future Xeon
releases, but it seems given that they're going to have it there as
well. Have there every been x86 extensions that aren't eventually
portable across the entire line, or that they've ended up removing
from x86 once introduced?

In any case, I think by the time we're ready to follow-up the current
hash refactoring efforts with actually changing the hash
implementation many of us are likely to have laptops with these
extensions, making this easy to test.

I think you underestimate the life of hardware and software.  I have
servers running KVM development instances that have been running since
at least 2012.  Those machines are not scheduled for replacement anytime
soon.

Whatever we deploy within the next year is going to run on existing
hardware for probably a decade, whether we want it to or not.  Most of
those machines don't have acceleration.

Furthermore, you need a reasonably modern crypto library to get hardware
acceleration.  OpenSSL has only recently gained support for it.  RHEL 7
does not currently support it, and probably never will.  That OS is
going to be around for the next 6 years.

If we're optimizing for performance, I don't want to optimize for the
latest, greatest machines.  Those machines are going to outperform
everything else either way.  I'd rather optimize for something which
performs well on the whole everywhere.  There are a lot of developers
who have older machines, for cost reasons or otherwise.

Here are some stats (cycles/byte for long messages):

                   SHA-256    BLAKE2b
Ryzen                 1.89       3.06
Knight's Landing     19.00       5.65
Cortex-A72            1.99       5.48
Cortex-A57           11.81       5.47
Cortex-A7            28.19      15.16

In other words, BLAKE2b performs well uniformly across a wide variety of
architectures even without acceleration.  I'd rather tell people that
upgrading to a new hash algorithm is a performance win either way, not
just if they have the latest hardware.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204