mailing list of musl libc
 help / color / mirror / code / Atom feed
* [musl] Why the musl libc did not support neon simd acceleartor officially on mem* operations?
@ 2021-08-28  8:01 tugouxp
  2021-08-28  9:48 ` Markus Wichmann
  2021-08-28 19:53 ` Rich Felker
  0 siblings, 2 replies; 7+ messages in thread
From: tugouxp @ 2021-08-28  8:01 UTC (permalink / raw)
  To: musl

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

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?


thanks for your kindly help!


BRs

[-- Attachment #2: Type: text/html, Size: 822 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [musl] Why the musl libc did not support neon simd acceleartor officially on mem* operations?
  2021-08-28  8:01 [musl] Why the musl libc did not support neon simd acceleartor officially on mem* operations? tugouxp
@ 2021-08-28  9:48 ` Markus Wichmann
  2021-08-28 14:29   ` [musl] " tugouxp
  2021-08-28 19:53 ` Rich Felker
  1 sibling, 1 reply; 7+ messages in thread
From: Markus Wichmann @ 2021-08-28  9:48 UTC (permalink / raw)
  To: musl

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.

I am not an expert on this or indeed anything, but it seems like there
are two plausible explanations for this:

1.) Neon support is not architectural, and not subarchitectural. It
appears Neon comes with a new register set the kernel has to switch out
on context switch, so Neon support is predicated on kernel support. That
makes it a runtime thing. Leaving aside where the kernel declares such
support, having a runtime switch in memcpy() is going to be a slowdown
of some kind for all existing users. I don't know how much of a
slowdown, but a slowdown nonetheless.

My guess is the other libcs ignore the issue of the user compiling a
userspace that won't run on the target platform and allow the user to
shoot themselves in the foot.

Adverting to the competition is a poor choice for this mailing list, by
the way, because part of musl's success comes from looking at them and
saying: No, we are not going to do that.

2.) The code does not exist because it has not been written yet. You are
welcome to submit a patch. I mean, you found the mailing list easily
enough.


> 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?

None that I am aware of, so they have not been submitted to this list
for sure.

Ciao,
Markus

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [musl] Re:Re: [musl] Why the musl libc did not support neon simd acceleartor officially on mem* operations?
  2021-08-28  9:48 ` Markus Wichmann
@ 2021-08-28 14:29   ` tugouxp
  0 siblings, 0 replies; 7+ messages in thread
From: tugouxp @ 2021-08-28 14:29 UTC (permalink / raw)
  To: musl

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




Thank you!















At 2021-08-28 17:48:47, "Markus Wichmann" <nullplan@gmx.net> 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.
>
>I am not an expert on this or indeed anything, but it seems like there
>are two plausible explanations for this:
>
>1.) Neon support is not architectural, and not subarchitectural. It
>appears Neon comes with a new register set the kernel has to switch out
>on context switch, so Neon support is predicated on kernel support. That
>makes it a runtime thing. Leaving aside where the kernel declares such
>support, having a runtime switch in memcpy() is going to be a slowdown
>of some kind for all existing users. I don't know how much of a
>slowdown, but a slowdown nonetheless.
>
>My guess is the other libcs ignore the issue of the user compiling a
>userspace that won't run on the target platform and allow the user to
>shoot themselves in the foot.
>
>Adverting to the competition is a poor choice for this mailing list, by
>the way, because part of musl's success comes from looking at them and
>saying: No, we are not going to do that.
>
>2.) The code does not exist because it has not been written yet. You are
>welcome to submit a patch. I mean, you found the mailing list easily
>enough.
>
>
>> 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?
>
>None that I am aware of, so they have not been submitted to this list
>for sure.
>
>Ciao,
>Markus

[-- Attachment #2: Type: text/html, Size: 2368 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [musl] Why the musl libc did not support neon simd acceleartor officially on mem* operations?
  2021-08-28  8:01 [musl] Why the musl libc did not support neon simd acceleartor officially on mem* operations? tugouxp
  2021-08-28  9:48 ` Markus Wichmann
@ 2021-08-28 19:53 ` Rich Felker
  2021-08-28 20:27   ` Jeffrey Walton
  1 sibling, 1 reply; 7+ messages in thread
From: Rich Felker @ 2021-08-28 19:53 UTC (permalink / raw)
  To: tugouxp; +Cc: musl

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.

The asm files we have for arm are already way too large and complex,
with all the high level flow gratuitously written in asm. Ideally at
some point we will refactor that to have all the high level logic in C
and just core block copy primitives provided by the archs. Whether
this would cleanly admit using methods only known to be available at
runtime I'm not sure.

Do you know what performance difference you're missing out on by not
having neon? At what block sizes does it matter?

Rich

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [musl] Why the musl libc did not support neon simd acceleartor officially on mem* operations?
  2021-08-28 19:53 ` Rich Felker
@ 2021-08-28 20:27   ` Jeffrey Walton
  2021-08-28 20:34     ` Rich Felker
  0 siblings, 1 reply; 7+ messages in thread
From: Jeffrey Walton @ 2021-08-28 20:27 UTC (permalink / raw)
  To: musl

On Sat, Aug 28, 2021 at 3:53 PM Rich Felker <dalias@libc.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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [musl] Why the musl libc did not support neon simd acceleartor officially on mem* operations?
  2021-08-28 20:27   ` Jeffrey Walton
@ 2021-08-28 20:34     ` Rich Felker
  2021-09-04 13:56       ` Ismael Luceno
  0 siblings, 1 reply; 7+ messages in thread
From: Rich Felker @ 2021-08-28 20:34 UTC (permalink / raw)
  To: Jeffrey Walton; +Cc: musl

On Sat, Aug 28, 2021 at 04:27:49PM -0400, Jeffrey Walton wrote:
> On Sat, Aug 28, 2021 at 3:53 PM Rich Felker <dalias@libc.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.

No, this is a really really bad way to do it. It's not compatible with
static linking and greatly increases startup overhead finding the
right libraries (leading to glibc recently redesigning how they do
it).

> 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.

If you really need this, assuming your distro/package installation
system knows what specific ISA extensions you want it could just
install suitable alt packages, *or* install both and edit the
ld-musl-$(ARCH).path file (or do boot-time symlink or bind mount
stuff, etc.) to make the desired ones available.

Rich

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [musl] Why the musl libc did not support neon simd acceleartor officially on mem* operations?
  2021-08-28 20:34     ` Rich Felker
@ 2021-09-04 13:56       ` Ismael Luceno
  0 siblings, 0 replies; 7+ messages in thread
From: Ismael Luceno @ 2021-09-04 13:56 UTC (permalink / raw)
  To: musl; +Cc: Jeffrey Walton

On 28/Aug/2021 16:34, Rich Felker wrote:
> On Sat, Aug 28, 2021 at 04:27:49PM -0400, Jeffrey Walton wrote:
> > On Sat, Aug 28, 2021 at 3:53 PM Rich Felker <dalias@libc.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.
> 
> No, this is a really really bad way to do it. It's not compatible with
> static linking and greatly increases startup overhead finding the
> right libraries (leading to glibc recently redesigning how they do
> it).
> 
> > 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.
> 
> If you really need this, assuming your distro/package installation
> system knows what specific ISA extensions you want it could just
> install suitable alt packages, *or* install both and edit the
> ld-musl-$(ARCH).path file (or do boot-time symlink or bind mount
> stuff, etc.) to make the desired ones available.
> 
> Rich

It might be interesting to use the dynamic linker to implement this, by
switching the symbols depending on some link-time test, which could be
provided by the library in a special function symbol (is __init too late?).

I'm interested in rewriting these functions...

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2021-09-04 13:56 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-28  8:01 [musl] Why the musl libc did not support neon simd acceleartor officially on mem* operations? tugouxp
2021-08-28  9:48 ` Markus Wichmann
2021-08-28 14:29   ` [musl] " tugouxp
2021-08-28 19:53 ` Rich Felker
2021-08-28 20:27   ` Jeffrey Walton
2021-08-28 20:34     ` Rich Felker
2021-09-04 13:56       ` Ismael Luceno

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).