Print

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

[Mesa]

The less 32 bit libraries I need on my 64 bit machine, the better.

Also multithreading is not a case of "maybe" if you guys ever want remotely acceptable performance when all the extra features get added and end up being simulated, but I realize how much of an undertaking it would be to actually implement.
But it's not something that can be delayed forever lest the game becomes so slow you won't be able to appreciate all the simulation, especially in worlds that are larger/longer-lived.

[Yawzheek]

The drawback is that pointers are twice as large, which makes programs use up more memory in turn.

Clearly I have much to learn. Am I to assume most of DF is 16-bit chars?

Sorry I have stupid questions, but it's interesting and educational.

[decev]

The drawback is that pointers are twice as large, which makes programs use up more memory in turn.

Clearly I have much to learn. Am I to assume most of DF is 16-bit chars?

Sorry I have stupid questions, but it's interesting and educational.

DF is a big program and surely has a large number of data types including chars (8bit) shorts (16) integers (32), longs (64) pointers (64) etc etc etc. What you see on the screen is the tip of the iceberg.

Pointers used to point to one of 2^32 memory locations, now they point to one of 2^64 memory locations, so they are bigger. The more you know!

[Illyon]

Now, speaking from an effective point of view, what does this upgrade mean for the end-user? I've seen talk about worldgen not crashing halfway through, but I have not encountered any problems with that in the past. Though only once, I did set the largest world to generate for the longest history and after roughly an hour it was finished. Did not look like it crashed on me while I was not at my PC.

In the 64bit test release I also tried a 16x16 embark square. After a good ten minutes of loading, I in fact managed to embark. FPS highs of 15 though, drawing something between 3GB-4GB of my RAM.
Would the 32bit version have crashed trying to comprehend it? Is the low number of FPS normal or may I blame the giant riversystem (including that beautiful waterfall) I embarked on? And if the upgrade to 64bit also increased the amount of RAM it can use, what exactly is it used for?


I've tried looking for the effective difference between 32bit and 64bit programs in the past, but for some reason I can only find people answering with the difference between 32bit and 64bit OS. Or people being ignored.

[Admiral Obvious]

It does mean an upgrade for what the user is capable of doing.

A 32 bit system/program runs out of memory at around 3.8 GB of memory usage, because it runs out of bits to actually put into said memory.

Your game would have for sure crashed once it hit the magic 3.8 gig mark.

More RAM is used, so the game has more space to add stuff on to, like in the most simple case, world generation, larger world's require more space to assign everything, and that's not even counting the history that's applied on top of it.

It also in theory should help with FPS death in larger forts.

What 64 bit won't/shouldn't do would be to actually run the 4 GB of memory through at any reasonable speed (ex. A 16x16 embark), since any changes must be handled by the processor, then fed back into RAM, so it can do another calculation after that. The key difference is that it CAN run now, with more than 4 GB of RAM. For higher performance, you need a faster unit (higher clockrate, usually), a bigger buffer (effectively more RAM/working space inside the processor), or multithreading.

If you want better program specific performance, you are going to have to multithread, which is a whole other can of worms from a programming perspective, which essentially means core 1 of your processor, for example would handle movement, while core 2 handled projectiles in flight, and core 3 does something else, like simulating the damage caused by that projectile impact.
If multuthreading was a thing already in place, it's probable that water movement would be on a seperate core, and the FPS wouldn't tank THAT bad, depending on your system (my processor had 8 logical cores, for example, meaning it theoretically can do 8 single threaded things at once, or a multithreaded program that has 8 threads, until it reaches over 8 threads, where it's going to delegate stuff to core 1 and up again, balancing the work load [if it's done well/right]).

Multithreading usually won't help those with single core processors, or in most cases, those with dual cores, since core 1 usually has to handle the OS.

[PatrikLundell]

A fair bit of overlap with what Admiral obvious posted while I typed, but not a complete repeat...

The Windows 32 bit version would have crashed on you, since it could address a maximum of 2 GB. With a Large Address Aware patch it would be capable of addressing 4 GB theoretically, but about 3 on Windows, because Windows hogs a large part of the address range for its own use. Thus, that embark would crash before finishing the embark. Even if all 4 GBs were available, the game would likely crash somewhat later as more data was generated.
15 FPS actually sounds rather good for such an embark (although I've never tried). However, it only goes downhill from there...

What's DF using the memory for? Well, each embark level tile consists of 48*48 fortress level tiles, and these are stacked to different depths in different embarks, but can probably go well above 200 levels on a thick one. A 16*16 embark is 256 times that size. Each little tile has a state that will at least contain what it consists of. You've also got fluids sloshing about, creatures moving, items moving (falling or pushed by fluids, moving in carts...), each creature also has state information. Each tile of exposed surface (above or below ground) has to keep a state, vegetation has to keep a state,... In addition to that, there's a world outside of the fortress in which stuff happens.

The difference between execution efficiency between 32 and 64 bits: generally insignificant. The additional address space is what 64 bits brings to the table, with performance effects just coming along for the ride. On the one hand pointers twice as large requires twice the band width to move to/from memory, so an application that mainly shuffled pointers back and forth would probably be a bit slower. On the other hand there are some operations that are available/more efficient in 64 bits, so programs that would happen to be heavy on those things might get a speed increase.
However, my first assumption when someone says the 64 bit version is noticeably faster than the 32 bit one is that it would be due to the switch of compiler in 0.43.04: any valid 64/32 bit comparison would have to use the same save (from the same starting point) in both the 32 and the 64 bit version of 0.43.05 on the same OS, with comparisons between 64 bit 0.43.05 and 32 bit 0.43.03 being invalidated by the compiler change.
Finally, one bit size being faster than the other on one OS does not automatically mean it's going to be faster on another OS.

[Yawzheek]

Pointers used to point to one of 2^32 memory locations, now they point to one of 2^64 memory locations, so they are bigger. The more you know!

Definitely, and thank you! I had it all completely messed up and obviously need to get more into computer architecture haha! I was wondering where, "double the size" came from, since I knew a pointer on my hardware is a 32-bit object, and my (by now more than obvious lack of) knowledge of a char being 8-bits, and knowing at minimum DF used extended ASCII, I foolishly related the two and assumed this meant a step to wide characters or something else completely different. Even more confusing since that would by association mean quadruple the usage and-OH MY GOD it's all so confusing.

I had read somewhere that 32-bit programs could only utilize a maximum of 2GB RAM, which made sense as I intentionally caused a memory leak in some basic console programs just to see what point it would crash, and sure enough it was just shy of 2GB on a 64-bit machine, so foolishly assumed it likely to be true. Trying to understand it all and what it means, but it's tough

[Miuramir]

Most consumer grade PCs are limited to a maximum of 32G physical memory. Servers can go up to 128G.

Pedantic nitpick: Modern servers can go *far* above that.  Each Xeon E7 CPU socket, of which you could have up to 8; can connect to up to 4 "Jordan Creek 2" memory controllers.  Each controller can control up to 6 physical RAM slots.  Each physical RAM slot could theoretically have up to a 64 GB stick in it.  8 * 4 * 6 * 64 GB = 12,288 GB = 12 TB of directly accessible RAM. 

I'm not actually sure anyone currently makes a specific server that does that; the ordinary desktop / tower Dell workstations we work with top out at 16 slots of 64 GB = 1 TB of RAM, and given that would be a $42k workstation, no one I know fills them up due to cost even though it's a simple radio-button stock option on the Dell site.  Still, we don't usually bother with less than 32 GB of RAM these days, and 64 GB is reasonably common for serious work. 

Side note regarding other discussions about "width" vs. "height" on parallel processing and multi threading: said workstations are routinely available with up to two, 22-core processors (although, again, overpriced; the largest one I've personally ordered was 2x20 = 40 CPU cores, and that was for a special case).  Yet no one core can go above about 3.7 GHz, and that only on the lower-core designs; 3.6 in Turbo mode when using only some of the cores on the big ones.  Most of the advantages these days are in "width", and DF will need to take advantage of that some day. 

[Thief^]

There's a lot of confusion about how much ram the 32-bit builds of DF can use. The reason is... it depends. The simple answer is that the limit for a 32-bit program varies between 2 and 4 GB depending on your system: on Windows, access to over 2 GB of ram requires the DF executable to be patched as large-address-aware* and running on 64-bit Windows**

DF can easily go over the lower limit of 2 GB, and can even hit the upper limit of 4 GB in some circumstances.

* anyone know if the new compiler used for 0.43.05 sets this by default?
** except for some obscure settings on 32-bit Windows which have a tendency to make the system unstable (from experience)

[Bumber]

* anyone know if the new compiler used for 0.43.05 sets this by default?

Is the new compiler even used for the 32-bit version? I mean, I guess it probably is if people were having problems on 0.43.04.

[PatrikLundell]

The new compiler is used for 0.43.04 (as well as 0.43.05 32 bit). Things went wrong and trashed the previous compiler's installation, so that one cannot be used any more.

[Thief^]

Specifically, the old compiler was Visual Studio 2010 and the new one is Visual Studio 2015.

[ORCACommander]

and with visual studio you have to actually change a property on the project's settings before it will compile to be LAA

[TheBiggerFish]

PTW.