| ▲ | tialaramex 5 days ago | |
Yes, Rust absolutely might memcpy your Big when you move it somewhere. I will say that programmers very often have bad instincts for when that's a bad idea. If you have a mix of abilities and can ask, try it, who in your team thinks that'll perform worse for moving M = 64 or M = 32? Don't give them hours to think about it. I would not even be surprised to find real world experienced programmers whose instinct tells them even M = 4 is a bad idea despite the fact that if we analyse it we're copying a 4 byte value rather than copying the (potentially much bigger) pointer and taking an indirection Edited: To fix order of last comparison | ||
| ▲ | ninkendo 5 days ago | parent [-] | |
> I will say that programmers very often have bad instincts for when that's a bad idea True that. memcpy is basically the literal fastest thing your processor can do, it’s trivially pipelined and can be done asynchronously. If the alternative is heap storage you’re almost always cooked: that heap space is far less likely to be in L1 cache, allocating it takes time and requires walking a free list, dealing with memory fragmentation, freeing it when dropped, etc. It’s not a bad short-hand to think of the heap as being 10-100x slower than the stack. | ||