____wcstold_l_internal Question

____wcstold_l_internal Question

[Samir Droubi]

[-- Attachment #1: Type: text/plain, Size: 646 bytes --]

Hello,

I was profiling a project that I have been working on and the function above shows up amongst other internal functions. I was wondering if you could shed a light on what could possibly be happening to cause calls to this function to be so frequent. Here is the profiling result:

  13.72%  mitscriptbc  libc.so.6             [.] ____wcstold_l_internal
   5.45%  mitscriptbc  libc.so.6             [.] ____wcstof_l_internal
   2.46%  mitscriptbc  libc.so.6             [.] round_and_return
   2.28%  mitscriptbc  libc.so.6             [.] ____wcstod_l_internal

The libc version being used is 2.35.

Thank you!

Best,
Samir

Re: ____wcstold_l_internal Question

[Florian Weimer]

* Samir Droubi via Libc-help:

> I was profiling a project that I have been working on and the function
> above shows up amongst other internal functions. I was wondering if
> you could shed a light on what could possibly be happening to cause
> calls to this function to be so frequent. Here is the profiling
> result:
>
>   13.72%  mitscriptbc  libc.so.6             [.] ____wcstold_l_internal
>    5.45%  mitscriptbc  libc.so.6             [.] ____wcstof_l_internal
>    2.46%  mitscriptbc  libc.so.6             [.] round_and_return
>    2.28%  mitscriptbc  libc.so.6             [.] ____wcstod_l_internal
>
> The libc version being used is 2.35.

The external name is wcstold or wcstold_l.  If your application isn't
calling that, the profiling data is wrong.  You might find out by
setting a breakpoint or probe on the function.

Thanks,
Florian

Re: ____wcstold_l_internal Question

[Noah Goldstein]

On Thu, Dec 1, 2022 at 10:09 PM Florian Weimer via Libc-help
<libc-help@sourceware.org> wrote:
>
> * Samir Droubi via Libc-help:
>
> > I was profiling a project that I have been working on and the function
> > above shows up amongst other internal functions. I was wondering if
> > you could shed a light on what could possibly be happening to cause
> > calls to this function to be so frequent. Here is the profiling
> > result:
> >
> >   13.72%  mitscriptbc  libc.so.6             [.] ____wcstold_l_internal
> >    5.45%  mitscriptbc  libc.so.6             [.] ____wcstof_l_internal
> >    2.46%  mitscriptbc  libc.so.6             [.] round_and_return
> >    2.28%  mitscriptbc  libc.so.6             [.] ____wcstod_l_internal
> >
> > The libc version being used is 2.35.
I've noticed on ubuntu 22.04 (2.35 as well) `__wcstold_l` is showing up
in perf profiles incorrectly. It's usually malloc / memcpy / whatever other
functions are usually hot if you look at the asm.

Not sure where the bug is but don't think `__wcstold` is whats taking up
all those cycles.
>
> The external name is wcstold or wcstold_l.  If your application isn't
> calling that, the profiling data is wrong.  You might find out by
> setting a breakpoint or probe on the function.
>
> Thanks,
> Florian
>

RE: ____wcstold_l_internal Question

[Samir Droubi]

[-- Attachment #1: Type: text/plain, Size: 3617 bytes --]

<libc-help@sourceware.org> wrote:

> >

> > * Samir Droubi via Libc-help:

> >

> > > I was profiling a project that I have been working on and the function

> > > above shows up amongst other internal functions. I was wondering if

> > > you could shed a light on what could possibly be happening to cause

> > > calls to this function to be so frequent. Here is the profiling

> > > result:

> > >

> > >   13.72%  mitscriptbc  libc.so.6             [.] ____wcstold_l_internal

> > >    5.45%  mitscriptbc  libc.so.6             [.] ____wcstof_l_internal

> > >    2.46%  mitscriptbc  libc.so.6             [.] round_and_return

> > >    2.28%  mitscriptbc  libc.so.6             [.] ____wcstod_l_internal

> > >

> > > The libc version being used is 2.35.

> I've noticed on ubuntu 22.04 (2.35 as well) `__wcstold_l` is showing up

> in perf profiles incorrectly. It's usually malloc / memcpy / whatever other

> functions are usually hot if you look at the asm.


> Not sure where the bug is but don't think `__wcstold` is whats taking up

> all those cycles.


I have noticed the same thing. I started noticing this when I was profiling on ubuntu 22.04 (with libc 2.35).

When I look at the annotated assembly in perf for `____wcstold_l_internal`, I see that I am in `_int_free`, but I still see calls to  `____wcstold_l_internal`.

Specifically, here is a segment of what I am seeing:


```

       │      ./malloc/malloc.c:4605

  0.01 │        mov        0x8(%rbp),%rdx
  0.08 │        and        $0xfffffffffffffff8,%rdx
  1.36 │        cmp        %rax,%rdx
       │      ↓ jne        716
       │      ./malloc/malloc.c:4607
  0.14 │        mov        %rbp,%rdi
       │      → call       ____wcstod_l_internal
       │      ./malloc/malloc.c:4610
  1.39 │  b9:   cmp        %r14,0x60(%r12)
  0.01 │      ↓ je         480
       │      ./malloc/malloc.c:4615
  0.05 │     ┌──testb      $0x1,0x8(%r14,%r15,1)
  9.31 │     ├──je         520
       │     │./malloc/malloc.c:4619
  1.31 │     │  andq       $0xfffffffffffffffe,0x8(%r14)

```


I was also confused about why `wcstold_l` would be called here, at least from a quick glance at the external function definition.

Is there a way to confirm that this is actually a problem with perf? When I was looking at what ./malloc/malloc.c:4607 is I found this:

https://github.com/bminor/glibc/blob/release/2.35/master/malloc/malloc.c#L4607

Which calls this macro: https://github.com/bminor/glibc/blob/release/2.35/master/malloc/malloc.c#L1436

which is reading this field: https://github.com/bminor/glibc/blob/release/2.35/master/malloc/malloc.c#L1151

Reading the comments in the file it seems that INTERNAL_SIZE_T  should be defined as size_t: https://github.com/bminor/glibc/blob/release/2.35/master/malloc/malloc.c#L173

I don't really see why those calls to `____wcstold_l_internal` are showing there. Is it possible that the reported line numbers in malloc.c are inaccurate or for a different source than the one I am looking at?


Is there a way to downgrade libc version on Ubuntu 22.04 to study how the performance/perf results change?


> >

> > The external name is wcstold or wcstold_l.  If your application isn't

> > calling that, the profiling data is wrong.  You might find out by

> > setting a breakpoint or probe on the function.

> >

> > Thanks,

> > Florian

> >