README improvement

[carstenbauer]

See #124.

I've tried to clarify the README and have updated/rerun the examples on Julia 1.9 on a linux machine with 8 threads.

The sections about threadlocal and disabling polyester threads have not gotten much attention (but benchmarks in the latter have been rerun as well).

(I think the package needs an overhaul but this is beyond this PR which just tries to communicate the status quo a bit better.)

[chriselrod]

Thanks, looks great!

[chriselrod]

Why no muladd?
Because Julia takes a strong stance against unexpectedly giving people better performance and accuracy, I'm pro-normalizing-muladd.

Zen CPUs probably don't muladd much faster than separate mul and add, because they have 2 adders and 2 multiply units that can also fma.
For the muladd version on Zen, the adders are idle, so throughput is the same w/ respect to the backend (but fewer instructions and uops with muladd is friendlier to the frontend).

[carstenbauer]

I'm not strongly opposed to using muladd, I just don't think it matters here. The purpose of this example is to demonstrate how to use @batch. Optimizing the axpy kernel itself is an orthogonal issue IMO and only a distraction.

[chriselrod]

That's fine. FWIW, even on my intel system, muladd wasn't faster. axpy isn't compute bound.

[chriselrod]

No automatic @inbounds as of StrideArraysCore.jl 0.5
but using --check-bounds=yes is good advice, anyway.
Especially because @batch adds @inbounds.

[carstenbauer]

Not sure I understand.

• Will arrays this be turned into PtrArray?
• Will slices still default to view?

I'll add a note about @batch automatically adding @inbounds.

(I have to say I'm not a fan of adding automatic @inbounds and defaulting to views inside of @batch. For me, the latter is about low-overhead threading. The former two are optimizations that a user can add themself if they want to. But it's your package.)

[chriselrod]

I think the package needs an overhaul but this is beyond this PR which just tries to communicate the status quo a bit better.

What do you have in mind?

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (f29a42e) 91.13% compared to head (7832539) 91.13%.

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #125   +/-   ##
=======================================
  Coverage   91.13%   91.13%           
=======================================
  Files           3        3           
  Lines         451      451           
=======================================
  Hits          411      411           
  Misses         40       40           

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

[carstenbauer]

What do you have in mind?

Apart from what I said above - I'd personally drop auto @inbounds and view behavior - threadlocal is a misnomer and very much broken. Also per is somewhat of a misnomer to me. Additionally, the disabling of polyester threads doesn't show the timing differences anymore that it used to which warrants a reconsideration of this section/feature. Statements about nesting should be generally revisited given that @threads defaults to :dynamic these days, which is nestable with ok-ish performance.

[chriselrod]

Thanks!

I don't really want to change PtrArray. I do not like copy-by-default, so even though it is now documented that slices of AbstractArrays are supposed to copy, maybe I'll make PtrArray no longer subtype AbstractArray.
We could drop the StrideArraysCore dependency and just make our own PtrArray type for being able to pass it to the tasks.