[PATCH] D18055: ELF: Implement --build-id.

[Sean Silva via llvm-commits]

On Thu, Mar 10, 2016 at 2:51 PM, Rui Ueyama <ruiu at google.com> wrote:

> For LLD, it hashed 75,421,320 bytes. For Scylla, it hashed 207,703,010
> bytes. So the throughput of MD5 is 444 MB/s and 480 MB/s, respectively.
>
> BLAKE2 claims that it is about 1.6x faster than MD5, but it is probably
> the lower bound for a secure hash function.
>

AESNI claims to be able to do 1.3 cycles per byte on an old Nehalem. That
is multiple gigabytes per second.
https://software.intel.com/sites/default/files/m/d/4/1/d/8/10TB24_Breakthrough_AES_Performance_with_Intel_AES_New_Instructions.final.secure.pdf

Have you tried using ADT/Hashing.h? That is probably the simplest option.

-- Sean Silva


>
> On Thu, Mar 10, 2016 at 2:16 PM, Sean Silva <chisophugis at gmail.com> wrote:
>
>> silvas added a subscriber: silvas.
>> silvas added a comment.
>>
>> One thing that is missing from the data you provided in the OP is the
>> actual amount of data hashed, and in what pattern (lots of small, or a
>> couple large?). How fast does the hashing have to be to be "acceptable"?
>> E.g. ADT/Hashing.h claims 6.5GB/s hashing for large keys on Nehalem (which
>> is pretty old at this point, modern CPU's likely to better). That is
>> 6.5MB/ms. If we need to hash 100MB then the overhead should be about 15ms.
>>
>> For LLD, you quoted a number 713.78ms link time. So for 1% overhead we
>> need to spend <7ms. This is enough for 45MB hashed with ADT/Hashing.h
>> (which is similar to LLD text+data size), assuming that we can get max
>> memory bandwidth (like Rafael said, we can do this while we would be
>> copying data otherwise, so I don't see a reason we can't hit the full
>> performance of ADT/Hashing.h).
>>
>>
>> http://reviews.llvm.org/D18055
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160310/847d58c1/attachment.html>