Print

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

[Amalgam]

I've done an experiment. The purpose: to determine how severely map area affects framerate, in matematical terms. Put simply, I've embarked on a 16x16 (area 256) site with no fps and recorded an estimated average of the fps I got: 110. As a control, I embarked on a 4x4 (area 16) site and recorded the same thing: 350. Those estimates are as accurate as I could get them with the fps counter constantly flickering, I noted the lowest common value in tens and the highest value in tens and went with a middle value, basically the difference between the two values divided by two and added to the lowest value. I'm awful at math and it's been a while since algebra so I'm not sure what to call that! I've done my best to eliminate any variables by lowering the priority of certain processes that were occasionally eating up cpu cycles and raising the DF's priority to "above normal" - the highest I could go without experiencing interface lag. Both embark sites were in a rocky wasteland with no water whatsoever, though the 16x16 area had more z-levels. It is incredibly hard to find a 16x16 site that is completely flat, but as far as I know z-levels only come into play when pathfinding is involved, and my dwarves were simply milling about the wagon in both instances. One thing is certain: There is very significant slowdown on larger maps that is not caused by your dwarves pathing any great distance, whatever the cause.

This is where you guys come into play: you need to do the last step. As I've said, I'm terrible at math and I can't figure out how to determine a relationship between these results, so I apologize if I'm overlooking something obvious. Maybe it's too abstract for me. In any case, I'm fairly certain someone with a little knowledge in math can come up with something. The only thing I've figured out is: for an area 16 times larger, fps will be altered by a factor of 0.314 (31.4% I guess), or nearly a third as fast. There is definitely not a linear relationship here. Two things to figure out:

• How much does a single local tile lower fps?
• What are the expected fps values for a 6x6 embark area? What about a 4x4 one? 3x3, 2x2, 1... This would be useful for purposes of comparison.

Again, sorry if I'm being an idiot. Help would be appreciated!

EDIT: Ugh. Kinda tired >.>

[ed boy]

Well, let's assume that on a featureless map like what you had, FPS follows the following equation:

f=kl^me
where f is fps, k, l and m are constants, and e is the number of embark tiles.

when e=256, f=110
when e=16, f=350

when e goes up by a factor of 16, f drops by a factor of 3.18.

I would need more experiments before I could calculate any values.

[MrFake]

You'll have too much variation in sites to get anything accurate with only two maps and two data points per map.  Z-levels, weather, creatures, idle dwarf behavior, finicky processor, alignment of the planets, etc.

Bar an accurate sample, you can just embark on a good number of sites and note the statistical measures of the FPS for each: mean and standard deviation are typical, mean is appropriate for something this coarse.

What you're calculating is an average.  Since there's no proper statistical measure for the average between minimum and maximum values, it's just a plain ol' average.  Since it's very possible that you captured outliers, then it's also very possible those aren't very accurate measures at all (please don't take offense; it's not wrong, just not complete).  A better method is to take many FPS readings for each map.  Just sit and watch the FPS counter and note down every number your eyes register (a precision of 10 FPS is perfectly fine).  After you've written down a good number of them, take the average of them all.  That's a fair measure of FPS for each map.

To relate this to map size, then embark on a number of NxM maps with a lot of variation: water, magma, HFS, chasms, aquifers, z-levels, biomes, civs, and pets just for the hell of it.  With that, you have an average for the FPS as related specifically to map size (by the way, you can create a distribution for each of these measures to get a better idea of how the numbers skew).

Finally, to create a relation between map sizes to FPS, you need more than 2 map sizes.  Two can only give you a linear relationship at best.  Three is necessary for anything non-linear.  Five or more is good to verify your model (like ed boy's).  To simplify things, you can discard multivariate map sizes (NxM) in favor of map area, but that's a critical assumption.

[bluea]

You might be happier with this method:

Prior to embark, buy 7 picks, set 7 miners. (+ food, beer) Make sure all the FPS limiters are turned off.
At embark, pause. Designate a large column of staircases from ground level to the bottom right next to the wagon. Shift your display to the very bottom layer designated for digging.
Start a stopwatch while unpausing.

The instantaneous FPS flickers up and down for all sorts of reasons - but you should get pretty consistent wall clock times given identical starting positions.

[Amalgam]

Heh, thanks everyone! I was actually pretty stoned last night since I'd been awake for... What, 16 hours? And that after hardly getting any sleep the night before. I noted values in tens that looked like outliers when doing the average, so I think it should be fairly accurate, but I'll probably discard that anyway. So basically, I just need to get the mean of the estimated averages for several sites of the same size to conclude the fps for a site that size? I'm a little unsure about embarking in a site with magma or chasms, I'd assumed those were variables I'd want to eliminate... Would I really get a more ideal value if I averaged those too?

Also, I'll try to get some samples for some areas of different size, if that's what you need. Does 5 different samples for 4 different map sizes sound thorough enough or will I need more?

EDIT: Oh, also. I found in a previous experiment that water volume is the main culprit of lag when embarking on a stream. A 16 long brook probably brought my fps down by 50... For those who really want a wide river it might be ideal to squish the map size down to 3-4 tiles or soso you only have a small segment of it on site, and make the map a little longer to compensate for lost space if you want.

[gtmattz]

you may want to look into the nanofortress utility, as it allows you to embark on a 1x1 area, and with that in mind you probably want to check out embark anywhere as well, and might as well see what kind of FPS impact you get revealing everything using the reveal tool. could get a lot of useful data using those tools to kind of get a baseline estimate of the way each feature impacts overall framerate.

[Amalgam]

you may want to look into the nanofortress utility, as it allows you to embark on a 1x1 area, and with that in mind you probably want to check out embark anywhere as well, and might as well see what kind of FPS impact you get revealing everything using the reveal tool. could get a lot of useful data using those tools to kind of get a baseline estimate of the way each feature impacts overall framerate.

Heh, thanks. I'll probably embark on some ocean or mountain peaks. Now I think about it, taking samples with different variables might give a better result, since my samples could still have some unknown variable throwing things off... Best to just average them all, right? I'm most definitely not a statistics expert, and I'm still not sure how many samples I should take.

[Grax]

Guys don't forget about zlevels.

All that speed strictly depends on the stone volume on the map.

[ed boy]

In fact, let's do this in even more detail.

Instead of considering FPS, let us consider SPF.
Let us assume that everything in the map - be it water, dwarf or empty space - takes a certain time to be processed, and the sum of these times is the SPF.

What we should ideally do is log everything on the map and the SPF, so we try to give values to the individual items, so we can mathematically predict FPS as fortresses progress.

[Flaede]

I like where this is headed. Even a rough idea of what features contribute what to the crawl in large fortresses would be good.

That said, I'm worried that no one will want to do this AGAIN once the new release comes out. I know it's not for a bit yet, but it keeps getting closer and Ihear it will change some of these interactions.

[Amalgam]

Well, I'm still not sure what direction to go with this. Or maybe I'm just lazy. Or maybe I'm too sleep deprived to be trusted with anything more complex than basic arithmetic.

Now that I've set this in motion, if anyone more competent wants to give this a go I'd be delighted. Any volunteers?

[MrFake]

Given the data, I can generate a model based on the map size, and fit the data to the model for a sufficient mapping between map size and FPS.  But that's the easy part.  Someone else would have to go through the slog of testing maps.

Guys don't forget about zlevels.

All that speed strictly depends on the stone volume on the map.

Stone, as in natural walls or stone items?  The stone items don't exist until dug.  For that matter, it's possible most of the natural walls don't technically exist until designated for digging either, since the game appears to generate the contents of natural rock only after it's been designated.

Immediately after embark, most of that is moot anyway, but it's true that z-levels can and will affect FPS.

In fact, let's do this in even more detail.

Instead of considering FPS, let us consider SPF.
Let us assume that everything in the map - be it water, dwarf or empty space - takes a certain time to be processed, and the sum of these times is the SPF.

What we should ideally do is log everything on the map and the SPF, so we try to give values to the individual items, so we can mathematically predict FPS as fortresses progress.

That's like trying to model Earth's weather.  There are just too many variables, too many interactions, too many possibilities for how all those crop up during play.  Not everything has a distinct time t to process, since they may "process" in more than one way or at an asynchronous rate.  That makes way too many bases to cover.

[Grax]

but it's true that z-levels can and will affect FPS.

That. I mean that.

[Amalgam]

I'm confused why map area affects framerate at all. I'd thought that a larger map would just consume more memory and only eat up cpu if your dwarves are pathing large distances. On a 16x16 map I noticed there was a *lot* more wildlife, almost immediately there was at least 15 animals on the map, and it seemed like every time a new animal arrived there would be a spike of lag (similar to how migrants generate lag), which seems odd since as far as I know they don't actually path anywhere, just meander around. One of my theories is that an immense amount of wildlife and vermin meandering around could be generating lag, which doesn't seem too implausible since I've observed many idling dwarves in my meeting hall slowing things down considerably. Thoughts?

[chewd]

Something i noticed is that the -shape- of the map seems to make a difference.

try this... make a map that is 3 X a lot
and make one that is a lot X 3

XXX
XXX
XXX
XXX
XXX
XXX

vs

XXXXXXXX
XXXXXXXX
XXXXXXXX

They both cover the same area, but IIRC map 1 will get much better performance.