Re: Building kernels with FPU support?

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 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()` ?..

-- 
WBR, @nuclight