Bay 12 Games Forum

There's always the classic joke about baby powder though...

Quote from: BauxiteProcessor on December 06, 2016, 01:50:37 am

My concern was that the amount of memory DF can check before it needs to do another calculation to be able to check memory might not have been large enough to benefit from increased memory bandwidth. If we think it's wrangling large amounts of memory in single chunks that's good.

Uhh... I don't keep up with Toady's programming style, but last I read he didn't even know what vectorized math (SIMD) was and just assumed the compiler would automagically optimize his code to use it. SSE is far too impractical when you're extremely OOP with massive pointer chains to follow and data spread out all over the place which makes me doubt it being used at all (yes you can use it, but it'd result in negative performance gain... err, again... yes and no... but really it works much better with linearized memory. Just load, operate, and write.).

Having more channels would really matter more on the fetching mechanisms of the CPU than DF's code (given toady is not explicitly taking advantage of this stuff) which again, hit and miss.

Well ... compilers do use SSE automatically ... they just use the single-float instructions there, not SIMD. Some compilers might do a little bit of vectorization but that is pretty rare and, indeed, the gains from that in general case are pretty marginal. In the context of DF, they'd probably have some application in weather and temperature calculations but little else.

I'm sure a person with some tools and more enthusiasm than I have could do some in-depth profiling about it but I seem to recall that with DF processor speed matters much less than your memory latency and cache size. With quad-channel you can theoretically have four cache misses going the same time but since DF is single-threaded that is fairly unlikely to give any benefit.

Also, in my experience, the only way to optimize massive pointer chains is to get rid of them.

Objects that are reserved for a task don't show up on stocks screen. That is the list of available goods, after all, not all goods. Although DF's definition of available can be somewhat creative. Objects inside containers that are reserved for a task don't show up either.

So if the books were first tasked for hauling to a stockpile and then for storing in a bookshelf and possibly the bookshelf became tasked for a store loop and then dworfs started reading the book with gusto and other such condiments. In such situation books would not show up in stocks at all, other than for very short times between being read.

Easiest way to add to the intensity and longevity of the game would be to reduce the migrant waves by a factor of five or even ten. If you get migrants by one or two instead of hordes of ten or twenty at a time then you'll appreciate them a lot more, and you obviously don't get lagged from running a fort of 200 dorfs by year 3.

I once almost lost half of my fort to a few crundles. This was in the brief period while jumping and climbing were only "extremely discouraged," not "only in special circumstances."

The crundles were stuck on a cavern wall, causing extreme pathfinding lag in the process. I decide to "help" them with a little bit of mining and perhaps some crossbow bolts or just plain militia action (where 'militia' is pronounced 'meleetia'.)

Miner digs a tunnel that's just a couple tiles away from crundles. Immediately he jumps into the chasm to try and fistfight the crundles on the wall. And by chasm here I mean a few z drop onto the cavern floor. Not deadly but quite injurely.

I order a floor to be built there to eliminate the chasm. Quite a few dworfs go there, one by one, carrying blocks and then jump into the chasm trying to fistfight the crundles.

Bridge? Same thing.

Okay, let's put down a door, or a wall there, to block the line of sight so that dorfs might do something than jump into the chasm. Nope, they all jump down.

Now the injured dorfs in the pit also catch the attention of medical staff who try to reach the site. Vengeance first, they also run at the cave beasts and jump into the chasm.

Certainly marksdworfs can handle this kind of menace? They have been practicing shooting down keas and other flying pests with some success before. Oh no, crundles must be punched in the face, not shot with a crossbow! Down they go into the heap.

Okay, let's dig another, safe, passage to the cavern floor. Of course miner decides to start it from the cavern end and, well, you certainly have spotted the pattern.

Eventually, though, some crundles get tired of just hanging around on a wall and also fall down and get mowed down by some of the less injured survivors. And some of those crossbowdorfs who have lost their ability to climb but apparently not to shoot finally get into a more productive line of action. It takes some more time but finally the crundle charade is resolved in dwarf fashion, with a massacre of innocent animals.

Of course, in post-scriptum, I also need to dig more stairs about in the caverns to rescue dorfs who somehow managed to climb or teleport on top of the vertical cliff, another 4 or 5 z upwards. But for a while I had twenty or thirty dorfs pretty much stranded in the caverns with no practical way back into the fort, many of them injured, all because they were barking at the wrong crundle.

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

Technical details aside, generally the side effect of converting to 64bit is 2%-5% speedup, very much dependent on the program however.

Also the game won't be running in "32 bit emulation" mode in your 64bit OS, which helps a tiny bit as well.

The automatic conditions on reagents/materials and products (r and p keys by default) will fill in those for you almost always correctly and get you the correct ash too (burnt wood vs logs of ash tree).