Actually, the overwhelming majority of temperature checks are just "Has anything changed this tick? Nope? OK, then, carry on... NEXT!" Keep in mind that most items are underground where temperature is a constant anytime magma isn't flowing over them, anyway.
A large portion of the game's calculations are the responsibility of various "checks" on all the sundry "items" in the game. Several of us did SCIENTIFIC testing on the subject a few years ago, see:
Operation FPS Bomb. When you have a sufficiently large number of items in the game (possibly enough to start going outside memory cache?) then the game starts slowing down significantly, and because of this, "garbage disposal" and maintaining sane stockpile levels are critical for maintaining FPS.
Other problems are that the modified A* (although it should be noted that it is modified mainly in that standard A* only handles 2d pathfinding) just doesn't handle large open spaces too well, even if they "don't go anywhere". This is mainly because the modified A* has extremely little clue how to find its way through 3d mazes, which are less "obvious" than paths through 2d mazes. Methods like a Vector Pathfinding, or even simple addition of Jump Point Search to A* would be of assistance, by allowing the simplification of large open areas with minimal additional overhead, but Toady has been loathe to dig into alternate pathfinding methods until he comes across problems current pathfinding just can't handle. (Like, say, multi-tile creatures...)
This brings us to the third in the big three FPS killers, connectivity map redraws. The connectivity map is derived from the real map, doing things like declaring any tiles with more than 4/7 water or any magma to be "walls" (actually somewhat clever, because it only has to check two bits) for connectivity purposes, and is used for the modified A* pathfinding. (This is why fliers and swimmers have entirely different, floodfill-based pathfinding, since they cannot rely upon the same connectivity map, and Toady considers those movement types rare enough not to be worth the added lag of making more connectivity maps.) The problem is, these connectivity maps are only effective time-saving measures in a static map, and DF does not have a static map. Fluid motion easily "breaks" the map through dropping water levels below 4/7 then rising back up again, or having magma flow, evaporate, then flow again, etc. The connectivity map can also be broken any time a drawbridge is activated, or other pieces of fortress move, blocking traffic. Once broken, the connectivity map has to be redrawn, and considering the sizable, apparent-to-the-player amount of lag simple drawbridge raisings and lowerings cause, this requires a full-map redraw that produces significant lag if you have continuously moving fluids.
Now then, I'm not educated on GPU threading enough to say whether any of those bottlenecks are significantly faster with GPU threading. I can, however, say that there are some general optimizations that could be made just through rethinking DF's item checks to use schedulers and/or checks to items only when environmental changes are taking place, as well as changing over to the previously mentioned vector-style pathfinding that would obviate the need for connectivity maps in the first place and simplify calculations of large open fields or rooms.
If you want to have a faster computer for DF, incidentally, get a computer with as large a memory cache as possible, and as fast a memory access speed as possible. CPU power doesn't really matter much, because most of what the game winds up slowing down upon tends to be memory cache misses, and waiting upon access to memory. What lags DF are really, really simple calculations that are made randomly upon data tables too large to be cached effectively.
Author
Topic: GPU threading in DF (Read 1712 times)