Re: Data oriented programming

There are a few differing points of view here.
Clearly, you can't super-optimize all code you write up front, because you
don't know that that's going to be the part that matters.

Clearly, *some* code will almost always matter -- the core of a CPU skinning
loop, say, or broad-phase collision detection. Will the performance of a
script interpreter matter? If 95% of the heavy lifting is done in the
rendering and simulation subsystems anyway, then probably not. (Not to
mention that you *should* be using Lua or Python or Mono or some other
already-debugged scripting facility :-)

You can't always know which will end up mattering, and you can't assume that
everything will matter, or you'll end up wasting a lot of expensive
programmer time. Thus, you take a good stab at guessing where it's worth it,
and move on. A CI performance tester (which I think is what this thread is
about?) is a good safety net for when you get it wrong.

Then there's the question of "bashing it into shape" as a phase of shipping.
If what you're shipping is a game, on physical (or near-physical) media,
then spending a few months to make it great, once you know that the design
of the game is solid, makes a lot of sense.
If what you're shipping is a platform or a service, you don't have that
opportunity.
I'm working at a place where we synthesize a very dynamic web site, a
semi-real-time game server back-end, and a end-user-installable 3D client
application. We ship 50 times a day. This allows us to react to changes in
the market and tune for customers with incredible speed! If we were to stop
and not ship anything new for six months, we'd probably be dead.
Thus, we take a guess at performance up front, and then let CI performance
tests, as well as measurements collected from actual customer installs, tell
us what areas we need to optimize.

Sincerely,

jw

--
Americans might object: there is no way we would sacrifice our living
standards for the benefit of people in the rest of the world. Nevertheless,
whether we get there willingly or not, we shall soon have lower consumption
rates, because our present rates are unsustainable.



On Wed, Oct 6, 2010 at 2:52 AM, Richard Fabian <[email protected]> wrote:

> I'm with Tony on this one: Too many times "just write it and we'll optimise
> it later" has come to bite.
>
> So many times it's been "just add a system to do this", and then three
> years later, we're not using it the way it was originally intended due to
> performance issues. For example, scripting languages that get too slow, get
> compiled to code, then get optimised further by doing trickery, then some
> random guy walks up and says, "so why not do this stuff in code anyway" and
> gets bashed for pointing out the painful but obvious.
>
> Don't trap yourself in thinking that something that seems easy to use, can
> ever be made fast enough to USE. If you wait until your performance slot
> (say one year before release), then you're in for an almighty headache as
> you have to do awful things like change the way in which you even approach
> certain problems. Take some visibility algorithms for example, how many
> different ones are there? Portals, PVS, octree, BSP, blah blah blah.....
> don't think they're all there because someone thought "ooh, i'lll try doing
> it this way." No, they did it because in different circumstances, different
> algorithms do better than others, either due to layout of your levels, or
> layout of the code using it, or simply the access patterns into the
> structure. For anyone who's actually done a complete conversion of visibilty
> system from one to another, changing data structures and access techniques
> throughout a codebase: I feel your pain.
>
> There are many different ways to lay out your data, some are performant,
> some are easy to manipulate... Not many are both.
>
> Apply natural selection: If you don't care about performance from day 1,
> then manipulability wins over performance. Thus ends the tale.
>
>
> On 6 October 2010 05:12, Tony Albrecht <[email protected]> wrote:
>
>> So you are recommending that you shouldn't think about the performance
>> impact of your code before you write it?
>>
>> I think you should. If you are working on code which is likely to have a
>> performance impact on a system, then you should think carefully about the
>> layout of data and code. Smart decisions at the start will save you a lot of
>> time in the long run. I've worked on systems that are incredibly difficult
>> to optimise due to uniformly slow code where a week spent fiddling around
>> during the design of the system would have saved months down the track.
>>
>> -Tony
>>
>>
>> On 6 October 2010 14:18, Gregory Junker <[email protected]> wrote:
>>
>>> >
>>> > I didn't mean to suggest that you shouldn't test performance during
>>> > testing, just that it shouldn't be your "first line of defense".
>>> > Obviously you can't fix problems before you notice them, but a lot of
>>> > these problems are entirely avoidable if you think things through early
>>> > enough.
>>>
>>> Which can easily lead to "analysis paralysis"...
>>>
>>> Greg
>>>
>>> _______________________________________________
>>> 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
>>
>>
>
>
> --
> fabs();
> Just because the world is full of people that think just like you, doesn't
> mean the other ones can't be right.
>
> _______________________________________________
> 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