On May 25, 2023, at 1:34 PM, Wolfgang Corcoran-Mathe <xxxxxx@sigwinch.xyz>
wrote:
 >
 > This point deserves more discussion. Do we have to incur "impractical
 > overhead" to avoid mutation leaks?

Without addressing “impractical overhead" in general, I’d like to
mention some timings and space usage in the sample 64-bit Gambit
implementation of SRFI 231 on a MacBook Pro with M1 Max processor and
64GB of RAM.

We define two 5,000 x 5,000 arrays, the first an f64 specialized array,
the second a generalized array with the same getter as the first:

(define domain (make-interval '#(5000 5000)))

(define specialized
    (time
     (array-copy
      (make-array domain
                  (lambda (i j)
                    (fl- (fl* (random-real) 275.) 10.)))
      f64-storage-class)))

(define generalized
    (make-array domain
                (array-getter specialized)))

There is no time (or space) difference between simple array-copy and
array-copy! of the specialized array into another f64 array, which both
use memcpy:

(time (array-copy! specialized))
      0.033412 secs real time
      0.033172 secs cpu time (0.015888 user, 0.017284 system)
      no collections
      200000640 bytes allocated
      12209 minor faults
      no major faults
(time (array-copy specialized))
      0.031428 secs real time
      0.031265 secs cpu time (0.014084 user, 0.017181 system)
      no collections
      200000640 bytes allocated
      12209 minor faults
      no major faults

Copying the generalized version of the array into an f64 array takes
*much* longer, but the specific time penalty for using array-copy
instead of array-copy! is about 60%; the space penalty is 120%:

(time (array-copy! generalized f64-storage-class))
      0.520990 secs real time
      0.520128 secs cpu time (0.478557 user, 0.041571 system)
      no collections
      1000000576 bytes allocated
      37494 minor faults
      no major faults
(time (array-copy generalized f64-storage-class))
      0.839642 secs real time
      0.837973 secs cpu time (0.749068 user, 0.088905 system)
      2 collections accounting for 0.469323 secs real time (0.423792
user, 0.044610 system)
      2199999200 bytes allocated
      33701 minor faults
      no major faults

There’s no time (or space) difference when copying the specialized f64
array to an f16 array, with a somewhat complex conversion routine:

(time (array-copy! specialized f16-storage-class))
      0.762574 secs real time
      0.761298 secs cpu time (0.724044 user, 0.037254 system)
      no collections
      850000704 bytes allocated
      28338 minor faults
      no major faults
(time (array-copy specialized f16-storage-class))
      0.854443 secs real time
      0.852973 secs cpu time (0.726463 user, 0.126510 system)
      1 collection accounting for 0.095403 secs real time (0.001659
user, 0.093639 system)
      849999040 bytes allocated
      24279 minor faults
      no major faults

(There’s an extra accidental GC there for array-copy.)

With the generalized array, there’s about a 20% time penalty and 140%
space penalty when using array-copy instead of array-copy! into an f16
array:

(time (array-copy! generalized f16-storage-class))
      0.922248 secs real time
      0.920584 secs cpu time (0.913335 user, 0.007249 system)
      1 collection accounting for 0.000139 secs real time (0.000135
user, 0.000009 system)
      850000192 bytes allocated
      3052 minor faults
      no major faults
(time (array-copy generalized f16-storage-class))
      1.184263 secs real time
      1.181636 secs cpu time (1.101517 user, 0.080119 system)
      2 collections accounting for 0.414932 secs real time (0.376693
user, 0.037288 system)
      2050000480 bytes allocated
      52451 minor faults
      no major faults

When converting the specialized f64 array to a u8 array, there is about
an 80% time penalty and 10% space penalty when using array-copy instead
of array-copy!:

(time (array-copy! (array-map (lambda (x) (fxmax 0 (fxmin 255 (exact
(flround x))))) specialized) u8-storage-class))
      2.209744 secs real time
      2.204997 secs cpu time (2.033162 user, 0.171835 system)
      11 collections accounting for 0.088302 secs real time (0.007955
user, 0.080307 system)
      11503939536 bytes allocated
      79017 minor faults
      no major faults
(time (array-copy (array-map (lambda (x) (fxmax 0 (fxmin 255 (exact
(flround x))))) specialized) u8-storage-class))
      3.977813 secs real time
      3.968935 secs cpu time (3.842786 user, 0.126149 system)
      10 collections accounting for 1.832764 secs real time (1.810734
user, 0.017901 system)
      12703940128 bytes allocated
      80540 minor faults
      no major faults

Finally, when converting the u8 specialized array to an f32 array, the
time penalty when using array-copy instead of array-copy! is about 23%;
the space penalty is about 133%:

(time (array-copy! (array-map inexact u8array) f32-storage-class))
      0.654019 secs real time
      0.652803 secs cpu time (0.621477 user, 0.031326 system)
      no collections
      900000944 bytes allocated
      19144 minor faults
      no major faults
(time (array-copy (array-map inexact u8array) f32-storage-class))
      0.802877 secs real time
      0.801162 secs cpu time (0.710570 user, 0.090592 system)
      2 collections accounting for 0.305247 secs real time (0.242820
user, 0.061808 system)
      2100000400 bytes allocated
      21621 minor faults
      no major faults

The program is included below.

Brad