* [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).