Print

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

[Jeoshua]

Yes, people seem to think that 64 bit is magical and will make the game run faster or more efficiently.  Fact of the matter is that unless the game's framework was changed very significantly to take advantage of the wider data-path, it would do absolutely nothing to the game except avoid a few persistent overflow errors.

[Kogut]

And will be unable to run on 32 bit.

[Jeoshua]

Another thing to be wary of about 64-bit is memory usage. 64 bit integers take up twice the space of 32 bit ones.  While you may be able to address a higher amount of memory, you'd also be taking up a higher amount of memory.  An embark that took up 1.5 GB could easilly end up taking 3 GB due to memory storage overhead.

Something ELSE to be aware of is that although DF is a 32 bit app, much of it's data isn't necessarilly 32 bit.  So far as I can tell there are no floating points in the game, everything being done with fixed point integer maths.  These integers are not 32 bit for the most part, since they can flop signs at 32767 to -32767.  Sometimes, the bit depth is even lower.

So basically, 64 what? bit what? You're dreaming if you think that would change anything.

[Fayrik]

Another thing to be wary of about 64-bit is memory usage. 64 bit integers take up twice the space of 32 bit ones.

...Whoa.
64-bit integers are a data type; a variable.
Variables are assigned in code, and when compiled do not change type (most of the time).
Changing from a 32-bit system to a 64-bit system changes your hardware and thusly the way the software needs to interact. The requirement of what the software wants to accomplish does not change.
Programs do not, will not, and have absolutely no reason, to change a 32-bit integer into a 64-bit integer when changing from a 32-bit system to a 64-bit system.

As for this:

An embark that took up 1.5 GB could easilly end up taking 3 GB due to memory storage overhead.

Even if someone with access to the source decided to go and change all the 32-bit integers to 64-bit, that embark would probably only go up to 2.0 GB, or slightly over. Most of the variables Dwarf Fortress will use will probably be booleans and arrays.

Personally, I'd love to see a 64-bit compilation of the game so that we could finally embark on full size maps without the game crashing.
The only problem... Is quite a big one. The file SDL.dll is an open source project; and I've used it outside of Dwarf Fortress. For some reason (and I'm sure they have a good one), that file is compiled in 32-bit only mode. So, to get hold of a 64-bit version of Dwarf Fortress, first, we'll need to get a 64-bit compatible version of SDL.dll. (And perhaps a few others.)

[kaenneth]

Yep, 64 bit code and pointers take up more space, making 64 bit programs average 25% larger.
Also there is library integration, do the graphics (and other) librarys have 64 bit versions?

[Starver]

Another thing to be wary of about 64-bit is memory usage. 64 bit integers take up twice the space of 32 bit ones.

...Whoa.
64-bit integers are a data type; a variable.
Variables are assigned in code, and when compiled do not change type (most of the time).
Changing from a 32-bit system to a 64-bit system changes your hardware and thusly the way the software needs to interact. The requirement of what the software wants to accomplish does not change.
Programs do not, will not, and have absolutely no reason, to change a 32-bit integer into a 64-bit integer when changing from a 32-bit system to a 64-bit system.

As someone who already mentioned this general concept, I'd like to ask about memory pointers.  Even when the programmer doesn't explicitly use pointers, I'm betting the compiler will introduce a significant amount of its own to manage almost any complex data structure that the programmer didn't implement at assembler-level himself.  There are optimisations, but it's likely to be much the same as the case of however the programmer styles the variables, it's the compiler that has the last say.  It may either 'optimise' the data into padded 64-bit structures for easy shifting around or introduce a multi-step process (albeit that the speed hit may even be as low-level as at the microcode level, depending on what the chip architecture allows, and more efficient for all that) to pack multiple.

I'm not saying that booleans will still take up a 64-bit space in memory, and depacking them from either 32-bit or 64-bit conglomerate structures might well give nearly the same overheads (if it doesn't just XOR on the appropriate bit, but there are more and less efficient ways of doing that) but everything from ints on up do not get guaranteed improvement from being stored within a 64-bit environment.

I remember a number of arguments from the time of Win32, although that was a very different beast of change, as I recall so I won't reiterate them here  16-bit (and 8-bit before that) was probably the environment that I last seriously did large-scale (comparative to the time) assembly programming, and I tended to abandon the low-level stuff about the same time as 32s came about.  Since then I've been mostly at the mercy of compilers, although I do sometimes disassemble them to see what I derive.  Have to admit I've not tried compiling for 64-bit and disassembling that, so my main argument contains received wisdom (or otherwise) and personal speculation rather than experience through yours truly's very own eyeballs.  But it also checks out with sources I've wandered over and had a look at when my mind was drawn that way, previously.



(Although, speaking of compilers, I've also made a 2-bit environment emulator.  Two-bit.  Repeating that in words, just in case you thought I'd typoed something, there.  To be fair, it's more properly a multiple of two-bit segments, but each of the just four commands/operators/instructions with which it is blessed is defined by one of the four possible 2-bit 'instruction' states, the operands then following in a similar manner to quadword data on <64-bit systems (but is tuned to a fixed multiple of 2-bits appropriate to the size of the 'memory core' of that implementation).  And in my preferred set-up it contains a particularly interesting tweak to enable complete instructions to be an exact multiple of "2N-bit"-sized slots.  It's not a little esoteric (also very good code-fodder for a darwinian code evolver, as well as allowing self-modification of instruction as well as data), but probably could be implemented on non-IC (or very basically IC-based) circuitry, if brought out of the computer and put onto a real-world device.)

[sockless]

And will be unable to run on 32 bit.

So that's why you have both a 32 and 64 bit version.

[Blade Master Model 42]

And will be unable to run on 32 bit.

So that's why you have both a 32 and 64 bit version.

That sounds like more work for the Great One. Seems to me he's got enough on his plate.

[sockless]

That's true.

But to all this, how would 64 bit make DF faster?

From Wikipedia, the Free encyclopedia:

While 64-bit architectures indisputably make working with large data sets in applications such as digital video, scientific computing, and large databases   easier, there has been considerable debate as to whether they or their   32-bit compatibility modes will be faster than comparably-priced 32-bit   systems for other tasks.

Some 64-bit architectures, such as x86-64,   allow for more general purpose registers than their 32-bit   counterparts. This is a significant speed increase for tight loops since   the processor doesn't have to fetch data from the cache or main memory   if the data can fit in the available registers.

So there we go, that's one way that you can get an increase in speed from using 64 bit.

[devek]

In real world scenarios, 64bit is actually slower.

The advantage of 64bit DF is that the large adaman spire map would actually be able to load instead of crashing when DF ran out of memory. On a typical basis though, I really don't want DF consuming more than 2 gigs of ram :/

[Jeoshua]

The advantage of a 64 bit program only comes into play when there is something that requires 64 bits to compute.  Since DF does not use anything of sufficient complexity to warrant 64 bits, it would basically do nothing except allow more memory to be addressed.  As Devek says, it would allow the Adamantine Space Elevator to be LOADED.  It does not mean that it would be playable at all.  In fact, unless DF's archetecture was drastically changed to take advantage of a 64 bit format in drastic ways, it would be less playable than it is now.

[K.I.L.E.R]

Modern x86_64 architectures will get double the register width and number of registers. Modern compilers will try their best to batch operations to take advantage of this. As far as performance, and this thread, is concerned this is all speculation.

If any performance is to be gained it would be through a profiler and a lot of time. I wonder if Toady would  spend one to three months doing this?

[Maklak]

A smaller step would be to build with MMX and SSE2 rather than pure 386 instruction set. You don't need x64 for vectorized instructions. Performance gain could be well worth it, but even this is a lot of work. It also needs all the libraries to be compiled with MMX and SSE2, and there is potential for some bugs and crashes that disappear without optimization.

[Uristocrat]

A smaller step would be to build with MMX and SSE2 rather than pure 386 instruction set.

Doesn't Toady do that already?

[Jeoshua]

"Toady" doesn't do that.

"Toady's compiler" does.