Print

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

[Skyrage]

I remember this was discussed a while back but I lost track of that thread and wondered if this eventually was gonna be implemented or not?

With such a processor-intense game like DF, it'd be neat (actually, more than neat - it'd be very beneficial) if this could be added and taken care of some day, cause it's kinda a bit sad watching my CPU performance hovering at 50% cause it's unable to utilize the whole processor. The power to avoid most or all the lag etc is there, yet cannot be harnessed.

[Core Xii]

Easier said than done.

[Zurai]

Much easier said than done. Multi-threaded apps have a lot less room for error than single-threaded ones. You have to know precisely what and where every variable is being accessed, because if two different threads try to access the same variable, the game goes boom.

On top of that, Toady has said before that he doesn't even know how to do multi-threading. Trying to "learn on the job" so to speak could be pretty disastrous. I'm sure he'll add it in eventually, but it will not likely be any time soon.

[0x517A5D]

Fourthed.  Nailing multithreading on after-the-fact is hard, much harder than designing it that way from the start.  In a program this size, it's a recipe for disaster.

That said, it would be cool if a few of the more time-consuming operations (such as the A* searches) could be parallelized.  Or even put on a GPU for massive parallelism.  But realistically it's not going to happen.

Multi-core owners take note: there has been a report of better performance by restricting the game's process to one CPU.  Ctrl-Alt-Delete, processes tab, right click on dwarfort.exe, Set Affinity, only allow CPU 1.  It's worth a shot.

0x517A5D

[Mylon]

I don't know the specifics, but how hard would it be to "contract" out some steps to the other CPU?  An example of this would be pathfinding.  The algorithm is set loose on the other CPU while the dwarf stands still, "thinking".  When the process is complete, the other CPU says, "Done!"  And provides a direction for the Dwarf to move, or possibly a complete path.

I've never heard of anything using a GPU to do calculations other than graphically related ones, but that might be interesting if it could be done.

[Karlito]

I thought I had heard somewhere that DF was already threaded for dual core processors, but perhaps I am mistaken.

[0x517A5D]

'Tisn't, except that I seem to remember that the graphics updates are decoupled from the world clock, so that might be in another thread.

No, I just checked with SysInternals' Process Explorer.  One thread.

That's good for utility writers, anyway.  Always a bright side.

0x517A5D

[Hanse]

With map generation, you could farm out alternating zones to a thread, since the seed is constant.  Effectively, you would be decreasing the generation time based on how many processors you have.

[Sean Mirrsen]

I have that Process Explorer, too. DF does have one thread for the executable, that's true. However, there are several additional dlls and libraries that also use CPU, like directsound and opengl. So in general, while DF doesn't work multi-thread, it does work faster on  dualcore, simply because the excess power of the second core is diverted to the graphics and sound (I saw them use about 20% of my combined 4Ghz), while the main thread is allowed to use full power of first core.

[Ihlosi]

quote:Originally posted by Zurai:
<STRONG>Much easier said than done. Multi-threaded apps have a lot less room for error than single-threaded ones.</STRONG>

Well, actually, it's the other way round: Multi-threading adds lots and lots of room for errors that you would never have to deal with in a single-threaded app.   It can also make debugging a real pain.

 

quote:<STRONG>You have to know precisely what and where every variable is being accessed, because if two different threads try to access the same variable, the game goes boom.</STRONG>

Then again, it's not quite that harsh. You may read the same variable from as many threads as you wish, it's only when you start writing that you need to pay attention to who does it and when.

This is why I think DF has some great potential for multithreading. I would assume that the game computes the "new" state for all objects in the game from the "current" state. The "current" state will not be written to anymore, so several threads could be started that compute the "new" states that only need to read from the "current" state. In this regard, DF could benefit almost perfectly from multiple cores.

Of course, there might be some need to resolve conflicts in the "new" state, but  most of the processing done only reads from the "current" state and writes to the "new" state.

[ February 16, 2008: Message edited by: Ihlosi ]

[zagibu]

I think the climate could be shifted to a seperate thread pretty easily. Other things could be more complicated, depending on the actual implementation...

[The-Moon]

quote:Originally posted by Zurai:
<STRONG>Much easier said than done. Multi-threaded apps have a lot less room for error than single-threaded ones. You have to know precisely what and where every variable is being accessed, because if two different threads try to access the same variable, the game goes boom.

On top of that, Toady has said before that he doesn't even know how to do multi-threading. Trying to "learn on the job" so to speak could be pretty disastrous. I'm sure he'll add it in eventually, but it will not likely be any time soon.</STRONG>

Multi threading is not hard at all to program. In fact its quite easy.

I used pthread's before in a server client app i was working on. It was really a piece of cake to get it working once i knew how to use it correctly.
http://en.wikipedia.org/wiki/Pthreads

Learning Threads is not disastrous. Using them wrong is however.

[Ihlosi]

quote:Originally posted by The-Moon:
<STRONG>Multi threading is not hard at all to program. In fact its quite easy.</STRONG>

Well, yeah. It's getting the multithreaded app bug-free that's the hard part.

If you have a couple of threads working on completely different things that only need to talk to each other occasionally, then maybe it's easy. But as soon as the threads need to play nice with each other, you better start learning about semaphores, priorities, race conditions, deadlocks, atomicity, reentrancy, prioritiy inversion and all that stuff, or you don't stand a chance of getting it right.

Then again, if DF works the way I assume it does, it should lend itself very well to multithreading and almost achieve a linear performance increase with the number of cores.

[Draco18s]

Necropost...

[numerobis]

quote:Originally posted by The-Moon:
<STRONG>Multi threading is not hard at all to program. In fact its quite easy.

I used pthread's before in a server client app i was working on. It was really a piece of cake to get it working once i knew how to use it correctly.</STRONG>

Parallelism is all about making sure that two tasks are independent (and if not, using some kind of synchronization).  Once you have a parallel algorithm to implement, it's not *too* bad to code up, though there remain some pretty substantial pitfalls.  What's really hard is figuring out what things are truly independent.  On top of that, synchronization overheads can very easily eat up all the gains.

Path planning is a good example.  Every planned path looks like it's totally independent of every other, so that's a good candidate.  But, first thing, to make it fast Toady is likely storing some data in each tile.  So now you have to remember to have each tile store data for each thread, and have a mapping from threads to that index.  And now each tile has size that differs depending on the number of threads.  OK, we fix all that, so that the path planner is independent across threads.  But we still haven't achieved anything: there's still only one path planner being spawned at a time.  So before we see any benefits, we also need to parallelize the per-frame loop over all animals (dwarves and gobbos included) that updates their state and does path planning.  State updates are going to react to each other, so there's definitely some non-independence that needs to be coaxed out via mutexes or greater re-engineering; this will be hard.  OK, *now* we can parallelize path planning (and state updates).  How much faster is dwarf state update now?  Twice as fast on our beloved dual-core chips, minus synchronization overhead and memory hierarchy overhead that probably triples (actual number from many things I've seen) the total work, which yields a speedup of...  OK, on our beloved quad-core machines, it's faster.  But we only sped up part of the program, so it's not much faster.

This constitutes a lot of development time, especially if Toady isn't already an expert at this kind of stuff.  Compare that with just running the sequential program in a profiler and looking for bottlenecks and fixing them using traditional techniques that Toady presumably knows well (using fewer instructions, using less memory, etc).  Or with fixing bugs and adding content.