Re: Building kernels with FPU support?

From: gnn <gnn_at_freebsd.org>
Date: Thu, 24 Oct 2024 01:02:56 UTC

On 23 Oct 2024, at 20:17, Vadim Goncharov wrote:

> On Wed, 23 Oct 2024 19:13:17 -0400
> gnn <gnn@freebsd.org> wrote:
>
>> On 23 Oct 2024, at 19:05, Vadim Goncharov wrote:
>>
>>> On Wed, 23 Oct 2024 10:38:12 -0400
>>> gnn <gnn@freebsd.org> 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 paper 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 restriction on vanilla FPU state rather than supporting every  extension that Intel or Arm ever thought of.  Just, you know, not pretending we run on a PDP-11 ;-)

Best,
George