Bay 12 Games Forum

Please login or register.

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

Author Topic: Multhreading Dwarf fortress  (Read 13451 times)

NW_Kohaku

  • Bay Watcher
  • [ETHIC:SCIENCE_FOR_FUN: REQUIRED]
    • View Profile
Re: Multhreading Dwarf fortress
« Reply #30 on: March 30, 2011, 12:19:38 pm »

About A* pathfinding complexity: The growth of complexity of A* is linear when you are just adding dwarves or other pathfinding creatures.  Having 20 pathfinding creatures takes twice as long as having 10 pathfinding creatures.

The thing is, A* pathfinding gets harder to do as you dig out a larger fortress for those new units.  Now, you have twice as many creatures pathfinding through twice as much space.  And that space becomes more complex, as well - an early pathfinding "mistake" of pathing down a dead-end hallway or into a bedroom is quickly overcome, but the longer and more serpentine your fortress becomes, the more likely it is you are going to get stuck pathing down long dead-end hallways and rooms. 

You obviously can't make a hard-and-fast complexity number for the size of a fortress, since a lot depends on the way in which players lay out their fortress, but the larger it is, the more complexity it tends to introduce, and that complexity can often be in greater-than-linear growth. 

Also, just to mention something else, the game supposedly crashes if you try to embark on a full 16x16 with standard cavern sizes now, since it exceeds 2 gigs of memory, and without 64bit processing, that's the cap.  So there's something else Toady would be better off doing before he tried multithreading...

You don't think so?

More and more people are going to have multi-core CPUs, and the individual cores in those CPUs will be getting slower and slower. DF is going to run worse and worse - in particular, the pathfinding is going to get slower and slower, not faster.

Pathfinding takes almost no processor time at all (it's really just basic addition and comparison - absurdly easy math for a processor).  The entire reason why pathfinding takes up time is because it has to access several megs of map data from memory, one tile at a time.  And most of that data is contained through a complex series of vectors with difficult-to-guess points in memory.  That means that the game is slowed down by memory access speed, and the processor speed has almost nothing to do with it.
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

Capntastic

  • Bay Watcher
  • Greetings, mortals!
    • View Profile
    • A review and literature weblog I never update
Re: Multhreading Dwarf fortress
« Reply #31 on: March 30, 2011, 12:28:20 pm »

And he's going to have to do it eventually.

This isn't actually true.  And I myself personally agree that multithreading would be a good thing.

You don't think so?

More and more people are going to have multi-core CPUs, and the individual cores in those CPUs will be getting slower and slower. DF is going to run worse and worse - in particular, the pathfinding is going to get slower and slower, not faster.

Individual cores aren't going to become slower, so much as the focus of development will be on more cores in general.  But even so, what does that have to do with Toady 'having' to do anything?  Toady has acknowledged the issues at hand- I guarantee that he's weighed things out far more than anyone in the thread- and he simply isn't confident at this time to implement multithreading in a fruitful way.
Logged

zncon

  • Escaped Lunatic
    • View Profile
Re: Multhreading Dwarf fortress
« Reply #32 on: March 30, 2011, 03:54:54 pm »

Pathfinding takes almost no processor time at all (it's really just basic addition and comparison - absurdly easy math for a processor).  The entire reason why pathfinding takes up time is because it has to access several megs of map data from memory, one tile at a time.  And most of that data is contained through a complex series of vectors with difficult-to-guess points in memory.  That means that the game is slowed down by memory access speed, and the processor speed has almost nothing to do with it.

I'd like to see a bit more testing done before I believe this. If no one else already has, I'll do a few benchmarks with my RAM clocked slower/faster. Anyone else interested in seeing the results of that?
Logged

Artanis00

  • Bay Watcher
    • View Profile
Re: Multhreading Dwarf fortress
« Reply #33 on: March 30, 2011, 04:28:02 pm »

Pathfinding takes almost no processor time at all (it's really just basic addition and comparison - absurdly easy math for a processor).  The entire reason why pathfinding takes up time is because it has to access several megs of map data from memory, one tile at a time.  And most of that data is contained through a complex series of vectors with difficult-to-guess points in memory.  That means that the game is slowed down by memory access speed, and the processor speed has almost nothing to do with it.

I'd like to see a bit more testing done before I believe this. If no one else already has, I'll do a few benchmarks with my RAM clocked slower/faster. Anyone else interested in seeing the results of that?

You're considering testing something related to DF. As far as I'm concerned, this falls under !!SCIENCE!!, so we absolutely want to see the results.
Logged
Git - fast, efficient, distributed version control system
Github - Free public repositories, issue tracking, wikis, downloads...

zncon

  • Escaped Lunatic
    • View Profile
Re: Multhreading Dwarf fortress
« Reply #34 on: March 30, 2011, 04:31:02 pm »

Okay, deal. Any constraints/variables I should look at specifically? I know I can adjust both freq. and timings on my RAM.
Logged

Niseg

  • Bay Watcher
    • View Profile
Re: Multhreading Dwarf fortress
« Reply #35 on: March 30, 2011, 04:53:01 pm »

I have benchmarked the game already using a save with 200 dwarves or so (can't recall l#'s) and a flying circus with a freak show.

I kept killing the game to have same conditions every time. I kept fsb of my Q6600 @ 367MHz. and changed the multiplyer from 9 to 7 . I noticed that fps degraded accordingly.

I think it was the difference between 33fps and 26fps. this is practicaly the speed my cpu was running at if you divide by 10 and put GHz next to it.

I appologize for spelling.  I am posting from an Android pda.
Logged
Projects:Path finding simulator(thread) -A*,weighted A*(traffic zones), user set waypoints (path caching), automatic waypoint room navigation,no-cache room navigation.

zncon

  • Escaped Lunatic
    • View Profile
Re: Multhreading Dwarf fortress
« Reply #36 on: March 30, 2011, 05:22:43 pm »

This test would be more focused on the effects of RAM speed then processor.
Logged

profit

  • Bay Watcher
  • Finely Crafted Engravings... Or it didn't happen.
    • View Profile
Re: Multhreading Dwarf fortress
« Reply #37 on: March 30, 2011, 06:08:14 pm »

For all those who say memory bottlenecks are the stumbling point.. I just opened up performance monitor, added memory reads and writes.. and processor information.  Tested what it was under maximum memory load using passmarks burn in program. 

Compared to the maximum throughput of my memory as shown in performance monitor dwarf fortress uses about 1/18th of the available bandwidth. *edit bad eyes, commas look like periods. This has been corrected*

Processor usage is of course a full core though.

I do not think memory is the bottleneck. 

Dwarf Fortress has a memory access of about 1,600 pages a second,  when I use passmark it runs at 27,000 pages/second.
« Last Edit: March 30, 2011, 06:57:02 pm by profit »
Logged
Mods and the best utilities for dwarf fortress
Community Mods and utilities thread.

zncon

  • Escaped Lunatic
    • View Profile
Re: Multhreading Dwarf fortress
« Reply #38 on: March 30, 2011, 06:10:08 pm »

!!Results!!
DF Benchmarking - RAM Speed

Bench marked System
AMD Phenom II x4 955 Black @ 3.20 GHz
16GB DDR3 RAM @ Listed Speeds
Nvidia GeForce GTX 460 SE 1GB GDDR5

Identical Saves over a one minute period.
95 Dwarfs
0-5 Idle


Timings:   7-7-7-21
Freq.      1333 Htz
49-57 FPS

Timings:   9-9-9-27
Freq.      1333 Htz
49-55 FPS

Timings:   9-9-9-27
Freq.      1066 Htz
46-51 FPS

It seems that timings have very little effect on FPS, however the frequency does seem to matter a bit, with a loss of 3 FPS on the low end, and 4 FPS on the high end.
« Last Edit: March 30, 2011, 06:41:27 pm by zncon »
Logged

profit

  • Bay Watcher
  • Finely Crafted Engravings... Or it didn't happen.
    • View Profile
Re: Multhreading Dwarf fortress
« Reply #39 on: March 30, 2011, 06:53:47 pm »

Make sure you are not accidentally lowering your processor speed when you change the memory speed. make sure you up the processor multiplier to keep it constant.
Logged
Mods and the best utilities for dwarf fortress
Community Mods and utilities thread.

zncon

  • Escaped Lunatic
    • View Profile
Re: Multhreading Dwarf fortress
« Reply #40 on: March 30, 2011, 07:19:01 pm »

The BIOS automatically adjusted that when I lowered the memory speed. I verified that everything else was consistent after I made each change.
Logged

NW_Kohaku

  • Bay Watcher
  • [ETHIC:SCIENCE_FOR_FUN: REQUIRED]
    • View Profile
Re: Multhreading Dwarf fortress
« Reply #41 on: March 30, 2011, 08:21:54 pm »

Pathfinding takes almost no processor time at all (it's really just basic addition and comparison - absurdly easy math for a processor).  The entire reason why pathfinding takes up time is because it has to access several megs of map data from memory, one tile at a time.  And most of that data is contained through a complex series of vectors with difficult-to-guess points in memory.  That means that the game is slowed down by memory access speed, and the processor speed has almost nothing to do with it.

I'd like to see a bit more testing done before I believe this. If no one else already has, I'll do a few benchmarks with my RAM clocked slower/faster. Anyone else interested in seeing the results of that?

I see you've already gone ahead and done a test (and good for you for doing so), but I'd explain my reasoning for saying what I said, anyway...

This link is a (fairly easy-to-read) description of how A* pathfinding works.

Now, A* pathfinding is actually fairly simple - you just add the traffic weight of a given tile plus what the heuristic says is the distance from the tile you are about to test pathing onto, and compare that to all the other tiles.  That's just simple addition and comparison. 

The thing that makes A* pathfinding take so long is that in a maze like the sort of thing that most player forts become, A* will often run into a dead end, and wind up going through every single tile in the entire area before finding its way around a given wall - that means it's accessing the data of every single tile in the entire area.  That's potentially thousands of checks to memory - per unit pathfinding - and because we are dealing with a series of vectors storing the map data, it is very difficult to make a guess as to what parts of memory you need to access next.

What's behind pathfinding in tying up system resources?  Temperature checks on every single item on the map - tens of thousands of items on some maps, all need to be checked for their temperatures every frame, which is up to 100 frames per second.  Most temperature checks don't even DO anything, and the few that do only change a small amount of data per frame.  You're just iterating through pieces of data, performing a few simple comparisons, then dumping that data, and fetching the next from memory.

So, to go back to pathfinding, the problem with pathfinding, and the reason why people want to improve the pathfinding algorithm isn't that the current A* pathfinding requires crunching way too many numbers, it's that it requires accessing memory far too often looking up bad paths that turn out to be looking for a way to get to the central staircase by going into someone's bedroom, only to find out it's a dead end, then going into the next bedroom, finding out THAT'S a dead end, going to the next bedroom, etc. etc. etc. 

It's a problem of the game checking a huge number of individual tiles that it doesn't need to check, and each one of those checks forcing the CPU to queue up another call on the memory for the next set of tiles. 

Now, if memory bandwidth isn't being fully used, as Profit says, my best guess is it's because the computer can't speculate on what data it will need to access next (at least as far as pathfinding goes), so it can't take up all the memory bandwidth in one access of memory, and is waiting on what's actually in the memory that the game reads to tell it where to look next in memory.  (Which is something that can be helped by multithreading if you just make more than one creature pathfind at the same time, but it still is also something where just making memory access faster results in faster performance.)

The bottleneck is still the processor reading one piece of data, realizing it needs to fetch a new piece of data, and putting the process on hold until the fetch is complete. (Slicing to another thread at that point.) It has to go to RAM because you're never going to have a cache big enough for the sorts of things DF is going to process every frame, and because we are dealing with vectors, it's just plain going to be slower to access RAM.  (And RAM access speeds are laughably slower than CPU speeds.)
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

profit

  • Bay Watcher
  • Finely Crafted Engravings... Or it didn't happen.
    • View Profile
Re: Multhreading Dwarf fortress
« Reply #42 on: March 30, 2011, 08:30:23 pm »

I am fairly certain there is a pattern used for temperature calculations and flows.   If you cheat in a large block of water above the ground, you can see it takes about 100 frames for it to all fall, and when it does it falls in a certain pattern.  Probably to save processor time, and yes, spare a ton of memory reads.  I can only assume temperature is checked based on that same pattern.

Just thought of something though my memory tests were with temp off in D_init.txt because it slows things down so terribly.  Maybe with that on memory reads and writes would go up massively.


Logged
Mods and the best utilities for dwarf fortress
Community Mods and utilities thread.

NW_Kohaku

  • Bay Watcher
  • [ETHIC:SCIENCE_FOR_FUN: REQUIRED]
    • View Profile
Re: Multhreading Dwarf fortress
« Reply #43 on: March 30, 2011, 09:00:06 pm »

I've watched a fluid flow frame-by-frame before - I know they don't actually check every tile every frame.  In fact, it takes about 60 frames before the water even realized I had mined out a hole for the water to escape to (giving the miner plenty of time to run), and then taking about a dozen frames after that to start flowing into individual tiles. 

I had just assumed it was random directionality, but maybe it checks for certain directions on certain frames?  That could potentially make sense. 

The check merely seems to be a matter of testing if the tile of fluid doing the checking (let's call it "A") has more fluid than the target tile (let's call it "B").  And if A > B, then (A-B)/2 + 1 fluid is transferred.  This can easily wind up having a 3/7 and 2/7 constantly toss a single unit of water back and forth.  Sometimes, it seems to toss that unit of water back and forth a couple of times before it realizes there are 0/7 or 1/7s right next to them.
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

profit

  • Bay Watcher
  • Finely Crafted Engravings... Or it didn't happen.
    • View Profile
Re: Multhreading Dwarf fortress
« Reply #44 on: March 30, 2011, 09:16:49 pm »

It is definitely a pattern, water will fall in diagonal lines.   Looks like 1 falls 10 not, 1 falls 10 not with the next line the tile that will fall is shifted one to the right.

Logged
Mods and the best utilities for dwarf fortress
Community Mods and utilities thread.
Pages: 1 2 [3] 4