Print

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

[Hammurabi]

Hot tip: I see many players using stacked up/down staircases. FYI, these kill your FPS. Ramps are extremely FPS friendly on the other hand.

Why?  Ramps and Stairs are just different names for connecting z-levels, regarding pathing.  IMO, stairs being massively slower than ramps is a bug.   

[gtmattz]

4 things I do to save FPS:

• Embark on 3x3 or smaller areas. The new features really don't need any larger.
• Set up smart burrows to restrict accessibility and thus reduce pathfinding load.
• Use ramps instead of stairs whenever possible.
• Avoid large amounts of flowing liquids if possible.

[Urist McDepravity]

Just tried to callgrind one of my bigger forts with that binary with symbols.
80.9% time - moveunits()
74% time - moveunit() (called from moveunits())
15.58% time - update_health() (called from both moveunit() and moveunits())
4.45% time - shoulddie()
5.57% time - contaminant_advance()
4.46% time - assignjobs_des()
1.75% time - advancebuildingstates()

I'm too lazy to properly analyze results right now (there are about 2000 functions), but even quickly looking at results i see that healthcare is definitely eating more than it should, for example. And moveunit() has very obscure call-graph, seems it triple-checks each path before actually moving.
So as i said before, theres alot of space for optimization even with single-threaded style and same pathfinding

[Hyndis]

I think it depends on whether or not Toady wants to go for a simpler Dwarf simulation - for example, overtly complicated temperature calculations are clearly a huge drain on CPU, turn it off on your 100 dwarf fortress and see - and past updates don't point to this being the direction he wants to go. Certainly end-game needs urgent fixing for this very reason.

This.

A lot of times you just need to abstract away certain things, using a model that approximates the result, but gets the result with a much simpler albeit less accurate method.

The end result might be 20% less realistic, but 90% more efficient in terms of processing power. While the detail of each individual thing drops slightly, it at least gets done more or less accurately but then frees up a huge amount of processing power that can be used on other things instead.

Memory leaks are another huge issue. AFAIK, you can have a fortress run at the same speed forever so long as the fortress remains idle. FPS shouldn't drop unless you're digging out new areas that can be pathed to or creating new items that can also be pathed to. DF does have the potential for memory leaks though. Remember those goblins you killed in the fall of 1050? They're still on your units listing even if it happens to be the year 1150. Or 1250. They're there forever. With the infinite invasions now this means that as time goes on your units list will become infinitely long. I'm sure thats killing FPS in some way or another.

There needs to be some way to remove dead units from the units list.

[Rafal99]

I really doubt that dead goblins sitting in the unit list have any significiant impact on FPS.

Generally speaking about DF performance I hope Toady's code doesn't contain simple mistakes, that can screw preformance very badly. Things like unnecessary copying of large objects instead of pointers to them for example. This could be the first thing to optimize if such things happen in the code.
Concerning dwarves searching for items, and checking distance to every item, if this is done that way, it should be optimized. Distance calculations should avoid sqrt() which is expensive if they don't already. You can compare squared distances as well as original distances. Checking every item isn't necessary either, you can divide the map into smaller areas containing lists of items inside them, and check the closest areas first. There are things like QuadMap which let you check items from the smaller nearby area first, then progress to larger ones if not found. This is how it is done in games or phisics engines where lots of moving objects iteract which each other. Checking vs every item is usually the least efficient method.
Well these are some things concerning DF performance I was thinking about. It is all very hypothetical, since I have no idea how good or bad DF code is and what methods it uses.

[Makbeth]

[deleted by author]

Is there no way to actually delete posts?

[Morac]

Just tried to callgrind one of my bigger forts with that binary with symbols.
80.9% time - moveunits()
74% time - moveunit() (called from moveunits())
15.58% time - update_health() (called from both moveunit() and moveunits())
4.45% time - shoulddie()
5.57% time - contaminant_advance()
4.46% time - assignjobs_des()
1.75% time - advancebuildingstates()

I'm too lazy to properly analyze results right now (there are about 2000 functions), but even quickly looking at results i see that healthcare is definitely eating more than it should, for example. And moveunit() has very obscure call-graph, seems it triple-checks each path before actually moving.
So as i said before, theres alot of space for optimization even with single-threaded style and same pathfinding

That's some interesting info. I need to try this for myself at some point (maybe make some charts or something).

[Noble Digger]

I'm getting 35+ FPS with 60 dwarves in 31.06. There are some init tweaks you can use that supposedly help with framerate; I'm going to say this once. After disabling these tweaks and making NO OTHER CHANGES, my fort drops to 23 FPS. Print mode: standard

- Changing pathing costs. 1:1:2:5
- Change GFPS to half of FPS cap (I cap regular FPS at 60 and GFPS at 30)

One other final bit of advice that should help every fortress:

- Don't make more stockpiles than you need. Stockpiles constantly search the map for items that are relevant to their interests which is CPU-intensive.
- Never make hallways or staircases that are less than 3 tiles. It doesn't matter how they're arranged (in the case of stairways) just make sure there's enough breadth to all thoroughfares that cats, dwarves, and other animals (and liasons, etc) don't jam each others' way at ANY point in the fortress. Even bedroom hallways with 3-4 bedrooms should be at least 2-wide. Dwarves crashing into each other in narrow hallways and stairs is MURDER on the game's overall speed.
- Do without liquids. It seems like a 1-tile flow of liquid uses about as much CPU power as 10 dwarves.

[Urist McDepravity]

maybe make some charts or something

KCacheGrind produces all kinds of graphs and charts itself, just i'm not sure that Toady would not mind sharing the data.

[madk]

Concerning dwarves searching for items, and checking distance to every item, if this is done that way, it should be optimized. Distance calculations should avoid sqrt() which is expensive if they don't already.

You can easily compare distances with acceptable accuracy just by using only addition, bitshifting, and Abs.

Example:
(Abs(Origin_X-Target_X) Shl 4) + (Abs(Origin_Y-Target_Y) Shl 4) + (Abs(Origin_Z-Target_Z) Shl 12)



Such comparison would be lightning fast, and would rarely assign a dwarf something that is a greater distance away. It would also help to prevent dwarves from thinking something directly above them that may or may not have nearby access is actually closer, though I do think Toady's got that covered with the current system.



How does it work?

Abs(X₁-X₂) makes the number positive. This operation is extremely fast, requiring only 3 opcodes on the x86. Abs(X₁-X₂) will henceforth be referred to as "A".

A Shl Y Is equivalent to A*2^Y. While this is far from a perfect linear distance, it would work
beautifully for mere comparisons. This operation is a single opcode on the x86.

And, lastly, adding the three A values for X, Y, and Z (shifting the bits farther left for the Z axis) is, very obviously, trivial.

Sorry for getting so technical, but if Toady sees this post, he must realize the awesomeness of this method.


ADD IT NOW, TARN! PLEASE!!

[Morac]

Me likes. Noting for future use.

[goffrie]

madk: I believe that that is already essentially what happens. With masonry workshops over layers full of stone, you can see that the masons will collect stones in a square pattern, a characteristic of the Manhattan distance metric.

[Kazang]

4 things I do to save FPS:

• Embark on 3x3 or smaller areas. The new features really don't need any larger.
• Set up smart burrows to restrict accessibility and thus reduce pathfinding load.

• Use ramps instead of stairs whenever possible.

• Avoid large amounts of flowing liquids if possible.

The others are self explanatory but why does ramps instead of stairs help fps?

[Mel_Vixen]

madk: I believe that that is already essentially what happens. With masonry workshops over layers full of stone, you can see that the masons will collect stones in a square pattern, a characteristic of the Manhattan distance metric.

The problem is that toady abandoned manhatten space some while back. A direct diagonal movement is possible and has its own distance.

Well the forum has already a pathing project but has anyone a nice idea for a faster temperature and/or Liquid system?

edit: iirc df does additional checks on stairs (if you fall them down f.e. ) and in the Pathing stairs may be valued differently.

[goffrie]

madk: I believe that that is already essentially what happens. With masonry workshops over layers full of stone, you can see that the masons will collect stones in a square pattern, a characteristic of the Manhattan distance metric.

The problem is that toady abandoned manhatten space some while back. A direct diagonal movement is possible and has its own distance.

Well the forum has already a pathing project but has anyone a nice idea for a faster temperature and/or Liquid system?

edit: iirc df does additional checks on stairs (if you fall them down f.e. ) and in the Pathing stairs may be valued differently.

The closest-item-to-dwarf metric still uses Manhattan distance.

A dwarf's movement ability has little to do with this.