Print

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

[davsim]

^^ Absolutely this, the performance has decreased way too much in the last update. After 3 years you are down to 50-ish fps........

[miauw62]

As others have said, there is probably much to be gained by just freeing the memory held by items when they are no longer relevant instead of only when atom smashed.

[reality.auditor]

What timeframe would it take roughly for a 64bit

Unknown, but possible. Maybe even it will be faster than few years, if stars align right.

or even a multithreaded version to be released?

Never. People, get over it.

[Putnam]

What timeframe would it take roughly for a 64bit

Unknown, but possible. Maybe even it will be faster than few years, if stars align right.

you notice what topic you're in

[reality.auditor]

you notice what topic you're in

You, on other hand, do not seem to notice what Toady said.

Hint: he did not said "Hey guys, I have working DF compiled in 64 bit! Release tomorrow.".

[Putnam]

He also didn't say "I have 64-bit working! Well, that's not coming out for a while", but whatever, you're already confrontational so I'm out unless you happen to directly address me.

[Pseudo]

Unfortunately, I suspect that 64-bit will slow DF down. It's primarily ram bandwidth limited, from what I can see. And relatively pointer-heavy. The combination being the single worst case for a 32->64 bit transition.

That being said, x86_64 does have some things that can cause a speedup (extra registers, SIMD support (actually: is DF compiled with SSE?), etc). So... We'll have to see.

And not crashing on the memory wall would be nice.

[soulsource]

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

Quietust says that MSVC 2010 can handle 64-bit builds. Did Toady say he's actually using a newer compiler? (I remember him mentioning trouble getting it to work a few months ago, but he could have worked around that.)

While I of course don't know anyhting about the upcoming 64bit builds, that comment made me wonder which compiler Toady is using for current dwarf fortress builds.
The answer for Linux is definitely GCC:

Code: [Select]

$ readelf -p .comment Dwarf_Fortress | head -n5

String dump of section '.comment':
  [     1]  GCC: (Ubuntu 4.3.2-1ubuntu12) 4.3.2
  [    26]  GCC: (Ubuntu 4.3.2-1ubuntu12) 4.3.2
  [    4b]  GCC: (GNU) 4.5.1

For Windows I think it's MSVC:

Code: [Select]

$ strings Dwarf\ Fortress.exe | grep icro
PA<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
      <assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50727.762" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>

For OSX I think it might also be GCC:

Code: [Select]

$ strings dwarfort.exe | grep gcc
__gcc_except_tab__DATA
/usr/lib/libgcc_s.1.dylib
/usr/local/lib/libgcc_s.1.dylib

I'm quite surprised Toady isn't using the same compiler on all platforms, especially since one of the compilers he is using (gcc) is available on all three of them (and, of course, supports 64bit). Luckily the C++ standard is relatively strict, so differences between compilers should be small, but from my experience it still is a pain to compile the same code with different compilers, as some of them will happily translate non standard conformant code, making assumptions the compiler authors consider reasonable (yes, Borland C++, I'm talking about you), while others will fail, or at least warn if something would lead to undefined behaviour. Now, guess what happens if one uses two compilers that won't complain and make different assumptions for the same undefined behaviour.... With one of them, the program will work as intended, with the other it'll generate garbage for no apparent reason...

[lethosor]

He uses MSVC 2010 on Windows mainly due to it being easy to use with visual studio, from what I understand. He uses gcc 4.5 on the other platforms (4.5.1, according to some paths in the libstdc++ he distributes). I think gcc could require distributing more libraries on Windows, and I'm not sure how well it plays with visual studio, but he's run into a number of MSVC-specific issues (see 0.40.18), so it may be worth a shot.
ABI compatibility is another issue - C libraries, like SDL, might work with gcc-compiled code, but FMOD would probably need to be recompiled (and it's proprietary, from what I remember).

[TheBloke]

I agree with an above poster that while there are amazing new features each update, performance issues are really the biggest thing holding down my enjoyment of the game.

I wanted to add another +1 to this.  Well, +100 really

I've only been playing DF five weeks but in that time I've been completely hooked - I have played it every available hour in that time.  But if anything ever stops me playing, it will be performance.  And FPS already influences everything I do in the game.   My PC is five years old, but it was top-end for the time and I have since overclocked it to 4.2ghz.  Before DF, I never thought anything felt slow, but DF is a constant performance struggle.  I really can't afford the + it would cost to get a PC noticeably better than the one I have now. 

On a brand new fortress I can get 200 FPS.  But it doesn't take at all long for it to drop dramatically.  My largest fort to date is a 3x3 with 270 dwarves.  I can just get 30 FPS, but I can only achieve that by: not having too many pets/animals; turning weather off; turning temperature off (or to turn it on, I have to first use DFHack to delete 30,000 objects); turning traffic designations off; avoiding any flowing water/magma; not digging into the caverns.

I'm having a great time, but I have to constantly play with FPS in mind.  Most significantly, on some maps I have to avoid the caverns completely - the moment I open one wall into the caverns, FPS drops from 30 to 10.  10 FPS is just unplayable.  So it feels like I'm missing out on big chunks of the intended experience.    Yesterday I built a magma pump stack to create a magmaduct to kill some merchants, and was relieved it didn't slow down the game.  Then I thought I'd make a magma moat, so I let the magma flood a bigger area: FPS instantly dropped to 0 - 2, until I just quit.  This map is literally unplayable when liquid floods a wider area.

So it often feels like I'm only able to experience half the game.  And I'm one of the lucky ones: I sent my 270-dwarf save to a tileset developer on this forum to test with, and he got 5 FPS.  And sure I know I could have fewer dwarves, make less wide-open areas, put animals in pens, etc etc.  And I do do those things.  I practically have the Wiki's FPS page memorised.  But that's what I mean about playing around FPS rather than just playing the game; and even then, I still always hit a major slowdown eventually - and usually by the time I hit it, it's dozens of hours into a game and too late to easily fix.

My point is: I really hope Toady won't spend a lot of effort making a 64bit build before he works on much more pressing FPS issues.  And I really, really hope some work will be done on multi-threading.  It's so sad for me to see my FPS being so terrible while the game is using less than 25% of the CPU resources I have (quad core with hyper threading.)  I can think of plenty of multi-threading opportunities: not least, moving creature pathing into a multi-threaded queue. I have no idea what the game's code looks like, and I fully understand that there can and will be complications to parallelisation that doesn't break game behaviour/outcomes.  But it has to be done at some point, and I do feel very confident saying there are myriad opportunities for it, and that Toady is more than capable of implementing it effectively. 

I also don't really understand why 64bit is particularly important.  Of course if it's really easy then why not.  But I'm guessing the discussion comes because it's not simple.  If it's primarily to avoid Out Of Memory with huge histories then surely there are other options to solve that: streaming the data from disk in chunks for example?  And how many games does that actually affect? Surely a tiny fraction of those affected by FPS? (Which is more or less All I'd imagine, to lesser or greater extents.)

So I do hope Toady will start to consider FPS a priority.  I look at the features coming in the next version, and I want to feel only joy and excitement.  Instead I can't help thinking "so how much slower will my game be then?  Can I even use these features?"  Which is very sad   Come next update I fear my dwarves will literally be fiddling while my FPS burns

Anyway, of course such feelings are only because I love DF and want to enjoy it to the very max.  I am very grateful for DF and DFHack.  Even if I were only able to play half of DF at a time, it's still an astounding experience