Print

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

[Geltor]

Not that I'm complaining, but... why? Before my fps started to drop from 100 with the coming of 80 dwarves. Now, it's 170 and it's still on 100!! It's like a wet dream coming true. Every migrant wave I say "okay, now THIS TIME it will definitely drop", but that moment never comes...

I heard people say that 64 bit would allow DF to just use more memory, and that it wouldn't improve processing speeds whatsoever. Does more memory really equal this much performance gain? This isn't just in fortress mode, world generation is multiple times faster than what it used to be and that period where the calendar calculates after you start a new fort/adventure game is pretty much instant (before it took a few second to calculate each date).

Note that the ONLY thing that changed (whether it's PC specs, fort design, world size, etc etc..) is the fact that I'm running pure vanilla DF without DFhack or therapist. I don't think there's anything more to it. World is a small, 250 years old. Default cavern settings. Nothing edited. Hell, I'm even being seiged right now (granted it's only 30 crossgoblins) but it's still pretty amazing.
And here I was, thinking that the additional 20 visitors are going to cause havoc...

Edit: Loaded my 64 savegame into a 32 DF and things seem only slightly worse. It must be something else.

[Greiger]

Wow despite being a computer rapair guy it suddenly hits me that I don't have a solid answer about why you'd get such a big increase.

At any rate I think when they were talking about there being no major processing differences I imagine they were speaking on the average.  There are many different variables in play and some of the stuff on your particular rig or software setup may be able to operate on 64 bit processes far more efficiently than 32 bit ones. (EDIT: actually thinking back I remember reading something about windows 10 choking on particular kinds of 32 bit programs. That could explain a lot.)

I would expect them to be minor, but who knows, maybe a software engineer can come in and give us a better idea what could be happening.

It's also possible the map yer on may just not be as processor heavy as well.  Things like large bodies of unstable water, waterfalls, and certain kinds of 'pathing trap' terrain can slow maps down pretty good.

[PatrikLundell]

Performance for individual DF worlds vary hugely, so generating two worlds and embark in different version won't give a useful performance comparison. You'd have to use the same world with the same embark.
It can also be noted that apart from 64 bit support, the compiler generating the code had to be replaced, and a good compiler can improve results of unchanged source code.

To make a valid comparison between 64 and 32 bit versions you'd need to compare the 32 and 64 bit version of the same DF version using the same embark by shifting the same embark between the 64 and 32 bit versions, alternating the FPS measurement to be earlier on one version with making it earlier on the other (i.e. play a bit on one, measure, move, measure, continue, measure, move, measure,...). You may want to do this multiple times, varying the world and embark sizes, as well as computer used (same computer for but 32 and 64 bit every time, of course). If the resultant FPS curve pairs show a consistent trend you may draw a conclusion. The clearer the indication, the fewer samples you need.

However, enjoy your nice responsive embark.

[Libash_Thunderhead]

Just tested the same game on 32 and 64 bit release..., they are exactly the same.

I used an i3-2120, same save file, same init.txt

[Ironbreaker]

Yes, its working good for me, no more lag of death from 120 dwarves and a refuse pile the size of a small state lol. There really needs to be some refuse pile fix, this is getting ridiculous. What do you guys do with your refuse pile when it gets too big?

[PatrikLundell]

To answer the derail question:
The two main methods are minecart quantum stockpiles and dumping. In the latter case the destination may be a single tile, a chute into magma, or an atom smasher. Worn clothing is either disposed of as per the above or hauled off by the garbage trucks (a.k.a. caravans).

[Putnam]

Wow despite being a computer rapair guy it suddenly hits me that I don't have a solid answer about why you'd get such a big increase.

Trust me, my recent internship with a computer repair place has told me that the overlap between this kind of thing and computer repair is very small. I know how a CPU works, but I don't know how it works if you know what I mean. I couldn't tell you what could be making it go wrong if it's a hard error.

[jecowa]

I wonder if even the CPU engineer knows how it works.

[wierd]

Wow despite being a computer rapair guy it suddenly hits me that I don't have a solid answer about why you'd get such a big increase.

Trust me, my recent internship with a computer repair place has told me that the overlap between this kind of thing and computer repair is very small. I know how a CPU works, but I don't know how it works if you know what I mean. I couldn't tell you what could be making it go wrong if it's a hard error.

Even then, the logical understanding of how the memory bus works (and thus why the bus width is important) or how a CPU uses registers is not common in PC repair as standard knowledge.

You and I seem to be in the same boat; I doubt I could design a CPU either.

[Max™]

I wouldn't call it major, but in certain situations it is noticeable.

I tested the same exact world-gen/seed/everything except on 32 and 64 bit.

I ran them both for three minutes and tracked info about their progress.

Code: [Select]

32 bit started: 11:21:30, hit stop 11:24:30, finished 11:24:45 on year 184.
32 bit pops:
>56349 Dwarves
>30427 Humans
>48514 Elves
>11572 Goblins
>3913 Kobolds
>Total: 150775

64 bit started: 11:27:30, hit stop 11:30:30, finished 11:30:36 on year 186.
64 bit pops:
>59593 Dwarves
>33106 Humans
>42689 Elves
>12330 Goblins
>10884 Kobolds
>Total: 158602
Then I did two runs for 300 years and checked how long it took them.

Code: [Select]

test64 start: 10:38:30, stop: 10:54:01, finished: 10:54:34 (year 300), 16:04 total worldgen
64 bit pops:
>60553 Dwarves
>32485 Humans
>51199 Elves
>36119 Goblins
>5738 Kobolds
>Total: 186094

test32 start: 10:56:30, target: 11:12:01 (year 286),stop: 11:13:24, finish: 11:14:05 (year 300), 18:05 total worldgen
32 bit pops:
>54795 Dwarves
>28097 Humans
>45384 Elves
>27181 Goblins
>8280 Kobolds
>Total: 163737
So in summary, 64 bit world-gen reaches the same year earlier, despite having significantly higher populations (23k+ in the 300 year test), responds faster to the stop signal, and takes longer to slow down as badly as the 32 bit world-gen.

This isn't directly applicable to fort mode, but world-gen is one of the most extreme examples of lag you usually encounter outside of like century old megaproject forts or 10k+ goblins and 100k trolls/beak dogs in a dark fort while you collapse it in adventurer mode, and it was easier to quantify the difference due to the bitness change.

[jecowa]

When generating a world, Dwarf Fortress creates and rejects several versions before it finds one it likes. You aren't including the time spent on rejected worlds in your results, are you?

[Libash_Thunderhead]

If everything is the same, why did you get two different results?

[wierd]

When generating a world, Dwarf Fortress creates and rejects several versions before it finds one it likes. You aren't including the time spent on rejected worlds in your results, are you?

A properly formulated seed set will either not reject at all (ideal), or will reject in a very orderly and predictable way.

In either case, worldgen will naturally control those experimental variables.

As for why civ data is different, the game seems to initialize the RNG differently than the world seed. Even on same version, same seed, same bit width gen runs, civs will have diff names, diff pops, diff host figs, et all.

[jecowa]

When generating a world, Dwarf Fortress creates and rejects several versions before it finds one it likes. You aren't including the time spent on rejected worlds in your results, are you?

A properly formulated seed set will either not reject at all (ideal), or will reject in a very orderly and predictable way.

In either case, worldgen will naturally control those experimental variables.

As for why civ data is different, the game seems to initialize the RNG differently than the world seed. Even on same version, same seed, same bit width gen runs, civs will have diff names, diff pops, diff host figs, et all.

Oh, yeah, that's right.

[Max™]

When generating a world, Dwarf Fortress creates and rejects several versions before it finds one it likes. You aren't including the time spent on rejected worlds in your results, are you?

Didn't reject at all, and yeah, the 64 and 32 bit versions put down the same basic starts from the same seeds but it plopped them in different spots which gave slightly different outcomes, but 64 bit was able to expand further and faster population wise.