I'm not the most intimate with computer workings, but isn't the main issue with DF processing speed, not really the memory size? Does this change have any worthwhile effect on speed?
So, to clarify, this change will help curb some woldgen crashes for very large, old worlds? That's much more relevant and probably should have been made very clear. As it stands, the actual purpose of this project wasn't made clear, only that it had been done.
World gen will probably be effected, indeed.
I've said this many times, and I know Toady doesn't particularly agree, but it'd be perfectly happy to see him take a year or two out to rebuild the game multithreaded... :p
Quite. From a technical standpoint, there are no two actions that can run without interacting with each other, other than the game itself / the graphics, which are already on their own threads.
Thread collision (when multiple threads that can potentially interact with each other inevitably modify the same thing at the same time -- like kids who don't know how to share a toy) rectification creates a much larger problem than the multithreading would solve.
I am not experiencing any issues with RAM during world gen, as previously predicted. The issue seems entirely processor-related. At any given time during world gen, I am max on one of my cores.That's not what the problem with RAM is.
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.
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.
Which index file?
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.
Would there be any reason to do this if you have 1GB RAM but 5GB virtual memory?
1GB RAMholy shit
I seem to recall Toady stating somewhere that an experimental 64-bit build was in the cards soon. That was on the same level as finishing plants and trees and adding job priorities, so it hopefully wouldn't be a year or two away in a major release.Yeah, he mentioned it in the last monthly summary update IIRC.
hello! thnak you for your effort on this! do you know how can I use or of it is possible to use this on the Old genesis mod made by Deon and continued by TomiTapio?That download is for DF v34.04, OldGenesis is now in DF v44.12 which has major changes in the code.
Because a just dropped both files, the SDL and the Legacy exe on the folder, both in seperate ocasions, and they dont work :(
http://www.techpowerup.com/forums/threads/large-address-aware.112556/to get the program that made the download in the first place. Grab the first or second attachment depending on whether your computer has .NET Framework v4.5(then grab the second) or not(get the first). Use the program as directed.