[spense]

rust is equivalent to C when using static allocation

i sent a pr to fix it

[Aissen]

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/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]

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-...

[Aissen]

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 :-)