[lld] r250808 - [ELF2] - Lazy relocation support for x86_64.

[Hal Finkel via llvm-commits]

----- Original Message -----
> From: "Rui Ueyama via llvm-commits" <llvm-commits at lists.llvm.org>
> To: "George Rimar" <grimar at accesssoftek.com>
> Cc: "llvm-commits" <llvm-commits at lists.llvm.org>
> Sent: Tuesday, October 20, 2015 3:26:44 PM
> Subject: Re: [lld] r250808 - [ELF2] - Lazy relocation support for x86_64.
> 
> On Tue, Oct 20, 2015 at 1:17 PM, George Rimar <
> grimar at accesssoftek.com > wrote:
> 
> 
> >That would be awesome. Please be careful about the detail conditions
> >because the symbol resolution performance is affected by various
> >conditions such as library search order, symbol name, etc. Probably
> >the easiest way to evaluate that is to use a real world program,
> >such as Clang, as a benchmark.
> 
> What about that synthetic case: 1 DSO with N generated functions and
> 1 caller file with N * 2 calls to this different N functions.
> Comparing time of first N calls and second N calls we can know the
> time of N dynamic resolvings and time of clear N calls since PLT
> table will be filled with actual addresses after first N calls.
> 
> That test may be good to measure the bare performance, but I guess
> that's synthetic. One of the big selling points of lazy binding is
> that it would reduce the number of symbol resolution because not all
> function are actually used.

Exactly. And the disadvantage is that you're then likely doing symbol resolution with a cold cache (relative to the ELF data structures), and polluting the cache otherwise being used by the application, when you do it on demand later.

 -Hal

> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory