OOP, faster data layouts, compilers

[bearophile]

Through Reddit I've found a set of wordy slides, "Design for Performance", on designing efficient games code:
http://www.scribd.com/doc/53483851/Design-for-Performance
http://www.reddit.com/r/programming/comments/guyb2/designing_code_for_performance/

The slide touch many small topics, like the need for prefetching, desing for cache-aware code, etc. One of the main topics is how to better lay data structures in memory for modern CPUs. It shows how object oriented style leads often to collections of little trees, for example  arrays of object references (or struct pointers) that refer to objects that contain other references to sub parts. Iterating on such data structures is not so efficient.

The slides also discuss a little the difference between creating an array of 2-item structs, or a struct that contains two arrays of single native values. If the code needs to scan just one of those two fields, then the struct that contains the two arrays is faster.

Similar topics were discussed better in "Pitfalls of Object Oriented Programming" (2009):
http://research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf

In my opinion if D2 has some success then one of its significant usages will be to write fast games, so the design/performance concerns expressed in those two sets of slides need to be important for D design.

D probably allows to lay data in memory as shown in those slides, but I'd like some help from the compiler too.  I don't think the compilers will be soon able to turn an immutable binary tree into an array, to speedup its repeated scanning, but maybe there are ways to express semantics in the code that will allow them future smarter compilers to perform some of those memory layout optimization, like transposing arrays. A possible idea is a @no_inbound_pointers that forbids taking the addess of the items, and allows the compiler to modify the data layout a little.

Bye,
bearophile