> very random and very small a major part of JVM, JS Engines and even memory allocators, pools and similar is to make this patters less random, more predictab

> very random and very small a major part of JVM, JS Engines and even memory allocators, pools and similar is to make this patters less random, more predictable and more local. For example a common optimization for lisp like languages it to layout a linked list in a continuous way in memory. Stuff like that is needed even if you have more memory bandwidth as sometimes even more important then memory bandwidth is cache locality, which is WAY harder to scale then adding more memory channels. And branch prediction a major performance factor for modern CPUs also benefits quite a lot from cache locality. Furthermore having more bandwidth also only helps if you can bring the bandwidth to each core as needed. But if you ad more memory bandwidth it still has a limit per memory region which can be an issue. So in practice nearly all applications benefit from more bandwidth but the degree they do benefit is limited outside of highly paralelizable use-cases (like some graphics and AI use-case). So for most typical consumer use cases it's not worth the additional (high) cost this would impose to various aspects (especially motherboards). And for pro-sumer/server CPUs _we do have more channels_! But always a balance between added cost and expected need for more bandwidth. > In fact this is why DDR5 AFIK the reason they DDR5 has a split channel is way more complicated then that