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

[Rui Ueyama via llvm-commits]

AES is for encryption, so it's not usable for secure hashing, no?

On Thu, Mar 10, 2016 at 6:33 PM, Sean Silva <chisophugis at gmail.com> wrote:

>
>
> 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.
>

No, I haven't. But if CRC32 is not okay, then it is not okay as well.


> -- 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/689a874c/attachment-0001.html>