views:

77

answers:

2

Hello, I need to store a graph for the map of a game inside a game server written in C.

The graph has ~200 nodes and 3 kinds of edges that can connect two nodes (these three kind can also overlap: a node can be connected by 2 edges of two different types for example). The maximum degree of a node is something like 5-6 nodes.

What I would like to have is to have this static structure implemented in an efficient way to allow me to do simple operations like

  • is n1 connected to n2? (with all kinds of edges in case of affermative response)
  • what is n1 connected to? (with all kinds of edges or a specific one)

but in a multi-threaded environment since there will be many instances of the game that relies on the same static graph.

Since the graph can't be modified and the structure is well known I'm sure there are some tricks to implement it in a cool fashion to use least resources possible.

I would like to avoid using STL or Boost for now.. do you have any clues on a data structure that could suit well?

(it's not a premature optimization, the fact is that it will run on a vps and I don't have many ram neither cpu power so I need to keep it tight)

EDIT: just because I forgot (and thanks to make me realize it) the graph is undirected so every edge is symmetric..

Thanks in advance

+1  A: 

Since degrees are limited, you can get very good performance by just representing a node by a struct with arrays of pointers to other nodes (one array for each edge type).

Regardless of the data structure you pick, you can avoid worrying about multithreading if your graph is read-only (OK for multiple thread to access it without synchronization).

Mau
Mostly avoid - you still need a fence between setting the data in the graph and giving the pointer to the data to the threads, so you need to either pass the data to the threads on startup, or add the fence yourself.
Pete Kirkham
+4  A: 

Many answers are possible. This one relies on the fact that you have relatively few nodes. The advantage of this approach is probably unbeatable performance.

The idea is to represent your graph as a 200x200 matrix of bytes, each entry representing an edge. The byte gives you 256 different possible values, where a 0 will obviously mean "no connection" and any non-zero combination of bits can represent up to 8 different edge types.

Let the "row" of this matrix be the starting node and the "column" be the destination. Initialize the structure such that for every edge connecting one node with another, there's a value at the intersection of starting / ending. That value can be a combination of bits representing edge types.

To find out whether one node connects to another, simply query the byte at the intersection of one node and the other: If there's a nonzero value there, then there is a connection, and the value will tell you what kind.

For 200 nodes, this data structure will eat up 40 KB, which is pretty moderate. It won't scale too well once you get beyond, say, 1000 nodes.

As long as nothing (apart from one-time initialization) ever writes to this structure, it will be naturally thread safe, as its state never changes.

Carl Smotricz
Agh, beat me to it. Just wanted to add that if the graph is undirected, you only need to store half the array. (20KB)
wds
If I were implementing, I'd be too lazy to sink a lot of thinking into saving half the required memory. Also, the question hints that the OP will also be looking for reverse connections. My approach here would be "refinements left to the reader" :)
Carl Smotricz
For that matter, if there are three possible connections you should only require 3 bits per pair, or 14925 bytes. (the lookups would be easier if it were three arrays of 200*199 bits = 25 * 199 bytes rather than using 3 contiguous bits per pair)
Pete Kirkham
@Pete: Good idea! Looking at the OP's (updated) question, it seems memory is indeed at a premium, so it may be worthwhile to economize. If the graph is indeed undirected the @wds' suggestion could be incorporated to save another 50%. So we'd be down to what, 7500 bytes? Starting to look good. And still very fast.
Carl Smotricz
Yeah standard practice if you're cutting it in half is just find a good mapping function from (a,b) coordinates to a linear address space, then set up macro's whenever you address an element. (if a < b in (a,b) you can actually just do `a+b-1`). Pete's suggestion requires a bit more trickery. The upside of using bytes is it's easy to work with and you can do some tests (is there a link) without having to use masks. It's a mem/cpu tradeoff, I think.
wds