From: Emanuel Berg <incal@dataswamp.org>
To: emacs-devel@gnu.org
Subject: Re: [PATCH] Re: Bignum performance (was: Shrinking the C core)
Date: Mon, 14 Aug 2023 18:51:14 +0200 [thread overview]
Message-ID: <87msyth8jh.fsf@dataswamp.org> (raw)
In-Reply-To: 2d419e12-9239-de3e-47d0-38815a00025f@gmail.com
Gerd Möllmann wrote:
>> 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
Yikes, how did that happen, some slip involving symbolic
links ...
Here it is:
https://dataswamp.org/~incal/cl/bench/fib.cl
And timing is done with this:
https://dataswamp.org/~incal/cl/bench/timing.cl
Note the ugly absolute path in fib.cl BTW, otherwise you get
the path not of the file but of SBCL or Slime, maybe. I think
one is supposed to use ASDF, but surely there must some easy
way to just load a file using a relative path to the
current file?
(load "~/public_html/cl/bench/timing.cl")
> 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.
A very impressive optimization indeed, and expressed in
a cryptic way.
> ; 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!
How do you see only fixnums are used?
Are we talking 1 word = 2 bytes = 16 bits here, s2c?
If so, the range of fixnums are -32 768 to 32 767 inclusive,
so those are hardly huge numbers.
--
underground experts united
https://dataswamp.org/~incal
next prev parent reply other threads:[~2023-08-14 16:51 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
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 [this message]
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87msyth8jh.fsf@dataswamp.org \
--to=incal@dataswamp.org \
--cc=emacs-devel@gnu.org \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).