Date: Tue, 30 Jun 2015 16:04:54 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Further dynamic linker optimizations Discussion on #musl with Timo Teräs has produced the following results: - Moving bloom filter size to struct dso gives 5% improvement in clang (built as 110 .so's) start time, simply because of a reduction of number of instructions in the hot path. So I think we should apply that patch. - The whole outer for loop in find_sym is the hot path for performance. As such, eliminating the lazy calculation of gnu_hash and simply doing it before the loop should be a measurable win, just by removing the if (!ghm) branch. - Even the check if (!dso->global) continue; has nontrivial cost. Since I want to replace this representation with a separate linked-list chain for global dsos anyway (for other reasons) I think that's worth prioritizing for performance too. - We still don't save and reuse the last symbol lookup in do_relocs. Doing so could improve performance a lot when the same symbol is referenced multiple times from global data. When the only references are the GOT (thus only one per symbol), it's not going to help, but since it's outside the find_sym dso loop, it should not have measurable cost anyway. - String comparison (dl_strcmp) is costly, but nontrivial to optimize. Word-at-a-time optimizations have issues with crossing pages, even on archs that don't require aligned access. Probably the right way forward here is to get an optimized general strcmp, then add a mechanism (function pointer in struct dso? or global?) for the dynamic linker to call dl_strcmp when relocating itself but the real strcmp later. - The strength-reduction of remainder operations does not seem to provide worthwhile benefits yet, simply because so little of the overall time is spent on the division/remainder. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.