From nobody Mon Feb 13 15:24:39 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PFp6k71pcz3rHHW for ; Mon, 13 Feb 2023 15:24:46 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4PFp6k4f72z3C3r; Mon, 13 Feb 2023 15:24:46 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.17.1/8.17.1) with ESMTPS id 31DFOdUm084868 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 13 Feb 2023 17:24:42 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 31DFOdUm084868 Received: (from kostik@localhost) by tom.home (8.17.1/8.17.1/Submit) id 31DFOdav084867; Mon, 13 Feb 2023 17:24:39 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 13 Feb 2023 17:24:39 +0200 From: Konstantin Belousov To: David Chisnall Cc: freebsd-hackers@freebsd.org Subject: Re: CFT: snmalloc as libc malloc Message-ID: References: <2f3dcda0-5135-290a-2dff-683b2e9fe271@FreeBSD.org> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on tom.home X-Rspamd-Queue-Id: 4PFp6k4f72z3C3r X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Mon, Feb 13, 2023 at 12:51:30PM +0000, David Chisnall wrote: > On 09/02/2023 23:09, Konstantin Belousov wrote: > > 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. > > Does FreeBSD still do lazy context switching of SIMD state? I was under the > impression that this was disabled by all operating systems now because it > exposes speculative side channels across a process boundary. FreeBSD uses lazy context instantiations. Even with it, there were several reports of problems caused by the use of XMM registers in libthr due to significantly increased latency of the context switches. > > Given that the x86-64 and AArch64 ABIs both pass floating point arguments in > SIMD registers by default, I'd be surprised if it gave a performance win - > unless a workload manages to avoid passing any floating-point arguments in a > quantum, it will hit the trap every time. In addition, unless you explicitly > disable it, recent versions of clang will use SIMD registers for inlined > memcpy (irrespective of what libc does) and will also now spill GPRs to SIMD > registers in preference to the stack in some situations. It is common/not unusual to have programs that do not need floating point arithmetic.