Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #402677

Re: Taking hypot(3) To The Edge

Cross-posted to 2 groups.

Show all headers | View raw

Michael S <already5chosen@yahoo.com> posted:

> On Sat, 3 Oct 2026 20:22:51 +0200
> Terje Mathisen <terje.mathisen@tmsw.no> wrote:
> 
> > Michael S wrote:
> > > On Fri, 2 Oct 2026 20:35:56 +0200
> > > Terje Mathisen <terje.mathisen@tmsw.no> wrote:
> > >   
> > >> David Brown wrote:  
> > >>> On 01/10/2026 13:12, Michael S wrote:  
> > >>>> On Thu, 1 Oct 2026 10:17:57 +0200
> > >>>> David Brown <david.brown@hesbynett.no> wrote:
> > >>>>     
> > >>>>> On 01/10/2026 03:33, bart wrote:  
> > >>>>>> On 01/10/2026 01:47, Lawrence D’Oliveiro wrote:  
> > >>>>>>> A couple of things stand out immediately: one is that the
> > >>>>>>> “long double” type doesn’t seem to make
> > >>>>>>> use of all the 128 bits it occupies. I was expecting a
> > >>>>>>> mantissa length closer to 100 bits, but it’s nowhere
> > >>>>>>> near that.  
> > >>>>>>
> > >>>>>> Probably it uses Intel's 80-bit x87 FPU format. That uses a
> > >>>>>> 64-bit mantissa (with explicit top bit).  
> > >>>>>
> > >>>>> Yes, that's the default for "long double" in the standard x86-64
> > >>>>> ABI.
> > >>>>>
> > >>>>> On 32-bit x86, these 10-byte doubles were often stored in
> > >>>>> 12-byte (96-bit) containers for better alignment, but I don't
> > >>>>> know the ABI standards here.
> > >>>>>
> > >>>>> On 64-bit x86, for better alignment they are stored in 16-byte
> > >>>>> containers.  The rest of the space will be padding.
> > >>>>>
> > >>>>> gcc supports "-mlong-double-64", "-mlong-double-80" and
> > >>>>> "-mlong-double-128" flags.  
> > >>>>
> > >>>> The latter appears to be a default on ARM64 Linux.  
> > >>>
> > >>> That makes sense.  Although software 128-bit floating point is
> > >>> going to be very slow compared to hardware 64-bit, the reason you
> > >>> would use "long double" is to get more than "double".  
> > >>
> > >> Significantly slower, yes.
> > >>
> > >> For Mill we figured out that if the HW provided a small number of
> > >> helper functions (easy to do in HW, much harder in SW), then you
> > >> can do most ops in maybe 5x the HW cycle count.
> > >>
> > >> Without that help, you need to manually extract
> > >> sign/exp/mantissa(inserting leading bit unless subnormal), then for
> > >> add/sub you must normalize the smaller number (including sticky
> > >> bit), do the add, normalize again, then merge with exponent and
> > >> round.
> > >>
> > >> For FMUL you don't pre-normalize (so no extra cycles for
> > >> subnormal), but you have to handle the potential for up to 111
> > >> bits of post-normalization.
> > >>
> > >> Michael S is my current benchmark source here, I'd guess FADD128 in
> > >> less than 40 cycles, about the same for FMUL128, while FMAC128 has
> > >> to be a little bit harder with a _very_ wide intermediate result.
> > >>
> > >> Terje
> > >>  
> > > 
> > > Of course, an actual cycle count depends on what you measure,
> > > latency or throughput, on your CPU, on how many corners you are
> > > willing to cut w.r.t. support for rounding modes and for FP
> > > exceptions and on the ABI. Current x86-64 SYSV ABI is quite
> > > problematic and rather far from well-thought.
> > > Windows currently has no official FP128 ABI at all, the closest to
> > > official is the ABI implemented by gcc under msys2. It is even more
> > > problematic than SysV.
> > > As far as I am concerned, the most problematic part of both ABIs is
> > > program status word that is shared with FP32/64. But registers
> > > choice is also bad.
> > > According to what I hear from Thomas Koenig, in Fortran quite a few
> > > corners can be cut without violating language assumptions. For C it
> > > would be harder.
> > > With most corners cut, i.e. without non-default rounding modes and
> > > without support for Inexact exception, and for throughput rather
> > > than latency Zen3/Linux runs at ~50 clocks per FMUL+FADD. I never
> > > tried to separate between the two. Would think that they are about
> > > the same.
> > > 
> > > Pay attention, that nearly all cost of implementing non-default
> > > rounding mode is because of need to read rounding mode from HW
> > > register. The same applies to implementing Inexact exception - the
> > > main cost is update of HW register.  
> > 
> > So what you are saying is the my guesstimate was in the right
> > ballpark, but that it would be far better for fp128 to be a totally
> > separate environment, with all flags and modes maintained in the
> > library instead of sharing anything with the HW?
> > 
> 
> Yes. 

This, also, argues for FP8, FP16, FP32 have entirely separate
environments, too.

> Also it would be better if parameteres/return values to/from
> support routines (i.e. fadd128, fmul128 etc) passed either in GPRs or in
> memory instead of SIMD registers.
> 
> > Regarding rounding modes, in my own Mill work a single 64-bit const 
> > contain all the rounding rules for the four non-truncate
> > alternatives, so this didn't really cost much.
> > 
> 
> And what happens when FP32 implemented in HW, but FP64 emoulated in
> software as is the most common case in ARM-based MCUs?
> 
> > Terje
> > 
> > 
> 
> 

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Taking hypot(3) To The Edge Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-01 00:47 +0000
  Re: Taking hypot(3) To The Edge "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-10-01 01:02 +0000
    Re: Taking hypot(3) To The Edge Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-01 01:55 +0000
      Re: Taking hypot(3) To The Edge "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-10-01 03:44 +0000
  Re: Taking hypot(3) To The Edge bart <bc@freeuk.com> - 2026-10-01 02:33 +0100
    Re: Taking hypot(3) To The Edge Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-01 02:38 +0000
    Re: Taking hypot(3) To The Edge David Brown <david.brown@hesbynett.no> - 2026-10-01 10:17 +0200
      Re: Taking hypot(3) To The Edge Michael S <already5chosen@yahoo.com> - 2026-10-01 14:12 +0300
        Re: Taking hypot(3) To The Edge David Brown <david.brown@hesbynett.no> - 2026-10-01 13:47 +0200
          Re: Taking hypot(3) To The Edge Terje Mathisen <terje.mathisen@tmsw.no> - 2026-10-02 20:35 +0200
            Re: Taking hypot(3) To The Edge bart <bc@freeuk.com> - 2026-10-02 21:17 +0100
            Re: Taking hypot(3) To The Edge BGB <cr88192@gmail.com> - 2026-10-02 17:13 -0500
              Re: Taking hypot(3) To The Edge Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-03 02:17 +0000
                Re: Taking hypot(3) To The Edge BGB <cr88192@gmail.com> - 2026-10-03 15:20 -0500
                Re: Taking hypot(3) To The Edge Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-03 21:46 +0000
                Re: Taking hypot(3) To The Edge BGB <cr88192@gmail.com> - 2026-10-03 20:35 -0500
                Re: Taking hypot(3) To The Edge Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-04 23:54 +0000
            Re: Taking hypot(3) To The Edge Michael S <already5chosen@yahoo.com> - 2026-10-03 21:06 +0300
              Re: Taking hypot(3) To The Edge Terje Mathisen <terje.mathisen@tmsw.no> - 2026-10-03 20:22 +0200
                Re: Taking hypot(3) To The Edge Michael S <already5chosen@yahoo.com> - 2026-10-03 22:01 +0300
                Re: Taking hypot(3) To The Edge Terje Mathisen <terje.mathisen@tmsw.no> - 2026-10-03 23:20 +0200
                Re: Taking hypot(3) To The Edge MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-04 17:49 +0000
                Re: Taking hypot(3) To The Edge Thomas Koenig <tkoenig@netcologne.de> - 2026-10-03 19:47 +0000
  Re: Taking hypot(3) To The Edge bart <bc@freeuk.com> - 2026-10-01 23:05 +0100
    Re: Taking hypot(3) To The Edge Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-02 02:34 +0000
      Re: Taking hypot(3) To The Edge Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-01 21:14 -0700
      Re: Taking hypot(3) To The Edge bart <bc@freeuk.com> - 2026-10-02 11:39 +0100

csiph-web