DF could be partly multithreaded with fork-join or task pool methods. Each frame is does some calculations: temperature, weather, fluid movements, pathfinding, creature movements, and so on. Some of these can be partitioned, done in parallel, and finished before moving to the next phase. I cannot tell anything about effort / speedup tough. When I played with multithreaded matrix computations the speedup I got was small.
I've noticed that the Dwarf Fortress decompilation thing that's going on has made a considerable amount of progress. I'm wondering whether it might be possible to produce a hack to allow multithreading to at least a small degree? I am aware the amount of effort may be just too big for people to handle.
Same question goes for 64bit.
64-bit might sort of be doable, but would still be an enormous undertaking. Theoretically you could disassemble DF and replace any memory accessing instructions to use 64-bit addressing instead of 32-bit, and modify it so that pointer calculations use 8-byte pointers instead of 4-byte. Then you'd need to modify any allocations to use 8-byte pointers, and any code that accessed any data structures would need to account for increased pointer sizes... okay, probably not practical at all. Unless you
were able to decompile DF into higher level code that could recompile it in 64-bit, but you'd probably run into big problems with any libraries which I imagine is why Toady hasn't done this already.
Multithreading would probably be out of the question even if you could decompile it. It's almost certainly
doable, but by the time you figured out how to get it working with any speedup the next version of DF would likely be on the horizon and invalidate all of your work. Race conditions are not a thing to be trifled with when debugging multithreaded code, and that's with proper, not decompiled, code.
Author
Topic: Dwarf Fortress - Large Address Aware (Or, let DF use up to 4GB of RAM!) (Read 45821 times)