Print

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

[Astrid]

What i was wondering...

It's obvious that DF only uses one core of any given cpu, which is a kind of bummer on the most recent
machines. that however gave me an thought...

Wouldnt it be possible to write a small quick program that uses all of the cpus cores yet present itself
as a single core 'virtual cpu' for DF to use?

I am not a coder, that's why i am wondering whenever that would be doable or not.

[10ebbor10]

Nope, it's impossible. A system making one calculation every nanosecond is not equivalent with a system making 4 calculations every 4 nanoseconds.

In dwarf fortress case, the computer can't do multiple calculations at the same time (which is what multithreading is), because each of these calculations is dependent on the previous one.

[612DwarfAvenue]

This has been asked already. Many times. It's not something you can just hack in, Toady will have to go through and entirely redo the game's code to make use of additional cores.

[Tacyn]

This has been asked already. Many times. It's not something you can just hack in, Toady will have to go through and entirely redo the game's code to make use of additional cores.

And then, it is not even a given that multithreading would help at all.
If the game's speed bottleneck lies not with the CPU but the memory bus, using multiple cores would actually slow it down.

[Bohandas]

This has been asked already. Many times. It's not something you can just hack in, Toady will have to go through and entirely redo the game's code to make use of additional cores.

As written this is actually a slightly different suggestion than the one that usually comes up. This is suggesting not to make the game itself work multithreaded, but to use some kind of third party go-between program that makes the two cores act as a single faster core running a single thread. (which I assume probably isn't a plausible alternative, given that if it was then it (in a general, non-DF specific form) would probably have already developed into a utility by one of the major software companies)

[612DwarfAvenue]

This has been asked already. Many times. It's not something you can just hack in, Toady will have to go through and entirely redo the game's code to make use of additional cores.

As written this is actually a slightly different suggestion than the one that usually comes up. This is suggesting not to make the game itself work multithreaded, but to use some kind of third party go-between program that makes the two cores act as a single faster core running a single thread. (which I assume probably isn't a plausible alternative, given that if it was then it (in a general, non-DF specific form) would probably have already developed into a utility by one of the major software companies)

I know, my statement still stands for both kinds of suggestions. The effort required to pull something like that off, assuming it's even plausibly possible at the moment, means it'd be a lot better to just recode the game itself to work with multiple cores. The whole point of multiple cores is for multiple calculations at once, they're not designed to work as a single core, you can't just pool their capabilities together like harddrives in RAID.

[Evil Knievel]

IMHO the only feasible way to speed up an existing code using multiple threads is to isolate a single bottle neck, try pull it out into other threads. Then you try very hard to get a speed improvement without braking your program.

Since a commonly mentioned bottleneck is pathing, maybe it would be worth to look at that. I assume that DF calls A+ whenever a path is needed, and waits for the answer, and the proceeds the game. It would then mean that A+ is called in a different thread, the game would go only the pathing dwarf unable to move (locked) until the new movement directions are calculated. Does not seem like a desirable result, and it is not clear either if that would speed up things - after all a one-time pathing call must warrant firing up another thread for this.

It might be better to have continuously a thread in the background working on updating computing "helper" information for the pathfinding (whatever that might be) that is only communicated with every now and then to get some updates about the world for example. The pathing in the main thread can then be aware of said helper information and possible compute the paths faster using it. Needless to say that such a change would require a complete overhaul of the pathing paradigm in the game and the risk that it would not improve anything is still high.

EDIT: A+ is A* i guess

[miauw62]

Also, multithreading would almost certainly cause a lot of very weird bugs because of desynchronization, and a lot of crashes.

[Telgin]

Only because of bugs in the multithreaded implementation.  If everything is synchronized with mutexes and semaphores as needed that isn't a problem.  Of course, that is the problem, so yes, it's very likely that multiple releases of DF down the line would continue to have multithreading bugs because of how hard they are to track down and fix.

This has been asked already. Many times. It's not something you can just hack in, Toady will have to go through and entirely redo the game's code to make use of additional cores.

And then, it is not even a given that multithreading would help at all.
If the game's speed bottleneck lies not with the CPU but the memory bus, using multiple cores would actually slow it down.

We'll never know without profiling, but I bet that there are plenty of things in DF that could take advantage of multithreading.  Pathfinding and temperature calculations could likely benefit for example.

The memory bus thing is a good example of something that would require profiling to know.  If data isn't needed between several threads then the CPU's cache can eliminate a lot of that problem.



Anyway, yeah, I don't see Toady multithreading anything in DF any time soon.  It would be nice, but it's entirely reasonable to relegate it to the distant future, if ever, since he doesn't have the technical expertise and the fact that the game still works reasonably well as is.

[Evaris]

I simply have to ask, but what about the possibility of AMD Mantle being used for assisting with calculations?  Could you just run calculations on the GPU as needed, (or wanted) and could the VRAM then be used? 

Not entirely sure and while I'm pretty heavy on the hardware end of things, not so sure about a lot of software limitations, but I know that AMD's Mantle helps a lot when it comes to calculation heavy games.  And with my knowledge that DF is heavily limited by RAM... well VRAM tends to be a lot faster than what's there for your CPU.. so yeah.

[Cobbler89]

I thought Mantle was supposed to replace OpenGL or something... last I heard about it there was a lot of hype and virtually no publicly available data on how to use it though (at least, as far as I could find via internet search engines). [ETA: And is AMD's Mantle going to be supported by non-AMD graphics hardware, or what? Despite the hype focusing on eliminating the need for bloaty compatibility layers, I was unable to learn how it's going to handle portability either. Just curious.]

The thing that you have to remember about using the GPU to run calculations is that it basically requires learning a whole new programming language... for the simple reason that compilers don't make your regular programming languages that normally do calculations run on the hardware that was designed to do calculate en masse efficiently for graphics' sake. It's extremely ironic: we built special hardware for graphics because graphics needed lots more calculation, then we developed programming languages just to control the graphics hardware, then we realized that could be a more efficient way to do regular program calculations when there's a lot of calculating to do, and we haven't yet got to the point of saying, "Shoot, why don't we just make the regular hardware that powerful so you don't need to learn separate programming languages for using the graphics hardware for calculating other stuff?" (Now, I'll grant you, if you want to use separate programming languages because the way they approach calculation is better for mass calculation than traditional programs -- you know, things like SIMD [Single-Instruction Multiple-Data] -- that's another matter, whether the hardware's specialized or not. But that's, well, another matter!)

End rant. That's not to say that programming on the GPU is a bad idea, just that you have to keep in mind it's extra work and might be unnecessary in a decade or two (so, not long from now in the Dwarf Fortress Development Cycle Scale of Time!) if we can work through the fit of irony that is the fact of GPU programming languages in the first place.

Going back to the OP's question: I imagine that taking any old program and dynamically splitting its load in parallel between multiple cores might be something operating systems will do for all programs by analyzing their code, at least for code that doesn't modify itself while running, in another decade or two (again)... Sort of like how certain programming languages' runtime engines optimize their scripts or bytecode as they run it and see what it actually ends up doing.

[Telgin]

Agreed about the automatic parallelization thing.  I suspect that ultimately that's something that's going to be done automatically, although probably by compilers.  It's just so complicated and problem ridden that it's the only way it'll ever reach the necessary usage levels for programs in general.  Of course, as you said, it's likely to be a very long way off.  20 years might be optimistic, especially for free compilers.  This is likely to be the only way DF is ever substantially parallelized.

GPUs are interesting, but having worked with them I can say that they're really just not going to work for DF even if Toady learns CUDA or OpenCL (which aren't that bad really, they're almost straight C).  GPUs are really only efficient for very large data sets where you have many thousands of data units that need to be operated on, and for which you have fairly substantial mathematical computation to do.  GPUs are fantastic for that.  In DF terms about the only thing I can think of which might work well on a GPU would be temperature calculations on a per tile basis.  You still run into boundary condition problems though where you have to synchronize between threads, which is a very big bottleneck on GPUs.

You can't really use GPUs to do general unit updates.  Things like graph traversal, such as path finding, are generally terrible on GPUs (again, been there, done that).  Calculations that do lots of conditional branching are awful on GPUs.  Other unit update stuff like updating timers might actually run pretty fast on a GPU, but you're wasting too much time moving the computation kernel and data to and from the GPU to make it worthwhile.  And pretty much any interaction between units involves synchronization, which is going to make the GPU kernel run way, way slower than the CPU would.

[Dirst]

There are a handful of DF operations that I can see being handed off to a vector calculator such as a GPU... namely anything that is calculated more or less independently for a huge number of items.  The rule of thumb for independent is if it matters what order you processed the list, then it's not independent.  Temperature for each tile is a good example (independent because each tile is influenced by its neighbor's state 1 tick ago).  Wear status of clothing.  Rotting.  Plant growth.  Lighting.  Possibly world-gen battles.  And maybe fluid flow if it is reworked substantially.

As more simulation features get folded into DF, other applications might pop up.  But unless some truly cross-platform solution presents itself, don't expect Toady to make one (or multiple) hardware-specific versions of the game.  By the way, that cross-platform solution would need to fail gracefully if no suitable GPU is present, doing its calculations serially on as many spare CPU cores as it can find.

[Evaris]

There are a handful of DF operations that I can see being handed off to a vector calculator such as a GPU... namely anything that is calculated more or less independently for a huge number of items.  The rule of thumb for independent is if it matters what order you processed the list, then it's not independent.  Temperature for each tile is a good example (independent because each tile is influenced by its neighbor's state 1 tick ago).  Wear status of clothing.  Rotting.  Plant growth.  Lighting.  Possibly world-gen battles.  And maybe fluid flow if it is reworked substantially.

As more simulation features get folded into DF, other applications might pop up.  But unless some truly cross-platform solution presents itself, don't expect Toady to make one (or multiple) hardware-specific versions of the game.  By the way, that cross-platform solution would need to fail gracefully if no suitable GPU is present, doing its calculations serially on as many spare CPU cores as it can find.

Well AMD has made the Mantle API open for use if I'm not mistaken, so it's just a question as to if Nvidia decides to support it or not.  And it is already cross-OS compatible for Mac/windows/linux, so there is that for it.