[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Re: Bignum performance (was: Shrinking the C core)
From: |
Gerd Möllmann |
Subject: |
Re: [PATCH] Re: Bignum performance (was: Shrinking the C core) |
Date: |
Mon, 14 Aug 2023 11:28:21 +0200 |
User-agent: |
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.14.0 |
On 14.08.23 10:09, Ihor Radchenko wrote:
Gerd Möllmann <gerd.moellmann@gmail.com> writes:
Hm, then maybe we can look at the disassembly of then benchmark in SBCL?
Not that in the end the compiler is so smart that it optimizes a lot
of stuff simply away because it can prove that the result of the
computations cannot possibly be observed?
Sorry, but I do not know how to do it. Not familiar with CL.
Ok. I used the code from https://dataswamp.org/~incal/cl/fib.cl/fib.cl.
And the first thing that stares at me in this function:
(defun fib (reps num)
(declare (optimize speed (safety 0) (debug 0)))
(let ((z 0))
(declare (type (unsigned-byte 53) reps num z))
(dotimes (r reps)
(let*((p1 1)
(p2 1))
(dotimes (i (- num 2))
(setf z (+ p1 p2)
p2 p1
p1 z))))
z))
is the declaration (unsigned-byte 53).
The declaration means we are lying to the compiler because Z gets bigger
than 53 bits eventually. And all bets are off because of the OPTIMIZE
declaration. The result is that everything is done in fixnums on 64-bit
machines.
; disassembly for FIB
; Size: 92 bytes. Origin: #x700530086C ; FIB
; 6C: 030080D2 MOVZ NL3, #0
; 70: 040080D2 MOVZ NL4, #0
; 74: 0E000014 B L3
; 78: L0: 410080D2 MOVZ NL1, #2
; 7C: E20301AA MOV NL2, NL1
; 80: EB030CAA MOV R1, R2
; 84: 651100D1 SUB NL5, R1, #4
; 88: 000080D2 MOVZ NL0, #0
; 8C: 05000014 B L2
; 90: L1: 2300028B ADD NL3, NL1, NL2
; 94: E20301AA MOV NL2, NL1
; 98: E10303AA MOV NL1, NL3
; 9C: 00080091 ADD NL0, NL0, #2
; A0: L2: 1F0005EB CMP NL0, NL5
; A4: 6BFFFF54 BLT L1
; A8: 84080091 ADD NL4, NL4, #2
; AC: L3: 9F000AEB CMP NL4, R0
; B0: 4BFEFF54 BLT L0
; B4: EA0303AA MOV R0, NL3
; B8: FB031AAA MOV CSP, CFP
; BC: 5A7B40A9 LDP CFP, LR, [CFP]
; C0: BF0300F1 CMP NULL, #0
; C4: C0035FD6 RET
Tada!
- Re: [PATCH] Re: Bignum performance (was: Shrinking the C core), Gerd Möllmann, 2023/08/14
- Re: [PATCH] Re: Bignum performance (was: Shrinking the C core), Gerd Möllmann, 2023/08/14
- Re: [PATCH] Re: Bignum performance (was: Shrinking the C core), Ihor Radchenko, 2023/08/14
- Re: [PATCH] Re: Bignum performance (was: Shrinking the C core), Gerd Möllmann, 2023/08/14
- Re: [PATCH] Re: Bignum performance (was: Shrinking the C core), Ihor Radchenko, 2023/08/14
- Re: [PATCH] Re: Bignum performance (was: Shrinking the C core),
Gerd Möllmann <=
- Re: [PATCH] Re: Bignum performance (was: Shrinking the C core), Ihor Radchenko, 2023/08/14
- Re: [PATCH] Re: Bignum performance (was: Shrinking the C core), Emanuel Berg, 2023/08/15
- Re: [PATCH] Re: Bignum performance (was: Shrinking the C core), Ihor Radchenko, 2023/08/15
- Re: [PATCH] Re: Bignum performance (was: Shrinking the C core), Emanuel Berg, 2023/08/15
- Re: [PATCH] Re: Bignum performance (was: Shrinking the C core), Emanuel Berg, 2023/08/15
- Re: [PATCH] Re: Bignum performance (was: Shrinking the C core), tomas, 2023/08/16
- Re: [PATCH] Re: Bignum performance (was: Shrinking the C core), Emanuel Berg, 2023/08/16
- Re: [PATCH] Re: Bignum performance (was: Shrinking the C core), Emanuel Berg, 2023/08/14
- Re: [PATCH] Re: Bignum performance (was: Shrinking the C core), Gerd Möllmann, 2023/08/15
- Re: [PATCH] Re: Bignum performance (was: Shrinking the C core), Emanuel Berg, 2023/08/15