Re: Data oriented programming

Basically create both systems I guess and benchmark, how
fun.

Or create one, and use it until it becomes a blocking problem, and then try
to benchmark the other to see if it will be any better.
No project has infinite time and resources, and pretending that they do is
directly hurtful to the success of the project.

If this is the biggest risk in your entire project, then creating both
systems and measuring them may make sense. If this is just a small risk, or
a perfectionist wanting to avoid wasting 5% of the CPU, then just implement
the simplest thing that could possibly work, write tests that prove that
it's functionally correct, and don't re-visit the code until BOTH conditions
are true:
1) You are not reaching your target frame rate on your target hardware
2) A profiler tells you that this system is the lowest hanging fruit for
performance

It's OK to plan up front, and even compare the two approaches. If you know
that obviously one of the factors will dominate, planning says that's what
you should implement for. If you think it'll be a toss-up, then just pick
the quickest one to implement, and go with that.

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 Sun, Oct 17, 2010 at 4:45 PM, OvermindDL1 <[email protected]> wrote:

> On Sun, Oct 17, 2010 at 9:36 AM, Jon Watte <[email protected]> wrote:
> > tl;dr:
> > Either, you walk the data in memory order, and switch on type, or you
> group
> > the data in type order, and do all types separately.
> > In the first case, you get branch mis-predictions, which can be
> expensive,
> > and you also get higher I-cache pressure and even D-cache pressure
> because
> > you have to keep a bunch of different "subsystems" (type handlers?) in
> > memory.
> > In the second case, you have to map xyz->object (and object->xyz) in some
> > way other than the three-dimensional array, such as a sparse array
> > implemented as a hash table. That will cause more cache misses when
> locating
> > the item for any particular element, but it will let you walk elements of
> > the same type using linear memory access, and have less I and D cache
> > pressure and better branch prediction.
> > Which one is faster depends on whether you do mostly "update all of type
> X"
> > or do mostly "find element by xyz" operations per frame. You'll simply
> have
> > to come up with realistic workloads and profile it both ways.
> > Sincerely,
>
> That is what I figured, problem is I am going to be doing a lot of
> operations all on single types within a large area, and also going to
> be getting everything in range to send to the client often as well as
> their view area changes and on how blocks can affect other nearby
> blocks...  Basically create both systems I guess and benchmark, how
> fun...
> _______________________________________________
> 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