3 ms·

rust is equivalent to C when using static allocation i sent a pr to fix it

• Aissen 3y ago
  Doesn't your PR monomorphize the function every time N is changed ? I realize it's simpler since it keeps the structure, simplifies allocation of arrays, and elides bound check. But it explodes generated code size and matrix size can't be changed at runtime, which doesn't really match C. Edit: I have tried making an iterator-based version to elide bound checks, but had to resort to unsafe, and it's barely 50% faster than the original rust version (not as fast as C): https://gist.github.com/anisse/6b580628206293ef242faa7db6219bca https://gist.github.com/anisse/6b580628206293ef242faa7db6219... Edit 2: updated, and my rust iterator version now ~equivalent to C with no unsafe. Edit 3: too late, the repo has been updated with an other iterator-based version that is just as fast.
  • spense 3y ago
    C, Nim and Zig all benefit from static allocation and it's available in rust, so seems fair? also, `const N` is used in rust's nqueen test, so figured it would be fine. someone posted an `.iter().zip()` solution which benchmarks only a little slower (+10ms) than static allocation: https://github.com/attractivechaos/plb2/pull/4#issuecomment-1875298577 https://github.com/attractivechaos/plb2/pull/4#issuecomment-...
    • Aissen 3y ago
      I only looked at the C version, and it didn't use a generic over the allocation size, although yes, technically it was fixed at compile time. I saw the update to the PR, but I still prefer my collect()-based version :-)