carray-jit 0.1.5 → 0.1.7

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: a4d8ccd59d268ba31816c5339867d7231b7051f7879d67faecdc4eb4d924b375
-  data.tar.gz: d73b3600e59633ac69986019597626b42a27e5e18b0143e00d39406d3f1c562f
+  metadata.gz: 27ac95a6f004e19365a64f30d0a6e87384b1e20878b9374d8faf5b2cb328070d
+  data.tar.gz: d9ce3b1c9e3ebe5bc6c06288c4480fc25b1d88f58be5af635653e3f72067a637
 SHA512:
-  metadata.gz: 96e9c9585b2e93ed1a2f655ee92e3ef446a11d35f95895acf08dda59ed841c7570e5bc0361995c303eda8aa81b3461068fb93f0495814b6a973309d8f0f18bb0
-  data.tar.gz: 4b6fd2250447527deca38a65b19555833cd5702e2f27a253aa9bcba7359e3862e3f3b95f921004911de2ff502422c522a37d3507efb5b69449d94a3b40f4ecad
+  metadata.gz: 80b9d9cc62dc9d6042fc6a1aac00071e0a29084b00c060872ccc0f72777b15a583c8a052f85126e94922f1e1b5c7fefdbdad70d46f7ecf1d5b26140690bfe4bc
+  data.tar.gz: c2ca9876c7d8c1d23e63290e2273e2219004932d19d2ffcf2c118a482c29b50bdd0570c55f4ec687908a916e751a0a58212e312ded6c279f977da2dc62c54cba

data/CHANGELOG.md

@@ -37,6 +37,57 @@ version you have and a newer one.
      a release needs is said in the gemspec, and an entry says so only
      when the answer changes. -->
 
+## 0.1.7
+
+- Change: needs CArray 3.0.6 or later in the 3.0 series; install it
+  alongside this release. An element-wise pass is handed to
+  `CArray::AddressBasis.sweep`, which 3.0.6 is the first to have.
+
+- Change: the kernel cache keeps 2000 kernels per environment by
+  default, up from 512, which is about 60 MB on disk. A program that
+  compiled more than 512 rebuilt the ones evicted each time it ran. Set
+  `CARRAY_JIT_CACHE_LIMIT` for a different bound.
+
+- Change: `jit_for` and `jit_init` cost less per call when called again
+  with operands that agree in name, type and mask, and a kernel writing
+  an `int64` array is vectorised as a `float64` one is.
+
+- Fix: a lazy expression or `CArray.fuse` computed here keeps the sign of
+  a NaN as CArray does: `(a * -1).signbit` and a NaN fill of `shift`
+  gave other bits with the evaluator registered.
+
+- Fix: kernels built at once by several threads, or in Ractors, no
+  longer raise `Errno::ENOENT`.
+
+## 0.1.6
+
+- Change: needs CArray 3.0.5 or later in the 3.0 series; install it
+  alongside this release. A Float stored into an integer array in a block
+  is refused as CArray 3.0.5's own store refuses it, and under 3.0.4 the
+  block would raise where CArray's store does not.
+
+- Change: a Float stored into an integer array in a block, captured or
+  local, that the type has no integer for raises `RangeError`, or
+  `FloatDomainError` for a NaN or an infinity, as CArray 3.0.5's own
+  store does. Before, it stored whatever the machine's C conversion gave,
+  which differed between x86 and ARM. Round and clamp first where the
+  value may leave the range. A masked cell, and a `jit_function`'s return
+  value or pointer parameter, are not checked.
+
+- Fix: an int64 array handed to a C function declared to take
+  `long long *` compiles with gcc, as it did with clang; gcc 14 raised
+  CompilationError. An array of the wrong element type raises Unsupported,
+  naming the type the function takes, under gcc as under clang.
+
+- Fix: `finite?` on an integer cell in a block compiles with gcc; it
+  raised CompilationError there, while clang accepted it. It is true for
+  every integer, as in Ruby.
+
+- Fix: a lazy expression or `CArray.fuse` computed here now gives the
+  same bits as CArray's own walk where gcc is the compiler. On x86 with
+  `-march=native`, a multiply followed by an add could come out one
+  rounding off in the last bit. Builds with clang were not affected.
+
 ## 0.1.5
 
 - Change: needs CArray 3.0.4 or later in the 3.0 series; install it

data/README.md

@@ -8,7 +8,7 @@ The block is read with Prism, translated to C if it falls inside that subset, co
 
 ## Status
 
-0.1.5 is the current release, and it still moves: behaviour can change between releases.
+0.1.6 is the current release, and it still moves: behaviour can change between releases.
 
 ## Features
 
@@ -35,7 +35,7 @@ gem "carray-jit"
 Requires:
 
 - Ruby >= 3.2
-- CArray >= 3.0.4, < 3.1
+- CArray >= 3.0.6, < 3.1
 - A C compiler
 - Prism and Fiddle (both ship with Ruby; Fiddle is a bundled gem)
 

data/carray-jit.gemspec

@@ -33,7 +33,9 @@ Gem::Specification.new do |spec|
   spec.executables   = ["carray-jit"]
 
   # A kernel reaches CArray's C by address, so the ceiling is the next minor.
-  spec.add_dependency "carray", ">= 3.0.4", "< 3.1"
+  spec.add_dependency "carray", ">= 3.0.6", "< 3.1"
   # fiddle ships as a bundled gem; depend on it explicitly so Ruby 3.5+ resolves it.
-  spec.add_dependency "fiddle"
+  # 1.1.1, which Ruby 3.2 ships, is the first with TYPE_UCHAR and the other
+  # unsigned types.
+  spec.add_dependency "fiddle", ">= 1.1.1"
 end

data/docs/02_KernelShapes.md

@@ -46,7 +46,7 @@ It is the same shape of block `CArray.jit_function` takes, and not the same thin
 
 #### Who drives the loop
 
-An element-wise pass is the one shape that is a *sweep* -- nothing reaches a neighbour, nothing chooses an order -- so CArray can drive it instead. Where this CArray has `ca_call_cslab` (3.0.1 and later), `jit_each` hands it the compiled body and lets it acquire the operands.
+An element-wise pass is the one shape that is a *sweep* -- nothing reaches a neighbour, nothing chooses an order -- so CArray can drive it instead: `jit_each` hands its chunked sweep (`ca_call_cslab`) the compiled body and lets it acquire the operands.
 
 The body is the same either way. The sweep entry point is a wrapper that calls the same kernel with the chunk as its bounds, so what changes is who opens the arrays, not what they compute.
 
@@ -56,7 +56,7 @@ A **strided view** is the case where there is. A column, a transpose, every othe
 
 The rank does not stand in the way, and the arrays are not reshaped to get it out of the way. CArray's acquire reads an operand's element count and element size and never looks at its shape, so a chunk is already a flat run of cells; what has to be flat is the *kernel*, and it is compiled at rank one over the same cells rather than as a nest over the axes. One such kernel then serves whatever rank it is given, because the rank has left the loop.
 
-Four things keep the driver here. An operand that is a **strided view**, for the reason just measured: it is walked in place here, and re-gathered there for nothing. A **stretched operand**, which is the one thing that cannot be flattened: broadcasting arrives as a stride of zero on an axis, and a flat run has no axes, so cell k of the output would stop lining up with cell k of the operand. A body that **asks about a mask**, because a chunk carries no per-cell mask to ask it of -- CArray ORs and propagates the masks, but `a[i] == UNDEF` is a question about one cell. A CArray **without the family** at all, which is asked for by symbol rather than assumed, so an older one falls back without the caller hearing about it.
+Four things keep the driver here. An operand that is a **strided view**, for the reason just measured: it is walked in place here, and re-gathered there for nothing. A **stretched operand**, which is the one thing that cannot be flattened: broadcasting arrives as a stride of zero on an axis, and a flat run has no axes, so cell k of the output would stop lining up with cell k of the operand. A body that **asks about a mask**, because a chunk carries no per-cell mask to ask it of -- CArray ORs and propagates the masks, but `a[i] == UNDEF` is a question about one cell. And **more than seven operands**, because seven is the widest the sweep family is generated for.
 
 Whichever drives it, an operand that is **read while the pass writes the array it is a view of** is copied once before the loop. `a = b * 2.0` reads the whole right-hand side and then assigns; a kernel walks cell by cell, which is the same thing until a cell it reads is one it has written -- `hi = lo * 2.0` over two blocks that share six cells, a transpose written over itself. The copy is what makes those read the values the expression started with, as CArray's own operators do, and it is what lets the chunked sweep take them: what it re-gathers per chunk is then a copy nothing is writing to. Sharing a root is the test rather than overlapping cells, a view knowing what it is a view of; `a = a + 1.0` is not that case, the cell read being the cell written.
 

data/docs/03_SupportedFeatures.md

@@ -854,7 +854,7 @@ A window may be opened inside a window, and `#call` may be made inside one: both
 
 One flag per compiled object and one per thread, so two functions never share a window and neither do two threads. The second half matters more than it sounds: the object is shared whether or not anybody meant to share it, because two blocks with the same text compile to one function. So a program that never mentions threads can open two windows on one body, and one flag between them is a window neither of them can read -- the second to open puts down what the first had already recorded. The flag and the hook are `_Thread_local`, which costs about half a nanosecond a call, and only on a body that has a flag at all.
 
-The thread is the native one, which for Ruby is the thread that opened the window -- except under the M:N scheduler (a non-main Ractor's threads, or `RUBY_MN_THREADS=1`), where a Ruby thread is not tied to one native thread and the window cannot be relied on to be the same copy throughout.
+The thread is the native one, which for Ruby is the thread that opened the window -- except under the M:N scheduler, where a Ruby thread is not tied to one native thread and the window cannot be relied on to be the same copy throughout. Which threads that is depends on `RUBY_MN_THREADS`: unset or `0`, a non-main Ractor's threads; `1`, the main Ractor's threads other than the main thread as well; and from Ruby 4.1, `2`, the main thread too, so that no thread is outside it. `-1`, also from Ruby 4.1, takes every thread out of it.
 
 What this leaves outside the window is a library that calls the body from threads of its own. The flag such a call raises belongs to the thread that raised it: the body stops answering there, as it should, and the window watching from Ruby sees nothing and raises nothing. A library that calls back on the thread it was called from -- which is what GSL and NLopt do -- is inside the window.
 
@@ -1223,6 +1223,6 @@ Everything else: `for` and `until`, `begin ... end while`, strings, hashes, symb
 - **A local array's subscript counts from the start.** CArray's `w[-1]` is the last cell; a kernel has no such reading, so a literal negative subscript is refused by name and one the kernel works out raises `IndexError`. This is the difference the captured arrays already have. Write `w[n - 1]`.
 - **`CArray.empty` leaves its cells as the stack left them.** Reading one before writing it is out of contract, the way reading under a mask is: the value is whatever was there. What it saves is the clearing, which for a 256-cell array inside a per-cell loop is 2 KiB a cell.
 - **The stack limits are per function, and a chain of them is not counted.** One local array up to 4 KiB stands in a frame, and the arrays of one kernel body or one function body up to 16 KiB together; past either, a kernel allocates the array at its entry, while a function body -- which is called once per cell -- refuses it and asks the calling kernel for a pointer instead. A pasted function called from a kernel is a second frame, and a chain of three such functions can therefore stand 48 KiB deep while each of them is inside its own limit -- counting along the chain was considered and dropped, since the depth is not knowable where recursion is in the subset at all. What that costs is the bargain a deep recursion already takes: too deep is a SIGSEGV rather than a `SystemStackError`, and a body carrying arrays reaches it sooner. Both numbers are provisional, and neither counts a future thread pool's stacks.
-- **Storing a real number into an integer array is C's conversion.** A value past the type's range, or a NaN, is undefined behaviour rather than a number -- and the same is true of a captured integer array, so a kernel brings no new hazard here. Round and clamp before storing where the value may leave the range. The rounding methods are not this case: `floor`, `ceil`, `round`, `truncate` and `to_i` on a Float raise `FloatDomainError` for a NaN or an infinity, as Ruby does, and `RangeError` where the Integer is past int64 -- except written straight into a float cell, which holds it whole (`1e20.floor` is `1e20`). The check costs a comparison per call, and in a loop that does little else it shows.
+- **Storing a real number into an integer array is checked.** It keeps the integer part, as CArray's own store does, and a value past the type's range raises `RangeError` -- `FloatDomainError` for a NaN or an infinity -- where CArray's store raises the same; C leaves that conversion undefined, and x86 and ARM answer it differently. Like any error at a cell it is raised when the pass ends, and the cell holds 0 in the meantime. A masked cell is not checked. The check is a comparison per store; round and clamp before storing where the value may leave the range and the cost shows. A compiled function's return value and a write through its pointer parameter are not this case: they are C's conversion, as the declaration says. Nor are the rounding methods: `floor`, `ceil`, `round`, `truncate` and `to_i` on a Float raise `FloatDomainError` for a NaN or an infinity, as Ruby does, and `RangeError` where the Integer is past int64 -- except written straight into a float cell, which holds it whole (`1e20.floor` is `1e20`). The check costs a comparison per call, and in a loop that does little else it shows.
 - **A block's source must be recoverable.** Blocks defined in `eval` or in a console have no file to read back; set `RubyVM.keep_script_lines = true` before defining them, or hand the text to `CArray::JIT.compile`, which takes a kernel as a string rather than as a block. This also ties the gem to CRuby, which CArray requires anyway.
 - **Nothing existing is replaced.** `jit_for` is a new method, not a faster `each_index`: the two differ in what they reject, and a caller should be able to choose.

data/docs/04_Compiling.md

@@ -67,7 +67,7 @@ In `~/.cache/carray-jit` (honouring `XDG_CACHE_HOME`), one directory per version
 
 A kernel is only good for the version that generated it and the architecture it was built for, so those get their own directories. CArray's version is there for the same reason and one of its own: a kernel is handed CArray's memory, on layouts CArray decides, so one compiled against one version and run against the next would answer wrongly rather than fail to load.
 
-The two numbers say different things and move on their own clocks: the first is the version that generated the kernel, the second the version it was generated against. This gem is not versioned with CArray, and one release of it meets more than one -- the dependency is `>= 3.0.4, < 3.1`, so 3.0.4 and 3.0.5 both satisfy it -- and a layout the kernel reaches into can move between them. A new release does not spend its cache budget on entries nothing can reach any more, and a home directory shared between machines -- over NFS, or between Rosetta and native -- does not have one architecture evicting the other's kernels. A directory whose newest entry has not been touched in 30 days (`CARRAY_JIT_CACHE_MAX_AGE_DAYS`) is removed.
+The two numbers say different things and move on their own clocks: the first is the version that generated the kernel, the second the version it was generated against. This gem is not versioned with CArray, and one release of it meets more than one -- the dependency is `>= 3.0.6, < 3.1`, so 3.0.6 and 3.0.7 both satisfy it -- and a layout the kernel reaches into can move between them. A new release does not spend its cache budget on entries nothing can reach any more, and a home directory shared between machines -- over NFS, or between Rosetta and native -- does not have one architecture evicting the other's kernels. A directory whose newest entry has not been touched in 30 days (`CARRAY_JIT_CACHE_MAX_AGE_DAYS`) is removed.
 
 ```ruby
 CArray::JIT.cache_root                 #=> "/home/you/.cache/carray-jit"
@@ -99,7 +99,7 @@ The path is expanded where it is given, so a relative one does not move when the
 
 `CARRAY_JIT_CACHE` and `CARRAY_JIT_NO_CACHE` still come first, so whoever runs the program has the last word on where a cache may be written and whether there is one at all. `CArray::JIT.cache_root = nil` restores the default.
 
-The cache is **bounded**: past `CARRAY_JIT_CACHE_LIMIT` kernels per environment (512 by default, so about 9 MB) the least recently used are evicted, source and object together. Reuse updates an entry's timestamp, so what a program actually runs stays. This is the one place carray-jit deliberately parts with RubyInline, whose `~/.ruby_inline` has no eviction at all and grows for the life of the account.
+The cache is **bounded**: past `CARRAY_JIT_CACHE_LIMIT` kernels per environment (2000 by default, so about 60 MB) the least recently used are evicted, source and object together. Reuse updates an entry's timestamp, so what a program actually runs stays. This is the one place carray-jit deliberately parts with RubyInline, whose `~/.ruby_inline` has no eviction at all and grows for the life of the account.
 
 Removing a cached object never breaks a kernel already in use: unlinking a loaded shared object leaves its mapping intact.
 
@@ -143,7 +143,7 @@ carray_jit_contiguous (char **pointers, int64_t *strides, int64_t *bounds, ...)
   const int64_t legendre_s0 = strides[0];
   const double x = reals[0];
 
-  for (int64_t i = bounds[0]; i < bounds[1]; i++) {
+  for (int64_t i = bounds[0], i__limit = bounds[1]; i < i__limit; i++) {
     double w;
     double wy;
     w = x * ((double *)(p_legendre))[i - 1];
@@ -165,7 +165,7 @@ root         /home/you/.cache/carray-jit
 environment  0.1.0-carray3.0.1-arm64-darwin24
 kernels      3
 size         50.1 KB
-limit        512 kernels
+limit        2000 kernels
 
 other environments:
   0.0.9-carray3.0.1-arm64-darwin24  1.2 MB  last used 2026-01-01
@@ -217,7 +217,7 @@ carray_jit_contiguous (char **pointers, int64_t *strides, int64_t *bounds, ...)
 | `CARRAY_JIT_DUMP` | Print generated C to stderr before compiling |
 | `CARRAY_JIT_CACHE` | Cache directory (default `~/.cache/carray-jit`, or what `CArray::JIT.cache_root=` named), or `none` |
 | `CARRAY_JIT_NO_CACHE` | Keep the cache in a temporary directory, removed on exit |
-| `CARRAY_JIT_CACHE_LIMIT` | Kernels retained on disk, per environment (default 512) |
+| `CARRAY_JIT_CACHE_LIMIT` | Kernels retained on disk, per environment (default 2000) |
 | `CARRAY_JIT_CACHE_MAX_AGE_DAYS` | Days an unused environment's directory is kept (default 30) |
 | `CARRAY_JIT_CC` | C compiler (default `RbConfig::CONFIG["CC"]`) |
 | `CARRAY_JIT_REASSOCIATE` | `0` makes the serial accumulator the default for the process |

data/docs/08_LanguageReference.md

@@ -395,7 +395,7 @@ These are deliberate. Everything not listed here gives Ruby's answer, to the las
 - **A complex raised to a power** uses C's `cpow`, which can differ from Ruby in the last bit.
 - **A sine beside a cosine of the same argument** may be computed together by the C compiler, which can change the last bit.
 - **A reduction is reassociated** into partial sums unless `reassociate: false` is given, so its last bits can differ from adding in order.
-- **A real stored into an integer array** is C's conversion: past the type's range, or for a NaN, the result depends on the machine. Ruby would raise or grow.
+- **A real stored into an integer array** keeps its integer part, as CArray's store does, and one past the type's range raises `RangeError` where Ruby's `to_i` would grow. A NaN or an infinity raises `FloatDomainError`, as `to_i` does.
 
 **The language**
 
@@ -425,4 +425,4 @@ A block reads like Ruby run over one cell at a time, and it answers as that Ruby
 | `\|` and `&` of a masked boolean (`UNDEF \| true`) | Kleene: `true` | `\|\|` and `&&`: masked whenever an operand is |
 | a `uint64` compared with a negative `int64` | compares by value: `7 < -7` is false | compared as two `uint64`: `7 < -7` is true |
 
-Where they agree, the block keeps CArray's answer: integer `/` and `%` floor, a shift means what it means to `Integer`, `INT64_MIN / -1` is `INT64_MIN`, overflow wraps, an Integer meets a Float as two doubles, narrow types compute narrow, `Math` outside its domain is NaN, a real out of range stored into an integer cell is C's conversion, and a masked operand gives a masked result.
+Where they agree, the block keeps CArray's answer: integer `/` and `%` floor, a shift means what it means to `Integer`, `INT64_MIN / -1` is `INT64_MIN`, overflow wraps, an Integer meets a Float as two doubles, narrow types compute narrow, `Math` outside its domain is NaN, a real stored into an integer cell keeps its integer part and raises `RangeError` past the type's range (`FloatDomainError` for a NaN or an infinity), and a masked operand gives a masked result.

data/lib/carray/jit/analyzer.rb

@@ -1880,7 +1880,7 @@ class CArray
             "`#{name}` to; declare what it points at",
             argument.location)
         end
-        wanted = CDeclaration::DATA_TYPES.fetch(parameter.element.fiddle).to_s
+        wanted = CDeclaration::DATA_TYPES.fetch(parameter.element.abi).to_s
         unless storage == wanted
           raise Unsupported.new(
             "`#{c_function}` takes `#{parameter.text}` there, which is a " \