Date: Fri, 10 Feb 2023 01:09:45 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Mateusz Guzik <mjguzik@gmail.com> Cc: David Chisnall <theraven@freebsd.org>, freebsd-hackers <freebsd-hackers@freebsd.org> Subject: Re: CFT: snmalloc as libc malloc Message-ID: <Y%2BV9Oa6YlIF%2BpGj0@kib.kiev.ua> In-Reply-To: <CAGudoHFeFm1K%2BJSBXaxt2SNTv-tGFgT0onyErOCmBdVjmHaxUg@mail.gmail.com> References: <2f3dcda0-5135-290a-2dff-683b2e9fe271@FreeBSD.org> <CAGudoHFYMLk6EDrSxLiWFNBoYyTKXfHLAUhZC%2BRF4eUE-rip8Q@mail.gmail.com> <E140A3A2-5C4A-4458-B365-AD693AB853E8@FreeBSD.org> <CAGudoHFeFm1K%2BJSBXaxt2SNTv-tGFgT0onyErOCmBdVjmHaxUg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Feb 09, 2023 at 09:53:34PM +0100, Mateusz Guzik wrote: > So, as someone who worked on memcpy previously, I note the variant > currently implemented in libc is pessimal for sizes > 16 bytes because > it does not use SIMD. I do have plans to rectify that, but ENOTIME. Note that you need two kinds of micro-benchmarks for this: - normal microbenchmark which does the SIMD-enabled memcpy() in a loop - a microbenchmark which ensures that the SIMD register file ownership is re-taken on each iteration (or close to it). I am sure that the results from #2 would be astonishing and give quite different prospective on the use of SIMD for basic libc services.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Y%2BV9Oa6YlIF%2BpGj0>