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

Groups > comp.lang.c > #402656

Re: Taking hypot(3) To The Edge

Cross-posted to 2 groups.

Show all headers | View raw

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.

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