performance increases

[mrke]

apply @inbounds and @simd and add type parameters to structs

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.13%. Comparing base (9d9d345) to head (c1a8d5d).

Additional details and impacted files

@@           Coverage Diff           @@
##             main      #17   +/-   ##
=======================================
  Coverage   93.13%   93.13%           
=======================================
  Files           5        5           
  Lines         685      685           
=======================================
  Hits          638      638           
  Misses         47       47           

☔ View full report in Codecov by Sentry.
📢 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.

[mrke]

Still a red bar in the flame graph I can't get rid of

[rafaqz]

I doubt this @simd changes the assembly, likely julia/llvm can just detect that SIMD is fine here anyway. Mostly we use @simd when we know it can simd but the compiler cant prove that its ok. You can get claude to check @code_native.

Probably @simd ivdep may give the compiler more freedom than it can detect but still only use when you know it generates better assembly.

Otherwise these macros are just noise

help?> @simd
  @simd

  Annotate a for loop to allow the compiler to take extra liberties to allow loop re-ordering

  │ Warning
  │
  │  This feature is experimental and could change or disappear in future versions of Julia.
  │  Incorrect use of the @simd macro may cause unexpected results.

  The object iterated over in a @simd for loop should be a one-dimensional range. By using @simd, you
  are asserting several properties of the loop:

    •  It is safe to execute iterations in arbitrary or overlapping order, with special
       consideration for reduction variables.
    •  Floating-point operations on reduction variables can be reordered or contracted, possibly
       causing different results than without @simd.

  In many cases, Julia is able to automatically vectorize inner for loops without the use of @simd.
  Using @simd gives the compiler a little extra leeway to make it possible in more situations. In either
  case, your inner loop should have the following properties to allow vectorization:

    •  The loop must be an innermost loop
    •  The loop body must be straight-line code. Therefore, @inbounds is currently needed for all
       array accesses. The compiler can sometimes turn short &&, ||, and ?: expressions into
       straight-line code if it is safe to evaluate all operands unconditionally. Consider using
       the ifelse function instead of ?: in the loop if it is safe to do so.
    •  Accesses must have a stride pattern and cannot be "gathers" (random-index reads) or
       "scatters" (random-index writes).
    •  The stride should be unit stride.

  │ Note
  │
  │  The @simd does not assert by default that the loop is completely free of loop-carried memory
  │  dependencies, which is an assumption that can easily be violated in generic code. If you are
  │  writing non-generic code, you can use @simd ivdep for ... end to also assert that:

    •  There exists no loop-carried memory dependencies
    •  No iteration ever waits on a previous iteration to make forward progress.

[rafaqz]

This is all great, but adding @simd usually doesn't do anything if julia/llv can detect that its ok anyway. Best to make sure it actually improves something or in future it will look like you really knew that was needed for some reason.