It's bizarre how all these Lisps use different tagging regimes!
Note that Common Lisp 'integer-length' is the same as your 'l(n)' function.
"CCL" 1.9 (Clozure Common Lisp).
(integer-length most-positive-fixnum) => 60. I.e., 61-bit FIXNUM's.
"MKCL" 1.1.3 by Jean-Claude Beaudoin.
(integer-length most-positive-fixnum) => 61. I.e., 62-bit FIXNUM's.
"SBCL" Steel Bank Common Lisp 1.1.4.
(integer-length most-positive-fixnum) => 62. I.e., 63-bit FIXNUM's.
---
(integer-length (fact 19)) => 57
(integer-length (fact 20)) => 62
(integer-length (fact 21)) => 66
---
Some of these Lisps utilize the excellent Gnu 'GMP' multiple-precision integer library.
At 06:29 PM 3/24/2013, Daniel Lakeland wrote:
>On 03/24/2013 05:40 PM, Henry Baker wrote:
>>I've done some timings on SBCL v. GCL bignum routines; GCL is faster --
>>and not just because SBCL fixnums are only 30 bits v GCL's 32 bits.
>>
>>I don't know who the maintainers of SBCL are, but their bignums could
>>be made faster.
>>
>>Also, GCL's type info is terrible! GCL doesn't even realize that
>>BIT's are only 0's and 1's! E.g., (typep 3 'bit) => t !! (GCL 2.6.1).
>>
>>That may account for some of GCL's slowness == inability to know how
>>bit things are.
>>
>>BTW, which Common Lisps support ~ 64-bit fixnums & address spaces > 4 GBytes ?
>
>64 bit SBCL supports more than 4 GB, I know because back when 64 bit machines were rare, I had to buy one to complete some projects where I wanted to read the entire human genome into SBCL.
>
>I think their fixnums are a few bits less than 64 though, according to a little snooping I just did it's 62 bits:
>
>I don't have any problem with people working more on optimizing for 64 bits these days, and I kind of remember that 64 bit SBCL was faster than 32 bit for my purposes, possibly because the 64 bit word allowed them to have more leeway in tagging types and things, and possibly because AMD64 architecture has more registers and a more regular set of modern CPU facilities.