Print

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

[ab9rf]

#1 was actually map block processing, which included spatters and... temperature.

contaminant processing has been known to be a lag source for a while now, and i suspect it actually drags more than temperature, since temperature is just two ints in the map data block, while contaminants are vectors of pointers so there's not going to be any cache coherency

[TDSS02]

Source: I actually profiled the game, which is the only way to actually determine what is slow in a program.

Pathfinding is slow, yes. It's hilariously slow. The thing is, it doesn't happen often at all. When it does, fortresses drop to sub-single-digit FPS levels. This usually happens because you're using tightly closed doors. Don't do that.

Pathfinding happens so rarely that my profiling has shown it contributes to about 6% of an individual tick's processing time. This is compared to the largest cause, one whose contribution to total CPU usage actually grows faster than pathfinding and one that is still the slowest thing in early game: units checking other units for line-of-sight/proximity checks (running away from hostiles etc), which is more like 20%. The truth is that FPS death is not a matter of multithreading pathfinding or anything like that, it's a combination of just about everything in there.

Not to say there isn't some major high-level optimizations to be made. A lot of the CPU time in unit checks is wasted in branch misprediction due to the fact that it's checking the units vector and just skipping everything that happens to be inactive/caged/a ghost; if those units' indices (or pointers to them, as the case happens to be, unfortunately) were simply cached in a vector that contains only active/uncaged/non-ghostly units, that would be avoided and the game would probably run quite a bit faster.

In general, just, like. Trying to optimize a program without profiling is just... blind flailing at nothing of consequence. If you want to contribute to figuring out what is causing FPS issues, first you have to figure out how to actually use the tools that let you find out what's causing FPS issues. I don't know if this is a gatekeepy viewpoint, but I've seen people so hyperfocused on pathfinding, which does not cause FPS issues except in extreme edge cases and tightly-closed door mishaps, that they seem to be convinced that fixing the pathfinding will fix the FPS issues.

It won't. Pathfinding is not a major contributor to FPS issues. Sorry, people have just been wrong about this the whole time. You can get an FPS boost from fixing up pathfinding a bit--6% is 6%, reducing that helps!--but FPS death will set in just as it does now, even with magic oracle pathfinding that takes 0 time. It's not a pathfinding issue.

If I seem bothered by this, it's because I pondered the pathfinding a good deal too before I actually bothered to do the bare minimum work in actually figuring out why the game runs slowly and learned that, no, pathfinding has basically nothing to do with it. I literally had to be handed a save that had a pathfinding edge case (24 tightly-closed doors) before I even found the pathfinding function, since it's buried so deep due to its, again, not being a major use of CPU time.

Sorry for my ignorance but when you say "tightly-closed door mishaps" what does that mean?

[brushapocalypse]

Sorry for my ignorance but when you say "tightly-closed door mishaps" what does that mean?

With a built door, you have the option to close it tightly so that animals cannot go through it but dwarves and other sapient creatures can. However, animals don't treat tightly-closed doors as walls like you might assume, but will instead use the same pathfinding as creatures that can go through them. This results in creatures clustering around tightly-closed doors, unable to get through and spamming the same attempted pathfinding every single frame. This might not be a problem with one or two doors that get the occasional pet stuck on them, but if you have, say, a room full of dozens upon dozens of turkeys all fighting to get through a door, or if every single one of your doors is tightly locked, that can cause problems.

[TDSS02]

ohh ok. I understand. So when someone says tightly closed they are basically saying a locked door. I thought it was some command or feature I was missing lol. Thank you my friend.

[Putnam]

Not locked. Tightly-closed doors were removed in the steam version, I assume because they were the single largest cause of FPS death by a huge margin, so you won't find the option there. They let creatures who can open doors through but not creatures who cannot, which is most animals.

Also,

Sorry for my ignorance but when you say "tightly-closed door mishaps" what does that mean?

With a built door, you have the option to close it tightly so that animals cannot go through it but dwarves and other sapient creatures can. However, animals don't treat tightly-closed doors as walls like you might assume, but will instead use the same pathfinding as creatures that can go through them. This results in creatures clustering around tightly-closed doors, unable to get through and spamming the same attempted pathfinding every single frame. This might not be a problem with one or two doors that get the occasional pet stuck on them, but if you have, say, a room full of dozens upon dozens of turkeys all fighting to get through a door, or if every single one of your doors is tightly locked, that can cause problems.

Not every frame, more like every 10 frames. Pathfinding is very, very slow, it's just not done often.

[TDSS02]

Not locked. Tightly-closed doors were removed in the steam version, I assume because they were the single largest cause of FPS death by a huge margin, so you won't find the option there. They let creatures who can open doors through but not creatures who cannot, which is most animals.

Also,

Sorry for my ignorance but when you say "tightly-closed door mishaps" what does that mean?

With a built door, you have the option to close it tightly so that animals cannot go through it but dwarves and other sapient creatures can. However, animals don't treat tightly-closed doors as walls like you might assume, but will instead use the same pathfinding as creatures that can go through them. This results in creatures clustering around tightly-closed doors, unable to get through and spamming the same attempted pathfinding every single frame. This might not be a problem with one or two doors that get the occasional pet stuck on them, but if you have, say, a room full of dozens upon dozens of turkeys all fighting to get through a door, or if every single one of your doors is tightly locked, that can cause problems.

Not every frame, more like every 10 frames. Pathfinding is very, very slow, it's just not done often.

ohhh now i understand. Thank you kind sir!

[brushapocalypse]

Not every frame, more like every 10 frames. Pathfinding is very, very slow, it's just not done often.

My mistake! I am demonstrably not an expert on the matter. Anyhow your profiling has been quite illuminating and I'll be sure to take this thread into account in future fortresses.

[Miuramir]

...
Sorry if this is a bad suggestion I seldom stray this close to bare metal. IDK if it would play nice with the crazy optimisations CPUs do nowadays.

You (and others in this thread) may be interested in 700,000 lines of code, 20 years, and one developer , an interview by the Stack Overflow blog folks with Toady about a year ago in which he talks about some of the internals, the difficulty with getting optimization higher than what it already is, and a little about caching / cache miss issues. 

[Findulidas]

Do animals cause as much drain as dwarves from this then?

[ANickel]

If you've profiled, can you tell how much the world size actually effects FPS?  I've always felt that might be more superstition, but don't have the technical know-how to check.

[Bumber]

I was doing some disassembling (v0.47.05) and noticed the pow function being called on constant doubles (and then rounded down into integers for length and area) at runtime for material physics stuff. Not sure how much this was being done outside of where I observed it (body part constructor,) but hopefully upgrading the compiler optimized that away.

[feorh]

I returned to the game after 10+ years of hiatus and had to deal with the fact that my pc from 2018 is as bad at running DF as my pc from 2003

[Magmacube_tr]

I returned to the game after 10+ years of hiatus and had to deal with the fact that my pc from 2018 is as bad at running DF as my pc from 2003

I am so sorry, but lol.

[ab9rf]

I was doing some disassembling (v0.47.05) and noticed the pow function being called on constant doubles (and then rounded down into integers for length and area) at runtime for material physics stuff. Not sure how much this was being done outside of where I observed it (body part constructor,) but hopefully upgrading the compiler optimized that away.

no it's still there; that code is computing a cube root and there is not much the compiler can do to optimize it away. fortunately, that code doesn't appear to be called all that often so it likely has only a minimal impact on performance.

[Bumber]

no it's still there; that code is computing a cube root and there is not much the compiler can do to optimize it away.

It should be able to optimize trunc(pow(70000.0, 0.333) * 10.0) to 410, provided those functions are constexpr. (All values are being loaded from rdata into xmm, DF 47.05 Windows.)

For materials where the values are runtime (loaded from RAWs,) obviously it can't. I was just thinking that this might be typical in other avoidable places, v141_xp toolchain being what it is.