2 ms·
But things don’t fit into 64 bits all the time, and then you get tearing. This is observable and now you have to pay for “proper” synchronization. Also, apple’s
by kaba0 4y ago
But things don’t fit into 64 bits all the time, and then you get tearing. This is observable and now you have to pay for “proper” synchronization. Also, apple’s m1’s reason for speed is pretty much bigger cache, so I don’t think it’s a good choice to go down this road.
Most applications have plenty of objects all around that are rarely used and are perfectly fine with being managed by the GC as is, and a tiny performance critical core where you might have to care a tiny bit about what gets allocated. This segment can be optimized other ways as well, without hurting the maintainability, speed of progress etc of the rest of the codebase.
- bullen 4y ago64 bytes, 512 bits. Cachelines are 64 bytes on all modern hardware. They will probably never change this value ever. Everything fits into 64 bytes if you make the effort. And if it doesn't you have to use two Arrays of 64 byte Structures and pad the last. This is non negotiable and I'm completely baffled nobody has mentioned this yet. I call this law: Ao64bS (did I invent my first law?) :D
- kaba0 4y agoIt may be a language barrier thingy, but then we are talking about different things. Also, that is architecture dependent.
- bullen 4y agoNope on all modern CPUs (X86 and ARM) this is 64 bytes and has been since a looong time...
- astrange 4y agoCache lines are 128 bytes on M1. But since it’s AMP and not SMP, sharing work across cores doesn’t necessarily work how you expect it to.
- bullen 4y agoCan you ask the OS to give you a certain core type? 128 bytes is perfect 2 x 64! So even if the risk of cache invalidation goes up even if two cores are not writing to the exact same structure the alignment still works! Good job Apple!
- fisf 4y agoThere absolutely are modern systems that have e.g. 128 byte cache lines (M1).