Print

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

[lethosor]

Did hear that in the suggestion that just moving to 64 bit could end up with pathfinding being 5 times faster, though that might have been before running and jumping, its also early in so there might be more gains to come.

That's not true at all (see above). Where'd you hear that?

Edit: "above" being the previous few pages, I guess.

[Random_Dragon]

I just generated the same exact world twice in a row with the 64-bit Windows build, and history turned out differently each time - I used the seeds ABCDEFGHIJKLMNOPQRST + UVWXYZabcdefghijklmn + opqrstuvwxyz01234567 + 89ABCDEFGHIJKLMNOPQR on a MEDIUM REGION with a 100 year history, and while both worlds had the same geography and initial historical figures and sites/structures, history itself turned out completely differently. The problem may simply be that history is not deterministic, and the bug tracker confirms that this has been a problem since at least version 0.40.

I'm still wanting to know if you eliminated orographic precipitation as a cause. D:

[Zarathustra30]

Did hear that in the suggestion that just moving to 64 bit could end up with pathfinding being 5 times faster, though that might have been before running and jumping, its also early in so there might be more gains to come.

That's not true at all (see above). Where'd you hear that?

Edit: "above" being the previous few pages, I guess.

With 64-bit, memory ceases to be an issue, so paths can be cached to hell and back. It won't come immediately with the upgrade, but it is something to keep in mind.

[Shonai_Dweller]

Testing 64 bit mode in large world, 1050 years. Nice and stable worldgen (took a while of course).
However just now my adventurer got into a fight, mortally wounded I defiantly bit my opponent in the arm and he vanished. Or perhaps turned into a tree. Not sure.
Combat log says he kicked me first before disappearing. Has anyone seen this before? Will upload a save to DFFD but guess I should avoid the bug tracker for now. No mods used.

--Added save
http://dffd.bay12games.com/file.php?id=12194

[Max™]

I've kicked dragons (modded and posing as gods) and had them vanish out of the game before, never been kicked and had one disappear though, but it's close.

[eternaleye]

One other thing that 64-bit may open up in the future (on Linux, at least) is function multiversioning[1]

With function multiversioning (old form, GCC 4.8+) one can declare multiple versions of a function, which are optimized differently, and execute only on CPUs capable of the features they use. With the new form (GCC 6), you can simply declare which variants you want, and the compiler will do the work of generating the versions _for_ you - so for example, you can have tight code (such as water or temperature propagations) optimized for SSE2, SSE4.2, AVX, and AVX2 (along with plain, normal scalar code), and the best one the CPU can execute will be selected at runtime.

Old form (GCC 4.8+):

Code: [Select]

    __attribute__ ((target ("sse4.2")))
    int foo(){
// foo version for SSE4.2
return 1;
    }
    __attribute__ ((target ("sse2")))
    int foo(){
// foo version for SSE2
return 1;
    }

    int main() {
return foo();
    }

New form (GCC 6):

Code: [Select]

    __attribute__((target_clones("avx2","avx","sse4.2","sse2","default")))
    int foo(){
        return 1;
    }

    int main() {
        return foo();
    }

Put the target_clones attribute behind an #ifdef for GCC >= 6, and free performance win without sacrificing compatibility once it lands in your distro.

[1]: https://lwn.net/SubscriberLink/691932/0a7303ac5f1ac1a3/

[Zorbeltuss]

I remember some nightmare years ago that seemed to come down to some issue with what MSVC 6 was doing vs what I was getting elsewhere, but it has been long enough that I don't recall any details.  Maybe that came down to a type issue too.  In either case, I doubt I'll be able to clean up the code to the point where we can get reproducible worlds between OSs/bits.

I remember that too, which was one of the reasons I reported it (wasn't it about the mac version though IIRC?

I just generated the same exact world twice in a row with the 64-bit Windows build, and history turned out differently each time - I used the seeds ABCDEFGHIJKLMNOPQRST + UVWXYZabcdefghijklmn + opqrstuvwxyz01234567 + 89ABCDEFGHIJKLMNOPQR on a MEDIUM REGION with a 100 year history, and while both worlds had the same geography and initial historical figures and sites/structures, history itself turned out completely differently. The problem may simply be that history is not deterministic, and the bug tracker confirms that this has been a problem since at least version 0.40.

Yep tested and history do not seem to be deterministic.

Did you have rain shadows on? :V

I did, now I do not, history is not deterministic either way on 64 bit, will soon know on 32 bit as that has been slower in compliting it's assigned tasks, will also try to remove periodic erodation of cliffs though I doubt that would be the issue.

Edit: 32 bit was also non-deterministic, not really surprising but useful to know.

/Zorbeltuss

[KillzEmAllGod]

Did hear that in the suggestion that just moving to 64 bit could end up with pathfinding being 5 times faster, though that might have been before running and jumping, its also early in so there might be more gains to come.

That's not true at all (see above). Where'd you hear that?

Edit: "above" being the previous few pages, I guess.

It was in the suggestion for voting that mentioned that up it could improve pathfinding to be up to 5 times faster just from DF using the gains in performance from being 64 bit, though we're unlikely to see such gains or sometime soon.

[FantasticDorf]

Even prior to optimisation of the test build the results are a remarkable improvement on a pretty bad laptop like mine.

Recovery from large events (such as 5 fire imps and a fire man shooting projectiles at once in arena at a bunch of archers hovering in the air returning fire with arrows) recovers quickly and for the first time (without pushing my luck too far) larger embarks & longer world generations are being tolerated (barely but noticeably, take for example before in terms of my system 125 years+ was undoable and anything larger than the standard embark would crash or be VERY choppy)

Big thumbs up from me.

[Zorbeltuss]

No difference with periodically eroding extreme cliffs either, to determinism that is, what I have noted however is thatthe starting point of civs seem deterministic, but not the same in 32- versus 64-bit however, though just that it seems deterministic doesn't say much really.

/Zorbeltuss

[Quietust]

I'm still wanting to know if you eliminated orographic precipitation as a cause. D:

Why should that have anything to do with deterministic world generation?

[soulsource]

@Toady:
I'd definitely set up a 64 bit Linux install to build the 64bit applications, as compiling 64bit software on a 32bit system is more or less cross compiling (as you can't run 64 bit code on a 32bit system). You'd not only need a working cross compilation toolchain, but also all required libraries for the target architecture. Then the question would be: Why keep a Linux installation? If you are cross compiling anyhow, you could just as well do the Linux build on Windows... The other way - compiling a 32bit program on a 64bit Linux system - is rather straightforward though. You'll still need 32bit libraries, but thanks to multilib (what is supported on almost any recent 64bit Linux distribution), pulling those in is trivial (on Debian based systems, just suffix the package name with :i386 and that should do), and AMD64 gcc will happily produce i386 binaries if it's being run with the -m32 switch.

If you want to use Ubuntu for the Linux build, I'd suggest to pick the second-newest LTS release, which would currently be 14.04LTS. Using the newest version of any distribution will cause issues with other distributions that haven't updated their SDL (or other libs  used by DF) in between, while the second latest should hopefully produce a build that's working on most others.
By using 14.04LTS, you'd likely loose compatibility with some ancient distribution versions that still are supported by their respective distributors (Ubuntu 12.04LTS, CentOS 6, RHEL 6,...), but I strongly doubt that (m)any people play games on machines still running those...

[Knossos]

Seems to work really well on my Win10 machine.

I get some hilarious negative FPSs when it is calculating.

I usually run no-FPS-limit games. Looking forward to seeing how the late game runs! At any case, in early games, dwarfs are moving even more lightspeedy than usual. \o/

[Caprealis]

Well, My Fortress is having some weird but interesting issues.

My doctors get stuck on a diagnostic loop, Causing them to keep trying to diagnose and quickly becoming legends. The dwarf in question is still waiting for some help though, He's been sitting there with a broken leg for a few seasons now.. And if I lock them inside the hospital, they climb through the well, Under the wall and back ontop of the building to get back into the fortress.(Even babies are doing it)
Other than that dwarfs seem very eager to jump over ANYTHING that is stopping them from attacking something. Causing a lot of inconveniences..

But I am still very impressed with how well the game is running. 

[nop]

@toady
well, I would use ubuntu 16.04 LTS x64 for compiling. If older versions of linux are required, then I would use docker. The newer the compiler, the faster it produces.
Compile with max optimizations enabled (there is no need to patch the code, just use different compiler flags), such as "-O3 -funroll-loops" for GCC, and fast inaccurate floating point arithmetics. Also, it is definitely a good idea to produce several versions of binaries with different cpu instructions support (vanilla, SSE2, AVX, AVX2 - the only difference for you is just a compiler flag), because it does not take any (!) additional time, but may yield tens of percents of execution speed. This is valid for both Windows, Linux and OSX
Also, I would compile with Profile Guided Optimization (PGO), this gives additional performance improvements without any changes to the code, but requires a little more time of yours. PGO implies compilation in two steps. On the first step you run an instrumented binaries that collect statistics, on the second step compiler recompiles binaries with the knowledge of this statistics.