[PATCH] stdlib: reorganize stdlib Makefile routines by functionality

[abush wang]

I have compared the address by nm, readelf and objdump,
it seems like there is no different in lrand48

This is my so
https://github.com/wswsmao/glibc_so

7a7229de1d:
Average time for lrand48: 1940 cycles

a91bf4e0ff:
Average time for lrand48: 5626 cycles


On Tue, Apr 2, 2024 at 11:14 AM H.J. Lu <hjl.tools@gmail.com> wrote:

> On Mon, Apr 1, 2024 at 7:28 PM abush wang <abushwangs@gmail.com> wrote:
> >
> > Actually, not just d275970ab
> > I found after a91bf4e0ff, there is also performance degradation on
> x86-64,
> > even if this commit has nothing  to do with lrand48.
> > This is my test data:
> > before  a91bf4e0ff:
> > Average time for lrand48: 1940 cycles
> >
> > after:
> > Average time for lrand48: 5626 cycles
>
> Please compare alignments of 2 versions of lrand48.
>
> > It seems like there is a gradual performance degradation for lrand48.
> >
> >
> > On Tue, Apr 2, 2024 at 10:17 AM abush wang <abushwangs@gmail.com> wrote:
> >>
> >> Yes，on x86-64.
> >> I just compare the disassemble between d275970ab and before commit by
> objdump.
> >> And __drand48_iterate will be more long distance after d275970ab, so I
> revert this
> >> commit and found the performance will recover a little.
> >>
> >> Thanks,
> >> abush
> >>
> >>
> >> On Mon, Apr 1, 2024 at 9:12 PM Florian Weimer <fweimer@redhat.com>
> wrote:
> >>>
> >>> * abush wang:
> >>>
> >>> > This is test:
> >>> > ```
> >>> > uint64_t getnsecs() {
> >>> >     uint32_t lo, hi;
> >>> >     __asm__ __volatile__ (
> >>> >         "rdtsc" : "=a"(lo), "=d"(hi)
> >>> >     );
> >>> >     return ((uint64_t)hi << 32) | lo;
> >>> > }
> >>> >
> >>> > int main() {
> >>> >     const int num_iterations = 1;
> >>> >     uint64_t start, end, total_time = 0;
> >>> >
> >>> >     start = getnsecs();
> >>> >     for (int i = 0; i < num_iterations; i++) {
> >>> >         (void) lrand48();
> >>> >     }
> >>> >     end = getnsecs();
> >>> >     total_time += (end - start);
> >>> >
> >>> >     printf("Average time for lrand48: %lu cycles\n", total_time /
> num_iterations);
> >>> >     return 0;
> >>> > }
> >>> > ```
> >>> > before:
> >>> > Average time for lrand48: 21418 cycles
> >>> >
> >>> > after:
> >>> > Average time for lrand48: 9892 cycles
> >>>
> >>> Do you see this on x86-64?  So this isn't a displacement range issue?
> >>>
> >>> It could be that this is a random performance change due to code
> >>> alignment, and not actually caused by the direct call distance.
> >>>
> >>> Thanks,
> >>> Florian
> >>>
>
>
> --
> H.J.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20240402/410efa2d/attachment.htm>