Print

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

[Flarp]

Worldgen speed can vary enormously in my experience. I've run worldgen all night long and woke up to my CPU painfully chugging through the fourth century - and on other times, it's gotten to Year 900 in a couple hours.

Civ-civ interaction seems to be the main factor. The Year 900 world had one continent, but its northern and southern halves were connected by a tiny, Panama-like strip of land between two seas. The slower worlds tend to be wide open plains/forests where humans and elves and goblins can go to town on each other.

I'm gonna try running worldgen with identical seeds on 32 bit and 64 bit to see if there's any improvement. It's possible more than 2GB is being used, especially if there are multiple epic wars going on simultaneously.

[Thundercraft]

Playing for a while on the 64 bits version, no crash. And the fps is the same in either version. (42 with 150 dwarves and about the same number of animals)

That was what I was afraid of; That, currently, there is no FPS/speed difference between the 32 and 64-bit versions. But then, it is still in development. Hopefully, the 64-bit branch will eventually make use of multithreading and multiple cores.

I'm gonna try running worldgen with identical seeds on 32 bit and 64 bit to see if there's any improvement...

Please post your findings as they should be useful to the rest of us, either way.

[Shonai_Dweller]

Playing for a while on the 64 bits version, no crash. And the fps is the same in either version. (42 with 150 dwarves and about the same number of animals)

That was what I was afraid of; That, currently, there is no FPS/speed difference between the 32 and 64-bit versions. But then, it is still in development. Hopefully, the 64-bit branch will eventually make use of multithreading and multiple cores.

I'm gonna try running worldgen with identical seeds on 32 bit and 64 bit to see if there's any improvement...

Please post your findings as they should be useful to the rest of us, either way.

64 bit has nothing to do with speeding up the game or multithreading. The fear was that using 64 bit would actually slow down the game. Which thankfully doesn't seem to be the case.

[Criperum]

Hope next platform upgrade would be multithreading. It's so sad to see DF utilizes only 1 CPU core of 8.

[paxy97]

Implementing 64bit isn't nearly as much work as adding multithreading. It would require a lot of the features to be rewritten, like pathfinding, though I guess the performance improvement would be quite big, because pathfinding for each creature can be split on multiple cores shortening the calculation time for each frame.

[Criperum]

Implementing 64bit isn't nearly as much work as adding multithreading. It would require a lot of the features to be rewritten, like pathfinding, though I guess the performance improvement would be quite big, because pathfinding for each creature can be split on multiple cores shortening the calculation time for each frame.

As programmer I really understand that turning singlethreaded app into multithreaded is literally the Hell. But hope never dies.

[Zorbeltuss]

Tried to benchmark the 32 bit test versus the 64 bit test in world generation, on pre-history generation the 64 bit version was much faster with identical results, but even though the seeds were identical, their histories differed by a lot and I ended the test there, there though the 32 bit version didn't seem as left behind as earlier, but since the results differed I would take that with a few grains of salt.

/Zorbeltuss

[Toady One]

Yeah, I don't know that we'll ever have the different versions generating the same world.  Compiler optimizations have shifted around the order of calls before in a way that I can't easily control.


edit from Linux land: "sorry, unimplemented: 64-bit mode not compiled in".  Well, that was polite!  So I guess I have to rebuild GCC?  If I built it before, that was many many years ago.  Last time, I appear to have simply typed

"sudo apt-get install build-essential libsdl1.2-dev libsdl-image1.2-dev libgtk2.0-dev scons"

on a terminal on my Ubuntu computer and it did everything, but I don't recall if there was more to do.  I'm not sure if I should do something differently now.

[lethosor]

What architecture is your Linux distro? I think "uname -m" should tell you (and that might be worth checking on OS X while you're at it too).

[Toady One]

"i686".  Can we build for 64 bits on that without being able to test?  Or do we not even get that far?

edit: "i386" for the mini.

[Zorbeltuss]

Yeah, I don't know that we'll ever have the different versions generating the same world.  Compiler optimizations have shifted around the order of calls before in a way that I can't easily control.


edit from Linux land: "sorry, unimplemented: 64-bit mode not compiled in".  Well, that was polite!  So I guess I have to rebuild GCC?  If I built it before, that was many many years ago.  Last time, I appear to have simply typed

"sudo apt-get install build-essential libsdl1.2-dev libsdl-image1.2-dev libgtk2.0-dev scons"

on a terminal on my Ubuntu computer and it did everything, but I don't recall if there was more to do.  I'm not sure if I should do something differently now.

Well it seemed like 64 bits were faster in all of world generation, just much less so in the actual history part, that however may depend on the all together higher population of that world, or the 32 bits was almost keeping up despite all the extra events that happened, however, the 64 bit version did use a lot more ram, roughly 25% more, not unexpected and not an issue if you have enough ram to profit from using a 64 bit OS, but neither is it for everyone.

/Zorbeltuss

[eternaleye]

ToadyOne, Ubuntu has support for what's termed "multiarch", which allows you to cross-compile (relatively) easily.

According to what I've read, this should do the job:

Code: [Select]

sudo dpkg --add-architecture amd64
sudo apt-get install build-essential:amd64 libsdl1.2-dev:amd64 libsdl-image1.2-dev:amd64 libgtk2.0-dev:amd64 scons

The first line sets up your system to be ready for amd64 multiarch; the second line installs your dependencies' 64-bit variants (note the :amd64 suffixes). Note how I left that off of scons - scons does not need to be multiarch, because it's merely run as part of the build process, rather than being linked to by DF.

EDIT: You may also need to do some finagling of your buildsystem to _use_ the cross-compiler, which will be something like x86_64-unknown-linux-gnu-gcc, with similarly prefixed forms of ld, ar, nm, objdump, etc.

[TheHossofMoss]

http://bay12games.com/dwarves/redist/msvcp140.dll
http://bay12games.com/dwarves/redist/vcruntime140.dll

For the SDL version on the website, are those two files sufficient (put them in the folder with the exe), or does it give an additional DLL error?  I'd like to find the smallest set I can include without forcing anybody to run an installer.  I'll stay away from the /MT option if possible to keep DFHack running.

I have no idea what's going on with the exit crash...  was that only happening on XP/Win7 in the SDL version?

Thank you so much Toady One. This fixed it for me. I'd buy you a beer if I was near. Or.. fizzy pond water. Whatever amphibians prefer

[Toady One]

Code: [Select]

sudo dpkg --add-architecture amd64


"dpkg: unknown option --add-architecture"

Saw various posts online tangentially related, but not really clear what to do from here.

[mifki]

Code: [Select]

sudo dpkg --add-architecture amd64


"dpkg: unknown option --add-architecture"

Saw various posts online tangentially related, but not really clear what to do from here.

Looks like old dpkg and possibly Ubuntu. Do "dpkg --version" and "lsb_release -a".

On Mac, do "sw_vers -productVersion" and "system_profiler SPHardwareDataType"