[vchuravy]

This PR adds the public (not exported) type FixedSizeArrays.StaticSizeArray{T,N,D,Mem}: an N-dimensional array over a memory backend Mem<:DenseVector{T} whose dimensions are a tuple of type D of Ints and Static.jl StaticInts, e.g. (static(5), static(4), static(4), nelements). Any dimension can be static (a compile-time constant that takes no space in the array) or dynamic (set at runtime). The design follows StrideArraysCore.jl and JuliaGPU/GPUArrays.jl#814.

It also includes a fix for #200: fill!(::FixedSizeArray, x) loops directly over the memory backend, so that it elides the bounds checks and vectorizes on Julia v1.13+.

Motivation

In Trixi.jl the solution is stored as an array of size (nvariables, nnodes, ..., nelements). The number of variables and nodes is fixed by the equations and the polynomial degree, while the number of elements depends on the mesh and changes at runtime (e.g. with AMR). With static dimensions, the compiler folds the index computations into constants and can unroll the loops over the small dimensions. This matters in particular for:

• Polyester.jl @batch and LoopVectorization.jl: captured arrays are converted to PtrArrays through StaticArrayInterface.jl. With a plain FixedSizeArray all sizes become dynamic; with a StaticSizeArray, static_size and static_strides keep the static dimensions static.
• GPU kernels: the array stays isbits when its memory backend is, and the strides of the static dimensions are constants. (Have to revisit this for Add StaticDimsArray: GPU arrays with a mix of static and dynamic dimensions JuliaGPU/GPUArrays.jl#814, this here might be sufficient to get static type information down to kernels)

Design

• Fields: mem and dims. A StaticInt in dims takes no space, so e.g. a 3-D array with two static dimensions is the size of a FixedSizeVector.
• Constructors:
  • FixedSizeArrays.wrap(StaticSizeArray, mem, dims), where at most one dimension can be : and is computed from length(mem), e.g. to wrap a Vector again after resize!;
  • undef constructors, e.g. StaticSizeArray{T}(undef, dims); when the type gives the dimensions, the static ones can be passed as plain Ints, so similar(typeof(a), size) works;
  • StaticSizeArray(a::FixedSizeArray, dims), sharing the memory.
• Indexing: IndexLinear. The Cartesian linear index is a sum of strided terms, whose strides are constants as long as the dimensions before them are static. Unlike the Horner form, this lets loop-invariant terms be hoisted when dimensions are dynamic; with all leading dimensions static, both forms perform the same. size(a, d) is a compile-time constant for a static dimension.
• Arrays interface:
  • strided arrays interface (strides, elsize, unsafe_convert), copy, fill!, copyto!;
  • similar(a) and similar(a, T) return StaticSizeArrays, while similar(a, T, size) returns a FixedSizeArray, so that range indexing and reductions infer;
  • out-of-place broadcasting (also over views), reshape and vec return FixedSizeArrays.
• Shared code: the methods that only depend on the memory backend (linear indexing, iterate, fill!, copyto!, reshape, pointers, dataids) are shared with FixedSizeArray through an internal FixedOrStaticSizeArray union.
• Package extensions:
  • StaticArrayInterface.jl (new weak dependency): static_size, static_strides, known_size, known_strides. StaticArrayInterface.device of a FixedSizeArray or StaticSizeArray is forwarded to its memory backend, so that e.g. LoopVectorization.jl does not treat a GPU memory backend as a CPU pointer.
  • Adapt.jl: adapts the memory backend of a StaticSizeArray and wraps it again, for any memory backend.
  • MPI.jl: StaticSizeArrays can be used as communication buffers.
• Docs: a usage section, with a comparison to Array, FixedSizeArray, StaticArrays.jl, HybridArrays.jl and StrideArraysCore.jl, plus the reference and the CHANGELOG.

Open question: Static.jl as a hard dependency

Static.jl is a new hard dependency, but only StaticInt, dynamic and known are used. Loading it increases the load time of using FixedSizeArrays from about 10 ms to 48 ms and adds many invalidations, for every user. JuliaGPU/GPUArrays.jl#814 has the same open question. The alternatives are:

• moving StaticSizeArray into a package extension on Static.jl;
• defining a minimal StaticInt here and converting to and from Static.jl in an extension.

Testing

All tests pass on Julia v1.10 and v1.12, including Aqua.jl and the doctests. The new FileCheck tests check that indexing with static dimensions uses constant strides, that fill! vectorizes, and that in-place broadcasting is vectorized and free of bounds checks. They run only without --check-bounds=yes. Run that way, three existing heap-allocation FileCheck tests fail the same way on main.

---

This PR was written with major contributions from Claude Code (an AI assistant) and reviewed by me.

🤖 Generated with Claude Code

[vchuravy]

This might be too specific for FSA, and perhaps we can just introduce a abstract type FastDenseArray end to make it easier to support this forwarding work that is needed.

[codecov]

Codecov Report

❌ Patch coverage is 99.28058% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 95.41%. Comparing base (c15fd6e) to head (6d8a3d4).

Files with missing lines	Patch %	Lines
src/StaticSizeArray.jl	98.76%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #210      +/-   ##
==========================================
+ Coverage   93.50%   95.41%   +1.90%     
==========================================
  Files           6       10       +4     
  Lines         231      349     +118     
==========================================
+ Hits          216      333     +117     
- Misses         15       16       +1     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[giordano]

Other people expressed before the interest in having a static array which is backed by Memory and not tuple, so that you don't pay the penalty for large arrays (and smaller ones may still be allocated on the stack as the compiler gets better), so this is cool!

[giordano]

I'm happy about the feature, but the I'm a bit uncomfortable about the hard dependency on Static with its invalidations