Print

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

[kaijyuu]

I'm gonna build a new computer soon, and optimizing dwarf fortress is one of my bigger concerns. I came across a comment that stated DF isn't multi-threaded, meaning having 2 or more processors is meaningless; only one processor will be used.


If so, then I'll have to seriously reconsider my choice of motherboard/CPU. I was planning on getting a dual core, but since my budget is tight and DF is by far the most processor intensive thing I have to worry about, a dual core might actually be counter productive.

[LordSlowpoke]

One core for DF. Second for OS/all the other stuff.

[Silophant]

Right. If you have two cores, you can set DF to real-time priority. Doing that with one core causes... problems. Also, looking at newegg, it appears they only sell one single core processor, and it is disappointingly slow (1.8 GHz). So, yeah. You don't need quad-core, but you do need dual-core.

[Ratbert_CP]

If you use the SDL version, some (all?) of the graphics gets offloaded to another thread.  Multi-core is still a win as the OS (and anti-virus, torrent client, IRC, AIM, MSN, etc) sits on the other core(s).

We all hope/pray that Toady can/will someday refactor for mutlithreading, but I wouldn't hold my breath. 

[kaijyuu]

Righto.


Yeah I set DF to realtime on my current computer once. Oh boy. Insta crash.

[Zaerosz]

Right. If you have two cores, you can set DF to real-time priority. Doing that with one core causes... problems. Also, looking at newegg, it appears they only sell one single core processor, and it is disappointingly slow (1.8 GHz). So, yeah. You don't need quad-core, but you do need dual-core.

Thank you very much for this wonderful news!

[numerobis]

We all hope/pray that Toady can/will someday refactor for mutlithreading

Not all of us.  Dwarf fortress is almost certainly in the state where it's mostly hard to parallelize and comparatively easy to improve sequential performance.

This is the big crisis in applications development everywhere: performance doesn't automatically increase anymore, so you actually have to think about it.  "Thankfully," performance has sucked so there's lots of easy wins in many cases.  Parallelizing is only rarely worth it yet, though new libraries, languages, and algorithms are slowly improving things.

[kaijyuu]

Not all of us.  Dwarf fortress is almost certainly in the state where it's mostly hard to parallelize and comparatively easy to improve sequential performance.

Might be worth it to multi-thread some of DF's serious chokepoints, like pathfinding and fluid mechanics. Multiple cores is becoming the norm, not the exception, as I'm learning right now.


Not DF specific, but supposedly in ~10 years when computers have 16 or so cores, it will become feasible for compilers to do the multi-threading rather than the programmer doing it manually. We're just at the uncomfortable point where not all computers will benefit and compilers aren't sophisticated enough to multi-thread efficiently.

[nickbii]

We all hope/pray that Toady can/will someday refactor for mutlithreading

Not all of us.  Dwarf fortress is almost certainly in the state where it's mostly hard to parallelize and comparatively easy to improve sequential performance.

Double that.

I did some research on multi-threading, and it turns out a multi-threaded program is actually multiple programs working on the same data set. This is not easy, and many experienced programmers don't even try.

Moreover the stuff that sucks your processor power in DF is not really easy to separate from the main game. Pathfinding and fluid dynamics can be completely changed by a single wall, which means you need code to make sure those things always know where your walls are planned and instantly know when they're built. I could easily imagine a situation where those things get their own thread, but the game slows down because the main thread is always pausing to shuttle data between the subthreads, and then pausing to make sure that the data is still good...

Toady could probably take some stuff out of the main thread without problems. For example those meetings with diplomats, calculating whether you get sieged this month,  but multi-threading that stuff won't speed up the game much.

OTOH he's got a few ideas to help pathfinding without multi-threading.

[numerobis]

Not DF specific, but supposedly in ~10 years when computers have 16 or so cores, it will become feasible for compilers to do the multi-threading rather than the programmer doing it manually. We're just at the uncomfortable point where not all computers will benefit and compilers aren't sophisticated enough to multi-thread efficiently.

You can buy a $1000 computer today with 4 CPU cores and 80 GPU cores.  But you can't design a compiler that automatically gets full benefit out of that -- not just because it's impractical, but because it's mathematically impossible.  For example, A* is pretty much explicitly serial: its entire benefit is from exploring what is usually the right path and not seeing anything else.  Lisp and matlab do a great job of warping the programmer's brain to think about doing the same operation on lots of data, which can then be relatively easily parallelized.  The more classically-trained programmers I work with find this all pretty mind-blowing, so it's going to take a generation or two before we can really get data-parallel languages in mass usage.