Path: csiph.com!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch
Newsgroups: comp.lang.c++
Subject: Re: constexpr is really very smart!
Date: Wed, 18 Dec 2024 09:45:38 -0800
Organization: A noiseless patient Spider
Lines: 64
Message-ID: <867c7whol9.fsf@linuxsc.com>
References: <20241216112808.00003f74@yahoo.com> <86jzbyghdw.fsf@linuxsc.com> <20241218013342.0000518a@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Wed, 18 Dec 2024 18:45:45 +0100 (CET)
Injection-Info: dont-email.me; posting-host="bbceff83978fead1ac4b0629d6983104"; logging-data="2528629"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/gVCY9byyGyWKLOI+kc+b3Mj7bQ2MYeCA="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:BoTP1nJdc6APXjDDKGsw14vHrxg= sha1:YNLI1h0X6IC4s9b7VYBItwa/uZc=
Xref: csiph.com comp.lang.c++:121254
Michael S writes:
> On Tue, 17 Dec 2024 12:54:19 -0800
> Tim Rentsch wrote:
>
>> Michael S writes:
>>
[...]
>>> #include
>>> #include
>>> #include
>>>
>>> static long long fib(long n)
>>> {
>>> if (fib <= 0)
>>> return 0;
>>> long long f0 = 0, f1 = 1;
>>> for (long i = 1; i < n; ++i) {
>>> long long f2 = f0 + f1;
>>> f0 = f1;
>>> f1 = f2;
>>> }
>>> return f1;
>>> }
>>
>> Here is my second fastest fibonacci calculation code (for
>> relatively small inputs):
>>
>> typedef long unsigned long ULL;
>>
>> ULL
>> fibonacci( unsigned n ){
>> ULL b = n&1, a = b^1;
>>
>> if( n & 2 ) a += b, b += a;
>> if( n & 4 ) a += b, b += a, a += b, b += a;
>> if( n & 8 ){
>> ULL na = 13*a+21*b, nb = 21*a+34*b;
>> a = na, b = nb;
>> }
>>
>> n >>= 4;
>> while( n-- ){
>> ULL na = 610*a + 987*b, nb = 987*a + 1597*b;
>> a = na, b = nb;
>> }
>>
>> return b;
>> }
>
> From BigO perspective this code looks like it's still O(n) so no
> better than simple loop.
It is O(n) but it has a smaller constant.
> According to my measurement gear, in range 0 to 92 there are few
> points where it is faster than simple loop, but in majority of
> cases it is slower.
I'm at a loss to understand how this could happen. In my own
measurements, the code shown above runs faster than a simple loop in
all cases above n > 12, more than twice as fast when n > 17, more
than three times as fast when n > 42, and going up from there. What
might account for these radically different results?