Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Vigilant]

A bit of a problem with multi-threading a believe :

There's still one single memory. Pathfinding relies on doing a lot of memory access to check the status of each tile in a very large system (so caching is out), even if you have 12 cores and DF could multi-thread : there's still ONE memory with a bus that can only have so much accessing it at once. Multi-core programming works well for situations where most of the time burden is on calculations, not HD/Memory access (or if the case of HD/Memory access, when the data set is small enough to fit mostly into the processor's cache).

[Thief^]

Too true. You'd definitely want to eliminate cache thrashing from the pathfinder before you multithreaded it.

[eerr]

And now the full force of my teacher saying 'memory' limits the power of a computer, hits me.

: O

from what I've read, boolean operators are one cycle, while retrieving from memory is 5 or 6.

[Vigilant]

Try as much as 50 or 60 a lot of the time.

Memory access without a cache hit takes a WHILE. HD access takes ages (relatively).

[Makaze2048]

Page faults and cache thrashing are still problems for a single threaded implementation. There may be more when using more cores and especially if doing disparate tasks since generally L2 cache is shared between them, but that's simply part of the accepted overhead and why you don't see linear performance increases in relation to core count.

Obviously you'd want to profile things to look for slow spots but it should only be slightly more an issue than it already is for the single threaded version (and is probably simply an intrinsic part of pathfinding a large set of data with a complex heuristic). Cache thrashing is largely a red herring in relation to multithreading in this case. Time, knowledge and effort needed to set it up correctly are far larger barriers to implementation.

Multi-core programming works well for situations where most of the time burden is on calculations, not HD/Memory access

Actually one of the primary uses of multithreading is to use separate threads to load things from the HD (or any high latency I/O operation). If it takes one of your worker threads a long time to do or wait on something it's going to take your primary thread just as long or longer. The difference is that they can go to sleep and let other things do stuff while they wait.