3 ms·

> then your matrix is allocated on the heap not the stack, meaning slower operations This doesn't seem right at all... Does anyone know more? Maybe they meant

> then your matrix is allocated on the heap not the stack, meaning slower operations This doesn't seem right at all... Does anyone know more? Maybe they meant slow to allocate / deallocate? The author's problem appears to require you to generate a lot of temporary data and then throw it away. They might benefit from just writing their own pool allocator, so they don't have to wait for heap allocates (assuming that's their problem).

cfallin 9y ago
Yeah, the only downside of heap storage is the alloc/dealloc cost -- once you have the memory, it's all just bytes in RAM, whether heap or stack. It's not even a clear tradeoff for large arrays, because using value types on the stack implies lots of copies -- when you have a large block of data you want to refer to it by reference. Also, stack size is finite and relatively small -- 2MB-ish default per thread on Linux, or is it 8MB? -- so placing large matrices there will work until it doesn't. Heap allocation has all of virtual memory at its disposal.
Jare 9y ago
I imagine the following problems affecting performance outside of the alloc/dealloc themselves: - Heap memory may not be reused as cleanly as stack memory, which means lower cache efficiency. Your suggestion of a pool allocator should take care of this. - Runtime code for bounds checking needs to take the array size from the object even if it's constant. I recall there were XXX_unsafe() versions of accessors, which should not do any bounds checking, but the code is going to look ugly. - Having to go through an indirection from the object to the memory buffer. Here you are at the optimizer's mercy. So to avoid overly complex / ugly / brittle code where you need high performance, you are pretty much forced to write your own matrix types from the ground up, which is one of the concerns of the OP. I don't believe this is a terribly bad thing, and if the existing crates for this are not great yet, it would seem to me that it's just not been a focus for the Rust community, not an insurmountable problem.

cfallin 9y ago

Yeah, the only downside of heap storage is the alloc/dealloc cost -- once you have the memory, it's all just bytes in RAM, whether heap or stack. It's not even a clear tradeoff for large arrays, because using value types on the stack implies lots of copies -- when you have a large block of data you want to refer to it by reference. Also, stack size is finite and relatively small -- 2MB-ish default per thread on Linux, or is it 8MB? -- so placing large matrices there will work until it doesn't. Heap allocation has all of virtual memory at its disposal.

Jare 9y ago

I imagine the following problems affecting performance outside of the alloc/dealloc themselves: - Heap memory may not be reused as cleanly as stack memory, which means lower cache efficiency. Your suggestion of a pool allocator should take care of this. - Runtime code for bounds checking needs to take the array size from the object even if it's constant. I recall there were XXX_unsafe() versions of accessors, which should not do any bounds checking, but the code is going to look ugly. - Having to go through an indirection from the object to the memory buffer. Here you are at the optimizer's mercy. So to avoid overly complex / ugly / brittle code where you need high performance, you are pretty much forced to write your own matrix types from the ground up, which is one of the concerns of the OP. I don't believe this is a terribly bad thing, and if the existing crates for this are not great yet, it would seem to me that it's just not been a focus for the Rust community, not an insurmountable problem.