Open jedbrown opened 1 week ago
One other optional comment about Rust is its noalias
by default, where C requires restrict
and C++
doesn't even have that (in the standard). This is often a substantial performance benefit in numerical code (especially when using AD), and it's hard to safely use restrict
to the same degree (also as evidenced by LLVM noalias
bugs being exposed by Rust nalgebra).
thanks a bunch!
the figures are from before nanogemm was a thing. there have been some good perf improvements since then
i think mentioning the sparse algorithms can't hurt
one thing about the noalias part is that faer can't really make use of it, because matrices are implemented as pointers. there are some places where i convert to slices before i do the math to get noalias annotations, but rustc currently doesn't propagate the annotations to llvm in some cases
Would you mind updating the figures for nanogemm?
Regarding noalias, I was thinking as much of the caller's code, though I also wouldn't say a missed optimization in rustc/LLVM negates the benefit of making it safe to maximize noalias in the programming model (though tangible performance impact may be waiting for that compiler improvement). This may well be too far in the weeds for the paper.
i don't know if i still have the benchmark code. i lost some data on my pc recently, but i'll check if i have a backup somewhere
nvm i put it on github
This mostly fixes some citing/bib (
[@label]
is special syntax). I introduced the "JIT" acronym at first use, though it could be reworded elsewhere.Is it worth mentioning libxsmm since your nano-gemm implementation is surprisingly competitive without JIT? I don't know how to square that with mediocre performance at very small sizes in the figures here.
Should the mention of sparse matrix support be updated to reflect that it exists (perhaps in immature form) while still being out of scope for this paper?
https://github.com/openjournals/joss-reviews/issues/6099