Re: [musl] Re:Re: [musl] Re:Re: [musl] Re:Re: [musl] Re:Re: [musl] qsort

["alice" <alice@ayaya.dev>]

On Sat Feb 11, 2023 at 9:39 AM CET, Joakim Sindholt wrote:
> On Sat, 11 Feb 2023 06:44:29 +0100, "alice" <alice@ayaya.dev> wrote:
> > based on the glibc profiling, glibc also has their natively-loaded-cpu-specific
> > optimisations, the _avx_ functions in your case. musl doesn't implement any
> > SIMD optimisations, so this is a bit apples-to-oranges unless musl implements
> > the same kind of native per-arch optimisation.
> > 
> > you should rerun these with GLIBC_TUNABLES, from something in:
> > https://www.gnu.org/software/libc/manual/html_node/Hardware-Capability-Tunables.html
> > which should let you disable them all (if you just want to compare C to C code).
> > 
> > ( unrelated, but has there been some historic discussion of implementing
> >   something similar in musl? i feel like i might be forgetting something. )
>
> There already are arch-specific asm implementations of functions like
> memcpy.

apologies, i wasn't quite clear- the difference
between src/string/x86_64/memcpy.s and the glibc fiesta is that the latter
utilises subarch-specific SIMD (as you explain below), e.g. AVX like in the
above benchmarks. a baseline x86_64 asm is more fair-game if the difference is
as significant as it is for memcpy :)

i wonder if anyone has tried such baseline-asm for str*, or for non i386/
x86_64 by now. there seems to only be x86 and mips asm in the tree currently
(base platform support aside).
(purely out of interest of course- i don't have the ability to write such
things (yet), and maybe there are some gains more significant than "2.2%"
possible with just sse2 for instance.)

> As I see it there are 3 issues standing between musl and the
> glibc approach of writing a new function every time Intel or AMD
> releases a new core design:
> 1) ifunc resolvers don't work on statically linked binaries.
> 2) If they did it would mean shipping 12 different implementations of
>    each optimized function, making the binary huge for, for the most
>    part, no good reason.
> 3) The esoteric bug is no longer in memcpy but in either memcpy_c,
>    memcpy_mmx, memcpy_3dnow, memcpy_sse2, memcpy_sse3, memcpy_ssse3,
>    memcpy_sse41, memcpy_sse42, memcpy_avx, memcpy_avx2, memcpy_avx512,
>    or memcpy_amx or whatever else is added in the future in a
>    never-ending spiral of implementations piling up.

3) is admittedly the worst effect- niche esoteric debugging is worse than "disk
space", and having so many implementations is certainly hard to maintain.

> It is my opinion that musl should remain small and concise to allow it
> to effectively serve both the "small" and "gotta go fast" markets. I say
> both because you can always haul in libreallyreallyfastsort.a/so but you
> can't take the 47 qsort/memcpy implementations out of libc.

yes, i generally find myself having the same opinion :)