Re: max string size

[<don...@is...>]

Bruno Haible writes:

 > You are aware that the string-specific limit is only minimally
 > smaller than the general array-dimension-limit?

I was not.
This seems problematic:
  [1]> (length (make-array (expt 2 26) ))
  Segmentation fault (core dumped)
I see now that happens also on intel:
  $ cat /proc/cpuinfo 
  processor           : 0
  vendor_id           : GenuineIntel
  cpu family          : 6
  model                 : 170
  model name            : Intel(R) Core(TM) Ultra 5 125U
  stepping              : 4
  microcode             : 0x1f

I can get up to 2^24 -1.

So what's array-total-size-limit supposed to mean?
I notice in hyperspec:
 The actual limit on the array total size imposed by the
 implementation might vary according the element type of the array; in
 this case, the value of array-total-size-limit will be the smallest
 of these possible limits.
But the current value seems to be 2^32.

 > Correct. Generally you should go with the default for the particular
 > platform. IIRC, there are even platforms where TYPECODES does not
 > work at all.
 > 
 > >  > The smaller of these limits is 2^22-1, that is, > 4 millions.
 > >  > This is a good compromise of space (and thus speed) for functionality.
 > > 
 > > What's the difference between ampere and intel that leads to this
 > > difference?

I now see that the limits look similar on the two platforms, though
I thought I used to get larger limits on intel than I see now...

Ok, this must be an older build:
  [1]> (length (make-array (1- (expt 2 24))))
  16777215
  [2]> (length (make-array (1- (expt 2 25))))
  33554431
  [3]> (length (make-array (1- (expt 2 26))))
  67108863
  [4]> (length (make-array (1- (expt 2 27))))
  Cannot map memory to address 0x334c65000 .
  [../src/spvw_mmap.d:347] errno = 12 (:ENOMEM): Cannot allocate memory.
  Trying to make room through a GC...
  *** - No more room for LISP objects
  Break 1 [5]> [6]> Bye.
  [2024-11-26 12:00:29 root@clouddb ~]
  $ cat /proc/cpuinfo 
  processor       : 0
  vendor_id       : GenuineIntel
  cpu family      : 6
  model           : 63
  model name      : Intel(R) Xeon(R) CPU E5-2676 v3 @ 2.40GHz
  stepping        : 2
  microcode       : 0x49
  cpu MHz         : 2399.904
  ...
*features* on that looks the same as the one above with
  model name            : Intel(R) Core(TM) Ultra 5 125U

So now I wonder what difference between these two intel models
(or maybe the OS/libraries) causes this difference in the array
size limits and how the errors are handled.

 > TYPECODES vs. not TYPECODES, I would guess?

Is there a way to call configure to get typecodes (or at least try)?