Print

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

[SquashMonster]

I have the same problem.  I'm also on a dual-core computer, but I don't think this is related to the problem.

You shouldn't have to go into multi-threaded programming or anything to fix it.  In my experience fixing problems like this is as simple as putting a "defer()" statement (or equivalent for your current language) wherever the code that ends one frame and starts the next is.

[Align]

@Draco
That particular scenario could not happen unless you allowed flows to move one tick without also moving creatures one tick, which is self-evidently silly.

[Tormy]

I have the same problem.  I'm also on a dual-core computer, but I don't think this is related to the problem.

You shouldn't have to go into multi-threaded programming or anything to fix it.  In my experience fixing problems like this is as simple as putting a "defer()" statement (or equivalent for your current language) wherever the code that ends one frame and starts the next is.

So what is causing the "problem" in your opinion? Because there shouldn't be a problem at all if your OS is working flawlessly...at least I guess so.

[Footkerchief]

Setting affinity to a single core worked.

In case you missed it.

[Draco18s]

@Draco
That particular scenario could not happen unless you allowed flows to move one tick without also moving creatures one tick, which is self-evidently silly.

That's the beautiful flaw of multi-threading.  Each thread doesn't know what the other threads are doing!

[numerobis]

There is indeed a sleep statement in DF's loop, but only if the CPU can keep up.

I can't believe we're having the multithreading discussion *again*.

[Align]

@Draco
That particular scenario could not happen unless you allowed flows to move one tick without also moving creatures one tick, which is self-evidently silly.

That's the beautiful flaw of multi-threading.  Each thread doesn't know what the other threads are doing!

wouldn't it be more reasonable to, for each gameworld "tick", tell thread/core 1 to do pathfinding and thread/core 2 to do flows (and so on with line of sight and whatnot)? I mean, having them work asynchronously won't gain you anything unless you're storing up the results from one of the threads or something.

[Granite26]

@Draco
That particular scenario could not happen unless you allowed flows to move one tick without also moving creatures one tick, which is self-evidently silly.

That's the beautiful flaw of multi-threading.  Each thread doesn't know what the other threads are doing!

wouldn't it be more reasonable to, for each gameworld "tick", tell thread/core 1 to do pathfinding and thread/core 2 to do flows (and so on with line of sight and whatnot)? I mean, having them work asynchronously won't gain you anything unless you're storing up the results from one of the threads or something.

Yeah, I always envisioned something like this, but then I realized that creatures are actually moving one at a time, just REALLY fast and with small increments.  (Although a separate flows thread might work...)

[Kholint]

Am I the only one who thinks that a good place for toady to try out/experiment with multithreading is in world gen?
Obviously I have no idea the exact specifics of generating a world, but stuff that is fairly self contained and parallelisable (such as generating individual cells/tiles of the map) would be ideal for multithreading.

Of course there'd be issues (one readily apparant one would be making sure each world tile syncs up with another on the edges), but there always is. I'm just putting it out there that it wouldn't be totally impossible to add multithreading to DF- even if the main gameloop stays running on a single thread, plenty of other stuff that is (possibly/hopefully) relatively self-contained and atomic such as pathfinding for a individual dwarves could be split off to worker threads.


Dedicating threads one by one to specific tasks (as though they are quantifiable "things" before they're created anyway :p), such as one thread for flows, one thread for pathfinding, and so on isn't a great way to handle it. It doesn't scale with the hardware (which is sort of the whole point of threading- having your program increase in speed ideally at the same rate as the user adds cores to their machine) and is fairly ugly and ungraceful.

[Core Xii]

God, will you stop talking about multi-threading if you have no programming experience in the field?

[Mikademus]

God, will you stop talking about multi-threading if you have no programming experience in the field?

You know, if God made a post in this reply, I'd be a tad more courteous when addressing Him, but that's just me...

God is the Ultimate Programmer, and I'm quite certain he's perfectly able to handle multiple threads, mutices or no mutices.

Let's pray:

    Our Program who are in Memory.
    Hello by thy Name.
    Thy Operating System come.
    Thy Commands be done at the Printer as it is on the Screen.
    Give us this day our daily Data,
    And forgive us our I/O errors
    As we forgive those whose logic circuits are faulty.
    Lead us not into frustration, and deliver us from Power Surges.
    For Thine is the Algorithm,
    The Application,
    And the Solution
    Looping forever and ever.
    Return.

[scribbler]

Two cents! Two cents!
a) I always assumed (without basis) that the CPU use during pause was the game catching up, doing pathfinding and other time intensive stuff, like a chess program thinking on your turn. If not, I think ti would be cool, maybe have arbitrary points chosen, either based on locations like dining rooms, workshops and stockpiles or by setting "posts" at arbitrary coordinates and calculating which can be reached and the best routes between them. A GPS with a 16 square gradient could speed up the pathfinding and make it smarter since it will know how far things really are. The busy work can be done when the game is banging it's head against the fps cap, when time is stopped, or when a pathfinding routine requires a new route.
b) If Toady wants to do any multi-thread, and personally I don't care, I'd rather see improved control where I can leave a bunch of commands and know they'll be done and then paused/saved or paused/saved when something important happens... where was I? Oh, yeah. If Toady wants to multi-thread, and it's his bloody game, I'd say split off the interface just and/or maybe the general route finder GPS idea. i.e., background stuff that can leave his core all together and minimize headaches over multi-threading. (Route finder is a boost, it can go to hell and not be a detriment.)

[Andir]

God, will you stop talking about multi-threading if you have no programming experience in the field?

As a professional programmer who DOES work with multi-threading on a daily basis for SQL injection, file parsing, array processing, splitting and some other things, I fully understand that Dwarf Fortress could benefit fourfold from threading fairly easily right from the start.  Some of these things would be calculating fluids, temperature, line of sight, etc.  It's not hard to do, but it's hard to decide when to do it.  You can choke a processor by assigning it too many threads and you can starve it by not assigning enough.  Breaking your tasks up into separate "functional" tasks is the first step.  There are a few basic rules going on in DF that could benefit from SMP or threading.  The fact that Toady has decided to ignore this opportunity is out of our hands however.

It has inspired me to create a "3D" tile engine of my own though.

[Core Xii]

As a professional programmer who DOES work with multi-threading on a daily basis for SQL injection, file parsing, array processing, splitting and some other things, I fully understand that Dwarf Fortress could benefit fourfold from threading fairly easily right from the start.  Some of these things would be calculating fluids, temperature, line of sight, etc.  It's not hard to do, but it's hard to decide when to do it.  You can choke a processor by assigning it too many threads and you can starve it by not assigning enough.  Breaking your tasks up into separate "functional" tasks is the first step.  There are a few basic rules going on in DF that could benefit from SMP or threading.  The fact that Toady has decided to ignore this opportunity is out of our hands however.

I can see that. I was mostly referring to Draco18s' comment: "That's the beautiful flaw of multi-threading.  Each thread doesn't know what the other threads are doing!"

[DanielLC]

If the problem is that dwarf fortress is taking up too much processing power while doing absolutely nothing, I suggest getting a CPU with higher BogoMIPS