Rafael, Your latest benchmark results look great. LLD took 1.38 seconds where gold --threads takes 0.85 seconds. It needs to be faster, but that's not too bad. On Thu, Mar 19, 2015 at 10:13 AM, Rafael Espíndola < rafael.espindola at gmail.com> wrote:> > Here's an update. > > > > After http://reviews.llvm.org/D8372 , I updated the profiling data. > > > > https://people.freebsd.org/~davide/llvm/lld-03162015.svg > > It seems now 85% of CPU time is spent inside > > FileArchive::buildTableOfContents(). > > In particular, 35% of the samples are spent inserting into > > unordered_map, so there's maybe something we can do differently there > > (e.g. , Rui's proposal of a concurrent map doesn't seem that bad). > > > > Why do we even need to build the table from name to member? > > Can't we just walk "archive->symbols()" and check for each symbol if > it is needed by the current link status?Are you suggesting we do linear search instead of hash table lookup each time ArchiveFile::find(StringRef symbolName) is called? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150320/8e67ab35/attachment.html>
>> > https://people.freebsd.org/~davide/llvm/lld-03162015.svg >> > It seems now 85% of CPU time is spent inside >> > FileArchive::buildTableOfContents(). >> > In particular, 35% of the samples are spent inserting into >> > unordered_map, so there's maybe something we can do differently there >> > (e.g. , Rui's proposal of a concurrent map doesn't seem that bad). >> > >> >> Why do we even need to build the table from name to member? >> >> Can't we just walk "archive->symbols()" and check for each symbol if >> it is needed by the current link status? > > > Are you suggesting we do linear search instead of hash table lookup each > time ArchiveFile::find(StringRef symbolName) is called?No, what I mean is that we only need to keep one hash of the current state of the link (which symbols are still undefined). Once you get to an archive, don't build a hashtable of every symbol it provides. Instead, walk the list of symbols it provides and if one of those is currently undefined in the global table, include it in the link. Cheers, Rafael
On Fri, Mar 20, 2015 at 2:56 PM, Rafael Espíndola < rafael.espindola at gmail.com> wrote:> >> > https://people.freebsd.org/~davide/llvm/lld-03162015.svg > >> > It seems now 85% of CPU time is spent inside > >> > FileArchive::buildTableOfContents(). > >> > In particular, 35% of the samples are spent inserting into > >> > unordered_map, so there's maybe something we can do differently there > >> > (e.g. , Rui's proposal of a concurrent map doesn't seem that bad). > >> > > >> > >> Why do we even need to build the table from name to member? > >> > >> Can't we just walk "archive->symbols()" and check for each symbol if > >> it is needed by the current link status? > > > > > > Are you suggesting we do linear search instead of hash table lookup each > > time ArchiveFile::find(StringRef symbolName) is called? > > > No, what I mean is that we only need to keep one hash of the current > state of the link (which symbols are still undefined). > > Once you get to an archive, don't build a hashtable of every symbol it > provides. Instead, walk the list of symbols it provides and if one of > those is currently undefined in the global table, include it in the > link. >I think that wouldn't work. When we find a member file in an archive that resolves an undefined symbol, the file would add both undefined and defined symbols. We would need to scan the list of symbols again. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150320/329e9f03/attachment.html>