Print

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

[Apoco]

Dwarf Fortress itself is not multi-threaded. All game logic happens in a single thread. However, because it uses other libraries for sound and graphics, the application as a whole contains more than one thread.

This is true for nearly every program running on your computer. In fact, there's only one program on mine that uses but a single thread: Notepad.

i thought it was the programing that allowed the application to utilize other cores for things like sound, but unless support was implemented it would still only be single threaded. Take quake 3 for instance it is single threaded and the sound can be offloaded to a separate core but ONLY if you enable the smp support will it take advantage of the other cores

[Muz]

Well, maybe the computer spreads out all processes directed towards the general CPU into the other processors? Like it was designed to be used on a single-CPU, but the hardware configs or whatever, automatically distributes the calculations to the others.

I don't really think the sound and graphics for DF really use up much power at all.

[Sean Mirrsen]

You should get Process Explorer. Then you will see that DF itself always uses one core to the max, but it also has libraries for sound and graphics that use additional CPU cycles. For my 2Ghz dualcore, it's 50% for the dwarfort.exe, and 10-15% for the dsound.dll and nvoglv32.dll combined.

[Core Xii]

i thought it was the programing that allowed the application to utilize other cores for things like sound, but unless support was implemented it would still only be single threaded. Take quake 3 for instance it is single threaded and the sound can be offloaded to a separate core but ONLY if you enable the smp support will it take advantage of the other cores

Indeed, but the point here being that the programming of Dwarf Fortress, and the programming of the underlying libraries it uses are two completely different things. Audio libraries commonly run in separate threads because if the game logic or the graphics lag (which is especially the case with vertical synchronization), the audio would stutter.

But the game in itself, that is, the world, the dwarfs, the items and all that stuff, is processed in a single thread. (and obviously, that's the most beneficial part to multithread)

[Stathol]

You can inspect each thread's call stack with Process Explorer. That's not a real accurate trace of the thread's execution, but it will give you a rough idea of what the thread is presently doing in most cases. It's as good as you're going to get without knowing your way around a debugger, anyway. If you install the Debugging Tools for Windows and configure symbols, you'll get function names (plus offsets) instead of raw virtual addresses inside of system libraries/executables. It's hard to tell what's going on without some API names.

If I had to make a wild-ass guess, you probably have on-board audio, don't you? Built-in audio codecs are almost always software devices. Only the codec interface itself is implemented in hardware. For instance, if you look at the driver structure for on-board audio devices, they usually call for the installation of the kernel audio mixer device (kmixer.sys). This is a software device for mixing audio streams in kernel mode.

On-board audio devices are known to eat up potentially 5-10% of a processor's resources under heavy load, depending on the processor and the particular codec & drivers. This probably takes place in separate worker threads for technical reasons. That might account for what you're seeing. That said, 35% on a quad core means you're eating up about 60% of the second core.... At first glance, that sounds excessive for simple audio mixing, or even EAX effects (which I don't think DF uses ). Then again, multi-core systems are not strictly additive. A quad-core system doesn't really have 4x the processing power of an identical single core system, even with optimally threaded code. So 60% of a core isn't quite as bad as it sounds.

In short, I have no idea. Is the DF music MP3 encoded? Maybe it spawns a worker thread to decode the MP3 stream. Between decoding an MP3 stream and kernel mixing, it might be a plausible explanation.

Maybe you can post some call stacks and I can figure it out. Do configure symbols first, though. Calls like "kernel32!0x77123456" are meaningless since system DLLs are routinely loaded at different base virtual addresses on each system, or sometimes even for each process.

[Zeta]

oddly enough, I think DF is in fact using both cores evenly on my system, at least during worldgen (when I actually bothered to monitor it)

when I -don't- restrict dwarfort.exe to one core, I get somewhere around 60%-65% CPU usage total, and both CPU Usage graphs in the Task Manager Performance tab fluctuate.

when I -do- restrict dwarfort.exe to one core, I get a CONSTANT 50% CPU USAGE (with the occasional moment of 51% from other apps) - which is enough to suggest that either some code in Dwarf Fortress results in multithreaded capabilities or my motherboard or processor divides the workload evenly unless an application is restricted to one core or the other. (I severely doubt it's the latter, but, it could happen.)

this is using the May Green graphical mod (revision 15 - the one that comes with .40d) windowed and with sound turned OFF (so OpenGL or DirectX would be the only real variables). I doubt this would change with FullScreen (but I can test this as well - thank you, dual-screen).

[Draco18s]

I should drop in and say that I've got a dual core and I'm seeing (peak) 79% usage (that is, a full core + 29%).
0% and 8 to 20% when paused.
70%+ and 70%+ when unpaused (~45 to 60 FPS).  IE neither core is getting maxed out completely.

[Kittah_Khan]

I think a lot of these sorts of things should really wait until the game is mostly done.   Consider it like a cake that needs to be baked before you can frost it.

Oh hell no, I can't let ignorance like this stand.
You need to build your whole fricking architecture around multi-threading from the start, you can't just tack it on, doing so results in many many bugs and other varied problems( kind of like breaching HFS without a military ), this goes for all core functionality, and by god, multi-threading is core functionality.

This is the reason why Toady gutted DF when he went over to 3d, the existing stuff simply couldn't be modified that way reliably( though he has left a significant portion of code in 2D, siege engines being the most glaring example ).

TL;DR
multi-threading is like butter in the cake dough and not frosting.