tell him its single threaded, locked at 2GB ram
When Toady gets around to 64-bit and all of the multi-core CPU goodness that comes with it
Admittedly, DF isn't so much resource-intensive as poorly optimized :( When Toady gets around to 64-bit and all of the multi-core CPU goodness that comes with it, your FPS won't even blink at a mere 100 catsplosion. That said, just tell him about the sheer level of detail involved in this simulation. For example; The game computes every body part, of every creature, in every battle, for the entire length of WorldGen, just in case you want to read about the hilarious and bloody history of your world.
But I don't really get the question...is he mocking you because your computer is having trouble running a game that (according to him) isn't resource intensive? Or is he mocking you because you're playing a game that (according to him) is not resource intensive?
If it's the former, then just pop DF on a usb drive and run it on his computer. That would show him how slow it gets even on his ultra badass rig.
If it's the latter, and the only reason he's turning his nose up at DF is that it's not as resource intensive as the games he plays, then he's a fucking moron anyway and there's no point wasting time on this.
-snip-
Kinda sounds like the longer Toady puts off multi thread support, the harder it'll be to add :-\Pretty much, although it's basically impossible at this point anyway because you'd need to gut and rewrite 10+ years of code.
But wouldn't it be immensely difficult to recode this entire game so that it runs on 64-bit? I mean, change one thing and another 5 bugs pops up somewhere, right?64-bit version is in the works now, and it's hardly rewriting the entire game like multithreading would be. It should speed things up a little, and unlock more memory so paging won't be such an issue.
And since Toady just said that it's mainly badly optimized code (for which he has a fix-list) rather than single core threading that causes fps death it probably won't get done any time soon.-snip-
Kinda sounds like the longer Toady puts off multi thread support, the harder it'll be to add :-\
The best way to demonstrate it to him is take a save of 40 year old fortress with 150 dwarves in it on a good sized embark with a volcano that just breached the circus and install it on his gaming rig and watch it bring his rig to its knees.Sigging this
So to summarise the ‼XXMangled Horse CorpseXX‼, a proper multi-threading re-write looks prohibitively time-expensive. But extremely localised areas of code might (would need to be measured) see an improvement with a 'contained' implementation of parallel processing. For example, with pathfinding something like:You could do it that way, or you could just have one path finding thread, one distant world event thread, one... and send these off to do their thing while the main thread continues on, reach the collation phase of the main thread, verify the paths selected and recalculate if failed apply and continue. That approach requires any changes to the fortress used by other threads to be thread safe, though (the change resulting from channeling away a wall should cause the pathing thread to either make use of the tile as blocked by a wall or removed to create a path, not mid way through the changing of the state, possibly resulting in a program termination). From this perspective, the "divide-and-conquer while I wait" approach is easier and safer (the path finding threads are all reading a frozen common state, but not changing anything), but requires you to either use a rather conservative value for N, or determine a suitable number on DF program start based on the computer it's run on. It also hinges on the number of paths to calculate each tick is usually at least 2 and frequently N for a fairly large fortress e.g. during a siege.
- "This is the list of all the units who need a path calculated"
- Pause the main thread
- "N worker threads, divide up this list and crunch through them. Your answers will be aggregated." where N is a fixed, small number
- Resume the main thread after all units have their paths assigned
Incidentally, Toady has said there are better ways to implement pathfinding than what he's done so far, and it could stand to be improved.This is a rather important point. Before optimizing the code to be as efficient as possible, you should optimize the algorithm, as the gains there usually are much greater than anything code optimization can ever provide. Algorithm implementation also matters (iterating over a matrix column first or row first can matter a lot: if you iterate in the order the data is laid out in memory the next element is usually in the cache and quickly available, and on a cache miss several elements are usually fetched, while iterating with swapped indices can cause every read to be a cache miss if the data structure is large enough).
Probably involving chucking it onto a separate thread, really, but it's not like the algorithm itself is as efficient as can be.
... That approach requires any changes to the fortress used by other threads to be thread safe ... From this perspective, the "divide-and-conquer while I wait" approach is easier and safer ... but ...Aye, I proposed the "just wait until the threads are all done" approach with safety and ease in mind - Toady doesn't have experience with multi-threaded coding/debugging and whatever time he spends getting to grips with it will be time he can't chip away at his long To-Implement list. Though ongoing world gen probably should be on its own thread anyway as most of the time the main thread won't care what's happening outside your own fortress.
Once you get people to realise what gets excluded from more graphical games simply because it's hard to animate they can change their view of DF.
I don't believe that changing to 64-bit will actually speed something up. Occasionally I compare 64-bit versions of programs with their 32-bit versions, and usually the 32-bit version is faster (if there's a difference), and always it takes less memory (which is expected, and which may explain why it is faster). I suppose only the bigger forts will be affected positively, and they are already crippled by other things.If your program's performance is limited by CPU register space, going from x86-32 to x86-64 (specifically) will get you real performance improvements because you now have 16 registers instead of 8. (This doesn't apply to 32-bit vs. 64-bit versions of most other architectures.)
Basically, I want somebody to help explain it to him. He doesn't understand how an ascii game can be so resource intensive and he has mocked me relentlessly because of it. He's a major elitist snob who only plays modern games with HD 1080420P blaze it graphics.