> Can anyone explain how the advice generalizes? The factors constrained by the hardware can be generalized -- cacheability, memory bandwidth, etc. The rest is

> Can anyone explain how the advice generalizes? The factors constrained by the hardware can be generalized -- cacheability, memory bandwidth, etc. The rest is dependent on the performance characteristics of the runtime, especially the GC. While GC is inapplicable to languages with manually managed memory, allocator performance and fragmentation can still be problematic -- but this is usually much easier to tune. OCaml, which has a very well-designed generational GC, is designed for extremely high allocation rates in its minor heap, to the point where the hardware is the bottleneck -- although compaction of the major heap is still a concern sometimes. While a lot of the recent research into "mechanical sympathy" is fascinating, a lot of it seems driven by the problems brought by high-level languages such as Java. If you're at the point where L1/L2 hit rates are a concern, use a language with inherent control of the memory layout of data structures. The kind of engineering done by Azul, etc is really about making applications utilize the full capabilities of the hardware without being saddled by the underlying platform (eg, JVM).