Print

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

[Psieye]

Do dwarves have a preference for using plants inside barrels/pots for brewing or something? I don't understand why the amount of shrooms in pots keeps changing as the brewing/harvesting goes on. I only have 3 pots for one stockpile enabled and the rest don't use any containers.

Also, every time I create or destroy stockpiles, I seem to get huge FPS lag.

Edit: I tried making a leather stockpile, in this fort where there isn't a single piece of leather to be found. It still causes lag. Bear in mind I have LOTS of stockpiles. Maybe there is merit to an FPS test on just stockpiles?

Anyway, it's getting late here. I'll have the FPS data out after I wake up. I'm unsatisfied with the test procedure though, as I was adding more stockpiles as the game went on. I can still try out various things though, so we'll see what we can conclude from this run.

[orbcontrolled]

I wanted to mention something about the geometric lag you were seeing earlier when dumping stones.

The "conventional wisdom" that I've heard is as follows: Jobs choose dwarves rather than vice-versa. If you mark 10,000 stones for dumping then that results in 10,000 jobs, and on each frame each of those 10,000 jobs iterates through your population looking for an available dwarf to dump it. The same goes for designations and items waiting to be stockpiled. Naturally I have no data to confirm this, but it would line up nicely with the phenomenon you were seeing.

In any case; instead of using dwarf-powered dumping for these experiments it might be worthwhile to use DFHack's autodump. I don't think autodump messes with data structures in any way, just changes the item coordinates, so the results should still be reasonably reliable.

I'm also working on the cat experiment someone suggested earlier. Cats modded to CHILD:1000, embarked with 20 females and 4 males. 3x3 embark, initial FPS: 199000 (High because I have GFPS capped at 25). Also, the site I embarked on is actually named "catpalace". I think it must be some sort of sign.

Good lord it is a disaster trying to herd 24 cats at 100,000 fps.
I'll post when I have some results.

EDIT: Forgot: FPS with all the cats in one room is hovering around 400. I might not even have to atom smash these things as they seem to be fighting amongst themselves.

[Mego]

If it is integer overflow, then the next step I see is to try to get the value to wrap back around. 3,000,000 or so goblets should do the trick.

It still reacts as if you gave them negative stuff even when it wraps back around.  Besides, it only takes 3 to make it overflow, so 6 would make it wrap all the way around to a positive, logically speaking.

Err, yeah. I was thinking in value instead of number of goblets, and also failed to count zeroes and got off by 3.

[NW_Kohaku]

Huh, I just noticed a big FPS drop when I *deleted* a stockpile. Specifically, I made a seed stockpile in my mushroom farming SCIENCE fort and later decided I didn't need it. Suddenly my FPS takes a hit from 120-ish to 20-ish. Now this could just be a hiccup on my system, so can someone cross check this? I'll have my saves up in a bit - almost done stocking up 100k plump helmets and I've definitely been getting FPS decay though I want to do some fair tests before drawing conclusions.

I do suspect though, that Kohaku's "remove things from vector" theory of FPS decay can apply to jobs if each dwarf is given a 'queue' of things to do in what order.

Edit: the FPS recovered eventually, possibly because I set another seed stockpile or possibly because dwarves really really want to put seeds in a bag of some sort.

I'd honestly think the best way to check for the difference between a bloated vector and some other source of lag is to just open up Task Manager, and check how much memory DF is chewing through at the time. 

My base save uses up around 360 megs of memory - when I have more objects occupying that vector, it takes up more memory, obviously.  If it fully cleans out the vectors, then when all those items are gone, then the memory should go back down to its initial state.

If you get lag without additional memory, then it can't be an overly large data structure causing that lag.

[NW_Kohaku]

I wanted to mention something about the geometric lag you were seeing earlier when dumping stones.

The "conventional wisdom" that I've heard is as follows: Jobs choose dwarves rather than vice-versa. If you mark 10,000 stones for dumping then that results in 10,000 jobs, and on each frame each of those 10,000 jobs iterates through your population looking for an available dwarf to dump it. The same goes for designations and items waiting to be stockpiled. Naturally I have no data to confirm this, but it would line up nicely with the phenomenon you were seeing.

I wasn't dumping that stone, it was a single reaction that had 10,000 reagents.  That way, it wasn't a matter of waiting for dwarves to individually carry objects one by one to a pit, I simply had to create a reaction to create 10,000 objects, and then destroy 10,000 objects. 

Besides, the point is that I have to test each individual destruction method for, basically, memory leaks, so destroying all the objects with autodumpdestroy misses the point of the experiment.

[Psieye]

Ok, now presenting my work on the plant spam fort of Operation FPS Bomb.

=== Summary ===

A fort harvested and stockpiled (without barrels) 100k plants for the study of how they affect FPS. Intermediate saves were created at certain thresholds of stockpiled plants. The worldgen and raw data for this fort is detailed in this previous post.

=== The Saves ===
http://dffd.wimbli.com/file.php?id=5954

This .zip contains saves taken at 0, 10k, 20k, 30k, 45k, 60k, 75k, 90k and 100k 'megashrooms', which are GROWDUR:3 plump helmets. All saves have no jobs awaiting (all farms empty, no workshop queues, nothing more to move to stockpiles) and the dwarves are walled in at a small meeting area. Every save is at spring, aside from the 75k save which is in summer (FPS was too low to wait for spring to come again). While the earlier saves have the same number of stockpiles each, these proved insufficient to hold the final quota of plants so later versions have more stockpiles and mined out space.

=== Methodology ===

Six farms were utilised for non-stop 'megashroom' farming with [SPEED:1], naturally legendary+5 planters. Seeds were generated by making booze from some of the harvest, using stone pots. Before the experiment began, a lot of storage space was dug out, designated and walled off in advance. This way, FPS would be saved during harvesting by only opening up each section of stockpiles when the previous one was full.

Due to the culling of the animal raws, no caravans will ever arrive and invaders were turned off. Therefore the only outside interference was the diplomat from mountain homes once the 2 hard-coded migrant waves came in. Said diplomat was always dealt with by going through the meetings ASAP. All animals in the fort were individually walled off in 1x1 cells. As per NW_Kohaku's original fork save, these dwarves don't emote, sleep, eat or drink (though they do go on breaks and have marriages).

Unfortunately, the amount of space that 100k plants take up (without barrels) as well as space to store the booze pots were both underestimated. By the end of the experiment, several additional storage areas had to be designated in new sections that were quarried out to make the stone pots. Four z-levels of this 2x2 embark are entirely filled with megashrooms and their wine - this still wasn't enough so the last of the produce spilled over into the surface.

An atom-smasher is provided in case further experiments in atom-smashing are desired.


=== Results ===

Spoiler: "Graphs" (click to show/hide)

On loading of a save, the FPS would dip down (for 75k and above, down to 2 FPS). After some time, paused or not, the FPS would recover from this dip. The FPS would then very slowly increase until, several minutes later, it stabilised. The graph shows FPS readings taken at this peak. Note the FPS reading at 0 megashrooms has a large error bar because the season switched from spring to summer too quick before the FPS fully settled.

Results from further testing with these plant saves (e.g. removing all stockpile designations) will be linked here for future convenience.
Further Results, now with item destruction to measure permanent FPS loss.
A study of cleanup during save/quit/reload.

=== Conclusions ===

The original objective of demonstrating "having lots of plants = FPS damage" was successful. The extra stockpiles were only added from the 45k save onwards, but the FPS decay curve clearly starts before that. The disjoint in the curve between 30k and 45k is due to stockpiles eating up further FPS - this deserves some further investigation. The memory graph was included for completeness, it shows nothing unexpected - more items = more memory used. Remember that as the number of megashrooms stockpiled gets higher, the number of wine pots stored also increases so you can't directly translate that graph into a "plants take up this much memory" formula.

It was a good habit to be checking memory together with FPS though, as future tests will be trying to see how job spam and stockpile spam affect performance.

[Shadowkx]

A couple things:
1) Paging.  you have no control over that (unless you want to disable paging entirely) and most likely neither does the program you are executing.  It is a OS level thing, it allowed earlier computers to get around the limitation of not having enough RAM to run a program and still lets user get around want to run 4GB worth of applications with only 2GB physical RAM.  In windows 7 you can look at the task manager -> Processes tab  and enable Paged Pool (show memory eligible to be paged), Page Faults (number of times the required memory was not in memory and had to be retrived) and PF (Page Faults) Delta ( number of page faults since last update).  This will clearly show that DwarfFortress.exe ends up paging a lot.

2) Multi-threading is not equivalent to making the program multi-core friendly.  A great example of this is in Python.  You can mutli-thread to your hearts content but the implementation of python only allows one thread to be active at a time per interpreter.  It is great for processes that need to wait on something else like IO or network but not so great getting more cores active in a cohesive process.  In fact i bet a measurable amount of FPS is lost on multi-core systems do to interrupts and context switching.  Setting the affinity to just one core should stop some of that.  I agree with the line of thought that Toady will have to multi-thread and make use of multiple cores before 1.0 is reached barring some new break through in processor architecture.

3) This is the worst way to profile an application.  There exists profiling tool of all sorts that will tell Toady exactly where CPU time is being spent and more importantly where wall clock time is being spent.  When he gets around to focusing on speeding up processes research like this may be helpful but i would bet that 1 day fiddling with a code profiler would be of much more benefit then reading our (or should i say your?) research.  That being said i don't think that is high on his todo list so this research is a great help to players who want to know what to avoid so they can enjoy their forts longer, like me.   

So thanks for running this.  I am watching with interest. 

[mogthew]

2) Multi-threading is not equivalent to making the program multi-core friendly.  A great example of this is in Python.  You can mutli-thread to your hearts content but the implementation of python only allows one thread to be active at a time per interpreter.  It is great for processes that need to wait on something else like IO or network but not so great getting more cores active in a cohesive process.  In fact i bet a measurable amount of FPS is lost on multi-core systems do to interrupts and context switching.  Setting the affinity to just one core should stop some of that.  I agree with the line of thought that Toady will have to multi-thread and make use of multiple cores before 1.0 is reached barring some new break through in processor architecture.

This is C++, not python. Real threads exist and ARE usable. There are plenty of proper threading libraries for C/C++, not least of which is pthreads, which is very easy to use. I would bet that a NON measurable amount of fps is lost on context switching and interrupts, especially on hyper threading systems.

Making use of multiple cores is easy, making sure things are synchronized properly may not be so much, but there are good ways around some of this stuff. Also, changing to 64bit should not cause problems unless toady is doing some funky stuff with pointers/memory allocation (sizeof?) or using pointers / int32's interchangeably.

Bottom line, there's plenty of optimization available, but you're right in the sense that a good code profiler would likely be more helpful than anything we can do.

[arphen]

also :
pagefile
implying i'm on windows
implying i have a swap partition
laughinggirls.jpg

[NW_Kohaku]

Well, when I tried to make a bug report, the response was that the report was closed, and I was told to bring proof in the form of doing things that take several hours that Toady could confirm or deny in seconds, because, as Footkerchief put it, the burden of proof is on the players reporting.

So, it's an inefficient brute-force way to get results, but it's what we've got. Besides, brute-force calculations are practically a trademark of DF...  (I'm looking at you, fluid flow calculations.)

[white_darkness]

Irregardless it's still an interesting read, with quite a few educational bits.

[NW_Kohaku]

Anyway, Psieye, simply having more objects taking up more memory or causing lag isn't really the point - I've proven that a long time ago.

No unnecessary items in my fort?  400 FPS.
1,000,000 extra objects on top of that? 4 FPS. 
Trying to eliminate 10,000 objects by reaction when you already have 1,000,000 extra objects on the map? 0.0000556 FPS (or .2 Frames per Hour)

The lag caused by objects is a known issue, which I'm sure Toady is well aware of.  What I've been looking for are ways in which permanent FPS decay can creep in.  As in, they lag the game long after they have been completely eliminated.  Dead creatures are an obvious suspect, but I've been building my way up, looking for other sources of bloat in the save files, so that I can finally point to this and definitively state that either these people who were trying everything they could to minimize their fortress in order to keep FPS high were leaving something out that they should have atom-smashed, or else that there is some sort of systemic bug that needs to be squashed.

You should also try making cheat reactions for everything, and reducing the number of objects you generally have.

For example, make a custom reaction that generates stone pots from nothing.  Then alter pots to have a capacity of 100,000,000, which should be enough to store 10,000 items at a time.  Then you only need a hundred pots to store a million items.

[Shadowkx]

@ NW_Kohaku: Please don't get me wrong i am a fan of what you are doing.  As has been made clear on several occasions Toady does not consider optimization a priority at the moment, mores the pity as i lose more mature forts to FPS issues then anything else.  I am merely saying i believe this has more value to the players then to Toady.  It is a pity that the burden of proof for something that could be easily found by someone with access to the source code is on those with no access.   If you can get something across that will get any kind of bug fix for FPS issues you will be doubly my hero. 

@ mogthew; yes this is in C++.  CPython (the standard implementation of python) is written in C, yet even at that low of a level there are issues getting the multiple threads to utilize multiple cores.  It is a non-trivial problem unless your only goal is to max out a number of cores.  Once you start sharing variables between threads it get complicated.  Python was merely an example that suffered from multi-thread != multi-core, it was not meant to imply i believe the project was implemented in python.   

@arphen: As you say, so it is.

[rtg593]

Bah. 5 new pages since I last checked this thread. I'll read em later.

Interesting to note, DF appears to check every item individually on the stocks screen as you scroll through it. I have 5000 stone in my current fort, I get a 5-6 second lag when I press the key to move highlight stone in stocks. Move off, back on, same lag, so I guess it recheck every item.

I'd hate to see your lag, with a million :p

IDEA: after you destroy an un-Armokly amount of stone, check the stocks screen, see if it still has a horrendous lag, even if you have no stone...

Edited to fix phone autocorrecting :p

[NW_Kohaku]

I'd hate to see your lag, with a million :p

Basically put, I have to find ways to do things without having to "look" at workshops or actually put my cursor over specific items in the stocks menu.

(Looking at the stocks menu is helpful, since it's an at-a-glance view of how many items are in my fort, but I have to be very careful to never actually cursor over the "goblets" or "stones" list item.)

Also, "q" and "t" are off-limits when I get going, so I have to queue up all my actions.

Most of the time is actually spent just letting the thing run on auto-pilot, though.  A year takes about an hour with no lag.  With lag, I have to just let it run all day or all night in the background. 

I'm still vaporizing stone in the background right now.  When I try the melt test again, I'll have to do it by waiting for late winter to come before I start making the melty stuff because a million melted objects are still a million objects, and do NOT get cleaned up with the season.  (So magma melting stone = bad idea, use atom-smashing instead.)