
Game Engine Containers – handle_map - mbradber
http://www.gamedev.net/page/resources/_/technical/general-programming/game-engine-containers-handle-map-r4495
======
webkike
I find it highly suspect when a data structure uses independently allocated
nodes tha contain actual pointers (as opposed to indirection ints). I know
people like to make the tree just be another node, but it's really really
important to allocate things together! I would deem it mandatory to allocate
every node in the same tree in the same vector.

~~~
hcs
Are you criticizing the separation of m_sparseIds and m_items in this article?
Could you give some more detail as to why you see this as a problem?

The only performance issue I see with having these separate is what the author
describes as Consideration #2: you have to do completely separate read for the
indirection which may incur an additional cache miss. But this is the cost of
keeping the dense set dense and the handles constant.

Is there another issue I'm overlooking? Maybe I misunderstand you, as this
structure does use int indexes (both for the free lists and to locate objects
in the other array), and I don't know what you mean by "I know people like to
make the tree just be another node"

~~~
webkike
Sorry I'm not going to look at specifics, but I'm not arguing with the
article; I'm agreeing with it.

~~~
hcs
Ah, sorry, I completely misunderstood.

~~~
webkike
Yeah, I think it's common to associate a hn comment with criticisms :) (in the
negative sense).

------
JohnLeTigre
You should use maps in game engines parsimoniously and when you do, use
integer keys like a hash or something. This should be evident for any game
programmer.

If you are at the point of inventing a more complex structure to compensate
for programmer mistakes and/or malpractice, I suspect you should fire or
reassign people instead of coding this.

But meh, I'm probably getting too old/grumpy... lol

~~~
adamrezich
STL containers aren't the most optimized things for game programming ever...
otherwise the EASTL[0] wouldn't be a thing.

[0]
[https://github.com/electronicarts/EASTL](https://github.com/electronicarts/EASTL)

~~~
JohnLeTigre
It's also very optimal not to use a map when you don't really need one, that's
my point.

I agree eastl is cool, I clearly remember smilling when it first came out.

------
gens
Inspired by "Pitfalls of Object Oriented Programming"[0], i did something
similar to this (in C). Idk how the cpu usage would be by doing it another
way, but this way processing thousands of matrices is no problem.

[0]
[http://harmful.cat-v.org/software/OO_programming/_pdf/Pitfal...](http://harmful.cat-v.org/software/OO_programming/_pdf/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf)

------
tylorr
Reminds me of this article [1] that appeared in game dev mag when that was
still circulating.

[1] [http://seanmiddleditch.com/data-structures-for-game-
develope...](http://seanmiddleditch.com/data-structures-for-game-developers-
the-slot-map/)

------
gravypod
Could someone give this code a try to see if G++ will vectorize it's tree? If
this is ordered to enhance cache hits for this data then you should see some
serious performance with vectorization enabled IF g++ recognizes it.

------
fulafel
Do any languages have compilers that do this (semi-)automatically? Data layout
optimizations are really lacking in the current state of compilers.

~~~
chrisseaton
Yes! I work on a dynamic compiler (also known as a JIT) for Ruby that will for
example represent small hash maps as a single allocation of a linear
consecutive set of keys and values. This helps further optimisations such as
escape analysis, scalar replacement and loop unrolling, which in turn improve
the effectiveness of inline caching and then inlining, splitting and
specialisation. So after all that it can have quite an impact, beyond simply
being more cache friendly.

------
tlarkworthy
Mmmm, like getting a ticket to exchange for your coat.

