Re: sparse components

I think really that it's the implementation of OOP that people have problems with when looking for performance. The very limited data definition, the seemingly pointless property accessors (in C++ the boilerplate makes this seem more of a problem) and the abstractions that don't fit the performance profile of modern processors (inheritance, virtual functions) really seem counter-productive. Then again, you often see large case statements etc as the presented alternative when really these have the same or worse performance characteristics in comparison to say, sorting by type. I don't agree with many who think these mechanisms aren't productive at all though, they're quite productive when elegance is more important than performance. 

The idea of externally abstracted state machines that talk to each other via a limited message interface (OOP) is a very good way of providing unbreakable contracts so people don't have to think of every implementation detail when using your code (in many ways, it doesn't go far enough). The shortcuts placed on top of that for re-use (inheritance, polymorphism) are great for certain cases where you have to do the same thing across heterogeneous data with similar facets. However the simplest implementation of these ideas becomes very constricting when you're looking for the best performance. To get the most performance with current OOP languages you may end up encapsulating more and more complex state machines with more complex operations on what is really quite homogeneous data, in which c
 ase you are giving up the benefit of higher level abstractions for performance. At this stage, it may seem like the encapsulation is not really worthwhile, because you
 have so much complexity underneath and so much exposed to escape the performance constraining encapsulation mechanism that you don't feel like you're gaining any benefit. However, this is when you most need the encapsulation around the complex system, to hide the implementation complexity from the rest of the world.

Really, what we need is better abstraction mechanisms at a language level (and I don't mean ala Haskell or F#) that provide for performance without giving up the invariants and power that type safe OOP gives. For example, if you could define classes that uses structure of array when you had a collection of like objects, the compiler could vectorize a lot of the operations and save a reasonable amount of time/code. Other mechanisms which would simplify execution by type across collections (replacing a a virtual function call per item with a single virtual function call across many items per type) would also be beneficial in reducing code cache thrashing and other performance taboos. These are all already things people do by hand today and when a lot of people are doing the same thing by han
 d it means there is a need for some mechanism to simplify or formalize it.  

I think Corrinne Yu put it best recently in her Channel 9 interview when she was contrasting C against other languages; C was successful vs a lot of higher level languages because it presented the most logical and clearest representation of what the computer (essentially a single state machine) was doing at a low level. Now these machines work best with data concurrency and local state the new systems language has to represent that reality. 

Cheers,
Conor


----- Original Message ----
From: JS Zirani <[email protected]>
To: [email protected]
Sent: Sat, 29 May, 2010 12:01:41 AM
Subject: Re: [Sweng-Gamedev] sparse components

It is a bit out of topic, but I think you should say "OOP has
pitfalls" instead of "OOP is bad". "OOP is bad" is really the wrong
message.




My 0,2 cents,
JS
_______________________________________________
Sweng-Gamedev mailing list
[email protected]
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com



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