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

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

why is there not a ipow version of pow?

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

Contents

  why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-11 03:01 -0500
    Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-11 13:11 +0200
      Re: why is there not a ipow version of pow? bart <bc@freeuk.com> - 2026-08-11 12:45 +0100
        Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-11 14:34 +0200
        Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-11 14:55 +0200
          Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-11 15:19 +0200
            Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-11 15:27 +0200
              Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-11 16:08 +0200
                Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-11 16:18 +0200
                  Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-11 17:11 +0200
                    Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-11 17:20 +0200
                      Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-11 17:32 +0200
                        Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-11 17:39 +0200
                          Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-11 18:33 +0200
                            Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-11 18:39 +0200
                            Re: why is there not a ipow version of pow? Michael S <already5chosen@yahoo.com> - 2026-08-11 23:31 +0300
                        Re: why is there not a ipow version of pow? James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-08-11 11:46 -0400
                          Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-11 18:35 +0200
                        Re: why is there not a ipow version of pow? antispam@fricas.org (Waldek Hebisch) - 2026-08-11 22:53 +0000
                          Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-12 10:08 +0200
                            Re: why is there not a ipow version of pow? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-12 03:58 -0700
                              Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-12 13:31 +0200
                              Re: why is there not a ipow version of pow? Michael S <already5chosen@yahoo.com> - 2026-08-12 22:43 +0300
                                Re: why is there not a ipow version of pow? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-12 13:44 -0700
                                  Re: why is there not a ipow version of pow? Michael S <already5chosen@yahoo.com> - 2026-08-13 00:24 +0300
                                    Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-12 16:49 -0500
                                      Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-13 08:38 +0200
                                        Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-13 18:59 -0500
                                          Re: why is there not a ipow version of pow? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-13 18:51 -0700
                                            Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-14 00:58 -0500
                                              Re: why is there not a ipow version of pow? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-14 12:08 -0700
                                                Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-14 15:48 -0500
                                                  Re: why is there not a ipow version of pow? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-14 13:51 -0700
                                                    Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-14 16:40 -0500
                                                      Re: why is there not a ipow version of pow? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-14 19:24 -0700
                                                        Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-14 22:51 -0500
                                                          Re: why is there not a ipow version of pow? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-14 22:33 -0700
                                                          Re: why is there not a ipow version of pow? Ross Finlayson <ross.a.finlayson@gmail.com> - 2026-08-15 10:40 -0700
                                                            Re: why is there not a ipow version of pow? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-15 11:41 -0700
                                                            Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-17 14:48 -0500
                                                      Re: why is there not a ipow version of pow? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-16 14:58 -0700
                                          Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-14 08:57 +0200
                                            Re: why is there not a ipow version of pow? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-14 12:46 -0700
                                  Re: why is there not a ipow version of pow? James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-08-13 12:59 -0400
                            Re: why is there not a ipow version of pow? antispam@fricas.org (Waldek Hebisch) - 2026-08-12 20:23 +0000
                      Re: why is there not a ipow version of pow? scott@slp53.sl.home (Scott Lurndal) - 2026-08-11 18:19 +0000
                        Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-11 20:21 +0200
                          Re: why is there not a ipow version of pow? scott@slp53.sl.home (Scott Lurndal) - 2026-08-11 21:10 +0000
                            Re: why is there not a ipow version of pow? Michael S <already5chosen@yahoo.com> - 2026-08-12 00:42 +0300
                            Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-12 06:41 +0200
                              Re: why is there not a ipow version of pow? scott@slp53.sl.home (Scott Lurndal) - 2026-08-12 14:19 +0000
                                Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-12 16:56 +0200
                                  Re: why is there not a ipow version of pow? scott@slp53.sl.home (Scott Lurndal) - 2026-08-12 15:32 +0000
                              Re: why is there not a ipow version of pow? Michael S <already5chosen@yahoo.com> - 2026-08-12 22:05 +0300
                                Re: why is there not a ipow version of pow? Paul <nospam@needed.invalid> - 2026-08-12 19:09 -0400
                      Re: why is there not a ipow version of pow? Michael S <already5chosen@yahoo.com> - 2026-08-11 21:58 +0300
                  Re: why is there not a ipow version of pow? Ross Finlayson <ross.a.finlayson@gmail.com> - 2026-08-11 21:44 -0700
                Re: why is there not a ipow version of pow? bart <bc@freeuk.com> - 2026-08-11 15:45 +0100
                  Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-11 16:56 +0200
                    Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-11 17:23 +0200
                      Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-11 17:24 +0200
                    Re: why is there not a ipow version of pow? bart <bc@freeuk.com> - 2026-08-11 16:23 +0100
                      Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-11 17:26 +0200
                      Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-11 17:54 +0200
                      Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-11 18:40 +0200
                        Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-12 08:49 +0200
                          Re: why is there not a ipow version of pow? Paul <nospam@needed.invalid> - 2026-08-12 09:11 -0400
                            Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-12 16:05 +0200
                              Re: why is there not a ipow version of pow? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-12 12:40 -0700
                                Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-13 15:46 +0200
                                  Re: why is there not a ipow version of pow? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-13 14:28 -0700
                      Re: why is there not a ipow version of pow? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-11 16:20 -0700
                    Re: why is there not a ipow version of pow? bart <bc@freeuk.com> - 2026-08-11 18:43 +0100
                      Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-11 19:56 +0200
                        Re: why is there not a ipow version of pow? bart <bc@freeuk.com> - 2026-08-11 20:41 +0100
                          Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-12 06:42 +0200
                          Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-12 10:23 +0200
                      Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-11 20:24 +0200
                        Re: why is there not a ipow version of pow? bart <bc@freeuk.com> - 2026-08-11 20:27 +0100
                          Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-12 06:45 +0200
                  Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-11 17:16 +0200
        Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-11 15:17 +0200
          Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-11 15:28 +0200
            Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-11 16:43 +0200
              Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-11 16:47 +0200
                Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-11 17:24 +0200
      Re: why is there not a ipow version of pow? Paul <nospam@needed.invalid> - 2026-08-11 09:36 -0400
        Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-11 16:42 -0500
    Re: why is there not a ipow version of pow? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-08-11 19:15 +0200
      Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-11 16:41 -0500
        Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-11 16:49 -0500
          Re: why is there not a ipow version of pow? bart <bc@freeuk.com> - 2026-08-11 23:28 +0100
            Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-11 17:51 -0500
        Re: why is there not a ipow version of pow? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-11 15:33 -0700
          Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-11 17:49 -0500
            Re: why is there not a ipow version of pow? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-11 16:19 -0700
              Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-12 00:32 -0500
                Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-12 14:08 +0200
                  Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-12 18:40 +0200
                    Re: why is there not a ipow version of pow? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-14 02:50 +0000
    Re: why is there not a ipow version of pow? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-12 04:26 +0000
      Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-12 01:37 -0500
        Re: why is there not a ipow version of pow? Paul <nospam@needed.invalid> - 2026-08-13 00:12 -0400
        Re: why is there not a ipow version of pow? Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-14 11:22 +0800
          Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-14 01:00 -0500
            Re: why is there not a ipow version of pow? Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-14 14:47 +0800
              Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-14 13:54 -0500
                Re: why is there not a ipow version of pow? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-16 22:49 +0000
                  Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-17 14:56 -0500
                    Re: why is there not a ipow version of pow? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-17 23:53 +0000
                      Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-17 19:59 -0500
                        Re: why is there not a ipow version of pow? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-18 02:47 +0000
                  Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-17 15:17 -0500
              Re: why is there not a ipow version of pow? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-14 12:03 -0700
                Re: why is there not a ipow version of pow? Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-15 03:51 +0800
                  Re: why is there not a ipow version of pow? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-14 12:52 -0700
                    Re: why is there not a ipow version of pow? Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-15 04:01 +0800
                      Re: why is there not a ipow version of pow? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-14 13:27 -0700
                        Re: why is there not a ipow version of pow? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-14 13:29 -0700
                          Re: why is there not a ipow version of pow? Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-15 04:49 +0800
                            Re: why is there not a ipow version of pow? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-14 20:32 -0700
      Re: why is there not a ipow version of pow? bart <bc@freeuk.com> - 2026-08-12 11:28 +0100
        Re: why is there not a ipow version of pow? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-12 23:52 +0000
    Re: why is there not a ipow version of pow? Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-13 17:19 +0800
      Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-13 19:07 -0500
        Re: why is there not a ipow version of pow? Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-14 10:58 +0800
          Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-14 01:14 -0500
        Re: why is there not a ipow version of pow? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-17 06:40 +0000
          Re: why is there not a ipow version of pow? Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-17 21:40 +0800
    Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-18 00:42 -0500
      Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-18 09:34 +0200
      Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-18 11:32 +0200

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

#124609 — why is there not a ipow version of pow?

Why is there not a ipow version of pow?

ipow would return an int instead of a double.  Or a long long int.

Thanks,
Lynn

[toc] | [next] | [standalone]

#124610

Am 11.08.2026 um 10:01 schrieb Lynn McGuire:

> Why is there not a ipow version of pow?
> ipow would return an int instead of a double.  Or a long long int.

Integer multiplies have nearly the same cost as floating point multi-
plies. pow() is done with binary exponentation. This means that you
need a lot of bit-checks an multiplies. This is nearly the same as
with floating point numbers which don't have fractions. So you can
stick with fp-values. The only difference is the reduced amount of
bits (24 vs. 32 or 53 vs. 64).
But I don't think that's there much usage for such a function.

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

#124611

On 11/08/2026 12:11, Bonita Montero wrote:
> Am 11.08.2026 um 10:01 schrieb Lynn McGuire:
> 
>> Why is there not a ipow version of pow?
>> ipow would return an int instead of a double.  Or a long long int.
> 
> Integer multiplies have nearly the same cost as floating point multi-
> plies.

Have you done any actual measurements?

My language has an "**" operator which is overloaded for ints and floats.

Doing a**b, which uses a special recursive routine for integers, is 5 
times as fast as for floats where it calls out to 'pow()' inside msvcrt 
C library.

(This was for a=4, b=3; it will likely vary for integers depending on b, 
but b is unlikely to be large, as the results would overflow anyway. 
However for 2**63 - I'm using 64 bits - the integer version was still 
twice as fast.)

With C, you are dependent on how well a compiler may optimise it. But an 
expression like c = pow(a, b), where a/b/c are all ints, still seemed to 
call pow() even using gcc-O3.

In fact it is slower than with floats since conversion between ints and 
floats is needed.

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

#124612

Am 11.08.2026 um 13:45 schrieb bart:

> Have you done any actual measurements?

https://agner.org/optimize/instruction_tables.ods

> In fact it is slower than with floats since conversion between ints and 
> floats is needed.

Your measurements are not correct for sure. Check the above document.
With my Zen4-CPU double * double is faster than i64 * i64.

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

#124613

I did run the numbers. I wasn't wrong but also not totally right.
The result of the difference between integer and fp-multiplies
is nearly zero:

#include <iostream>
#include <chrono>

using namespace std;
using namespace chrono;

volatile double dOne = 1.0;
volatile uint64_t dU64 = 1;

int main()
{
	auto tm = []( const char *what, auto fn )
	{
		time_point start = steady_clock::now();
		uint64_t n = fn();
		duration dur = steady_clock::now() - start;
		int64_t dur64 = dur.count();
		cout << what << (double)dur64 / (double)n << endl;
	};
	double d = ::dOne;
	tm( "fp: ", [&]
		{
			uint64_t r = 0;
			for( ; r < 1'000'000'000; d *= d, ++r );
			return r;
		} );
	uint64_t u = ::dU64;
	tm( "int: ", [&]
		{
			uint64_t r = 0;
			for( ; r < 1'000'000'000; u *= u, ++r );
			return r;
		} );
	return (int)d + (int)u;
}

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

#124615

On 11/08/2026 14:55, Bonita Montero wrote:
> I did run the numbers. I wasn't wrong but also not totally right.
> The result of the difference between integer and fp-multiplies
> is nearly zero:
> 

Even if that were true (and it is processor-dependent, so only true on 
some devices), it would be irrelevant to the OP's question.  Floating 
point "pow" does not work by repeated multiplication - both operands are 
floating point.

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

#124616

Am 11.08.2026 um 15:19 schrieb David Brown:

> On 11/08/2026 14:55, Bonita Montero wrote:

>> I did run the numbers. I wasn't wrong but also not totally right.
>> The result of the difference between integer and fp-multiplies
>> is nearly zero:

> Even if that were true (and it is processor-dependent, so only true on 
> some devices), it would be irrelevant to the OP's question.  Floating 
> point "pow" does not work by repeated multiplication - both operands
> are floating point.

The OP asked why there's no pow() with integers. I said the performance
must be almost the same as the overhead of a fp-multiplication is 
"near-ly the same" as with integers. Bart said that integer multiplies are
five times faster than fp-multiplies. I did run the numbers for a modern
machine and proved him wrong.

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

#124619

On 11/08/2026 15:27, Bonita Montero wrote:
> Am 11.08.2026 um 15:19 schrieb David Brown:
> 
>> On 11/08/2026 14:55, Bonita Montero wrote:
> 
>>> I did run the numbers. I wasn't wrong but also not totally right.
>>> The result of the difference between integer and fp-multiplies
>>> is nearly zero:
> 
>> Even if that were true (and it is processor-dependent, so only true on 
>> some devices), it would be irrelevant to the OP's question.  Floating 
>> point "pow" does not work by repeated multiplication - both operands
>> are floating point.
> 

I'll take this slowly and hope that you read this better than you read 
other posts.

> The OP asked why there's no pow() with integers.

Yes.

> I said the performance
> must be almost the same as the overhead of a fp-multiplication is "near- 
> ly the same" as with integers.

You did.  You failed to mention the vital fact that this applies to some 
processors and not others, but it is apparently correct for Zen 4 
processors at least.

It is, however, almost entirely irrelevant to the OP or to calculating 
"pow" in floating point or integer arithmetic.  Floating point "pow" 
does not use multiplication (assuming the target processor has dedicated 
instructions for logs and anti-logs).  It also has a more limited range 
of precise integer values compared to an integer power function, unless 
you are using at least 80-bit floating point types.

> Bart said that integer multiplies are
> five times faster than fp-multiplies. 

No, he did not.

He said that in his language (we don't know what overheads that has, or 
what other instructions are used) doing "a ** b" in integers, with the 
example values of "a = 4" and "b = 3", was five times as fast as calling 
the external MSVCRT floating point "pow" function.  That is a completely 
different thing, and the only thing surprising (to me) about what he 
wrote is that the difference is so small.

> I did run the numbers for a modern
> machine and proved him wrong.
> 

No, you did not - you merely demonstrated that you did not understand 
the OP's question and Bart's reply, or that for some reason you want to 
talk about something completely different and pretend that it is 
relevant.  No one has said you were wrong about the speed of 
multiplications on Zen 4, because it does not matter.

The fact that floating point multiply can, in some cases, be nearly as 
fast as integer multiply can be relevant to some code, and can come as a 
surprise to some people.  But it has no bearing to the OP and an integer 
power function.

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

#124620

Am 11.08.2026 um 16:08 schrieb David Brown:

> You did.  You failed to mention the vital fact that this applies to some 
> processors and not others, but it is apparently correct for Zen 4 
> processors at least.

Agner has taken this numbers on dozens of CPUs, and if you compare
fp- and integer-times you've mostly the same relationship.

> It is, however, almost entirely irrelevant to the OP or to calculating 
> "pow" in floating point or integer arithmetic.  Floating point "pow" 
> does not use multiplication (assuming the target processor has dedicated 
> instructions for logs and anti-logs).

Of course it doesn multiplications. It multiplies base by itself as
long there are exponent bits and if an exponent bit is set the currently
calulated value is multiplied by the base ^ (2 ^ n) value. For the frac-
tion bits the square root is inrementally done in the same way. That's
called binary exponentation.

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

#124625

On 11/08/2026 16:18, Bonita Montero wrote:
> Am 11.08.2026 um 16:08 schrieb David Brown:
> 
>> You did.  You failed to mention the vital fact that this applies to 
>> some processors and not others, but it is apparently correct for Zen 4 
>> processors at least.
> 
> Agner has taken this numbers on dozens of CPUs, and if you compare
> fp- and integer-times you've mostly the same relationship.

He has numbers for dozens of x86 processors.  There are many others that 
he has not covered.  (But he has done a truly amazing job with the x86 
world.)

> 
>> It is, however, almost entirely irrelevant to the OP or to calculating 
>> "pow" in floating point or integer arithmetic.  Floating point "pow" 
>> does not use multiplication (assuming the target processor has 
>> dedicated instructions for logs and anti-logs).
> 
> Of course it doesn multiplications. It multiplies base by itself as
> long there are exponent bits and if an exponent bit is set the currently
> calulated value is multiplied by the base ^ (2 ^ n) value. For the frac-
> tion bits the square root is inrementally done in the same way. That's
> called binary exponentation.
> 

"pow(a, b)" is implemented approximately as "exp(b * log(a))".  The 
calculations for "exp" and "log" will involve multiplications, of 
course, but not repeated multiplications of "a".  Since it does not use 
multiplication in the same way and for the same purpose as you have in 
an integer power function, the relationship between the speed of 
multiplication instructions for integers and floating point does not matter.

It is possible, I suppose, for a "pow" function to have a path that 
checks for "b" being a positive integer and then using an algorithm akin 
to the "ipow" for the calculation.  I don't see that being the case in 
my testing (with glibc), but it could give a fast path for small integer 
"b".  It would still have more overheads and be slower than the integer 
version, but much less less so.

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

#124627

Am 11.08.2026 um 17:11 schrieb David Brown:

> He has numbers for dozens of x86 processors.  There are many others that 
> he has not covered.  (But he has done a truly amazing job with the x86 
> world.)

Agner covers almost all x86-microarcitecures that have been seen so far.


> "pow(a, b)" is implemented approximately as "exp(b * log(a))".

Check the glibc sourcecode. Binary exponentation is the fastest way
to to that and the way with the least precision loss.

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

#124633

On 11/08/2026 17:20, Bonita Montero wrote:
> Am 11.08.2026 um 17:11 schrieb David Brown:
> 
>> He has numbers for dozens of x86 processors.  There are many others 
>> that he has not covered.  (But he has done a truly amazing job with 
>> the x86 world.)
> 
> Agner covers almost all x86-microarcitecures that have been seen so far.

Most processors in the world are /not/ x86.  On some devices, a floating 
point multiply will be perhaps 200 times slower than an integer 
multiply.  You may also find that on some devices with 32-bit GPRs and 
64-bit hardware floating point, floating point multiplication could be 
faster than 64-bit integer multiplication.  Anger covers the x86 world, 
not the entire processor world.

> 
> 
>> "pow(a, b)" is implemented approximately as "exp(b * log(a))".
> 
> Check the glibc sourcecode. Binary exponentation is the fastest way
> to to that and the way with the least precision loss.
> 

Let me try again.

"pow(a, b)" is implemented approximately as "exp(b * log(a))".

/Obviously/ the base used for the "exp" and "log" is base 2, since that 
is the most efficient base for calculating "exp" and "log" on a binary 
computer, especially with standard floating point formats.

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

#124634

Am 11.08.2026 um 17:32 schrieb David Brown:

> Most processors in the world are /not/ x86.

And do you think they've better multipliers because they've a
different architecture ? I don't.

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

#124637

On 11/08/2026 17:39, Bonita Montero wrote:
> Am 11.08.2026 um 17:32 schrieb David Brown:
> 
>> Most processors in the world are /not/ x86.
> 
> And do you think they've better multipliers because they've a
> different architecture ? I don't.
> 

I know that on many devices, integer multipliers are faster than 
floating point multipliers.  Most processors do not have any kind of 
hardware floating point - all floating point is done in software.  For 
those that have hardware floating point, a many take a few cycles to do 
the multiplication in hardware, because single-cycle floating point 
hardware takes a lot of die space and is far less useful than 
single-cycle integer multiply.

Once you have a die as large as for x86 processors, the cost of 
single-cycle floating point multipliers is not nearly as high.  But even 
then, many x86 processors have been designed where there are 
significantly more integer multiply units than floating point multiply 
units - giving significantly greater integer multiply throughput.

This is not difficult to understand.  Integer multiplications are needed 
more than floating point multiplications, and they are simpler and 
smaller to implement.

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

#124639

Am 11.08.2026 um 18:33 schrieb David Brown:

> I know that on many devices, integer multipliers are faster than 
> floating point multipliers.  Most processors do not have any kind
> of hardware floating point - all floating point is done in software.

Cood for comparisons between int- and fp-multipliers !!!

> Once you have a die as large as for x86 processors, the cost of single- 
> cycle floating point multipliers is not nearly as high.

With x86 there are no single cycle fp-multipliers and I'm pretty sure
that's not different on any comparable performant cores with other
architectures.

> But even then,  many x86 processors have been designed where there are
> significantly more integer multiply units than floating point multiply
> units - giving significantly greater integer multiply throughput.

Absolutely not because there's SIMD whose execution units could be used
scalar.

> This is not difficult to understand.  Integer multiplications are needed 
> more than floating point multiplications, and they are simpler and 
> smaller to implement.

But they're not faster on all current x86-architectures.

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

#124650

On Tue, 11 Aug 2026 18:33:11 +0200
David Brown <david.brown@hesbynett.no> wrote:

> On 11/08/2026 17:39, Bonita Montero wrote:
> > Am 11.08.2026 um 17:32 schrieb David Brown:
> >   
> >> Most processors in the world are /not/ x86.  
> > 
> > And do you think they've better multipliers because they've a
> > different architecture ? I don't.
> >   
> 
> I know that on many devices, integer multipliers are faster than 
> floating point multipliers.  Most processors do not have any kind of 
> hardware floating point - all floating point is done in software.
> For those that have hardware floating point, a many take a few cycles
> to do the multiplication in hardware, because single-cycle floating
> point hardware takes a lot of die space and is far less useful than 
> single-cycle integer multiply.
> 
> Once you have a die as large as for x86 processors, the cost of 
> single-cycle floating point multipliers is not nearly as high. 

If you talk latency, then the cost of single-cycle floating point
multiply, even single precision, on any "big" fast CPU, not just x86,
but all of them that still compete in high-perf single-thread game,
is not just high, it's practically unattainable without compromising
Holy Cycle Time.
Throughput is another matter. Here you can see rather huge numbers.
32 SP fmuls per cycle (2x512bit SIMD) are not uncommon.


> But
> even then, many x86 processors have been designed where there are 
> significantly more integer multiply units than floating point
> multiply units - giving significantly greater integer multiply
> throughput.
> 
> This is not difficult to understand.  Integer multiplications are
> needed more than floating point multiplications, and they are simpler
> and smaller to implement.
> 

Actually, x86-64 has integer multiplications up to 64b * 64 bit => 128
bit.
Such multiplier is significantly bigger than the one needed by DP FMUL
or even by DP FMA. Naturally, on majority of x86-64 implementations
such integer multiplication has the same or slower latency than DP
FMUL/FMA.

On aarch64 there is no 64x64=>128b, but there is 64-bit UMULH, which is
only 1/4th or so smaller. It also typically has the same or higher
latecy as DP FMUL. Apple is an exception to that (3 for UMULH, 4 for
FMUL).

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

#124635

On 2026-08-11 11:32, David Brown wrote:
> On 11/08/2026 17:20, Bonita Montero wrote:
>> Am 11.08.2026 um 17:11 schrieb David Brown:
...>>> "pow(a, b)" is implemented approximately as "exp(b * log(a))".
>>
>> Check the glibc sourcecode. Binary exponentation is the fastest way
>> to to that and the way with the least precision loss.
>>
> 
> Let me try again.
> 
> "pow(a, b)" is implemented approximately as "exp(b * log(a))".
> 
> /Obviously/ the base used for the "exp" and "log" is base 2, since that 
> is the most efficient base for calculating "exp" and "log" on a binary 
> computer, especially with standard floating point formats.
I hope that exp() and log() use base e! The exp2() and log2() functions
are the ones that are supposed to use base 2.

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

#124638

On 11/08/2026 17:46, James Kuyper wrote:
> On 2026-08-11 11:32, David Brown wrote:
>> On 11/08/2026 17:20, Bonita Montero wrote:
>>> Am 11.08.2026 um 17:11 schrieb David Brown:
> ...>>> "pow(a, b)" is implemented approximately as "exp(b * log(a))".
>>>
>>> Check the glibc sourcecode. Binary exponentation is the fastest way
>>> to to that and the way with the least precision loss.
>>>
>>
>> Let me try again.
>>
>> "pow(a, b)" is implemented approximately as "exp(b * log(a))".
>>
>> /Obviously/ the base used for the "exp" and "log" is base 2, since that
>> is the most efficient base for calculating "exp" and "log" on a binary
>> computer, especially with standard floating point formats.
> I hope that exp() and log() use base e! The exp2() and log2() functions
> are the ones that are supposed to use base 2.

I know this is c.l.c. (and c.l.c++), but I was referring to generic 
logarithmic and anti-logarithmic functions rather than the C standard 
library functions.  For implementing a power function, any base will do. 
  (And the implementation is unlikely to use the standard exp2 and log2 
functions.)

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

#124660

In comp.lang.c David Brown <david.brown@hesbynett.no> wrote:
> On 11/08/2026 17:20, Bonita Montero wrote:
>> Am 11.08.2026 um 17:11 schrieb David Brown:
>> 
>>> He has numbers for dozens of x86 processors.  There are many others 
>>> that he has not covered.  (But he has done a truly amazing job with 
>>> the x86 world.)
>> 
>> Agner covers almost all x86-microarcitecures that have been seen so far.
> 
> Most processors in the world are /not/ x86.  On some devices, a floating 
> point multiply will be perhaps 200 times slower than an integer 
> multiply.  You may also find that on some devices with 32-bit GPRs and 
> 64-bit hardware floating point, floating point multiplication could be 
> faster than 64-bit integer multiplication.  Anger covers the x86 world, 
> not the entire processor world.
> 
>> 
>> 
>>> "pow(a, b)" is implemented approximately as "exp(b * log(a))".
>> 
>> Check the glibc sourcecode. Binary exponentation is the fastest way
>> to to that and the way with the least precision loss.
>> 
> 
> Let me try again.
> 
> "pow(a, b)" is implemented approximately as "exp(b * log(a))".

In floating point this formula is loosing accuracy for very large
'a'.  The is pressure on library authors to deliver high accuracy,
so there is nontrivial chance that library is using much more
complicated (and expensive) method to compute the resut.

> /Obviously/ the base used for the "exp" and "log" is base 2, since that 
> is the most efficient base for calculating "exp" and "log" on a binary 
> computer, especially with standard floating point formats.

This is rather unfortunate statement.  Logaritms are defined for
any base and "pow(a, b)" has alternative name as "exponential function
with base a".  Of course log above is natural log, that is base 'e'
and 'exp(x)' means "e to power a", so normaly wordy version would be
"exponential with base e".  To avoid loss of accuracy library
may write a as 2^k*m with m mot too far from 1 and then it may
use higher precision computation to handle 2^k part.  You can
view 'k' above as base 2 logarithm of 2^k.  But for m base 2
give only troubles and if you multiply k times b you typically
get something that is not an integer, so exponential in base 2
really boils down to multiplying by log(2) and normal exp.  In
other words, you are likely to use log(2) in computation (it may
be stored to desired accuracy), but you really are not using
exponential with base 2.

-- 
                              Waldek Hebisch

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

#124671

On 12/08/2026 00:53, Waldek Hebisch wrote:
> In comp.lang.c David Brown <david.brown@hesbynett.no> wrote:
>> On 11/08/2026 17:20, Bonita Montero wrote:
>>> Am 11.08.2026 um 17:11 schrieb David Brown:
>>>
>>>> He has numbers for dozens of x86 processors.  There are many others
>>>> that he has not covered.  (But he has done a truly amazing job with
>>>> the x86 world.)
>>>
>>> Agner covers almost all x86-microarcitecures that have been seen so far.
>>
>> Most processors in the world are /not/ x86.  On some devices, a floating
>> point multiply will be perhaps 200 times slower than an integer
>> multiply.  You may also find that on some devices with 32-bit GPRs and
>> 64-bit hardware floating point, floating point multiplication could be
>> faster than 64-bit integer multiplication.  Anger covers the x86 world,
>> not the entire processor world.
>>
>>>
>>>
>>>> "pow(a, b)" is implemented approximately as "exp(b * log(a))".
>>>
>>> Check the glibc sourcecode. Binary exponentation is the fastest way
>>> to to that and the way with the least precision loss.
>>>
>>
>> Let me try again.
>>
>> "pow(a, b)" is implemented approximately as "exp(b * log(a))".
> 
> In floating point this formula is loosing accuracy for very large
> 'a'.  The is pressure on library authors to deliver high accuracy,
> so there is nontrivial chance that library is using much more
> complicated (and expensive) method to compute the resut.

That's why I wrote "approximately".  I realise there are a lot of 
details involved to make the calculation of "pow" work accurately over a 
wide range of values.  My point was merely that calculation of powers 
with floating point is done with that mathematical formula at heart, 
which is entirely different from how an integer power function is 
usually calculated (by repeated multiplication).

> 
>> /Obviously/ the base used for the "exp" and "log" is base 2, since that
>> is the most efficient base for calculating "exp" and "log" on a binary
>> computer, especially with standard floating point formats.
> 
> This is rather unfortunate statement.  Logaritms are defined for
> any base and "pow(a, b)" has alternative name as "exponential function
> with base a".  Of course log above is natural log, that is base 'e'
> and 'exp(x)' means "e to power a", so normaly wordy version would be
> "exponential with base e".
No, "log" and "exp" as words alone do /not/ imply base "e" - or any 
other specific base.  Within some contexts, there may be an implication 
from common usage - and "context" may include "that's what we wrote at 
school or university in my country", "that's the name used in the 
standard library", "that's the buttons on my calculator", etc.  To be 
fair, these are the names for the functions in base "e" in the C 
standard library, and that is a reasonable context to use in these 
Usenet groups.  I should therefore have been a bit clearer that that was 
not what I meant.

I thought it was quite clear that I was referring to a general log and 
anti-log function pair, writing as mathematics and not as a C 
expression.  From the maths viewpoint, the base does not matter (at 
least for a sane base - a real number greater than 1), as long as it is 
consistent.

And I thought it is entirely obvious that when you are actually 
implementing a floating point power function on a binary computer using 
floating point formats specified in binary, it is most efficient to use 
base 2 for the log and anti-log.  If you had a floating point format 
that used base 10, you'd probably want to use base 10 for the log and 
anti-log.

This is all implementation detail, and not the focus of my post.

But again, given that "exp" and "log" are base "e" functions in the C 
standard library, I should have been clearer there.

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

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

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

csiph-web