Let’s say I have a large int array and I want to work with elements aligned on certain boundaries (64 bytes, say).
First, I realize that GC moves things around, but I imagine that for a large enough array (2 billion elements, say) it would tend to lodge at one place in the major heap. This is based mostly on the naive idea that it would be a drag to keep moving it around. Is this reasonable?
Second, is there a good way to determine the alignment of the array? It seems it would work to lie to the compiler and temporarily reinterpret the array as an int, but I don’t like to create invalid values even for a short time. Maybe somebody can reassure me that this is (reasonably) OK to do.
If you’re using very large int arrays, you probably want to use Bigarrays. They’re written in C and are very performant, and aren’t scanned by the GC unlike regular arrays. You can also use Owl and apply all sorts of transformations to the data such as adding or multiplying by a number. These will be done using SIMD instructions where possible in Owl, making them even more efficient.
For my purposes, regular int arrays are faster than Bigarrays because the ints don’t have to be converted to/from the external representation on store/fetch. At least that’s what I saw the last time I did a comparison.
I’m writing code that specifically does no allocation (once it settles down to do its computation), so there are no GC scans. I watch the running code with perf top.
I want to see if “cache-aware” alignment will have any effect on the speed of the code. The large array is shared (read and written) across several domains. This is far from my area of expertise but I thought I would just try different alignments and see how the compute times change.
It’s only a hobby project, but it’s been enjoyable to learn about multicore OCaml.