<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 11, 2016 at 12:13 AM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-family:arial,helvetica,sans-serif;font-size:10pt;color:#000000"><br><hr><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><b>From: </b>"Sean Silva via llvm-commits" <<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>><br><b>To: </b>"Rui Ueyama" <<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>><br><b>Cc: </b><a href="mailto:reviews%2BD18055%2Bpublic%2Bcfa74f4269f8beb5@reviews.llvm.org" target="_blank">reviews+D18055+public+cfa74f4269f8beb5@reviews.llvm.org</a>, "llvm-commits" <<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>><br><b>Sent: </b>Thursday, March 10, 2016 10:59:25 PM<br><b>Subject: </b>Re: [PATCH] D18055: ELF: Implement --build-id.<span><br><br><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 10, 2016 at 7:56 PM, Rui Ueyama <span dir="ltr"><<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">AES is for encryption, so it's not usable for secure hashing, no?<div class="gmail_extra"><br><div class="gmail_quote"><span>On Thu, Mar 10, 2016 at 6:33 PM, Sean Silva <span dir="ltr"><<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Thu, Mar 10, 2016 at 2:51 PM, Rui Ueyama <span dir="ltr"><<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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.<div><br></div><div>BLAKE2 claims that it is about 1.6x faster than MD5, but it is probably the lower bound for a secure hash function.</div></div></blockquote></span><div><br>AESNI claims to be able to do 1.3 cycles per byte on an old Nehalem. That is multiple gigabytes per second.</div><div><a href="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" target="_blank">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</a><br></div><div><br></div><div>Have you tried using ADT/Hashing.h? That is probably the simplest option.</div></div></div></div></blockquote><div><br></div></span><div>No, I haven't. But if CRC32 is not okay, then it is not okay as well.</div></div></div></div></blockquote><div><br></div><div>I disagree. CRC32 has dramatically weaker characteristics than ADT/Hashing.h. CRC polynomials are constructed to detect specific classes of errors that are characteristic to physical communication channels. e.g. "anything which toggles a single bit is guaranteed to change the CRC value".</div></div></div></div></span></blockquote>One advantage that CRCs might have here over other schemes is that it is possible to efficiently compute them in parallel. I wrote a small library that does this for CRC64 values a few years ago (<a href="http://trac.alcf.anl.gov/projects/hpcrc64" target="_blank">http://trac.alcf.anl.gov/projects/hpcrc64</a>), and while OpenMP is used for the parallelization, which we don't want to use here, it is pretty simple to see how the scheme works.<br></div></div></blockquote><div><br></div><div>Yeah. Even without OpenMP the inner loop of CRC computations typically have high latency but can be fully pipelined, so it is advantageous to do multiple computations simultaneously even on a single core. E.g. Intel's CRC32C instruction has a latency of 3 cycles but is fully pipelined, so to get max performance you have to be processing 3 blocks at a time and periodically merge them with CLMUL. With a table lookup implementation it is even more important because your table lookup latency is load, op, store to L1D so at least 7 cycles.</div><div><br></div><div>I see that your implementation ticks all the check marks (both multiword (within-a-register parallel) *and*  instruction parallel *and* thread parallel). Beautiful! I guess my ramblings above should be considered some extra explanatory comments for your code m(-_-)m</div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-family:arial,helvetica,sans-serif;font-size:10pt;color:#000000"><br> -Hal<br><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><span><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> They are not particularly good as hash values.</div><div>ADT/Hashing.h is designed against much more stringent tests (I believe it is tested against SMHasher).</div><div><br></div><div>The fedora page does not mention any use case that requires cryptographically strong hashing.</div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><div><br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><font color="#888888"><div><br></div><div>-- Sean Silva</div></font></span><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 10, 2016 at 2:16 PM, Sean Silva <span dir="ltr"><<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">silvas added a subscriber: silvas.<br>
silvas added a comment.<br>
<br>
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.<br>
<br>
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).<br>
<br>
<br>
<a href="http://reviews.llvm.org/D18055" rel="noreferrer" target="_blank">http://reviews.llvm.org/D18055</a><br>
<br>
<br>
<br>
</blockquote></div><br></div></div></div></div>
</blockquote></span></div><br></div></div>
</blockquote></span></div><br></div></div>
</blockquote></div><br></div></div>
<br></span><span>_______________________________________________<br>llvm-commits mailing list<br><a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a><br><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><br></span></blockquote><span><font color="#888888"><br><br><br>-- <br><div><span name="x"></span>Hal Finkel<br>Assistant Computational Scientist<br>Leadership Computing Facility<br>Argonne National Laboratory<span name="x"></span><br></div></font></span></div></div></blockquote></div><br></div></div>