[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Re: Bignum performance (was: Shrinking the C core)
From: |
Emanuel Berg |
Subject: |
Re: [PATCH] Re: Bignum performance (was: Shrinking the C core) |
Date: |
Mon, 14 Aug 2023 18:51:14 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
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
- Re: [PATCH] Re: Bignum performance (was: Shrinking the C core), (continued)
- 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), 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 <=
- 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
- Re: [PATCH] Re: Bignum performance, Po Lu, 2023/08/15
- Re: [PATCH] Re: Bignum performance, Emanuel Berg, 2023/08/15
- Re: [PATCH] Re: Bignum performance, tomas, 2023/08/15
- Re: [PATCH] Re: Bignum performance, Emanuel Berg, 2023/08/15
- Re: [PATCH] Re: Bignum performance, Po Lu, 2023/08/15
- Re: [PATCH] Re: Bignum performance, Emanuel Berg, 2023/08/15
- Re: [PATCH] Re: Bignum performance, Po Lu, 2023/08/15
- Re: [PATCH] Re: Bignum performance, tomas, 2023/08/16