From: "Gerd Möllmann" <gerd.moellmann@gmail.com>
To: Ihor Radchenko <yantar92@posteo.net>
Cc: incal@dataswamp.org, emacs-devel <emacs-devel@gnu.org>
Subject: Re: [PATCH] Re: Bignum performance (was: Shrinking the C core)
Date: Mon, 14 Aug 2023 11:28:21 +0200 [thread overview]
Message-ID: <2d419e12-9239-de3e-47d0-38815a00025f@gmail.com> (raw)
In-Reply-To: <87o7jaqc31.fsf@localhost>
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!
next prev parent reply other threads:[~2023-08-14 9:28 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-14 6:28 [PATCH] Re: Bignum performance (was: Shrinking the C core) Gerd Möllmann
2023-08-14 6:56 ` Gerd Möllmann
2023-08-14 7:04 ` Ihor Radchenko
2023-08-14 7:35 ` Gerd Möllmann
2023-08-14 8:09 ` Ihor Radchenko
2023-08-14 9:28 ` Gerd Möllmann [this message]
2023-08-14 9:42 ` Ihor Radchenko
2023-08-15 14:03 ` Emanuel Berg
2023-08-15 15:01 ` Ihor Radchenko
2023-08-15 22:21 ` Emanuel Berg
2023-08-15 22:33 ` Emanuel Berg
2023-08-16 4:36 ` tomas
2023-08-16 5:23 ` Emanuel Berg
2023-08-14 16:51 ` Emanuel Berg
2023-08-15 4:58 ` Gerd Möllmann
2023-08-15 14:20 ` Emanuel Berg
2023-08-15 6:26 ` [PATCH] Re: Bignum performance Po Lu
2023-08-15 14:33 ` Emanuel Berg
2023-08-15 17:07 ` tomas
2023-08-15 22:46 ` Emanuel Berg
2023-08-16 1:31 ` Po Lu
2023-08-16 1:37 ` Emanuel Berg
2023-08-16 3:17 ` Po Lu
2023-08-16 4:44 ` tomas
2023-08-16 5:18 ` Gerd Möllmann
2023-08-16 5:35 ` Emanuel Berg
2023-08-18 7:14 ` Simon Leinen
2023-08-19 13:10 ` Emanuel Berg
2023-08-20 5:07 ` Ihor Radchenko
2023-08-20 6:20 ` Emanuel Berg
2023-08-28 5:32 ` Emanuel Berg
2023-09-03 0:48 ` Emanuel Berg
2023-09-03 8:50 ` Ihor Radchenko
2023-09-03 9:05 ` Emanuel Berg
2023-09-03 10:30 ` Elisp native-comp vs. SBCL for inclist-type-hints benchmark (was: [PATCH] Re: Bignum performance) Ihor Radchenko
2023-09-04 1:03 ` Emanuel Berg
2023-09-03 1:57 ` [PATCH] Re: Bignum performance Emanuel Berg
2023-09-04 4:13 ` Emanuel Berg
2023-08-16 5:41 ` Gerd Möllmann
2023-08-16 6:42 ` Po Lu
2023-08-16 8:05 ` Gerd Möllmann
-- strict thread matches above, loose matches on Subject: below --
2023-08-09 9:46 Shrinking the C core Eric S. Raymond
2023-08-09 12:34 ` Po Lu
2023-08-09 15:51 ` Eric S. Raymond
2023-08-09 23:56 ` Po Lu
2023-08-10 1:19 ` Eric S. Raymond
2023-08-10 7:44 ` Eli Zaretskii
2023-08-10 21:54 ` Emanuel Berg
2023-08-11 10:27 ` Bignum performance (was: Shrinking the C core) Ihor Radchenko
2023-08-11 12:10 ` Emanuel Berg
2023-08-11 12:32 ` Ihor Radchenko
2023-08-11 12:38 ` Emanuel Berg
2023-08-11 14:07 ` [PATCH] " Ihor Radchenko
2023-08-11 18:06 ` Emanuel Berg
2023-08-11 19:41 ` Ihor Radchenko
2023-08-11 19:50 ` Emanuel Berg
2023-08-12 8:24 ` Ihor Radchenko
2023-08-12 16:03 ` Emanuel Berg
2023-08-13 9:09 ` Ihor Radchenko
2023-08-13 9:49 ` Emanuel Berg
2023-08-13 10:21 ` Ihor Radchenko
2023-08-14 2:20 ` Emanuel Berg
2023-08-14 7:20 ` Ihor Radchenko
2023-08-11 22:46 ` Emanuel Berg
2023-08-12 8:30 ` Ihor Radchenko
2023-08-12 16:22 ` Emanuel Berg
2023-08-13 9:12 ` Ihor Radchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2d419e12-9239-de3e-47d0-38815a00025f@gmail.com \
--to=gerd.moellmann@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=incal@dataswamp.org \
--cc=yantar92@posteo.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.