Print

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

[Guedez]

After getting slow downs during year 3 i wanted to check how much of my cpu the game was using and it surprised me to see 25%

Is there any plans to make this game mult-thread? something like:

in a single thread: define what each dwarf will do
mult thread afterwards: calcule pathfind
in single thread again: move the dwarfs

etc...

[Capntastic]

At this time Toady has no plans to multithread.

[Jeoshua]

... unfortunately.

[NW_Kohaku]

Multithreading is something that is suggested fairly often and by a good number of people.  Toady has been lobbied many times about the notion, but he isn't particularly interested in taking it up. 

There are several technical reasons for why simply using all four cores isn't really going to be able to quadruple the speed of the game, and why it would cause a tremendous potential for bugs while doing it, and there are more low-hanging fruits that Toady can still reach for in improving performance. 

[sockless]

Multi threading would require a lot of work. Like a couple of months to even get it working I'd imagine. All the while, he wouldn't be developing new gameplay features.

Gameplay features mean donations. They are also a lot more fun for Toady to program, he DF for himself, not for others. Multithreading wouldn't get many donations.

Also multithreading would create a lot of bugs, which people would incessantly complain about, more than they currently do.

Multithreading would have rather marked improvements, even if they aren't proportional. If we had temperature on one core, path-finding on another, fluids on another and then the rest on another, we could probably get a 200% performance improvement at least.

One of the main difficulties with multithreading is that really, it would run as slow as the slowest process. e.g. If pathfinding was the slowest process, then in order to remain synced, the temperature etc. processes would have to wait for pathfinding to finish before starting another tick.

This could be fixed by a new system instead of ticks, but that would probably require almost a complete rewrite of the code.

[Maklak]

I don't have a quote from Toady One at hand, but he mentioned that he is not doing multithreading, and even if he decides to di it, it will be stuff, like fork / join over a loop, or something simple, like that. So no separate threads for pathfinding, temeretaure, or whatever, and no task / thread pools.

[Sordid]

Well that's a damn shame. Multi-core CPUs are already the industry standard, and we're only going to get more of the same in the future. Refusing to multithread in this situation is kinda like stubbornly insisting on using the good ol' telegraph instead of this newfangled invention called email.
*sigh*

[Chocolatemilkgod]

Multi-threading would be a major pain...I don't blame him for not doing it. Doing it to a small degree might work.

[Artanis00]

Multi-threading would be a major pain...I don't blame him for not doing it. Doing it to a small degree might work.

I agree, and further, I think sockless is understating the work involved in this suggestion. Essentially, what is being asked is a redesign and rewrite from the ground up.

I am not kidding about the redesign part: multi-threaded applications are completely different from single-thread applications. You can't just fork a random function call onto a new thread (at least not in C/C++).

[Untelligent]

Well that's a damn shame. Multi-core CPUs are already the industry standard, and we're only going to get more of the same in the future. Refusing to multithread in this situation is kinda like stubbornly insisting on using the good ol' telegraph instead of this newfangled invention called email.
*sigh*

The problem with this logic is that everyone has access to email whereas multithreading is apparently very hard, especially for something as complicated as DF.

[Uristocrat]

I don't have a quote from Toady One at hand, but he mentioned that he is not doing multithreading, and even if he decides to di it, it will be stuff, like fork / join over a loop, or something simple, like that. So no separate threads for pathfinding, temeretaure, or whatever, and no task / thread pools.

The rendering code is already multithreaded.  But adding multithreading to the rest of the code would cause lots of bugs and crashes, not to mention redesign work.  That said, it doesn't really matter to us how he speeds the game up, only that it speeds up, right?  He *has* been looking for other things he can make more efficient and will continue to, I'm sure.

I'd worry more about hitting the wall with RAM first, honestly.  You can already crash by attempting too large an embark.  Maybe we'll have to have a "buy Toady a 64-bit dev machine" fundraiser someday.

[Sordid]

The problem with this logic is that everyone has access to email whereas multithreading is apparently very hard, especially for something as complicated as DF.

Isn't that all the more reason to do it, and do it as quickly as possible? DF is only ever getting more and more complex, the longer he puts it off the harder it's going to be. And he's going to have to do it eventually.

[Capntastic]

And he's going to have to do it eventually.

This isn't actually true.  And I myself personally agree that multithreading would be a good thing.

[Max White]

Toady hasn't had any formal programming lessons. That doesn't mean he isn't able to understand and sue multi threading, but rather it means that right now there is a very good chance he's code is a mess of spaghetti. If Toady wants to start multi threading now, I think he would be better of with making Slaves III, rather then spending a year or three working just on fixing it up as it is now.

Even without taking this into account, Dwarf Fortress is not a work of profit, nor is it a banner to set the standard for what games should be. Rather, it is a work of love. Toady makes this game for one simple reason, it brings him happiness. If, one day, Toady thought decided he was done making games, then we would never see another update, and would have no right to demand one.

And I, for one, wouldn't have it any other way.

[sockless]

How exactly would 64-bit make DF run faster?