Print

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

[Libash_Thunderhead]

Well it dependes on how events are actually generated.
You test case alone didn't show any obvious evidence of which one is faster.
Try 100 times. :p

[PatrikLundell]

I don't think MaxTM's experiment provides much in isolation. If the worlds had proceeded identically it would, but when the paths taken differ you can no longer perform direct comparisons, but will have to resort to statistics, i.e. running the same kind of comparison (using the same seeds on both DF versions, but different seeds for different run pairs) and collect statistics from that to see if there is a consistent result.

[Max™]

Each world used the same exact seeds, settings, everything, and each time they were ran they produced the same output from their seed, it's only the difference between 32/64 and how they handle seed parsing that changes it.

If I pull it up right now, load the 64 bit df/64 bit world gen and run it for 3 minutes it'll get to year 186, have the same pop and everything.

Spoiler (click to show/hide)

See if you can figure out which of those runs are the 184/186 and which are the 300 year world gens.

[jecowa]

I stared at those GIFs for maybe 15 minutes.

I'm guessing the 300-year worlds are

Spoiler: Spoilers in case others want to try to guess without being influenced. (click to show/hide)

on the Top.

[PatrikLundell]

The problem is that if the same seeds generate different results, the results are not directly comparable. It's actually rather bad, because that would mean the previous rule that you'd only have to avoid rejections to generate the same world on different architectures is tossed out the door, and seeds are not portable (or portable between 32 bit Windows and everything else but 64 bit Windows, which could sort of be worked around by never sharing Windows 64 bit seeds, which is rather constraining). If that's the case, I consider it a bug that should make it high on Toady's bug fixing list (and I wouldn't mind if rejections causing different results was fixed as well, but there's s (sort of) work around for that, so it's of a much lower priority).

[kingsableye]

The results not being directly comparable doesn't mean it's not useful data. Not saying you're making that assertion, Pat, but I think it should stand that this is viable data. Though I would also have to agree with Libash based on Pat's observation, because the data points aren't directly comparable we'd need more data to make a clear argument. If we generated a list of world seeds (like maybe 20, that seems like a sufficient number to give some kind of evidence; thoughts?) and ran that list through 64 and 32bit world generators and timed each one for how long it would take to reach year 300 we could get a pretty decent comparison of performance; at least in WorldGen.

Based on my knowledge of computer processing 64bit should be fairly beneficial to DF, but multi-thread implementation could be a lot more beneficial, assuming it could be realistically implemented effectively. But that's a whole other can of worms; very long and tedious worms.

[PatrikLundell]

I'm not saying individual measurements are useless: I'm saying that if they're not measuring exactly the same thing they need to be collected, which is the same as you're saying, so we're on the same page. MaxTM's data is one pair. The number of samples needed is dependent on how clear a difference it is. A huge one might be clear after 5, while a tiny one might require hundreds. 20 sounds like a good wet finger starting point estimate (and if nothing is seen at that point the conclusion should probably be that the difference isn't significant enough to measure exactly anyway).

[jecowa]

Based on the 3-minute test, the 64-bit version performs 1% better than the 32-bit version. Based on the 300-year test, the 64-bit version performs 11% better than the 32-bit version.

[Max™]

^Yup, but I'd look at it more as a logarithmic scale, the difference at year 184 was visible, it got larger and larger consistently, hence why I say that it isn't faster so much as 64 bit doesn't slow down as much.

Those tests were all on linux btw, but given how the gap kept growing when I ran worlds for longer and longer, there is no chance that 64 bit would suddenly slow down enough for 32 bit to ever catch up.

I don't have other oses to test if seeds generate exactly the same from 64 bit linux to windows to osx, but it seemed like the change from 32 > 64 was due to the compiler optimizations partially, something like that as I recall. It's still a pretty minor difference, many sites wind up in the same place, and a lot of the variance is due to the 64 bit reaching higher populations faster causing history changes that don't emerge in the 32 bit gen.

I stared at those GIFs for maybe 15 minutes.

I'm guessing the 300-year worlds are

Spoiler: Spoilers in case others want to try to guess without being influenced. (click to show/hide)

on the Top.

Spoiler (click to show/hide)

Nope.

[kingsableye]

How did you do your tests? Did you manually time and check world gen stats? Or did you use cmd line?

[jecowa]

Maybe the extra bits letting it move data between the RAM and CPU faster.

I wonder if the 64-bit version would help any with reduced FPS caused by lava/magma or reduced FPS caused by pathfinding.

[Fleeting Frames]

Should be easy enough to test. For pathing, save on uncorking HFS, load up in 43.05 32 and 64. For fluids, similar idea.

[Max™]

How did you do your tests? Did you manually time and check world gen stats? Or did you use cmd line?

Given that the difference between them was so large it isn't a case where human error matters much.

Sat with the button ready, waited to see the clock tick over from :29 to :30, hit enter, waited 3 minutes, hit enter when it clicked over from :29 to :30, noted when it actually stopped, exported sites and pops.

Afterwards I started a run when the clock went from :29 to :30, hit enter when it rolled over to year 297 so it would end on year 300, noted the times involved, exported sites and pops.

On the 32 bit versions I had cases where the population explosions (campsites seem to remove wildlife from the roaming populations without removing the currently present populations so they keep doubling? http://www.bay12games.com/dwarves/mantisbt/view.php?id=9925 is the bug report) left the entire computer frozen at much less than the total ram available because of df hanging, on the 64 bit versions I was able to max out and use all available ram before everything froze up. It's a pretty significant overhead change which is most noticeable in situations where you would previously be slamming into fps death, now you've got more breathing room.

The most extreme lag I've induced on 64 bit is deconstructing a dark fortress with huge populations of beak dogs and blizzard men while standing in hell, it took over an hour for the collapse to finish in one case.

[Fleeting Frames]

Hm, I wonder if that bug is why sometimes I get forts with 800 gorlacks in worldgen?

...nah, probably not happening in worldgen.

Still, interesting and dangerous bug.

[Thief^]

For anyone wondering why 64-bit would be faster, it's most likely the increased register count in 64-bit mode, reducing the need to spill registers to ram in complex code (and DF is all about the complex code!), and the fact that running 32-bit code on a 64-bit OS has additional slowdown from the CPU having to switch modes on every system call.

64-bit mode also guarantees the availability of some advanced instructions (specifically SSE2) which can dramatically speed up some code, but most compilers assume SSE2 is available for 32-bit code as well these days so that probably doesn't apply (although it could explain a performance difference between the latest version on the 64-bit-capable compiler and the previous one on the much older compiler).