juliaarrays / fixedsizearrays.jl Goto Github PK

Using --compile=min about halves the run time of the test suite, as far as I remember. -O0 is something else to consider.
Xref julia-actions/julia-runtest#47.

These compiler options shouldn't be used when testing a production build (because they inhibit optimization, constant-folding, introduce additional allocations which we test for, etc.) or a code-coverage-enabled build (because Julia code coverage is currently not compatible with these compiler options, xref JuliaLang/julia#37059), but I guess we could use -O0 --compile=min for most jobs to save CPU time.

I think the generic isassigned implementation from Base that we're currently subject to isn't good for performance. Probably it should be overloaded for FixedSizeArray.

Possibly we'd want to support GenericMemory instead of just Memory. We'd need to add some type parameters to FixedSizeArray. AFAIK the address space parameter would be helpful for support on some GPU architectures (AMD?). The atomic access parameter might also be useful for concurrency. 🤷

Didn't check if a significant performance improvement would be possible, however it crossed my mind that it might possibly make sense to implement the FixedSizeArray copying constructor via copy(::Memory). Right now it dispatches to the converting constructor for AbstractArray.

I think we could easily support Julia versions before v1.11 something like this: instead of defining struct FixedSizeArray directly at the top level, we could use @static if:

@static if VERSION < v"1.11-"
    struct FixedSizeArray{T,N} <: DenseArray{T,N}
        mem::Vector{T}
        size::NTuple{N,Int}
    end
    parent_type(::Type{<:FixedSizeArray{T}}) where {T} = Vector{T}
else
    struct FixedSizeArray{T,N} <: DenseArray{T,N}
        mem::Memory{T}
        size::NTuple{N,Int}
    end
    parent_type(::Type{<:FixedSizeArray{T}}) where {T} = Memory{T}
end

A downside is that this could complicate #33.

Given that Julia v1.11 seems to be getting released soon anyway, I'm not sure that it makes sense to do this, though.

JuliaLang/julia#54244

This should probably also add some other methods. In particular, similar would be nice (otherwise it falls back to Array), and convert would enable conversions.

1. Perhaps add a new struct StaticSizeArray which would have size as a type parameter instead of a field.

2. Perhaps parameterize FixedSizeArray by the element type of the size field. I'm not sure how likely this is to be useful, but I know that GPU programs tend to avoid 64-bit values, so perhaps this would be a desired next step after #52.

• Aqua
• CI
• Codecov

AFAIK specializing Base.dataids could improve performance, while specializing Base.mightalias could improve aliasing safety. There's also Base.unaliascopy. None of these are officially API, though...

Xref JuliaLang/julia#51753

Getting the warning: Incorrect type. Expected "array".

diff --git a/.github/workflows/UnitTests.yml b/.github/workflows/UnitTests.yml
index 3d3d222..34d9f1e 100644
--- a/.github/workflows/UnitTests.yml
+++ b/.github/workflows/UnitTests.yml
@@ -1,9 +1,10 @@
 name: Unit Tests
 
 on:
   push:
-    branches: "main"
+    branches:
+      - "main"
   pull_request:
   release:
 
 concurrency:

The Interfaces page in the Julia Manual has a section on Strided Arrays.

It documents three methods that are mandatory to implement:

• strides(A): it seems we don't need to implement it, as Base comes with an implementation for DenseArray
• Base.unsafe_convert(::Type{Ptr{T}}, A): as discovered by @giordano, we need this for matrix multiplication using BLAS to work, otherwise we get a crash. I'll make a PR now.
• Base.elsize(::Type{<:A}): not sure about this. It seems like implementing this is impossible for us, as the method for Array is implemented using an undocumented internal function, aligned_sizeof, living in reflection.jl. Furthermore, there's a comment suggesting elsize should (?) be deprecated above these methods.

There's also an optional method, not sure if we need this for performance: stride(A, i::Int)

Perhaps StaticallySizedArrays would be clearer than FixedSizeArrays? When I see "FixedSize" I expect a value fixed at run time, not a compile-time constant.

Probably premature optimisation at this point, but I was surprised to see simple broadcasting operations with FixedSizeArrays are slower than with regular Arrays:

julia> using BenchmarkTools, FixedSizeArrays

julia> @benchmark z .= v setup=(v = randn(Float64, 1024); z = similar(v))
BenchmarkTools.Trial: 10000 samples with 943 evaluations.
 Range (min … max):  100.919 ns … 155.223 ns  ┊ GC (min … max): 0.00% … 0.00%
 Time  (median):     101.670 ns               ┊ GC (median):    0.00%
 Time  (mean ± σ):   102.621 ns ±   2.658 ns  ┊ GC (mean ± σ):  0.00% ± 0.00%

  ▁███▆▆▃▂▂▅▄▃▂▂▂▃▂▁▁   ▁                                       ▂
  █████████████████████▇██▇▇▅▆▇▇▆▇▆▆▇▆▇▅▆▅▆▅▆▅▅▅▅▅▇▆▆▆▅▆▆▆▆▆▅▆▆ █
  101 ns        Histogram: log(frequency) by time        115 ns <

 Memory estimate: 0 bytes, allocs estimate: 0.

julia> @benchmark z .= v setup=(v = convert(FixedSizeVector, randn(Float64, 1024)); z = similar(v))
BenchmarkTools.Trial: 10000 samples with 198 evaluations.
 Range (min … max):  446.551 ns … 562.712 ns  ┊ GC (min … max): 0.00% … 0.00%
 Time  (median):     450.338 ns               ┊ GC (median):    0.00%
 Time  (mean ± σ):   453.306 ns ±   9.527 ns  ┊ GC (mean ± σ):  0.00% ± 0.00%

  ▂▂▄▇█▅▄▁▂▁▁▁       ▂▂                                         ▁
  ████████████▇▇▆▇▆▇███▇▇▆▇▇▇▇▇▇▇▆▆▅▆▆▆▆▅▅▆▇▇▆▆▅▄▄▄▄▃▅▄▄▄▅▆▅▆▅▆ █
  447 ns        Histogram: log(frequency) by time        501 ns <

 Memory estimate: 0 bytes, allocs estimate: 0.

Some operations should never allocate, test using @allocated.

Some operations should have perfect type inference, test using @inferred.

Regular Arrays can be conveniently constructed using comprehensions:

julia> [(i, j) for i=1:3, j=1:2]
3×2 Matrix{Tuple{Int64, Int64}}:
 (1, 1)  (1, 2)
 (2, 1)  (2, 2)
 (3, 1)  (3, 2)

The above is basically equivalent to constructing a generator and collecting it:

julia> collect((i, j) for i=1:3, j=1:2)
3×2 Matrix{Tuple{Int64, Int64}}:
 (1, 1)  (1, 2)
 (2, 1)  (2, 2)
 (3, 1)  (3, 2)

A proposal exists to have Array constructors behave equivalently to collect here: JuliaLang/julia#16029. We do need some nice way of constructing FixedSizeArrays, so maybe we could have a constructor method that takes a Base.Generator? Or at least a convert method.

This repo should have a description, for example:

Fixed-size multidimensional arrays. An Array-like type with less indirection at the cost of resizing capability.

Some Github topics would probably also be good, for example julia and arrays.

AFAIK JuliaHub records these when registering packages and uses it to improve JuliaHub search. Of course they should also help with Github search.

Switching the type to the linear indexing style, like here, would both:

• enable better efficiency for generic user code

• decrease the amount of code required in the implementation here

Am I misunderstanding something?