Print

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

[Max™]

I got excited because I thought maybe the higher pointer sizes would get rid of the strength rollover (use a syndrome to give something like 1500% and +15000 directly to strength and you go from being super strong/fast to 0.099 speed) because I remembered Putnam doing the dfhack stuff to set the attributes to 2^32 -1 but it's a different cause still.

[Ganondworf]

Dear all,

could someone please explain to me what the 64-bit support does? Or point me to some place where someone else does the explaining? I'm on and off DF for at least 5 years, but I have only limited understanding of technical details, so I'm wondering how 64-bit will affect me as someone who is "just" an end user.

Yes I tried the search, but I didn't understand much except for "bigger, older worlds"

Nevermind, I'm blind.

Thank you very much!

[Cexp]

One possible legitimate cause of divergence between bitness and compilers is the use of floating point numbers, which I think applies to DF.

It's very difficult / almost impossible to get the exact same results out of floats across different environments. There are some heavy handed "solutions" but I don't think they're worth it in this case.

[Quietust]

One possible legitimate cause of divergence between bitness and compilers is the use of floating point numbers, which I think applies to DF.

It's very difficult / almost impossible to get the exact same results out of floats across different environments. There are some heavy handed "solutions" but I don't think they're worth it in this case.

If you're using the same size of floating point number (32-bit "float" or 64-bit "double"), you should always get exactly the same result whether you're running 32-bit or 64-bit code.

Toady mentioned warnings about "size_t", which has just reminded me that there are data types that vary between Win32 and x64 (most of the others being pointers, which you should never be using to store values anyways).

[mifki]

If you're using the same size of floating point number (32-bit "float" or 64-bit "double"), you should always get exactly the same result whether you're running 32-bit or 64-bit code.

http://stackoverflow.com/questions/22710272/difference-in-floating-point-arithmetics-between-x86-and-x64

[Chase]

New version runs great on a macbook.

[Amperzand]

Unless it was fixed, the game only runs in a buggy terminal mode with OSX El Capitan.

[Chase]

Unless it was fixed, the game only runs in a buggy terminal mode with OSX El Capitan.

I'm not using El Captian. Forgot to mention that. I followed this:

https://www.reddit.com/r/dwarffortress/comments/2va09g/help_with_running_df_in_console_on_os_x/

[tonnot98]

128 bit when

[dermal_plating]

Would anyone care to explain in laydwarve's terms why multi-threading will not have a great impact on fort mode performance?

[FantasticDorf]

128 bit when

Probably not for a while and when the modern day markets catch up, 64 bit is modern day market standard, 128 bit is a decade or so roughly down the line despite existing in the 1990's experimentally. (though saying that, people did not expect computers to progress as fast as they have done, estimating that only the richest people in the world will own a personal one)

Right now it was estimated that computers would dramatically improve every two or so years, and that number has been recalculated lately because of hardware requirements of keeping them cool (bigger fans & costs to make resulting) so unless we develop a new heat immune way of computing so we can cram super-computer like power into them consequence free, give or take some new breakthroughs in handling the heat and the raw power of computing in general so all 128 bits are being used constructively. Its a waste to use a system that can collect information on that scale but can't store it away as effectively due to processing constraints, 64 runs within the limits of modern day computers unlike their 32bit predecessors which are more limited.

Would anyone care to explain in laydwarve's terms why multi-threading will not have a great impact on fort mode performance?

It'd tidy stuff up into neat pretty pockets rather than going through the same channels as everything else, but you've still got to store and handle that stuff somewhere, therein lies the problem in it being a tool to tidy up, not a magic bullet to correct.

[Quietust]

If you're using the same size of floating point number (32-bit "float" or 64-bit "double"), you should always get exactly the same result whether you're running 32-bit or 64-bit code.

http://stackoverflow.com/questions/22710272/difference-in-floating-point-arithmetics-between-x86-and-x64

You learn something new every day - for those too lazy to click the link, 64-bit code uses SSE instructions (which have separate versions for 32-bit "float" and 64-bit "double") for floating point arithmetic, while 32-bit code uses FPU instructions (which upconvert all floats to 80-bit "long double", which you can't actually use directly on Windows) because of the possibility that SSE might not be available.

Apparently, though, newer versions of MSVC use (or can be told to use) SSE in 32-bit code as well to make things stay consistent, though I'm not sure if that's an option in the old version of GCC Toady's using.

[greycat]

Would anyone care to explain in laydwarve's terms why multi-threading will not have a great impact on fort mode performance?

Right now, any multi-threading that you see is just the libraries automatically delegating a few internal tasks to separate threads.  This may help a tiny little bit, but won't have a dramatic effect on overall speed.  The game itself has not been rewritten to multi-thread, and probably won't be any time soon.  Doing so is an enormous project.

[PatrikLundell]

Would anyone care to explain in laydwarve's terms why multi-threading will not have a great impact on fort mode performance?

I think a thorough threaded implementation of DF could add a lot of speed, but it would also require a huge amount of work.

One reason an application might not get much out of multi threading would be if its "memory bound", i.e. its speed is not constrained by the computation speed of the CPU, but the speed at which data can be shuffled to and from memory. If a single lane congested road leads to a factory, adding additional assembly halls might do nothing to speed up production because the trucks carrying the material to the factory are already arriving as fast as the (memory) road network allows. Given that the 32-> 64 bit conversion is driven partially by an increasing demand for memory, it's not unreasonable to assume memory band width might be a larger bottle neck than CPU speed.

[Dirst]

The obvious solution is to require 16GB of L2 cache.  Too bad that doesn't exist.