Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  
Pages: 1 [2] 3

Author Topic: My friend doesn't understand how resource intensive Dwarf Fortress is.  (Read 15790 times)

TheFlame52

  • Bay Watcher
  • Master of the randomly generated
    • View Profile
Re: My friend doesn't understand how resource intensive Dwarf Fortress is.
« Reply #15 on: March 28, 2016, 10:33:45 am »

Tell him every single 8-bit smiley has its own functioning circulatory, muscular-skeletal, and nervous systems. Show him the amount of data in each dwarf's profile. Tell him that it's all tracked and effects the gameplay. Also do the stuff other people said.

Foxite

  • Bay Watcher
    • View Profile
Re: My friend doesn't understand how resource intensive Dwarf Fortress is.
« Reply #16 on: March 28, 2016, 10:38:28 am »

The best way to demonstrate it to him is take a save of 40 year old fortress with 150 dwarves in it on a good sized embark with a volcano that just breached the circus and install it on his gaming rig and watch it bring his rig to its knees.
Sigging this
Logged
The best way to demonstrate it to him is take a save of 40 year old fortress with 150 dwarves in it on a good sized embark with a volcano that just breached the circus and install it on his gaming rig and watch it bring his rig to its knees.

Tarsis

  • Bay Watcher
    • View Profile
Re: My friend doesn't understand how resource intensive Dwarf Fortress is.
« Reply #17 on: March 28, 2016, 06:16:59 pm »

Every time 64-bit and multithreading come up I learn things. Thanks for the polite discourse guys!
Logged

NW_Kohaku

  • Bay Watcher
  • [ETHIC:SCIENCE_FOR_FUN: REQUIRED]
    • View Profile
Re: My friend doesn't understand how resource intensive Dwarf Fortress is.
« Reply #18 on: March 28, 2016, 07:39:14 pm »

Actually, you could probably just tell him that many people "burn test" their rigs by downloading a program from NASA that basically outsources some of the math they need to calculate all the data they get from various telescopes and satellites.  This basically involves using 100% of your computer's processors for as long as you leave it running doing nothing but pure math problems as fast as your GPU can solve them, which is more resource-intensive (and therefore will overheat your computer more) than any graphics ever could.
Logged
Personally, I like [DF] because after climbing the damned learning cliff, I'm too elitist to consider not liking it.
"And no Frankenstein-esque body part stitching?"
"Not yet"

Improved Farming
Class Warfare

Saiko Kila

  • Bay Watcher
  • Dwarven alchemist
    • View Profile
Re: My friend doesn't understand how resource intensive Dwarf Fortress is.
« Reply #19 on: March 29, 2016, 10:13:00 am »

I don't believe that changing to 64-bit will actually speed something up. Occasionally I compare 64-bit versions of programs with their 32-bit versions, and usually the 32-bit version is faster (if there's a difference), and always it takes less memory (which is expected, and which may explain why it is faster). I suppose only the bigger forts will be affected positively, and they are already crippled by other things.

But making multithreading should add more. Especially if made smartly, like adding pathfinding to another thread (which is often used in PC games) or doing that with some environmental updates. Still, it is much, much harder to do.
Logged

TheBiggerFish

  • Bay Watcher
  • Somewhere around here.
    • View Profile
Re: My friend doesn't understand how resource intensive Dwarf Fortress is.
« Reply #20 on: March 29, 2016, 10:39:30 am »

Post to watch people beat an ‼XXMangled Horse CorpseXX‼.
Logged
Sigtext

It has been determined that Trump is an average unladen swallow travelling northbound at his maximum sustainable speed of -3 Obama-cubits per second in the middle of a class 3 hurricane.

xana55

  • Bay Watcher
  • Booze Detected: Initiating Drinking Protocal
    • View Profile
Re: My friend doesn't understand how resource intensive Dwarf Fortress is.
« Reply #21 on: March 29, 2016, 10:59:23 am »

Just tell him if he's convinced it's so trivial to put it on his PC and see how long it lasts. I'm willing to bet it'll surprise him.
Logged
Urist The Foolish: Beheaded by a swarm of cats 379 BC.

Pvt. Pirate

  • Bay Watcher
  • Dabbling Linux User
    • View Profile
Re: My friend doesn't understand how resource intensive Dwarf Fortress is.
« Reply #22 on: March 29, 2016, 07:30:32 pm »

copy it over on USB and create a large world on his computer.
while his computer bends, open the DF wiki and explain to him WHAT the game has to calculate and keep track of while time passes.
and that all the events that are being calculated will affect your game when you chose to embark.
also tell him that in every single frame, it also keeps calculating the rest of the world with all its politics, economics, tragedies, wars, marriages, childbirths, animals, animals copulating, animals dying, animal corpses being processed into items or rotting away, trees growing and dying, simlultanous to your fortress growing or going to ruin.
Logged
"dwarves are by definition alcohol powered parasitic beards, which will cling to small caveadapt humanoids." (Chaia)

Dozebôm Lolumzalìs

  • Bay Watcher
  • what even is truth
    • View Profile
    • test
Re: My friend doesn't understand how resource intensive Dwarf Fortress is.
« Reply #23 on: March 29, 2016, 09:51:15 pm »

HAVE HIM BREACH HELL AND THEN SEAL IT OFF

HE WILL KNOW DESPAIR

AND THE STARING AT THE TASK MANAGER ANGRILY
Logged
Quote from: King James Programming
...Simplification leaves us with the black extra-cosmic gulfs it throws open before our frenzied eyes...
Quote from: Salvané Descocrates
The only difference between me and a fool is that I know that I know only that I think, therefore I am.
Sigtext!

Lummox JR

  • Bay Watcher
    • View Profile
    • BYOND
Re: My friend doesn't understand how resource intensive Dwarf Fortress is.
« Reply #24 on: March 29, 2016, 11:03:12 pm »

Converting a single-threaded program to multi-threaded is hideously difficult. Hideous. I could tell you horror stories.

DF might be uniquely suited to some forays into multi-threading, however, by virtue of the fact that some tasks like pathfinding could be considered inherently parallel. The temperature loop could probably be split off and also broken down into subsets, as could (to some degree) flows. The trick would be for all these things to never make a change on their own that might affect the main thread or each other, but rather to message the main thread.
Logged

PatrikLundell

  • Bay Watcher
    • View Profile
Re: My friend doesn't understand how resource intensive Dwarf Fortress is.
« Reply #25 on: March 30, 2016, 02:31:31 am »

I would expect converting a single threaded program into a multi threaded one usually to be easier to do by reimplementing it from scratch, making use of the knowledge of the overall design of the original, its algorithms, and some select pieces of code than to massage it by shifting load bearing structures around. In the case of DF, that would probably generate too much of a years long development hole. Also, the whole DF development is one of building a shack, expanding it into a cottage, then a house,...

I agree the results of what results side threads have come up with usually have to be introduced into the main memory structures through a main thread integration effort at the end of each tick, where you'll also have to resolve any conflicts (e.g. a fluid flow calculation may have to be modified or partially redone if an affecting drawbridge has been opened or closed).
Logged

Psieye

  • Bay Watcher
    • View Profile
Re: My friend doesn't understand how resource intensive Dwarf Fortress is.
« Reply #26 on: March 30, 2016, 07:48:59 am »

So to summarise the ‼XXMangled Horse CorpseXX‼, a proper multi-threading re-write looks prohibitively time-expensive. But extremely localised areas of code might (would need to be measured) see an improvement with a 'contained' implementation of parallel processing. For example, with pathfinding something like:
- "This is the list of all the units who need a path calculated"
- Pause the main thread
- "N worker threads, divide up this list and crunch through them. Your answers will be aggregated." where N is a fixed, small number
- Resume the main thread after all units have their paths assigned
Logged
Military Training EXP Analysis
Congrats, Psieye. This is the first time I've seen a derailed thread get put back on the rails.

Orange Wizard

  • Bay Watcher
  • mou ii yo
    • View Profile
    • S M U G
Re: My friend doesn't understand how resource intensive Dwarf Fortress is.
« Reply #27 on: March 30, 2016, 07:56:41 am »

Incidentally, Toady has said there are better ways to implement pathfinding than what he's done so far, and it could stand to be improved.
Probably involving chucking it onto a separate thread, really, but it's not like the algorithm itself is as efficient as can be.
Logged
Please don't shitpost, it lowers the quality of discourse
Hard science is like a sword, and soft science is like fear. You can use both to equally powerful results, but even if your opponent disbelieve your stabs, they will still die.

PatrikLundell

  • Bay Watcher
    • View Profile
Re: My friend doesn't understand how resource intensive Dwarf Fortress is.
« Reply #28 on: March 30, 2016, 08:59:56 am »

So to summarise the ‼XXMangled Horse CorpseXX‼, a proper multi-threading re-write looks prohibitively time-expensive. But extremely localised areas of code might (would need to be measured) see an improvement with a 'contained' implementation of parallel processing. For example, with pathfinding something like:
- "This is the list of all the units who need a path calculated"
- Pause the main thread
- "N worker threads, divide up this list and crunch through them. Your answers will be aggregated." where N is a fixed, small number
- Resume the main thread after all units have their paths assigned
You could do it that way, or you could just have one path finding thread, one distant world event thread, one... and send these off to do their thing while the main thread continues on, reach the collation phase of the main thread, verify the paths selected and recalculate if failed apply and continue. That approach requires any changes to the fortress used by other threads to be thread safe, though (the change resulting from channeling away a wall should cause the pathing thread to either make use of the tile as blocked by a wall or removed to create a path, not mid way through the changing of the state, possibly resulting in a program termination). From this perspective, the "divide-and-conquer while I wait" approach is easier and safer (the path finding threads are all reading a frozen common state, but not changing anything), but requires you to either use a rather conservative value for N, or determine a suitable number on DF program start based on the computer it's run on. It also hinges on the number of paths to calculate each tick is usually at least 2 and frequently N for a fairly large fortress e.g. during a siege.

Incidentally, Toady has said there are better ways to implement pathfinding than what he's done so far, and it could stand to be improved.
Probably involving chucking it onto a separate thread, really, but it's not like the algorithm itself is as efficient as can be.
This is a rather important point. Before optimizing the code to be as efficient as possible, you should optimize the algorithm, as the gains there usually are much greater than anything code optimization can ever provide. Algorithm implementation also matters (iterating over a matrix column first or row first can matter a lot: if you iterate in the order the data is laid out in memory the next element is usually in the cache and quickly available, and on a cache miss several elements are usually fetched, while iterating with swapped indices can cause every read to be a cache miss if the data structure is large enough).
Logged

Psieye

  • Bay Watcher
    • View Profile
Re: My friend doesn't understand how resource intensive Dwarf Fortress is.
« Reply #29 on: March 30, 2016, 10:01:01 am »

... That approach requires any changes to the fortress used by other threads to be thread safe ... From this perspective, the "divide-and-conquer while I wait" approach is easier and safer ... but ...
Aye, I proposed the "just wait until the threads are all done" approach with safety and ease in mind - Toady doesn't have experience with multi-threaded coding/debugging and whatever time he spends getting to grips with it will be time he can't chip away at his long To-Implement list. Though ongoing world gen probably should be on its own thread anyway as most of the time the main thread won't care what's happening outside your own fortress.
Logged
Military Training EXP Analysis
Congrats, Psieye. This is the first time I've seen a derailed thread get put back on the rails.
Pages: 1 [2] 3