[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAH8yC8kxHa9N08_Ni6o0x0KZePUYjbogkUXDszQEwE0OUNMGrg@mail.gmail.com>
Date: Sat, 28 Aug 2021 16:27:49 -0400
From: Jeffrey Walton <noloader@...il.com>
To: musl@...ts.openwall.com
Subject: Re: Why the musl libc did not support neon simd acceleartor
officially on mem* operations?
On Sat, Aug 28, 2021 at 3:53 PM Rich Felker <dalias@...c.org> wrote:
>
> On Sat, Aug 28, 2021 at 04:01:40PM +0800, tugouxp wrote:
> > HI guys:
> > I found that the current implmention of musl arm port memcpy.S and
> > other mem*.S operations did not use arm neon instructions, this
> > seems differenct with other counterparts like newlibc, glibc and
> > bonic libc, which all impl. the neon version of mem* operations. so
> > could you tell me why? is there and concern about on this in musl?
> > if i want to imple my self imple. how to do this, is there any
> > matual pathches to use?
>
> Generally we don't have any significant asm implementations that
> depend on non-baseline extensions to the ISA. The same is true for x86
> where no sse/avx is used.
Out of curiosity, does anyone use Hardware Capabilities
(https://linux.die.net/man/8/ld-linux) nowadays? Something like a
/usr/lib/musl, /usr/lib/sse/musl, /usr/lib/avx/musl,
/usr/lib/neon/musl, etc?
The benefit to using it is no runtime switching. The switching occurs
at load time, not runtime.
I know of a handful of libraries that could benefit from the speed up
on a critical path with an arch specific implementation. But I think
most libraries don't need it.
Jeff
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
