In my segmented Prime Sieves, I use memory Array|Slices within each thread as reusable segment memory, in multiples of 64-bit chunks. I’ve noticed, very consistently from monitoring memory use by
htop, that I get much better performance at times after total system memory use exceeds a certain amount (over 8GB).
Upon researching this phenomena in different language forums, it seems this may be a case of the segment use memory not being set on 64-bit boundaries, and thus are not optimally addressed.
Thus my question is, when Array|Slices are created, are they automatically aligned on native memory size boundary addresses (for 64-bit cpus that would be for 64-bit memory multiples), and if not, is there a way to ensure doing that in Crystal when creating an Array|Slice?
Array | Slice itself is pointer-aligned, as all reference + value unions do. The buffers they allocate have implementation-defined alignment.
I take it then there’s no way to ensure|force the actually memory addresses be on 64-bit boundaries?
In practice this is limited by what libgc provides. It could be that for some allocation sizes, it will always be aligned by default for new allocations.
But it may also be that it in practice behave differently on different allocation patterns, but even then it may be different on different platforms. But in practice, someone would have to go dive into its documentation and/or code to figure out what actually happens, when. Armed with that knowledge, it could perhaps be possible to make freshly allocated Slices allocate in an aligned manner given a flag or so.
You can read here how Rust handles this.