Print

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

[TerminatorII]

Hi I was wonderin g if Toady was going to enable multi threading support? I have a dual core but I can't run the game  past 50% on both cores. (or 100% on one and 0% on the other.)

would be really nice.   then my comp could really handle the bigger forts.

[ July 16, 2007: Message edited by: TerminatorII ]

[Boogey]

If nothing else, using Auto Parallelization might yield some performance gains on most environments... full rewrite to, say, OpenMP might be quite a task.

[axus]

Disagree, multi-threading opens up a crap-ton of problems for the programmer if it isn't considered from the start... and for an evolving project like DF you can't think of everything at the beginning or even the middle.  It's not a bad idea given more time and programmers.

It would be a better time investment if MMX / SSE instructions were used for DF, based on Toady's posts about programming I'm assuming he's not using them (I haven't ever needed to use them).  They are supposed to be great for parallel calculations on grids like the DF map, and there aren't threading concerns to worry about.

Of course I'd rather he just fix the bugs and add features as fast as possible and get to another release before worrying about optimizations.

[Kholint]

Yeah- multi-threaded programming is a whole lot nastier than single-threaded stuff. Trying to implement it can be about as fun as flaying your fingers then putting them in a barrel of salt.

That said (and I don't want to end up sounding like a know-it-all loser, but I will anyway), I think it could be used for a number of different miniature tasks in dwarf fortress. From my own experience it's much better to enable multi-threaded programming for specific tasks that could benefit from it than convert an entire project to make use of it.

An example: generating a world. As far as I can tell, it makes a number of sections of a map, then throws them away if they suck and keeps them if they rule. Now because this is a fairly segmented bit of programming it could be greatly helped with multithreading. One processor could make an area of the world whilst another processor is creating another bit.
For people with dual (or if they're extremely lucky/rich, quad) core processors, world generation time could be halved!

[ July 22, 2007: Message edited by: Kholint ]

[Mud]

This has been proposed before, and I think the conclusion was that adding multi-threading would require gutting the code and generally be way too much work for the benefits it'd provide.

[Juason]

Oh drat!  So much for my new quad core machine helping things out  

[Mud]

Well, I don't think it would help out that much in fortress mode anyway. If I recall correctly, most of the slowdown in fortress mode is more related to memory than processing power, because lots of objects like rocks accumulate, and even though those rocks aren't doing anything most of the time they still have to be stored in your RAM. I'm not 100% on this, but I think I remember Toady mentioning something like that in the Future of the Fortress thread.

More processing power would probably help in world gen and maybe adventure mode, (I know adventure works differently than fortress mode somehow,) but I don't think it affects fortress mode as much.

[ravensword227]

quote:Originally posted by Mud:
<STRONG>most of the slowdown in fortress mode is more related to memory than processing power</STRONG>

Interesting. I'd love to hear a second opinion on this.

I have 1GB of RAM on a 2.4GHz Core 2 Duo (3.2GHz P4 on my old build) and running an end game fort either in fortress mode or through adventure mode cripples my system.

In adventure mode, approaching a fortress, I poll up dozens of forward key presses out of impatience (having to wait at least a full second to move one step is not fun in such a large place) and my character moves forward until he hits a wall and I can't stop it.

With Z-coordinates in fortress mode I can only imagine how much worse it'll be.  Will it be much worse?

[hactar1]

I dunno...  I agree that multithreading is difficult to pull off correctly, and can cause lots of bugs if you don't know what you're doing.  But from the way Toady's described how certain processes in DF work, it might be possible to split certain tasks off into another thread without too much risk or change.  For example, certain processes like temperature or weather could probably run in a separate thread.  Maybe even the connectivity map calculation, although that is apparently calculated whenever a tile is blocked or unblocked, and the game might not be able to handle running the next tick if the connectivity map hasn't been updated by the second thread yet.