Print

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

[LordUbik]

In the last entry in the developer log, Toady says that: "I managed to get a skeletal 64 bit DF program running, finally, and I'll continue to work out problems with that once this release is out (this release will still be 32)."

Now, I'm not a programmer so i'm asking you guys, will this help with performances, or as I suspect only with things like generating a longer history or a bigger world?

[Rose]

It won't directly help performance, but the new compiler required for getting 64bit to work will help performance a little in both 32 and 64bit

[LordUbik]

Well, good to know! Thank you!

[Pancakes]

Well, if I am not mistaken, 64 bit would allow DF to use more memory, multiple cores, and perform more calculations per second. So the 64 version would be significantly faster than the 32 bit version, and as Japa said, the 32 bit version would also perform a tad bit better as optimizations to port to 64 bit are made.

At least that's how I think it is going to work.

< Based off quick read from http://www.computerhope.com/issues/ch001498.htm >

[Rose]

Nope, no extra cores or calculations per second come with 64bit

[miauw62]

You can multithread in 32-bit.
It just sort of requires that you can handle things running asynchronously, which is rather hard to do in DF.

Nevertheless, the extra memory is nice to have.

[King Mir]

It will allow longer history and larger embarks, as it prevents the application from running out of memory and crashing.

IMO, it most likely will make the game net slower. There are benefits from using a more modern compiler, and more registers, but because of the heavy memory access of DF, I suspect it will be most effected by the fact that it will use more memory.

[Putnam]

You can multithread in 32-bit.
It just sort of requires that you can handle things running asynchronously, which is rather hard to do in DF.

this sorta implies that you don't have to in 64-bit

you do

[Rose]

Really, there's absolutely no connection between multi-threading and 64bit.

[Boltgun]

64 bits is more about raising the bar of how many creatures and items you can handle before the game gets crashy.

It will open the way for better optimizations. Hacks that may have been down previously may be replace with better native code. So it ensure that developing DF remains possible.

DF's code will run faster, pathfinding will probably better too so big forts will have less FPS death... if memory access for items goes well.

Edit: Multithreading is a bad beast in any game. Most games unload work on the GPU at best but very rarely they multithread.

[4kn]

as for me - this is one of the best games ever, but the problem of fps death even on top builds ruins it all. multithreading is the only way to save this precious gem. i think toady should found a separate fund to support transition of the game to multithreading.
i'm no specialist in this technical stuff, but i think those funds could be spent on outsourcing some tasks, yet i've heard that recompiling a code to multithread could be made semi-automatically

[soulsource]

From what I've read about 64bit, there are two things that compete, regarding performance:
On the plus side, the AMD64 command set extension offers more registers, meaning more data can be stored in such a way, that the CPU can directly operate on it.
On the minus side, the pointer data type is bigger (64 bits instead of 32 bits), so more memory is required for the same program. This (of course) also applies to cache usage, so the number of cache misses will be bigger.

Another thing, that probably isn't an issue with df, is the utilization of x86 command set extensions. Most 32bit compilers default to a very conservative command set. I don't know if this is still the case, but last time I checked the defaults of gcc (a very popular compiler, as it's free software), they were chosen in such a way, that the generated code would be able to run on a 386. As the first AMD64 processors hit the market after MMX and SSE had been introduced, there are no AMD64 capable processors that wouldn't support SSE. For this reason, compilers for AMD64 enable SSE (and other command set extensions common to all AMD64 hardware) per default, giving a significant performance boost over the default settings of 32bit compilers.
Now, as dwarf fortress won't run on a 386 due to other constraints (for instance memory usage...) anyhow, it doesn't make much sense to limit compilers to the 386 command set. Instead I guess toady already enabled the usage of SSE manually, and I also wouldn't be surprised if dwarf fortress contained explicit SSE code. Probably (but don't quote me on that) dwarf fortress is being compiled for Pentium Pro/AMD K7 or newer (often called i686).
Anyhow, with reasonable compiler settings, the performance difference between 32bit and 64bit is given by the first two points mentioned - cache misses and number of registers.
As a side note: People have come up with an ABI that uses 32bit pointers, but is able to use also the registers not available to the i386 ABI. It is called x32, and some Linux distributions support it.

As others have already written, the question of i386 ABI vs. AMD64 ABI has nothing to do with multithreading, which is a completely different, and much more complicated beast.

I'd expect the game to be more stable, as crashes caused by inability to allocate more memory won't happen any more (or at least more seldom), but I'd also expect performance to be actually worse due to the higher memory usage and delays happening when transferring data between CPU cache and system RAM.

[Thief^]

It's impossible to guess at the performance impact. SSE2 and the extra registers will provide a benefit (modern compilers even make an attempt to convert some loops into SSE2 vectorised versions automatically, a potential 4x speedup). On the other hand the code and data will be larger, causing more cache misses (bad!) and more ram transfer. If the DF data structures aren't too pointer-heavy, the increase in memory use won't be too bad.

Crash wise, there will be a number of bugs in the early days, but after a while the only difference will be that the 64-bit version will have fewer out-of-memory crashes.

[davsim]

IMHO, being a long term project, creating a 64 bits dwarf fortress is just logical. 

[Putnam]

as for me - this is one of the best games ever, but the problem of fps death even on top builds ruins it all. multithreading is the only way to save this precious gem. i think toady should found a separate fund to support transition of the game to multithreading.
i'm no specialist in this technical stuff, but i think those funds could be spent on outsourcing some tasks, yet i've heard that recompiling a code to multithread could be made semi-automatically

1. Multithreading would maybe double performance. The very best case is hextuple. This makes FPS death go from 15 FPS to 30 FPS. Assuming some magical performance-multiplying solution, 15 FPS becomes 90 FPS, which is still slower than expected.

2. Time's the problem, not money. Throwing money at a program won't make it program itself.