Print

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

[Kiberkiller]

No, the same way you can't 'fool' a 1L engine to run like a 6L one.

[etgfrog]

the thing is...i'm sure many people have fancied the idea of making df multi-threaded, it would require like people said earlier, decompiling the game, backward engineering it, apply the proper alterations, recompiling it...and then repeat the process EVERY time a new version of the game comes out, its not something simple like the sdl update that you could just "patch" it since many core features would have to be changed. even if someone makes a multi-threaded version of df, they will be bombarded to update the program with every new version...this is also ignoring toady's wishes...which i honestly never looked up on toady's opinion on the core functions of the game being modified...

[Shades]

Similarly, you can't have multiple processors accurately run a single processor program on multiple processors faster than it would run on a single processor (without some sort of advanced AI that "understands" how the code works and can essentially rewrite it for multiple processors, no such AI exists yet), because you'd have to run a single-threaded copy of it to determine what parts could be run in separate threads.

This entirely depends on the program your running. If DF uses any of the standard library algorithms then there is a fair chance that not only is the possible but the code that can do it has been in the compiler for many versions already. Your logic for how you need to work it out is flaws because all you need to detect is isolated operations being performed on sets of data, once you have that you know you can run them in parallel. Obviously this wouldn't get everything, or even a large set of the possible options for parallelism but it may well improve things and at very little effort.

[HiEv]

Similarly, you can't have multiple processors accurately run a single processor program on multiple processors faster than it would run on a single processor (without some sort of advanced AI that "understands" how the code works and can essentially rewrite it for multiple processors, no such AI exists yet), because you'd have to run a single-threaded copy of it to determine what parts could be run in separate threads.

This entirely depends on the program your running. If DF uses any of the standard library algorithms then there is a fair chance that not only is the possible but the code that can do it has been in the compiler for many versions already. Your logic for how you need to work it out is flaws because all you need to detect is isolated operations being performed on sets of data, once you have that you know you can run them in parallel. Obviously this wouldn't get everything, or even a large set of the possible options for parallelism but it may well improve things and at very little effort.

It's not that simple.  For example, the code in Dwarf Fortress is designed to work serially, so it will likely behave quite badly when run in parallel.  Race conditions, such as one thread attempting to read/write/edit/delete data while another thread is attempting to read/write/edit/delete that same data, can produce erratic behavior or even crash the program.  For example, two dwarves deciding to do the same task at the same time could cause it to try to remove the same task from the list twice, which would likely screw up the task list, if not cause the program to crash entirely.  The current code wouldn't check for that because it would never happen when run serially.

The point is, when working with multithreading you have to be very careful when having two (or more) threads access the same data at the same time, and whether or not the code uses "standard library algorithms" or not doesn't change that fact.  Properly switching to multithreading really isn't something that requires "very little effort," at least not with anything as complex as Dwarf Fortress, and would require rewriting the code to do it properly.

[Shades]

That is why I specifically mentioned isolated operations on sets, at which point it is that simple. This is something the compiler can detect.

The experimental g++ flags don't touch anything they think might interact, this is to remove any false positives. It also means it's not as good as if you design threading in from the ground up.