Bay 12 Games Forum

Quote from: IronGremlin on January 23, 2023, 05:24:16 am

A clock speed of 3200 mhz means you get 3 billion operations in a second

Sort of, actually DDR (double data rate) frequency quoted is twice the actual clock speed because it transfers data twice per clock cycle, so it's 1.6 billion clock cycles per second. But the actual operations like set row to read, read a column etc. take several clock cycles - let's say 15 because that's what mine takes. So it's about 10ns just in the latency for the ram chip to respond, which works out to around 33 clock cycles of my CPU unless I'm mistaken, so I'm thinking halving the memory clock would increase the inherent latency on the chip to a full 66 clock cycles.

But anyway, neither the RAM chip's latency or the delay waiting for the signal to carry through the little wires from RAM to CPU would be increased by underclocking the CPU so I don't see how a highly memory bound workload would show such a direct correlation with CPU clock speed.

Right, sorry, 3 billion distinct opportunities to request/return an operation per second, which is not the same thing as ops per second - my bad.


But we're talking like 100 ns for a round trip here. It's not "one hundred cycles" as Putnam threw out for a random example, it's certainly not 30 cycles as in your example, it's MULTIPLE HUNDREDS of cycles.


Op time and data transfer windows are tiny fractions of the total time the CPU spends waiting. Nobody talks about this part because there isn't dick anyone can do about it, because we haven't managed to make electron wave propagation any faster over those kinds of distances yet, but when you hear things like "accessing data in RAM is an order of magnitude slower than accessing data in the L2 cache" this is what they are talking about. Adjusting the RAM clock is a fractional percent difference here.


That kind of small optimization -really- adds up when you're performing tens of thousands of operations in series - I am not saying RAM timings do not matter for performance - but the moment that one operation depends on the next one to complete it becomes very meager difference. Not all memory I/O problems are created equal, hence me talking about 'latency' vs. 'bandwidth' in network terms.


Here's is how this relates to the CPU / Ram timing test:

Decrease CPU clockspeed - Program moves slower. But you have introduced other opportunities for bottleneck. A program that was not CPU bound before can now become CPU bound.

We have proven nothing with this test, save that there is a point at which CPU speed can be a limiting factor for DF performance, but this shouldn't really be a surprise to anyone.


Turn the CPU clockspeed back up, and adjust RAM timings - Program stays the same speed. But as we've established, if the RAM I/O problem you are having is one of data latency, and not one of bandwidth, adjusting the timings will have near 0 effect.

We have also proven nothing with this test, other than that our problem probably wasn't one of RAM bandwidth.


Hence, we have not proven that the program was CPU bound or memory bound - those observations are consistent with a scenario in which your problems with performance are a result of conditional execution against data in RAM. Given that Putnam has also talked a bit about how conditionals in RAM are a big problem for DF performance, I'm inclined to interpret that as the explanation until evidence to the contrary is presented.

I don't think you can reasonably claim to have a "normal" fortress if happy thoughts and bad thoughts are breaking even with each other.


There are very few bad thoughts that come from things outside of player control - like, getting into arguments I guess is one, and sure sometimes dwarves die but that shouldn't be a source of continuous bad thoughts.


Everything you do for your dwarves gives them an opportunity for a positive thought or at least prevents a negative one, so the overwhelming majority of your dwarves should have a positive thought balance at any given time, with only a few malcontents having majority neutral/negative thoughts.



That having been said - a mist generator isn't better than, say, making sure your dwarves have clothes. Both are optional, both have rather extreme effects on the mood of a fort over time, but neither one is going to make up for your dwarves living in squalor while surrounded by their friends corpses / ghosts.

No.

Machine learning would be antithetical to everything that makes DF such an amazing example of procedural generation in game design.

DF is all about hand built proc-gen - proc-gen derived from observed fundamentals.

AI is all about the machine deriving patterns from an input set for you and coming to it's own conclusions - asking for machine learning in Dwarf Fortress is like asking why someone wouldn't just take a helicopter up to the peak of Mt. Everest, it sort of misses the point of the whole endeavor.

What actual problem are you having?

If a dwarf could theoretically choose between two tasks you have no way of telling them which task to pick (with the exception of priority designations and workshop jobs).

It's sort of part of the soul of the game that you have limits on how much control you can exert over your dwarves, so generally the better plan is to achieve your goal in some way that doesn't involve explicit instructions.

Nah, it's probably just my brain lying to me about the past, that happens.

Regardless, it seems like the kind of thing that would be cool if it existed - but you'd need to slow down the game a lot for it to be enjoyable.

The new labor system is phenomenal.


There are a few clunky pieces still, but a fortress will "just work" without heavy handed intervention, and the process of tweaking things is just so much smoother with this paradigm. Just a few more little tweaks and dwarf therapist will be useless in comparison.


The soundtrack is great and the contextual music system is just absolutely fantastic.


The creature details screen and all the various subscreens are massive improvements, much better presentation of information.


Being able to see at a glance whether or not my military dwarves have actually equiped at least some of their uniforms yet is a welcome change - being able to recognize a specific dwarf is also just such a great little addition.


As much as I am eager to see the return of a persistent log, the new alerts system is actually really really great.


The organization of menus is much, much better.

Zones is a better system than rooms were. Just light years easier to use and more sensible/approachable.


Scroll wheel to navigate z-levels is awesome. Being able to see multiple z-levels at once is likewise awesome.

The settings menu instead of digging through config files rocks.

The new save system is great.

Honestly everything that was added or changed was absolutely fantastic. I miss some things that haven't come back in yet (full keyboard controls and persistent logs, mostly) but all in all the game is just way more fun to play than it ever has been before.

A question to Putnam. What was your first impression on DF source code as a developer? Was it good? Was it OK? Was ot bad?

If we have questions about code and we want someone to actually answer them in a forum where the sole author of said code is reading their response, it might be advisable to ask questions that can be answered more objectively.

Tarn's an amazingly chill human being, so maybe he'd be alright with being a little irreverent about code quality, but even so, this is his life's work - it's not like code you'd work on at your job that slowly grows into a monster that nobody really owns anymore, it's one guy's baby.  Best case they laugh a little and give you an answer like : "Well there are some gnarly bits but that's to be expected" - which doesn't tell you much anyway. 

If we're more specific and objective, we're likely to get a better response, and we don't run the risk of giving the impression that we're digging around for mud to sling - not saying that's what you're doing, just saying it's a little funky.

Here are some examples of specific, more objective questions about the code:

- What areas seem like they are most/least optimized?

- Are the techniques Tarn is using familiar patterns, or is this mostly novel?

- Is there anything interesting that you can tell us about how the project is organized?

- How approachable was the project? Do you feel like you're getting a handle on it or do you think you might be lost for awhile?