Print

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

[Urist McAddict]

That consumed quite a bit of time in my mind...
For all your geeks and pros out there, is it possible that by using a emulation program to use the multiple processors and run DF through there so we from the multi-core generation can get all the processing power converted into pure dwarfness?
That idea came from the notion of the DOSBox, a program that make old games run normally in new OS.
So, any help there? Is it possible? More importantly, is it DOABLE?
I'd prize a gazillion internets and plenty of worship for anyone who would make this dream real... =P

[GreatWyrmGold]

I doubt it. If there was some easy way to get DF to multithread, wouldn't Toady have done it?

[Urist McAddict]

Well, in another topic ppl talked about making DF multi-threaded, i'm thinking on some kind of autonomous emulation program, since not many games have this problem due to team effort on designers, that would be only a problem faced by independent long running games, so maybe someone with good skills could make a multi-threaded program that would be used to run all the DF processing through... Dunno, it's just an idea...

[Putnam]

That would only make it slower.

[Telgin]

That would only make it slower.

This.

Believe me, if it was possible to just take a program and make it work on several processors (and significantly faster than on one), and someone knew how, they'd be famous and rich.

Even if you "fooled" the program to run on several processors, you can't get around the fact that the game is programmed for each CPU instruction to occur in sequence (within limits of a superscalar architecture of course).  If you start issuing them out of order, all heck will break loose.

[HiEv]

Software simply doesn't work that way.  Basically, this is like asking if your car can be "fooled" into running on hydrogen.  I suppose it could be done, but it would be incredibly inefficient and prone to blowing up.

The software, as it is written now, expects things to happen in a certain order.  In order to multitask properly, the CPUs would need to know what parts could be run simultaneously and what parts have to be run after other parts.  The amount of CPU time needed to figure out what parts can and can't be run that way (with some sort of AI task coordinator that doesn't exist yet) would be greater than the amount you'd save by running it normally (at least on any normal home PC available today).  To do it right you'd have to rewrite the code, but that's not public domain.  In other words, no, you can't do it.

We just have to wait for Toady to rewrite the core so it works in a multi-threaded kind of way.

[Mel_Vixen]

Software simply doesn't work that way.  Basically, this is like asking if your car can be "fooled" into running on hydrogen.  I suppose it could be done, but it would be incredibly inefficient and prone to blowing up.
 

Many cars run on natural gas and yes thats to good parts hydrogen too. The thing is that you have to know the engine and how to add your gas into the system. This leads us too:

The software, as it is written now, expects things to happen in a certain order.  In order to multitask properly, the CPUs would need to know what parts could be run simultaneously and what parts have to be run after other parts.  The amount of CPU time needed to figure out what parts can and can't be run that way (with some sort of AI task coordinator that doesn't exist yet) would be greater than the amount you'd save by running it normally (at least on any normal home PC available today).  To do it right you'd have to rewrite the code, but that's not public domain.  In other words, no, you can't do it.

We just have to wait for Toady to rewrite the core so it works in a multi-threaded kind of way.

Actualy this is not true. What you realy need is to understand how DF works. And by this i mean on assembly level. The thing is you need to know where the pathing respective the liquid flow code (both being mayor offenders) are and how they intersect with other parts of the code. Knowing how they work (a* for the pathing and intricate algorithm toady did discribe in an interview for flows) helps to find them but i guess as single coder you would need quite some time, most likely over a year or two, to get DF gutted and completly understood.

If you have that you must realise how the code intersects with the memory. Pathing should be easy on that (i gues all pathing happens with a stable "map" every turn) on the other hand flows? Not so much. You get problems with race conditions for movement (not path-planning) because each dorf checks its next step for obstacles (other dorfs, closed doors etc.). This needs to be handled which means some coding.

I could go into deeper detail but this anyway already just idle musing. It is possible for sure but a) it takes a long time and b) even if you get it to run with one version of DF every other version most likely changes the addresses and code so you have to do things many time over. Needles to say that toady doesnt like it (iirc. i am not entirely sure about that) if you fudge with his code outside of memory reading. 

[Telgin]

I believe he's cracked down on people who decompiled DF before, but he has no problem with the binary patches that members have made to fix some issues in the past, as far as I know.

And while what you're saying is technically true, I think HiEv hit the nail on the head when he said:

To do it right you'd have to rewrite the code

Trying to disassemble DF and figure out what it's doing, then determining which parts of the ASM can be run out of sequence, where to insert synchronization primitives, and so on would be hard enough that it's probably not really worth mentioning it as a possibility. 

If only computers could do that automatically...

[Shades]

If only computers could do that automatically...

He could just try compiling it with -fopenmp -D_GLIBCXX_PARALLEL, assuming he uses g++, and that will magically convert a number c++ standard functions to parallel processing equivalents, specifically the container and algorithm libraries.

Obviously not as good as specifying which bits should be in parallel manually as this flag has to avoid false negatives when looking for things that can be made parallel. Its also experimental (hence the need for flags). Might help as a cheap win though.

[Idranel]

That would only make it slower.

This.

Believe me, if it was possible to just take a program and make it work on several processors (and significantly faster than on one), and someone knew how, they'd be famous and rich.

This.
You might as well go ahead and publish the answer to the P = NP question while you're at it.

[Putnam]

And a lossless compression algorithm that will compress any file.

[Sizik]

And a lossless compression algorithm that will compress any file.

Come on, that one's actually impossible.

[i2amroy]

And a lossless compression algorithm that will compress any file.

Come on, that one's actually impossible.

Well with quantum computing you could technically make a lossless compression algorithm that would take any file of N bits and turn it into a file of substantially less qubits, since qubits operate on a ternary (3-base) numerical system, with the options being 0, 1, or both simultaneously. The compression would only be able to work once per file, and at that point you would need a fully operational quantum storage/operational system, the likes of which the world has yet to produce.

[HiEv]

And a lossless compression algorithm that will compress any file.

Come on, that one's actually impossible.

Well with quantum computing you could technically make a lossless compression algorithm that would take any file of N bits and turn it into a file of substantially less qubits, since qubits operate on a ternary (3-base) numerical system, with the options being 0, 1, or both simultaneously. The compression would only be able to work once per file, and at that point you would need a fully operational quantum storage/operational system, the likes of which the world has yet to produce.

That's not compression though, that's merely conversion from one system to another.  You could make a system where each "bit" has 256 possible states, making each bit equivalent to a binary byte, but again, that isn't compression, that's merely conversion from binary to another system.

A system that can truly losslessly compress any file is impossible, because that would have to be able to further compress its own output through any number of iterations, which obviously runs into problems as you approach zero file size.

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.  That single copy would be both your limiting factor on how fast you could get it to run on multiple processors and the speed you'd get if you ran it on a single processor.  In other words, there'd be no point in doing that, since it could only run slower on multiple processors that way.  (I suppose you could do a less exact simulation based on profiling, but that would likely produce odd, unpredictable, and unstable behavior of the program when the simulation "guesses wrong" in some situations, which would likely happen frequently in uncommon/complex situations.)

I'm not sure why Heph said what I wrote wasn't true, since everything else he wrote just agreed with exactly what I was saying.

[zeziba]

That would only make it slower.

This.

Believe me, if it was possible to just take a program and make it work on several processors (and significantly faster than on one), and someone knew how, they'd be famous and rich.

Even if you "fooled" the program to run on several processors, you can't get around the fact that the game is programmed for each CPU instruction to occur in sequence (within limits of a superscalar architecture of course).  If you start issuing them out of order, all heck will break loose.

True, true, this is a problem that they are working hard on because of the vast ammount of money that could be made. So give it a few tears and you might not be saying the same thing...