From nobody Thu Oct 24 01:02:56 2024 X-Original-To: freebsd-arch@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 4XYnhd3Hlzz5ZsCW for ; Thu, 24 Oct 2024 01:02:57 +0000 (UTC) (envelope-from gnn@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XYnhd2M23z4sYv; Thu, 24 Oct 2024 01:02:57 +0000 (UTC) (envelope-from gnn@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1729731777; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=vhtnNrzvlmMGmOv6g3e0AVKV0Z6MVr0xvvVKa69KBMA=; b=Skv18cx8jUi8MWUpkX+geqEuLwBtTWLPMcq5Rc/awaGhuvuhCx8kxsGgZHnP7/GX2bdqAW WcQEd6yqrmgekt/jZc2LkxPMBAaaYMR0t9MBwHsiMNmnaOAMynI+EcFkyFV9KsXg2PFSw4 xTrIzcY3rBK/8aS6L0grKJ0FvKUFL9HJ64s4XiuBKY62G13FJlfRlxPGiKuyLPAb/TnQ8Z JJ3JSO0Hk8R8O/CFpjID+OyTkzIXYCBXCeZErWezzOHXqq71aD4zVSbXsOBC3SPuuB36M9 7cfi1acTxbKgWSk8qOLvncKmL92FR3rmjZ1JAEmBbp4tnzHGK7jVyv5EGRAY6A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1729731777; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=vhtnNrzvlmMGmOv6g3e0AVKV0Z6MVr0xvvVKa69KBMA=; b=NY2tqwQKRqTgmLjSsNFLmm/U6qpOzD/iElpo16lmvRf7A76oSkXHrSR7gmk5ht1qOZH/Pg KmdozDpVdYmlSpQfRmkQXwu5C7BwdpizsXdtfjhzbb0skfSE3orZjJbTxckkDGn7v+va1J PiA4DmYsVvibuMdpKA0m2K95xNsH146s5C/Ehxr+vG8oS4FTscGTe3DCceoaWoIwfld2f+ Q77zuZpyz5z4hRN2WsIbJ1YPioNYHBFxmP9bZURZV38neizOhNJG8jjyNS+/FmrY3GNwWL UjNJ69mZ18fvp7us6RhMseDOVvnOnVrL+uCIi914tp1r8oP0EfhwXBi7Isn3Pg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1729731777; a=rsa-sha256; cv=none; b=ymUrJjhFLdVPAnjbRRdx/XojHyRR16WCw5WUq7RN6CNawmZK8aCxLy3ClWcl/sr9xt7YSH 6xWgKphH8ESNEBq42ny1haVi8SzHpqhSZOPtna9Uo9oLng9TuzFvPUkBekdMvyq9zhcA7v eh+5VMWvo7hq5FY6l4vsy9Ho7A3AofncJGuFPartvPXkAH8v5lFGi43i1JU02y20YA9S6A vURPZnnRsHR2iLf8V4fd9ieFOdyfhHnA1IG0VBLClqrxjRwAEa4zrFFRS48NJwjWbZRG7k vphvxzRaD5+mhHvqv+VjMwTgupzYayC/XiOmqnEAb3WxgLTTM+Dn6DrSC/8cZA== Received: from [192.168.68.1] (pool-173-56-221-109.nycmny.fios.verizon.net [173.56.221.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gnn) by smtp.freebsd.org (Postfix) with ESMTPSA id 4XYnhd1p31z1DkB; Thu, 24 Oct 2024 01:02:57 +0000 (UTC) (envelope-from gnn@freebsd.org) From: gnn To: Vadim Goncharov Cc: Arch Subject: Re: Building kernels with FPU support? Date: Wed, 23 Oct 2024 21:02:56 -0400 X-Mailer: MailMate (1.14r5937) Message-ID: In-Reply-To: <20241024031759.49296609@nuclight.lan> References: <20241024020534.37003492@nuclight.lan> <9BC8F88D-380F-4BC0-B1C7-2657916B13BF@freebsd.org> <20241024031759.49296609@nuclight.lan> List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On 23 Oct 2024, at 20:17, Vadim Goncharov wrote: > On Wed, 23 Oct 2024 19:13:17 -0400 > gnn wrote: > >> On 23 Oct 2024, at 19:05, Vadim Goncharov wrote: >> >>> On Wed, 23 Oct 2024 10:38:12 -0400 >>> gnn wrote: >>> >>>> Howdy, >>>> >>>> I am wondering if anyone has tried, lately, to see what effect >>>> building with FPU support has on overall system performance. I've >>>> been working with a kernel module that needs this (for reasons I'll >>>> not go into now) and it occurred to me that the perceived >>>> performance overhead that caused us to only do fixed point in the >>>> kernel may no longer be significant. I note that Linux has an >>>> option to build their kernel with FPU support. >>>> >>>> And yes, I know that we have the ability to selectively deal with >>>> the FPU, from the calls outlined in Section 9 for fpu, but I'm >>>> asking the more general question of "does it matter?" and "if so, >>>> how much?" >>> >>> Would be great to have it for e.g. having portions of SQLite in >>> kernel, e.g. it's R*Tree module for fast 5-dimensions lookup (like >>> for firewall rules) uses floats. >> >> Funny you should mention sqlite in the kernel, since that's the exact >> use case that started me down this path, and is covered in a paper >> I've co-authored that's been accepted for publication at a database >> conference in 2025. > > Well, I'd think this is a pretty obvious idea - to take a working > tested implementation of complex code under compatible license, e.g. > for B-trees - as we have very scarce choice of data structures in > kernel, e.g. RB-trees have 3-pointers overhead > Maybe your paper is about more interesting uses / as a real DB, IDK. > I'm giving a talk about this at the November DevSummit, and once the pape= r is out I'm happy to share that as well. >> I am sure there are other use cases, we already have this on for the >> openssl module, for example. > > Vector and other instructions e.g. for even just plain `memmove()` ?.. > Well, first, I'm just thinking about doubles, and turning off the restric= tion on vanilla FPU state rather than supporting every extension that In= tel or Arm ever thought of. Just, you know, not pretending we run on a P= DP-11 ;-) Best, George