Re: [GOLD] add new method for computing a build ID

[Geoff Pike <gpike at chromium dot org>]

>>>> Motivation for the change: computing a build ID is currently a
>>>> sequential bottleneck. E.g., in the example I mentioned in my email
>>>> yesterday, a 24.5s link was spending 5.2s on the build ID computation.
>>>
>>> Have you tried linking with OpenSSL and using their optimized MD5 and
>>> SHA1 variants?  I bet it makes a huge difference, some cpus even have
>>> SHA1 and MD5 instructions.
>>>
>>> For example, on my machine we can SHA1 at a rate of 760MB/sec and
>>> MD5 at a rate of ~775MB/sec.
>>
>> I thought about trying a faster version of what's already being done,
>> but felt that should be a lower priority than getting rid of the
>> sequential bottleneck.
>
> At the cost of needlessly making the hash weaker?  That sounds like
> a terrible tradeoff, especially if it is found to be completely
> unnecessary after doing the experiements I suggested above.

Both SHA-1 and MD5 are "broken" and not recommended for cases where a
secure hash is desired. So, I don't think the weakening you deride is
an issue in practice. But if it is an issue, it would be trivial to
modify my patch to use other hash functions instead of using a SHA-1
hash of MD5 hashes.

Should we be concerned about people trying to cause build ID collisions?

I understand your concern about libiberty's SHA-1 implementation, but
I'd rather not allow that concern to derail this patch. Even if we
could speed up SHA-1 by 10x on some platforms, it seems unlikely that
we can speed it by 10x on all platforms; and even then, a 10x speedup
on a 5.2s baseline is .52s, which is still a sequential bottleneck
worth eliminating.

Geoff