OOP, faster data layouts, compilers

[Paulo Pinto]

Many thanks for the links, they provide very nice discussions.

Specially the link below, that you can follow from your first link,
http://c0de517e.blogspot.com/2011/04/2011-current-and-future-programming.html

But in what concerns game development, D2 might already be too late.

I know a bit of it, since a live a bit on that part of the universe.

Due to XNA(Windows and XBox 360), Mono/Unity, and now WP7, many game studios
have started to move their tooling into C#. And some of them are nowadays 
even using
it for the server side code.

Java used to have a foot there, specially due to the J2ME game development, 
with a small
push thanks to Android. Which decreased since Google made the NDK available.

If one day Microsoft really lets C# free, the same way AT&T  somehow did 
with C and C++, then C#
might actually be the next C++, at least in what game development is 
concerned.

And the dependency on a JIT environment is an implementation issue. The 
Bartok compiler in Singularity
compiles to native code, and Mono also provides a similar option.

So who knows?

--
Paulo



"bearophile" <bearophileHUGS at lycos.com> wrote in message 
news:ioqdhe$2030$1 at digitalmars.com...
> 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