Print

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

[lethosor]

It won't directly help performance, but the new compiler required for getting 64bit to work will help performance a little in both 32 and 64bit

Quietust says that MSVC 2010 can handle 64-bit builds. Did Toady say he's actually using a newer compiler? (I remember him mentioning trouble getting it to work a few months ago, but he could have worked around that.)

[4kn]

as for me - this is one of the best games ever, but the problem of fps death even on top builds ruins it all. multithreading is the only way to save this precious gem. i think toady should found a separate fund to support transition of the game to multithreading.
i'm no specialist in this technical stuff, but i think those funds could be spent on outsourcing some tasks, yet i've heard that recompiling a code to multithread could be made semi-automatically

1. Multithreading would maybe double performance. The very best case is hextuple. This makes FPS death go from 15 FPS to 30 FPS. Assuming some magical performance-multiplying solution, 15 FPS becomes 90 FPS, which is still slower than expected.

are you telling me there's no way out?

[Putnam]

Algorithmic improvements are always underestimated. Pathfinding has much to be improved IIRC; from what Toady's said, it seems to be a really basic A* thing that's not at all designed for the very large complicated graphs that DF's maps are.

[TheBiggerFish]

I'm goimg to PTW this.

[Miuramir]

As several others have said, the primary benefit of a 64-bit DF is that it will directly permit larger worlds.  Several versions back there was one that slammed against the 2 GB (Windows) barrier hard, and Toady had to re-optimize to fit things in a more space-efficient manner.  But there's only so much diminishing returns you can get from such things; and in some cases optimizing for space can result in slower execution times. 

Slightly less directly, I suspect that the "world coming alive", with complex diplomacy and in particular trade, will eventually require more information kept track of than will be practical for a 32-bit application to keep in its very limited RAM.  The forward evolution of DF keeps track of more things as it adds features, and more things equates generally to more memory footprint.  There will probably come a day when users with 32-bit OSs and/or with 4 GB or less RAM will only be able to run smaller and/or simplified worlds; perhaps not "soon", but eventually. 

There are some possible tertiary benefits; much of the attention in modern CPUs and compilers is on the 64-bit side, so in the long run better tools help with a better product.  There may be cases where speed increases can be had by throwing memory at optimization problems, and so on. 

Hopefully, at some future point DF will become usefully multi-threaded; if for no other reason that *eventually* that will become something that compilers can do more or less on their own.  At that point, one starts to be concerned about memory per core and not just the overall total; and it's much easier to keep track of when you have a large address space. 

[reality.auditor]

Hopefully, at some future point DF will become usefully multi-threaded; if for no other reason that *eventually* that will become something that compilers can do more or less on their own.

I think you have better chance for AI writing programs themself than something that will be capable of making multi-threaded program from single-threaded code.

[mifki]

Algorithmic improvements are always underestimated. Pathfinding has much to be improved IIRC; from what Toady's said, it seems to be a really basic A* thing that's not at all designed for the very large complicated graphs that DF's maps are.

It seems to me that pathfinding is only a small part of what it does each frame. When there are tens of thousands of units+buildings+items to do some processing for each of them each frame, plus temperature and flows calculations, it won't be fast. I think the key here is to use more flags to specify what needs to be updated the next frame and what doesn't (and I think pathfinding isn't updated each frame even now). Currently I see almost all the changes to df data I do with dfhack have immediate effect, even those which normally can't happen without UI actions (and therefore can be tracked).

[lethosor]

Are you saying DF performs calculations when paused or just renders the data you change immediately? If it's the latter, it shouldn't have a noticeable impact on performance unless DF uses significant resources when paused, which it usually doesn't. (For example, changing a unit's name usually requires UI action, but is reflected immediately when done with DFHack; however, keeping track of whether each unit's name could have been changed through the UI and only updating it on-screen when that's the case is likely to be less efficient and/or far more complicated, and the time taken to actually display the name is negligible.)

[Putnam]

Algorithmic improvements are always underestimated. Pathfinding has much to be improved IIRC; from what Toady's said, it seems to be a really basic A* thing that's not at all designed for the very large complicated graphs that DF's maps are.

I think the key here is to use more flags to specify what needs to be updated the next frame and what doesn't

it already does that

[lethosor]

To an extent, yes. Angavrilov has found a few functions that could probably benefit from that, though.

[miauw62]

Really, there's absolutely no connection between multi-threading and 64bit.

Yeah, I didn't mean to imply there was. Sorry!

[Jay]

Virtually nothing happens while paused, that's a non-starter. The graphics are already parallel.

Everything is being iterated on in any given frame. This is why atomsmashing things tends to improve FPS vs just getting rid of it via other means; it completely ceases to exist.
Smarter sleeping would help a bit, but that's still not multi-threading, and no matter what there'll still be quite a number of calculations on any given frame.
If two threads try to modify the same data at the same time, bad things happen. So, you have a huge list of things to go through, and virtually all of it relies on the other calculations you need to do. How do you determine what you can do in parallel safely and what you can't? How do you get it to happen without cores endlessly waiting for each other to finish their jobs?

Multi-threading is hard. Like, really, really, hard.

[Flarp]

I think what's most likely is the code review required to transition to 64-bit will result in some modest optimizations just from Toady updating legacy code.

[Kumquat]

I don't think that there would really be very much speedup available from multithreading. Much depends on what kind of memory access patterns there are. If they are all over the place then it will be mostly bound by memory access. For instance you can have a list of dwarfs which each have pointers to each of their organs and the program updates each dwarf, organ by organ. Or you can have, say, a linear list of all livers in the fortress which can be updated each in a row; that way there is only a very tight loop that (hopefully) fits in the processor's L1 cache, and with a linear list the processor can guess which data is needed next and gets it in cache so that the code won't need to wait for it.

The latter approach is less intuitive to program but frequently 2x to 10x faster.

However that is just a small trivial example and there are certainly bigger fences to tackle. Converting a large codebase to work at 64-bit can be a huge undertaking. As for multithreading, if there are sufficiently isolated sections those could be made multi-threaded "easily". For instance world history. Dwarf mode has relatively small interaction with it frame-by-frame; only remarkable events need to be added, some events need to be chosen for art. World update could run in another thread, then, injecting its own generated events while most of the worldgen data would remain irrelevant and inaccessible to the common dwarf. All s/he knows is some of the history.

[Devast]

What timeframe would it take roughly for a 64bit or even a multithreaded version to be released?
I agree with an above poster that while there are amazing new features each update, performance issues are really the biggest thing holding down my enjoyment of the game.