JOSS paper: copy edits #153
Conversation
| @@ -60,7 +60,7 @@ such as data races and fatal use-after-free errors. | |||
|
|
|||
| Rust also allows compatibility with the C ABI, allowing for simple interoperability | |||
| with C, and most other languages by extension. Once a design has been properly fleshed out, | |||
| we plan to expose a C API, along with bindings to other languages (Currently planned are C, C++, Python and Julia bindings). | |||
| we plan to expose a C API, along with bindings to other languages (C, C++, Python and Julia bindings are currently planned). | |||
There was a problem hiding this comment.
My understanding is that there are some R and Python packages that are already using Faer, though I don't think there are comprehensive bindings.
There was a problem hiding this comment.
yeah, i think there's people using it but i haven't really been following their progress
|
One other optional comment about Rust is its |
|
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?
openjournals/joss-reviews#6099