From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 31767 invoked from network); 28 Aug 2021 09:49:02 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 28 Aug 2021 09:49:02 -0000 Received: (qmail 19904 invoked by uid 550); 28 Aug 2021 09:49:00 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 19883 invoked from network); 28 Aug 2021 09:48:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1630144128; bh=WAwtG7Yp2bq08XEQvV9+P4ENd+Ucia/A/rejrNwbYTY=; h=X-UI-Sender-Class:Date:From:To:Subject:References:In-Reply-To; b=Osp1ymK3lhF62gBNWuDo+KqozoGfbG1767vRP1m5gogfcR++pN9rhuVsbVkLTqYU+ HcEfQ/o/4wevm5aPgHk9mezIZKrUwrwMbqP5b9FBjHO1PBT8+T0BBAan15Ih9FaVXS 8pdByaCJkUWoEbZ3WHdXv6/8DkKGxJcugHvvqrtY= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Date: Sat, 28 Aug 2021 11:48:47 +0200 From: Markus Wichmann To: musl@lists.openwall.com Message-ID: <20210828094847.GB3090@voyager> References: <4e37b6c4.19be.17b8bc750df.Coremail.13824125580@163.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4e37b6c4.19be.17b8bc750df.Coremail.13824125580@163.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-Provags-ID: V03:K1:YKP6iVD/cPLdUn61m8LddgbhiM3SH6SoWg245XnuM7lCl+I3Lbx FHdBvO5D3to+bx4A0IjnvnXMDM/lybpsv47Bhye672vgaF+JmYQUc9Of9O9oxdnI/LJYM4J MA51uIXThcXrLrFkOGrsWAXOBFOhmd5/MxJVMChfovbjueG7MGZgkRVta2LK3wuLjZyByMW 1FUhTuUiRhpeibKEBez6A== X-UI-Out-Filterresults: notjunk:1;V03:K0:jW8Ny+XGWbA=:64oXXow1DbXR/LKqASVYDG OKcYYMlDA3Vjl0K5OgVteQQPJgunJM96T2LWD7BkW0cIYAVlivcey+uXQgWhabbnr96YC5zED wclH/2APRnaorwXcyuTgYl7oueH/lOzmpUuhKo2BivPAWnyrCIU0PuYO0VJFG7AWYIoBzGmm5 toOFzb02Kua/ISf89TNm0rnMpWoFPFfRiEnKVwGHvHxT+PbGQxg9GL86TIkMfLQw5Jlwp2RmX BaT8FNEqsT3FEuYJ8+pTmGjIFvDATpNMvwdcJAHKOWSNLday9QFbT7a2NvDAkWu4TUbx8tBQQ eg/AzzhHx4Nvilg/Kjbh4LkcTchzKBs4YeColTPNv/igJLUVN4ayEya2D4eRYYOCAF1Ol5dJi 7SoXG3g3h1BeZ7VXIJGnLQu6JGA+VwySOH+oQ5Mk0NFvNnwdDN2+rcDTCLF20uO9Yh3nIX53I w5MUDV9VMLnkoEJ0sYCiO/vbPJ8Vy3eAZXQc0WyyadzQZxLilvT2A7wdhMt+KO1DeaAOQ5Rzb OPmKSxS43jxn0IYd0OqPr+cEBviqyYCluOfvLM8NXfrMwQTEX8jYzUbHu7NXdpSypYeiluEZL C4TJBnfJrm5YvH514LqbI4Oi89P0P1eAuBtFSBDyI2ALcYikSqbwxc+JQ2QgRdwnmTKLKS/TV kMtWm+9kRMjTJjVmJ40kGsBgwRYiHYKcqwhSB6eo8twxRXeEKsJmU1DDZFKd7RSfk/fT55a5D NuIjceAWTcTTz3emQ95yhnuFm9tO01wcvSyHLzXl6EITEuzZ5e2/8dM3iqX4Vga+0k07Aon2q G+HSBQjbNjFbf1+WTPqKTUGMK6hbDfIvKNCi5/ScaW4bm3Tb2bU93B1yERxolPVljSEJy3EOh oZdLrMDH498zbs3UJRcSCL6rcpv8LGroodWMX6HK2R5IdC2k6ZBR6ANM/FPqP9geou+/DnXCX beBXBdCnrMaR+gZfzwN7wWwTYpcFqu3x725uK+JYKa2uvYQEjENA9Ae3m5YAk8EVPqfDjuilD LS/IOLTV8a3E5UnhacPEhD1YJdrQllLidwYQA77rHk1UOyxM2ncwfPlU80Tqgo1XquPfkQoRU UVYZBepXP7z8fwImGuBs0myHWA1tiZIGGGKPMDrmW1HWvcq7FrrwePtCA== Subject: Re: [musl] Why the musl libc did not support neon simd acceleartor officially on mem* operations? 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