carray-jit 0.1.6 → 0.1.7

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: e052fd85b01164a6147a30ca655b8997ba7c87ac9c7ec8354d73447d1208b5ca
-  data.tar.gz: 2a6ebb524fb6afee5c871c0a45ed13ecf2f120f9ef0194e36f486ac3b015b378
+  metadata.gz: 27ac95a6f004e19365a64f30d0a6e87384b1e20878b9374d8faf5b2cb328070d
+  data.tar.gz: d9ce3b1c9e3ebe5bc6c06288c4480fc25b1d88f58be5af635653e3f72067a637
 SHA512:
-  metadata.gz: bd5017f5251ad7b9f4263bfc25091a938d3bccd7f18ef5d83a5a68b63f57e0df6c1ee4278ccd1b903a68cb77a5a156a47c98cbc4832edabbf144593778fed1b5
-  data.tar.gz: d8d2733f8a98376561ccb183895e1e963eff8a1caea636d066e88ce4852f167fb8755c6f1225beaf0c89aea51bf18dab4482bde0a079983ff507e9cd66769b2f
+  metadata.gz: 80b9d9cc62dc9d6042fc6a1aac00071e0a29084b00c060872ccc0f72777b15a583c8a052f85126e94922f1e1b5c7fefdbdad70d46f7ecf1d5b26140690bfe4bc
+  data.tar.gz: c2ca9876c7d8c1d23e63290e2273e2219004932d19d2ffcf2c118a482c29b50bdd0570c55f4ec687908a916e751a0a58212e312ded6c279f977da2dc62c54cba

data/CHANGELOG.md

@@ -37,6 +37,28 @@ 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

data/README.md

@@ -35,7 +35,7 @@ gem "carray-jit"
 Requires:
 
 - Ruby >= 3.2
-- CArray >= 3.0.5, < 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.5", "< 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.
 

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.5, < 3.1`, so 3.0.5 and 3.0.6 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/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 " \