Re: Data oriented programming

On 9/30/2010 12:32 PM, Richard wrote:
>
> In article<D7F4D9E414140644BF099886C28C6636350A0B198D@bngexchange01.bungie.bng.local>,
>      Mat Noguchi<[email protected]>  writes:
>
>> Incidentally, Rico Mariani posted this earlier this week:
>>
>> http://blogs.msdn.com/b/ricom/archive/2010/09/27/less-loosely-coupled-than-me
> ets-the-eye.aspx
>
> This is why I've been recommending that performance tests be part of
> your CI build.  As soon as you have two components that each use 2/3
> of the L2 cache, you'll know from your performance tests.

Your cache usage patterns (usually) depend on architectural decisions, 
not implementation details. Any sort of integration testing (even if 
you're doing CI) is too late a stage to detect architectural problems. 
By that point you're already in trouble.

The whole point is that no development methodology will do the thinking 
for you. You simply *will not* get good results if you break your system 
down into little pieces and forget about the big picture. Details matter.

That's not arguing for Waterfall. Unexpected issues will bite you in 
unexpected ways, and you will have to iterate your design. But if you 
want high performance, you absolutely, positively have to start with a 
clear picture of the data flows you're going to have. "Module X and Y 
both use 2/3 of the L2 cache" is a completely useless value. How do they 
use it? What are they using it for? Cache usage isn't additive. If they 
both work on largely the same data, two modules that "use 2/3 of the L2 
cache" taken together might "use 3/4 of the L2 cache". Are they both one 
large loop going through a linear dataset, or are they randomly 
traversing linked data structures? Are they writing to large output 
buffers that don't get read for a while? (In which case you can use 
streaming stores/evictions to kick them out of the cache as soon as 
you're done). And so on.

None of that needs a detailed implementation to answer. But all of it 
needs a good idea of the layout (and size) of your data structures, and 
a knowledge of how they're used. "Module A magically transforms widgets 
to gadgets" isn't good enough. If you don't know enough about the 
behavior of your program to make reasonable back-of-the-envelope 
calculations about how much memory you're touching (and where), you 
don't know enough to make it run fast, period.

-Fabian
_______________________________________________
Sweng-Gamedev mailing list
[email protected]
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com