This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH, MPX] MPX-specific changes in dl_runtime routines


On Thu, Jul 09, 2015 at 09:07:24AM -0700, H.J. Lu wrote:
> On Thu, Jul 9, 2015 at 7:28 AM, OndÅej BÃlka <neleai@seznam.cz> wrote:
> > On Thu, Jul 09, 2015 at 07:12:24AM -0700, H.J. Lu wrote:
> >> On Thu, Jul 9, 2015 at 6:37 AM, Zamyatin, Igor <igor.zamyatin@intel.com> wrote:
> >> >> On Wed, Jul 8, 2015 at 8:56 AM, Zamyatin, Igor <igor.zamyatin@intel.com>
> >> >> wrote:
> >> >> > Fixed in the attached patch
> >> >> >
> >> >>
> >> >> I fixed some typos and updated sysdeps/i386/configure for
> >> >> HAVE_MPX_SUPPORT.  Please verify both with HAVE_MPX_SUPPORT and
> >> >> without on i386 and x86-64.
> >> >
> >> > Done, all works fine
> >> >
> >>
> >> I checked it in for you.
> >>
> > These are nice but you could have same problem with lazy tls allocation.
> > I wrote patch to merge trampolines, which now conflicts. Could you write
> > similar patch to solve that? Original purpose was to always save xmm
> > registers so we could use sse2 routines which speeds up lookup time.
> 
> So we will preserve only xmm0 to xmm7 in _dl_runtime_resolve? How
> much gain it will give us?
>
I couldn't measure that without patch. Gain now would be big as we now
use byte-by-byte loop to check symbol name which is slow, especially
with c++ name mangling. Would be following benchmark good to measure
speedup or do I need to measure startup time which is bit harder?

#define _GNU_SOURCE
#include <string.h>
#include <dlfcn.h>
int main()
{
  int p=0;
  for (int i=0;i<10000000;i++)
    p+=(int) dlsym(RTLD_DEFAULT, "strlen");
  return p;
}


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]