4 ms·

I can't find any info about the memory bus of apple m1. Is it 8 channels 16 bit each? That's drastically different from AMDs 2 channels 64 bit each. It looks l

I can't find any info about the memory bus of apple m1. Is it 8 channels 16 bit each? That's drastically different from AMDs 2 channels 64 bit each. It looks like apple m1 is much less eager when caching memory rows. Maybe because it doesn't have l3 cache. Edit: This test utilizes the 8x16bit memory bus of apple m1 fully. It's mostly just fetching random locations from memory, which can all be parallelized by the cpu pipeline. It explains why the results are exactly 4x slower on my ryzen 3 with 2 memory channels. So the summary is that m1 is optimized for dynamic languages that tend to do a DDOS attack on RAM with a lot of random memory access, but it might take a performance hit with compiled languages and traditional HPC techniques that tend to process data in sequence like ECS.

skohan 6y ago
That's an interesting observation - as someone who's built a few ECS implementations, one of the things I've always taken for granted is that things like cache line size are more or less set in stone, given the ubiquity of x86, so it's interesting to consider that the rise of ARM might create additional complexities there. I'm a bit of two minds about this: on the one hand, for a long time I've wanted a language for writing allocators which is more explicit about memory, and offers good abstractions for low-level memory operations (maybe Zig is going in this direction). In some sense, it feels like the move towards programmers thinking less about memory management has been a bit of a dead-end, and what we really want is better tools for memory management. Fragmentation in terms of how processors handle memory goes against this goal in some ways. On the other hand, it's a bit of a "holy grail" to imagine a hardware stack which obviates the need for memory optimization, and really does treat loading from and storing to memory anywhere on the heap as the same. But I imagine that the interesting things which the M1 is doing with memory are helping a lot with the worst case performance, and maybe even average case performance, but they're probably not doing much for the best case.
Dylan16807 6y ago
That would make sense for LPDDR4 but it apparently claims to have a 128 byte cache line size and I'm not sure how to square that with 16 bit channel width.

skohan 6y ago

That's an interesting observation - as someone who's built a few ECS implementations, one of the things I've always taken for granted is that things like cache line size are more or less set in stone, given the ubiquity of x86, so it's interesting to consider that the rise of ARM might create additional complexities there. I'm a bit of two minds about this: on the one hand, for a long time I've wanted a language for writing allocators which is more explicit about memory, and offers good abstractions for low-level memory operations (maybe Zig is going in this direction). In some sense, it feels like the move towards programmers thinking less about memory management has been a bit of a dead-end, and what we really want is better tools for memory management. Fragmentation in terms of how processors handle memory goes against this goal in some ways. On the other hand, it's a bit of a "holy grail" to imagine a hardware stack which obviates the need for memory optimization, and really does treat loading from and storing to memory anywhere on the heap as the same. But I imagine that the interesting things which the M1 is doing with memory are helping a lot with the worst case performance, and maybe even average case performance, but they're probably not doing much for the best case.

Dylan16807 6y ago

That would make sense for LPDDR4 but it apparently claims to have a 128 byte cache line size and I'm not sure how to square that with 16 bit channel width.