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

Groups > comp.lang.c++ > #121694 > unrolled thread

a MSVC and glibc-compatible fmod()

Started byBonita Montero <Bonita.Montero@gmail.com>
First post2025-02-24 11:48 +0100
Last post2025-03-09 14:56 +0200
Articles 20 on this page of 134 — 8 participants

Back to article view | Back to comp.lang.c++

Contents

  a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-02-24 11:48 +0100
    Re: a MSVC and glibc-compatible fmod() Muttley@DastardlyHQ.org - 2025-02-24 12:00 +0000
      Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-02-24 13:48 +0100
        Re: a MSVC and glibc-compatible fmod() Muttley@DastardlyHQ.org - 2025-02-24 13:09 +0000
          Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-02-24 14:22 +0100
            Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-02-24 17:13 +0200
              Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-02-24 16:19 +0100
                Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-02-24 17:52 +0200
                  Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-02-25 09:09 +0100
                    Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-02-25 16:17 +0100
                    Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-02-25 17:26 +0200
                      Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-02-25 16:45 +0100
                        Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-02-25 16:57 +0100
                        Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-02-25 19:17 +0200
                          Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-02-25 18:58 +0100
                            Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-02-26 00:36 +0200
                              Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-02-26 04:15 +0100
                              Re: a MSVC and glibc-compatible fmod() Muttley@DastardlyHQ.org - 2025-02-26 08:16 +0000
                                Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-02-26 14:27 +0200
                                  Re: a MSVC and glibc-compatible fmod() Muttley@DastardlyHQ.org - 2025-02-26 14:39 +0000
                                    FP_CONTRACT was : a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-02-28 16:28 +0200
                                      Re: FP_CONTRACT was : a MSVC and glibc-compatible fmod() Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-01 08:35 -0800
          Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-02-24 16:22 +0200
            Re: a MSVC and glibc-compatible fmod() Muttley@DastardlyHQ.org - 2025-02-24 15:10 +0000
              Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-02-24 17:33 +0200
                Re: a MSVC and glibc-compatible fmod() Muttley@DastardlyHQ.org - 2025-02-24 16:48 +0000
    Re: a MSVC and glibc-compatible fmod() Mr Flibble <leigh@i42.co.uk> - 2025-02-24 22:21 +0000
      Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-02-25 07:37 +0100
        Re: a MSVC and glibc-compatible fmod() Mr Flibble <leigh@i42.co.uk> - 2025-02-25 23:03 +0000
          Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-02-26 02:00 +0200
          Re: a MSVC and glibc-compatible fmod() Wuns Haerst <Wuns.Haerst@wurstfabrik.at> - 2025-02-26 04:01 +0100
      Re: a MSVC and glibc-compatible fmod() Muttley@DastardlyHQ.org - 2025-02-25 08:24 +0000
    Re: a MSVC and glibc-compatible fmod() Mr Flibble <leigh@i42.co.uk> - 2025-02-27 21:16 +0000
      Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-02-28 07:59 +0100
      Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-02-28 12:35 +0200
        Re: a MSVC and glibc-compatible fmod() Mr Flibble <leigh@i42.co.uk> - 2025-02-28 18:12 +0000
      Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-02-28 19:23 +0100
    Re: a MSVC and glibc-compatible fmod() Mr Flibble <leigh@i42.co.uk> - 2025-02-28 18:30 +0000
      Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-02-28 19:31 +0100
        Re: a MSVC and glibc-compatible fmod() Mr Flibble <leigh@i42.co.uk> - 2025-02-28 19:47 +0000
          Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-02-28 20:49 +0100
            Re: a MSVC and glibc-compatible fmod() Mr Flibble <leigh@i42.co.uk> - 2025-03-01 14:37 +0000
              Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-01 16:58 +0100
                Re: a MSVC and glibc-compatible fmod() Mr Flibble <leigh@i42.co.uk> - 2025-03-01 17:11 +0000
                  Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-01 21:02 +0100
                    Re: a MSVC and glibc-compatible fmod() Mr Flibble <leigh@i42.co.uk> - 2025-03-01 20:32 +0000
                      Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-01 21:37 +0100
                        Re: a MSVC and glibc-compatible fmod() Mr Flibble <leigh@i42.co.uk> - 2025-03-01 20:45 +0000
                  Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-02 09:40 +0100
    Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-01 22:55 +0200
      Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-02 18:54 +0200
        Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-02 17:59 +0100
    Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-02 15:41 +0200
      Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-02 17:10 +0100
        Re: a MSVC and glibc-compatible fmod() Mr Flibble <leigh@i42.co.uk> - 2025-03-02 16:22 +0000
          Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-02 17:26 +0100
            Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-02 19:07 +0200
              Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-02 18:09 +0100
                Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-02 18:11 +0100
                  Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-02 19:52 +0200
                    Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-02 18:55 +0100
                      Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-02 20:09 +0200
                        Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-02 19:14 +0100
                        Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-02 19:57 +0100
                          Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-02 22:58 +0200
                            Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-03 12:52 +0100
                              Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-03 18:10 +0200
                                Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-03 23:55 +0200
                                Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-07 09:51 +0100
                          Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-03 18:20 +0200
                            Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-03 17:30 +0100
                              Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-03 19:27 +0200
                                Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-03 18:39 +0100
                      Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-03 02:01 +0200
          Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-02 19:37 +0200
            Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-02 18:41 +0100
              Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-02 20:00 +0200
                Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-02 19:01 +0100
        Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-09 01:31 +0200
          Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-09 07:41 +0100
            Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-09 11:08 +0200
              Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-09 10:31 +0100
                Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-09 11:46 +0200
                  Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-09 10:54 +0100
                    Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-09 12:09 +0200
                      Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-09 11:21 +0100
                        Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-09 14:09 +0200
                          Re: a MSVC and glibc-compatible fmod() Mr Flibble <leigh@i42.co.uk> - 2025-03-09 15:26 +0000
                            Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-09 17:02 +0100
                              Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-09 19:55 +0200
                                Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-09 19:10 +0100
                                  Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-09 19:27 +0100
                          Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-09 17:23 +0100
                            Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-09 20:04 +0200
                              Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-09 19:11 +0100
                                Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-09 20:11 +0100
                              Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-10 07:24 +0100
                                Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-10 10:46 +0100
                                  Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-10 14:26 +0200
                                    Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-10 13:45 +0100
                                      Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-10 16:33 +0200
                                        Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-10 15:46 +0100
                                          Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-10 16:59 +0200
                                            Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-10 16:11 +0100
                                              Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-10 17:43 +0200
                                                Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-10 17:13 +0100
                                                  Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-10 19:51 +0200
                                                    Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-10 19:00 +0100
                                                      Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-10 20:38 +0200
                                                        Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-10 22:34 +0100
                                                          Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-10 22:36 +0100
                                                            Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-11 12:47 +0200
                                                        Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-10 23:52 +0100
                                                          Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-10 23:57 +0100
                                                            Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-11 09:34 +0100
                                                              Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-11 12:29 +0200
                                                                Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-11 12:12 +0100
                                                                  Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-11 13:34 +0200
                                                                    Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-11 13:10 +0100
                                                                      Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-11 14:55 +0200
                                                                        Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-11 14:08 +0100
                                                                        Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-11 15:46 +0200
                                                                  Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-11 13:51 +0200
                                                                Re: a MSVC and glibc-compatible fmod() James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-03-11 14:21 -0400
                                                        Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-11 20:28 +0200
                                                          Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-16 13:48 +0200
                                Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-10 13:17 +0200
                                  Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-10 12:53 +0100
                                  Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-10 12:54 +0100
                Re: a MSVC and glibc-compatible fmod() wij <wyniijj5@gmail.com> - 2025-03-09 18:51 +0800
                  Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-09 12:56 +0100
                    Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-09 14:23 +0200
                      Re: a MSVC and glibc-compatible fmod() Bonita Montero <Bonita.Montero@gmail.com> - 2025-03-09 13:39 +0100
                        Re: a MSVC and glibc-compatible fmod() Michael S <already5chosen@yahoo.com> - 2025-03-09 14:56 +0200

Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7  Next page →

#121777

FromBonita Montero <Bonita.Montero@gmail.com>
Date2025-03-02 18:55 +0100
Message-ID<vq2626$siiv$1@raubtier-asyl.eternal-september.org>
In reply to#121775
Am 02.03.2025 um 18:52 schrieb Michael S:

> Your distribution is very different from what one would expect in
> real-world usage.

There's no real world distibution, so I chose all finites to be
equally likely.

> In real-world usage apart from debugging stage there are no inf, nan or
> y=zero. x=zero happens, but with lower probability that 6%. Denormals
> also happen, but with even lower probability than x=zero.

As I said if I chose 100% finites from the 1 to 0x7FEFFFFFFFFFFFFFu
range I'm still 2.4 times faster.

> Also in majority of real-world scenarios huge x/y ratios either not happen at
> all or are extremely rare.
> 
> 
> 
> 
> 
>

[toc] | [prev] | [next] | [standalone]

#121780

FromMichael S <already5chosen@yahoo.com>
Date2025-03-02 20:09 +0200
Message-ID<20250302200936.00007f47@yahoo.com>
In reply to#121777
On Sun, 2 Mar 2025 18:55:22 +0100
Bonita Montero <Bonita.Montero@gmail.com> wrote:

> Am 02.03.2025 um 18:52 schrieb Michael S:
> 
> > Your distribution is very different from what one would expect in
> > real-world usage.  
> 
> There's no real world distibution, so I chose all finites to be
> equally likely.
> 
> > In real-world usage apart from debugging stage there are no inf,
> > nan or y=zero. x=zero happens, but with lower probability that 6%.
> > Denormals also happen, but with even lower probability than x=zero.
> >  
> 
> As I said if I chose 100% finites from the 1 to 0x7FEFFFFFFFFFFFFFu
> range I'm still 2.4 times faster.
> 
> > Also in majority of real-world scenarios huge x/y ratios either not
> > happen at all or are extremely rare.
> > 
> > 
> > 
> > 
> > 
> >   
> 

You didn't answer the second point, which is critical.
In your fully random scenario 48.7% of cases are huge x/y. That is
completely unrealistic. 

I can easily improve speed of huge x/y at cost of less simple code and
of small slowdown of more typical case, but I consider it
counterproductive. It seems, authors of standard libraries agree with
my judgment.

[toc] | [prev] | [next] | [standalone]

#121781

FromBonita Montero <Bonita.Montero@gmail.com>
Date2025-03-02 19:14 +0100
Message-ID<vq275j$sop2$1@raubtier-asyl.eternal-september.org>
In reply to#121780
Am 02.03.2025 um 19:09 schrieb Michael S:
> On Sun, 2 Mar 2025 18:55:22 +0100
> Bonita Montero <Bonita.Montero@gmail.com> wrote:
> 
>> Am 02.03.2025 um 18:52 schrieb Michael S:
>>
>>> Your distribution is very different from what one would expect in
>>> real-world usage.
>>
>> There's no real world distibution, so I chose all finites to be
>> equally likely.
>>
>>> In real-world usage apart from debugging stage there are no inf,
>>> nan or y=zero. x=zero happens, but with lower probability that 6%.
>>> Denormals also happen, but with even lower probability than x=zero.
>>>   
>>
>> As I said if I chose 100% finites from the 1 to 0x7FEFFFFFFFFFFFFFu
>> range I'm still 2.4 times faster.
>>
>>> Also in majority of real-world scenarios huge x/y ratios either not
>>> happen at all or are extremely rare.
>>>
>>>
>>>
>>>
>>>
>>>    
>>
> 
> You didn't answer the second point, which is critical.
> In your fully random scenario 48.7% of cases are huge x/y. That is
> completely unrealistic.

If I modify my genFinite that way:

	genFinite( 1, 0x433FFFFFFFFFFFFFu )

So that there are no dropped digits before the decimal point,
I'm still nearly twice as fast with my latest code.

> I can easily improve speed of huge x/y at cost of less simple code and
> of small slowdown of more typical case, but I consider it
> counterproductive. It seems, authors of standard libraries agree with
> my judgment.
>

[toc] | [prev] | [next] | [standalone]

#121783

FromBonita Montero <Bonita.Montero@gmail.com>
Date2025-03-02 19:57 +0100
Message-ID<vq29mm$t6t1$1@raubtier-asyl.eternal-september.org>
In reply to#121780
Am 02.03.2025 um 19:09 schrieb Michael S:

> You didn't answer the second point, which is critical.
> In your fully random scenario 48.7% of cases are huge x/y. That is
> completely unrealistic.
> I can easily improve speed of huge x/y at cost of less simple code and
> of small slowdown of more typical case, but I consider it
> counterproductive. It seems, authors of standard libraries agree with
> my judgment.

And you use fesetround, which takes about 40 clock cycles on my
CPU  under Linux (WSL2). Better chose _mm_getcsr() and _mm_setcsr()
for that, which directly sets the FPU control word for SSE / AVX*
/ AVX-512. This is multiple times faster. For the x87-FPU you'd
have to chose different code, but the x87-FPU is totally broken
anywax.

[toc] | [prev] | [next] | [standalone]

#121786

FromMichael S <already5chosen@yahoo.com>
Date2025-03-02 22:58 +0200
Message-ID<20250302225845.00007450@yahoo.com>
In reply to#121783
On Sun, 2 Mar 2025 19:57:30 +0100
Bonita Montero <Bonita.Montero@gmail.com> wrote:

> Am 02.03.2025 um 19:09 schrieb Michael S:
> 
> > You didn't answer the second point, which is critical.
> > In your fully random scenario 48.7% of cases are huge x/y. That is
> > completely unrealistic.
> > I can easily improve speed of huge x/y at cost of less simple code
> > and of small slowdown of more typical case, but I consider it
> > counterproductive. It seems, authors of standard libraries agree
> > with my judgment.  
> 
> And you use fesetround, which takes about 40 clock cycles on my
> CPU  under Linux (WSL2). Better chose _mm_getcsr() and _mm_setcsr()
> for that, which directly sets the FPU control word for SSE / AVX*
> / AVX-512. This is multiple times faster. For the x87-FPU you'd
> have to chose different code, but the x87-FPU is totally broken
> anywax.
> 

If it was on the fast path, I'd consider it.
But improving speed of unimportant slow path at cost of portability?
Nah.

[toc] | [prev] | [next] | [standalone]

#121799

FromBonita Montero <Bonita.Montero@gmail.com>
Date2025-03-03 12:52 +0100
Message-ID<vq456f$19q5b$1@raubtier-asyl.eternal-september.org>
In reply to#121786
Am 02.03.2025 um 21:58 schrieb Michael S:

> If it was on the fast path, I'd consider it.
> But improving speed of unimportant slow path at cost of portability?
> Nah.

For the 75% random finites case I've shown your code becomes about
28% faster with _mm_getcsr() and _mm_setcsr().

[toc] | [prev] | [next] | [standalone]

#121807

FromMichael S <already5chosen@yahoo.com>
Date2025-03-03 18:10 +0200
Message-ID<20250303181008.00002b1f@yahoo.com>
In reply to#121799
On Mon, 3 Mar 2025 12:52:51 +0100
Bonita Montero <Bonita.Montero@gmail.com> wrote:

> Am 02.03.2025 um 21:58 schrieb Michael S:
> 
> > If it was on the fast path, I'd consider it.
> > But improving speed of unimportant slow path at cost of portability?
> > Nah.  
> 
> For the 75% random finites case I've shown your code becomes about
> 28% faster with _mm_getcsr() and _mm_setcsr().

It seems that major slowdown is specific to combination of msys2
libraries with Zen3/4 CPU. 
I see even worse slowness of get/set rounding mode on msys2/Zen3. 
The same msys-compiled binary on Intel CPUs is o.k., at least
relatively to other heavy things going on on the slow path. 
On Zen3 with Microsoft's compiler/library it is also o.k.

As long as it only affects slow path there is nothing to agitated
about.

[toc] | [prev] | [next] | [standalone]

#121851

FromMichael S <already5chosen@yahoo.com>
Date2025-03-03 23:55 +0200
Message-ID<20250303235508.00005866@yahoo.com>
In reply to#121807
On Mon, 3 Mar 2025 18:10:08 +0200
Michael S <already5chosen@yahoo.com> wrote:

> On Mon, 3 Mar 2025 12:52:51 +0100
> Bonita Montero <Bonita.Montero@gmail.com> wrote:
> 
> > Am 02.03.2025 um 21:58 schrieb Michael S:
> >   
> > > If it was on the fast path, I'd consider it.
> > > But improving speed of unimportant slow path at cost of
> > > portability? Nah.    
> > 
> > For the 75% random finites case I've shown your code becomes about
> > 28% faster with _mm_getcsr() and _mm_setcsr().  
> 
> It seems that major slowdown is specific to combination of msys2
> libraries with Zen3/4 CPU. 
> I see even worse slowness of get/set rounding mode on msys2/Zen3. 
> The same msys-compiled binary on Intel CPUs is o.k., at least
> relatively to other heavy things going on on the slow path. 
> On Zen3 with Microsoft's compiler/library it is also o.k.
> 
> As long as it only affects slow path there is nothing to agitated
> about.
> 
> 
> 
> 

I can think about half a dozen of different ways of avoiding the need to
change rounding. However most of them are boring. Only one is fun.

#include <math.h>
#include <fenv.h>

double my_fmod(double x, double y)
{
  if (isnan(x))
    return x;

  // pre-process y
  if (y < 0)
   y = -y;
  else if (y > 0)
   ;
  else {
    if (isnan(y))
      return y;
    // y==0
    feraiseexcept(FE_INVALID);
    return NAN;
  }

  // y in (0:+inf]
  double ax = fabs(x);

  // Quick path
  if (ax * 0x1p-53 < y) {
    // among other things, x guaranteed to be finite
    if (ax < y)
       return x; // case y=+-inf covered here
    double d = floor(ax/y);
    double res = fma(-y, d, ax);
    if (res < 0) {
      // overshoot because of unfortunate division rounding
      // it is extremely rare for small x/y,
      // but not rare when x/y is close to 2**53
      res += y;
    }
    if (x < 0)
      res = -res;
    return res;
  }

  // slow path
  if (isinf(x)) {
    feraiseexcept(FE_INVALID);
    return NAN;
  }

  int flipflop = 0;
  do {
    double yy = y;
    while (yy < ax * 0x1p-1022)
      yy *= 0x1p1021;

    do {
      ax = fma(-yy, floor(ax/yy), ax);
      flipflop ^= (ax < 0);
      ax = fabs(ax);
    } while (ax >= yy);
  } while (ax >= y);
  if (flipflop)
    ax = y - ax;
  if (x < 0)
    ax = -ax;
  return ax;
}


To my surprise, in case of insane x/y ratios it was faster than original
not only on Zen3/Msys, but on Intel CPUs and MSVC platform as well.

[toc] | [prev] | [next] | [standalone]

#121899

FromBonita Montero <Bonita.Montero@gmail.com>
Date2025-03-07 09:51 +0100
Message-ID<vqec29$3evpa$1@raubtier-asyl.eternal-september.org>
In reply to#121807
Am 03.03.2025 um 17:10 schrieb Michael S:

> It seems that major slowdown is specific to combination of msys2
> libraries with Zen3/4 CPU.
> I see even worse slowness of get/set rounding mode on msys2/Zen3.
> The same msys-compiled binary on Intel CPUs is o.k., at least
> relatively to other heavy things going on on the slow path.
> On Zen3 with Microsoft's compiler/library it is also o.k.

If I use _mm_setcsr() and _mm_getcsr() I can disable your fast path
and I get the same performance. The Linux code with clang++-18 has
about the same performance like my Windows-code with MSVC (... and
this 128/64 -> 64:64 division).

[toc] | [prev] | [next] | [standalone]

#121810

FromMichael S <already5chosen@yahoo.com>
Date2025-03-03 18:20 +0200
Message-ID<20250303182009.00003f12@yahoo.com>
In reply to#121783
On Sun, 2 Mar 2025 19:57:30 +0100
Bonita Montero <Bonita.Montero@gmail.com> wrote:

> For the x87-FPU you'd
> have to chose different code, but the x87-FPU is totally broken
> anywax.
> 

x87 is not broken relatively to its own specifications. It just happens
to be slightly different from IEEE-754 specifications. Which is not
surprising considering that it predates IEEE-754 Standard by several
years.
Today there are very few reasons to still use x87 in new software.
However back in it's time x87 was an astonishingly good piece of work,
less so in performance (it was not fast, even by standards of its time)
more so for features, precision and especially for consistency of its
arithmetic.

[toc] | [prev] | [next] | [standalone]

#121813

FromBonita Montero <Bonita.Montero@gmail.com>
Date2025-03-03 17:30 +0100
Message-ID<vq4lfa$1crbh$1@raubtier-asyl.eternal-september.org>
In reply to#121810
Am 03.03.2025 um 17:20 schrieb Michael S:

> x87 is not broken relatively to its own specifications. It just happens
> to be slightly different from IEEE-754 specifications. Which is not
> surprising considering that it predates IEEE-754 Standard by several
> years.

You can reduce the with of the mantissa to 53 or 24 bit, but the
exponent is always 15 bit; that's not up to any specification.

> Today there are very few reasons to still use x87 in new software.
> However back in it's time x87 was an astonishingly good piece of work,
> less so in performance (it was not fast, even by standards of its time)
> more so for features, precision and especially for consistency of its
> arithmetic.

There are compiler-settings which enforce consistency by storing values
with reduced precision and re-loading them to give expectable results
when you use values < long double. That's a mess.

[toc] | [prev] | [next] | [standalone]

#121823

FromMichael S <already5chosen@yahoo.com>
Date2025-03-03 19:27 +0200
Message-ID<20250303192732.00002523@yahoo.com>
In reply to#121813
On Mon, 3 Mar 2025 17:30:39 +0100
Bonita Montero <Bonita.Montero@gmail.com> wrote:

> Am 03.03.2025 um 17:20 schrieb Michael S:
> 
> > x87 is not broken relatively to its own specifications. It just
> > happens to be slightly different from IEEE-754 specifications.
> > Which is not surprising considering that it predates IEEE-754
> > Standard by several years.  
> 
> You can reduce the with of the mantissa to 53 or 24 bit, but the
> exponent is always 15 bit; that's not up to any specification.
> 

That's up to x87 specification. Which predates IEEE-754.

> > Today there are very few reasons to still use x87 in new software.
> > However back in it's time x87 was an astonishingly good piece of
> > work, less so in performance (it was not fast, even by standards of
> > its time) more so for features, precision and especially for
> > consistency of its arithmetic.  
> 
> There are compiler-settings which enforce consistency by storing
> values with reduced precision and re-loading them to give expectable
> results when you use values < long double. That's a mess.
> 

It's a mess only if you try to be very compatible with IEEE-754 specs.
If you don't try to be compatible, you just enjoy higher precision
and higher dynamic range for as long as you can. If you want it all the
time, nothing prevents you from storing full 80-bit numbers in memory.
Back in the era of 16-bit buses it was only 10-25% slower than storing
64-bit results. For a full application difference in speed between
80-bit and 64-bit precision was typically just few per cents.

[toc] | [prev] | [next] | [standalone]

#121826

FromBonita Montero <Bonita.Montero@gmail.com>
Date2025-03-03 18:39 +0100
Message-ID<vq4ph7$1djan$1@raubtier-asyl.eternal-september.org>
In reply to#121823
Am 03.03.2025 um 18:27 schrieb Michael S:

> That's up to x87 specification. Which predates IEEE-754.

It's dangerous. From the "Handbook of Floating Point Arithmetic".

  The dynamic rounding precision can introduce bugs in modern soft-
  ware, which is almost always made up of several components (dy-
  namic libraries, plug-ins). For instance, the following bug in
  Mozilla’s Javascript engine was discovered in 2006: if the rounding
  precision was reduced to single precision by a plug-in, then the
  js_dtoa function (double-to-string conversion) could overwrite
  memory, making the application behave erratically, e.g., crash.
  The cause was the loop exit condition being always false due to
  an unexpected floating-point error.

So it can make it harder to write portable software.

[toc] | [prev] | [next] | [standalone]

#121790

FromMichael S <already5chosen@yahoo.com>
Date2025-03-03 02:01 +0200
Message-ID<20250303020125.000018db@yahoo.com>
In reply to#121777
On Sun, 2 Mar 2025 18:55:22 +0100
Bonita Montero <Bonita.Montero@gmail.com> wrote:

> Am 02.03.2025 um 18:52 schrieb Michael S:
> 
> > Your distribution is very different from what one would expect in
> > real-world usage.  
> 
> There's no real world distibution, so I chose all finites to be
> equally likely.
> 
> > In real-world usage apart from debugging stage there are no inf,
> > nan or y=zero. x=zero happens, but with lower probability that 6%.
> > Denormals also happen, but with even lower probability than x=zero.
> >  
> 
> As I said if I chose 100% finites from the 1 to 0x7FEFFFFFFFFFFFFFu
> range I'm still 2.4 times faster.
> 

On my CPU [for huge ratios] it is indeed faster than your previous
attempt, but still 1.25x slower than standard library. And for
non-huge ratios there is no improvement - still 3.3 times slower than
standard library.

[toc] | [prev] | [next] | [standalone]

#121773

FromMichael S <already5chosen@yahoo.com>
Date2025-03-02 19:37 +0200
Message-ID<20250302193716.00000bf2@yahoo.com>
In reply to#121762
On Sun, 02 Mar 2025 16:22:20 +0000
Mr Flibble <leigh@i42.co.uk> wrote:

> On Sun, 2 Mar 2025 17:10:37 +0100, Bonita Montero
> <Bonita.Montero@gmail.com> wrote:
> 
> >This is my code, improved by the _udiv128-intrinsic of MSVC which
> >provides a 128 / 64 division. With that my algorithm becomes nearly
> >tree times as fast as before. I'll provide a g++ / clang++ compatible
> >version with inline-assembly later.
> >  
> Still slow tho.
> 
> /Flibble

The truth is that relative speed of FP vs Integer algorithms depends on
specific CPU that one is using for measurements.
I measured on relatively old CPU - Intel Skylake. On this CPU integer
division is very significantly slower than floating-point division.
On newer CPUs, like Intel IceLake/Tiger Lake and Alder Lake or AMD Zen
3/4/5 and even more sore on Apple M-series the difference in speed
between floating-point and integer division is less significant, and
in few cases integer division is even faster, so in theory Bonita's code
could be more competitive.

From Agner Fog's tables:
Arch       DIVSD   DIV r64
Skylake    13-14   35-88
IceLake    13-14   15
Alder Lake 14      10
Zen3       13.5    9-17


My problem is that because of Bonita's horrible coding style I am not
even trying to understand what's is going on within his/her code.

[toc] | [prev] | [next] | [standalone]

#121774

FromBonita Montero <Bonita.Montero@gmail.com>
Date2025-03-02 18:41 +0100
Message-ID<vq2592$sd2m$1@raubtier-asyl.eternal-september.org>
In reply to#121773
Am 02.03.2025 um 18:37 schrieb Michael S:

> The truth is that relative speed of FP vs Integer algorithms depends on
> specific CPU that one is using for measurements.
> I measured on relatively old CPU - Intel Skylake. On this CPU integer
> division is very significantly slower than floating-point division.
> On newer CPUs, like Intel IceLake/Tiger Lake and Alder Lake or AMD Zen
> 3/4/5 and even more sore on Apple M-series the difference in speed
> between floating-point and integer division is less significant, and
> in few cases integer division is even faster, so in theory Bonita's code
> could be more competitive.
> 
>  From Agner Fog's tables:
> Arch       DIVSD   DIV r64
> Skylake    13-14   35-88
> IceLake    13-14   15
> Alder Lake 14      10
> Zen3       13.5    9-17

On my Zen4-CPU your code is slightly faster than my initial code with
the shown selection of random values (which don't prefer any fast path).
My current code is on my CPU with MSVC 2.4 times faster if I chose the
values somethat different with only finites and no denormals, infs, nans
or zeroes.

> My problem is that because of Bonita's horrible coding style I am not
> even trying to understand what's is going on within his/her code.

Your coding-style is horrible. Mine is "too beautiful" (my employer).

[toc] | [prev] | [next] | [standalone]

#121778

FromMichael S <already5chosen@yahoo.com>
Date2025-03-02 20:00 +0200
Message-ID<20250302200005.00004751@yahoo.com>
In reply to#121774
On Sun, 2 Mar 2025 18:41:58 +0100
Bonita Montero <Bonita.Montero@gmail.com> wrote:

> 
> Your coding-style is horrible. 

Even with minimal comments it's not too hard to understand what's going
on within my code. With few more comments it could become completely
clear.
Of course, floating-point algorithm is inherently simpler. That helps.

> Mine is "too beautiful" (my employer).
> 

It sounds like your employer agrees with me, but he expresses his
thought in humoristic style.

[toc] | [prev] | [next] | [standalone]

#121779

FromBonita Montero <Bonita.Montero@gmail.com>
Date2025-03-02 19:01 +0100
Message-ID<vq26cr$sl0v$1@raubtier-asyl.eternal-september.org>
In reply to#121778
Am 02.03.2025 um 19:00 schrieb Michael S:

>> Mine is "too beautiful" (my employer).

> It sounds like your employer agrees with me, but he expresses his
> thought in humoristic style.

No, he likes my style.

[toc] | [prev] | [next] | [standalone]

#121901

FromMichael S <already5chosen@yahoo.com>
Date2025-03-09 01:31 +0200
Message-ID<20250309013127.00003503@yahoo.com>
In reply to#121761
On Sun, 2 Mar 2025 17:10:37 +0100
Bonita Montero <Bonita.Montero@gmail.com> wrote:

> This is my code, improved by the _udiv128-intrinsic of MSVC which
> provides a 128 / 64 division. With that my algorithm becomes nearly
> tree times as fast as before. I'll provide a g++ / clang++ compatible
> version with inline-assembly later.
> 
> template<bool _32 = false>
> double xMyFmod( double x, double y )
> {
> 	constexpr uint64_t
> 		SIGN = 1ull << 63,
> 		IMPLICIT = 1ull << 52,
> 		MANT = IMPLICIT - 1,
> 		QBIT = 1ull << 51;
> 	uint64_t const
> 		binX = bit_cast<uint64_t>( x ),
> 		binY = bit_cast<uint64_t>( y );
> 	static auto abs = []( uint64_t m ) { return m & ~SIGN; };
> 	auto isNaN = []( uint64_t m ) { return abs( m ) >=
> 0x7FF0000000000001u; }; auto isSig = []( uint64_t m ) { return !(m &
> QBIT); }; if( isNaN( binX ) ) [[unlikely]] // x == NaN
> #if defined(_MSC_VER)
> 		return bit_cast<double>( isNaN( binY ) ? binY | binX
> & binY & QBIT : binX );
> #else
> 	{
> 		if( isSig( binX ) || isNaN( binY ) && isSig( binY ) )
> [[unlikely]] feraiseexcept( FE_INVALID );
> 		return bit_cast<double>( binX | QBIT );
> 	}
> #endif
> 	auto isInf = []( uint64_t m ) { return abs( m ) ==
> 0x7FF0000000000000u; }; if( isNaN( binY ) ) [[unlikely]] // x != NaN
> || y == NaN #if defined(_MSC_VER)
> 	{
> 		if constexpr( _32 )
> 			if( isInf( binX ) )
> 				feraiseexcept( FE_INVALID );
> 		return y;
> 	}
> #else
> 	{
> 		if( isSig( binY ) ) [[unlikely]]
> 			feraiseexcept( FE_INVALID );
> 		return bit_cast<double>( binY | QBIT );
> 	}
> #endif
> 	if( isInf( binX ) ) // x == Inf
> 	{
> 		feraiseexcept( FE_INVALID );
> #if defined(_MSC_VER)
> 		return bit_cast<double>( binX & ~MANT | QBIT );
> #else
> 		return -numeric_limits<double>::quiet_NaN();
> #endif
> 	}
> 	if( !abs( binY ) ) [[unlikely]] // y == 0
> 	{
> 		feraiseexcept( FE_INVALID );
> #if defined(_MSC_VER)
> 		return numeric_limits<double>::quiet_NaN();
> #else
> 		return -numeric_limits<double>::quiet_NaN();
> #endif
> 	}
> 	if( !abs( binX ) || isInf( binY ) ) [[unlikely]] // x == 0 ||
> y == Inf return x;
> 	auto exp = []( uint64_t b ) -> int { return b >> 52 & 0x7FF;
> }; int
> 		expX = exp( binX ),
> 		expY = exp( binY );
> 	auto mant = []( uint64_t b ) { return b & MANT; };
> 	uint64_t
> 		mantX = mant( binX ),
> 		mantY = mant( binY );
> 	int headBits = 11;
> 	static auto normalize = [&]( int &exp, uint64_t &mant )
> 	{
> 		unsigned shift = countl_zero( mant ) - headBits;
> 		mant <<= shift;
> 		exp -= shift;
> 	};
> 	auto build = []( int &exp, uint64_t &mant )
> 	{
> 		if( exp ) [[likely]]
> 			mant |= IMPLICIT;
> 		else
> 		{
> 			exp = 1;
> 			normalize( exp, mant );
> 		}
> 	};
> 	build( expX, mantX );
> 	build( expY, mantY );
> 	int
> 		tailX = countr_zero( mantX ),
> 		tailY = countr_zero( mantY ),
> 		tailBits = tailX <= tailY ? tailX : tailY;
> 	headBits += tailBits;
> 	mantX >>= tailBits;
> 	mantY >>= tailBits;
> 	uint64_t signX = binX & SIGN;
> 	int expDiff;
> #if defined(_MSC_VER)
> 	while( (expDiff = expX - expY) > 63 )
> 	{
> 		unsigned long long hi = mantX >> 1, lo = mantX << 63,
> remainder; (void)_udiv128( hi, lo, mantY, &remainder );
> 		expX -= 63;
> 		mantX = remainder;
> 		normalize( expX, mantX );
> 	}
> #endif
> 	while( (expDiff = expX - expY) > 0 )
> 	{
> 		unsigned bits = expDiff <= headBits ? expDiff :
> headBits; if( !(mantX = (mantX << bits) % mantY) ) [[unlikely]]
> 			return bit_cast<double>( signX );
> 		expX -= bits;
> 		normalize( expX, mantX );
> 	}
> 	if( !expDiff && mantX >= mantY ) [[unlikely]]
> 		if( (mantX -= mantY) ) [[likely]]
> 			normalize( expX, mantX );
> 		else
> 			return bit_cast<double>( signX );
> 	mantX <<= tailBits;
> 	mantY <<= tailBits;
> 	if( expX <= 0 ) [[unlikely]]
> 	{
> 		assert(expX >= -51);
> 		mantX = mantX >> (unsigned)(-expX + 1);
> 		expX = 0;
> 	}
> 	return bit_cast<double>( signX | (uint64_t)expX << 52 | mantX
> & MANT ); }
> 
> double myFmod( double x, double y )
> {
> 	return xMyFmod( x, y );
> }
> 
> inline float myFmod( float x, float y )
> {
> 	return (float)xMyFmod<true>( (double)x, (double)y );
> }


This code does not work in plenty of cases. It seems, your test vectors
have poor coverage.
Try, for example, x=1.8037919852882307, y=2.22605637008665934e-194

[toc] | [prev] | [next] | [standalone]

#121902

FromBonita Montero <Bonita.Montero@gmail.com>
Date2025-03-09 07:41 +0100
Message-ID<vqjd6i$k0pp$1@raubtier-asyl.eternal-september.org>
In reply to#121901
Am 09.03.2025 um 00:31 schrieb Michael S:
> This code does not work in plenty of cases. It seems, your test vectors
> have poor coverage.
> Try, for example, x=1.8037919852882307, y=2.22605637008665934e-194

	cout << hexfloat << myFmod( 1.8037919852882307, 
2.22605637008665934e-194 ) << endl;
	cout << hexfloat << fmod( 1.8037919852882307, 2.22605637008665934e-194 
) << endl;


Prints the same result under Linux and Windows.

[toc] | [prev] | [next] | [standalone]

Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7  Next page →

Back to top | Article view | comp.lang.c++

csiph-web