<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Dec 1, 2017 at 2:50 PM, Rafael Avila de Espindola <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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">Rui Ueyama <<a href="mailto:ruiu@google.com">ruiu@google.com</a>> writes:<br>
<br>
> On Fri, Dec 1, 2017 at 1:26 PM, Rafael Avila de Espindola <<br>
> <a href="mailto:rafael.espindola@gmail.com">rafael.espindola@gmail.com</a>> wrote:<br>
><br>
>><br>
>> I got curious how the lld produced gnu hash tables compared to gold. To<br>
>> test that I timed "perf record ninja check-llvm" (just the lit run) in a<br>
>> BUILD_SHARED_LIBS build.<br>
>><br>
>> The performance was almost identical, so I decided to try sysv versus<br>
>> gnu (both produced by lld). The results are interesting:<br>
>><br>
>> % grep -v '^#' perf-gnu/perf.report-by-dso-<wbr>sym | head<br>
>>     38.77%  <a href="http://ld-2.24.so" rel="noreferrer" target="_blank">ld-2.24.so</a>                              [.] do_lookup_x<br>
>>      8.08%  <a href="http://ld-2.24.so" rel="noreferrer" target="_blank">ld-2.24.so</a>                              [.] strcmp<br>
>>      2.66%  <a href="http://ld-2.24.so" rel="noreferrer" target="_blank">ld-2.24.so</a>                              [.]<br>
>> _dl_relocate_object<br>
>>      2.58%  <a href="http://ld-2.24.so" rel="noreferrer" target="_blank">ld-2.24.so</a>                              [.]<br>
>> _dl_lookup_symbol_x<br>
>>      1.85%  <a href="http://ld-2.24.so" rel="noreferrer" target="_blank">ld-2.24.so</a>                              [.] _dl_name_match_p<br>
>>      1.46%  [kernel.kallsyms]                       [k] copy_page<br>
>>      1.38%  <a href="http://ld-2.24.so" rel="noreferrer" target="_blank">ld-2.24.so</a>                              [.] _dl_map_object<br>
>>      1.30%  [kernel.kallsyms]                       [k] unmap_page_range<br>
>>      1.28%  [kernel.kallsyms]                       [k]<br>
>>      filemap_map_pages<br>
>>      1.26%  libLLVMSupport.so.6.0.0svn              [.] sstep<br>
>> % grep -v '^#' perf-sysv/perf.report-by-dso-<wbr>sym | head<br>
>>     42.18%  <a href="http://ld-2.24.so" rel="noreferrer" target="_blank">ld-2.24.so</a>                              [.] do_lookup_x<br>
>>     17.73%  <a href="http://ld-2.24.so" rel="noreferrer" target="_blank">ld-2.24.so</a>                              [.] check_match<br>
>>     14.41%  <a href="http://ld-2.24.so" rel="noreferrer" target="_blank">ld-2.24.so</a>                              [.] strcmp<br>
>>      1.22%  <a href="http://ld-2.24.so" rel="noreferrer" target="_blank">ld-2.24.so</a>                              [.]<br>
>> _dl_relocate_object<br>
>>      1.13%  <a href="http://ld-2.24.so" rel="noreferrer" target="_blank">ld-2.24.so</a>                              [.]<br>
>> _dl_lookup_symbol_x<br>
>>      0.91%  <a href="http://ld-2.24.so" rel="noreferrer" target="_blank">ld-2.24.so</a>                              [.] _dl_name_match_p<br>
>>      0.67%  <a href="http://ld-2.24.so" rel="noreferrer" target="_blank">ld-2.24.so</a>                              [.] _dl_map_object<br>
>>      0.65%  [kernel.kallsyms]                       [k] unmap_page_range<br>
>>      0.63%  [kernel.kallsyms]                       [k] copy_page<br>
>>      0.59%  libLLVMSupport.so.6.0.0svn              [.] sstep<br>
>><br>
>> So the gnu hash table helps a lot, but BUILD_SHARED_LIBS is still crazy<br>
>> inefficient.<br>
><br>
><br>
> What is "100%" in these numbers? If 100% means all execution time,<br>
> <a href="http://ld-2.24.so" rel="noreferrer" target="_blank">ld-2.24.so</a> takes more than 70% of execution time. Is this real?<br>
<br>
</div></div>I think so, BUILD_SHARED_LIBS is very slow.<br>
<br>
On another machine this time (amazon c5.9x) I just checked the time that<br>
lit reports in "ninja check-llvm":<br>
<br>
regular build:     Testing Time: 23.69s<br>
BUILD_SHARED_LIBS: Testing Time: 57.60s<br></blockquote><div><br></div><div>Aah, I knew Unix DSO's are not efficient in resolving symbol names, but it's too slow. I really don't like the Unix semantics of the dynamic linking object. Windows is much better.</div><div><br></div><div>I also dislike the fact that ELF/Unix/C are trying to make DSOs usable transparently. On Windows, you have to explicitly mark imported/exported functions as dllimported/dllexported, and that is IMO much better than trying to hide it.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It is a lot of libraries where almost all the symbols have default<br>
visibility.<br>
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br></div></div>