<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Mar 10, 2016 at 12:25 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-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Thu, Mar 10, 2016 at 12:17 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">BTW, have you tried this in combination with the patch for using<br>
posix_memalign? Since this basically reads back the output of the<br>
linker I would be curious if that patch makes any difference is the<br>
results.</blockquote><div><br></div></span><div>My gut is that accessing a mmap'd memory region linearly is very fast anyway, but let me try.</div></div></div></div></blockquote><div><br></div><div>The patch to use posix_memalign was slightly negative. It took 893.88 milliseconds to link LLD.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><br>
>  - Use CRC32 instead of MD5. Non-secure hash should be much faster.<br>
<br>
</span>That is a bit too weak I think, but we can block this on getting a<br>
better MD5 or use another strong but fast hash.<br>
<span><br>
>  - Make clang to calculate a secure hash for each section.<br>
>    This is basically moving the workload from the linker to the compiler,<br>
>    but we can use the hash for ICF in the linker,<br>
>    so it might be a overall win.<br>
<br>
</span>Seems like something we should do in the future, but should not depend<br>
on it. That is, having the hash available speeds up build-id, but<br>
build-id should work without it.<br>
<span><br>
>  - Compute a build-id from input files' timestamps. This makes builds<br>
>    non-reproducible if you touch a file, so I don't think we want this.<br>
<br>
</span>Not this. O use of build-id is for checking for reproducible builds I think.<br>
<span><br>
>  - Build-id is not needed for program execution in general.<br>
>    So we may be able to let the linker exit as soon as it's done with linking,<br>
>    and backfill the hash value in a background process which is kicked in<br>
>    by the linker. (It's probably unrealistic plan, though.)<br>
<br>
</span>A bit dangerous I would say.<br>
<br>
<br>
Cheers,<br>
Rafael<br>
</blockquote></span></div><br></div></div>
</blockquote></div><br></div></div>