Date: Fri, 15 May 2020 23:40:19 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Cc: Srinivasan J <srinidpdk@...il.com> Subject: Re: memcpy/memcmp optimizations and possible alternatives On Sat, May 16, 2020 at 08:37:34AM +0530, Srinivasan J wrote: > Hi, > I see that the musl-libc implementations of mem* functions does not > use AVX/SSE4 instructions. Please let me know if there is a plan to > support these or if there is a recommended way to use optimized > versions of mem* functions when running memory intensive applications > with musl-libc. The application is being run in alpine linux. You can safely replace memcpy/memcmp with another implementation just by linking it in your program, as long as it matches the contract of the standard function and GCC's additional requirements on the function. On modern x86, "rep mov" is, or at least until recently was, supposed to be the fastest way to memcpy. But AMD and Intel like to keep making regressions in this area so it's possible it's not true anymore. I haven't kept up with it the past few years. At least some of the possible alternatives have properties that might make them slower depending on use or even unsafe with respect to weakly ordered memory operations. It's possible that if there are reliably faster approaches, we'll integrate them at some point. Probably not with any runtime selection, although it's inexpensive to do the selection in a code path only used for large n, so it might be ok. Note that our memcmp right now is really bad, and should be optimized.
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.