Print Page - !!SCIENCE!! Thread: Operation FPS Bomb

Dwarf Fortress => DF Dwarf Mode Discussion => Topic started by: NW_Kohaku on March 14, 2012, 09:33:28 pm

Title: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 14, 2012, 09:33:28 pm

For those who want to play our Home Game, I'm putting saves up on DFFD. They include annual saves for each experiment:
Fork Save (http://dffd.wimbli.com/file.php?id=5883)
Boulder Experiment (http://dffd.wimbli.com/file.php?id=5884)
Goblet Experiment (http://dffd.wimbli.com/file.php?id=5885)
Atom-smasher Fork Save (http://dffd.wimbli.com/file.php?id=5886)
Atom-smasher results Save (http://dffd.wimbli.com/file.php?id=5926)
Large and Small Contraction Experiments (http://dffd.wimbli.com/file.php?id=5906)
Medium Contraction Experiment save (http://dffd.wimbli.com/file.php?id=5913)

If someone wants to either help run some alternate tests, or else wants to try just continuing some of these experiments for another 10 or 20 years to see if you can get some further FPS degradation, that would help.

Initial Conclusions:

Item count plays a clear and present role in FPS decay. The game decays in FPS to unplayability around 100,000 items. FPS decay seems to be sub-geometric.
Dead things take up memory forever, and contribute to FPS decay.
Consuming items in reactions takes up significantly more FPS drain than the act of creating them.
Destroyed or consumed items, except for creatures that are listed as dead, are properly removed from play and take up no memory and produce no lag.

It is possible that changing the container class for items from an STL Vector to a Deque or custom container class may result in a faster game without having to significantly change aspects of the actual game.

Purpose:
Because of a certain thread (http://www.bay12forums.com/smf/index.php?topic=104450.0) where I postulated that a potential reason for unavoidable fortress entropic decay might be the data structures Toady is using in maintaining an index of all items might be a simple giant item index vector, which may actually never get any sorting, I now have to come up with some sort of proof of concept to actually get a bug report posted.

As such, I'm announcing Operation FPS Bomb, a !!SCIENCE!! project that attempts to understand how the data structures DF uses work, and can be better optimized.

Hypothesis:
Items in this game are tracked in an "Item Index Vector", a giant vector of items that just never really gets cleaned up, and as the game goes on, this vector keeps on getting filled up with items that, even when they are destroyed or permanently removed from the map, are still taking up some sort of reference slot in memory, and the game keeps on checking past them.

This would lead to the inevitable entropic decay of forts, the behavior that people have been complaining about killing even forts where players take every possible precaution and atom-smash all unnecessary objects. If even atom-smashed objects leave a "memory footprint" for lack of a vector sorting, then they will still cause a (lesser) degree of lag, even when they are completely destroyed objects.

Experiment:
Modded dwarves with no need to eat, sleep, drink, or do much of anything will have 21 custom workshops. 20 will all be doing the same thing, and the 21st workshop will be producing a single stone object repeatedly for the duration of the experiment. (This is to control for a possibility of a vector truncation in the case that large numbers of objects being removed will damage the

In the control, the 20 work dwarves will be performing a "Do Nothing" task with no reagent or product. It basically just keeps them sitting at a workshop busy without doing anything.

As the independent variable, the 20 work dwarves will perpetually alternate between a "create 20 stones" reaction and a "destroy 20 stones" reaction. This will create a large list of created and destroyed objects which, if cleanups took place, would result in no different FPS drop than in the control, but if my hypothesis is correct, will result in a noticably lower FPS than the control.

The experiment and control will run for 10 years to give the game enough time to make an appreciable difference.

I will also be doing several other experiments to see if different behaviors make a difference in how FPS degrades over time - magma destroying and atom-smashing have been reported to not fully "destroy" items in memory, so I'm going to try another experimental run with atom-smashing, and one with magma if I can get around to it.

Data:
I have set up my experimental fort. 21 "Sweatshop" workshops are built, and 16 dwarves have arrived. I am not going to start the full experiment until the start of year 2, which will be the forking point between the control and the experiment (so that the initial setup of the fort does not come out different between the two).

Unfortunately, I didn't do anything to stop dwarves from going "On Break", and there are some dwarves that still aren't working in their sweatshops like good zombie laborers. Useless curs! I don't pay them nothing to stand around talking, I pay them nothing to do my precious "do nothing" task forever!

I also forgot to custom-generate my world with no caverns, so there are probably some giant cave spiders lurking around, spitting webs, and doing some slightly random things to FPS. Hopefully, several years of item-creating will outweigh any cave spider webbing, and it will be roughly equal between both the control and the expermimental versions of the fort, anyway, so this shouldn't be too large an impact.

I have had to set my max FPS to 300, and I still manage to have full FPS initially.

However, as soon as the first caravan arrives (which I have built no Trade Depot for), my FPS drops to below 250. Even after leaving, it is at 275. This already starts to confirm the hypothesis, as I have experienced permanent FPS drop for simply having a merchant caravan walk on the map.

Spoiler (click to show/hide)

I hit the new year, and didn't get all the dwarven immigrants I wanted. I guess I'll just make do with what I have. Only 16 workers total, making and destroying 20 stones repeatedly forever.

Spoiler (click to show/hide)

I am working on the experimental version first. All regular workshops have their new orders:

Spoiler (click to show/hide)

FPS is more variable than it really should be - it must be some crundles hopping on and off the map down in the caverns, or some wolves moving around up top. FPS goes down to 220 and then back up to 280 again.

Year 2 caravan has arrived. FPS dipped to 210, occasionally going down to 195.

Start of year 3. FPS remains around 210. FPS seems to go up when I let DF run in the background while I'm typing these things. If I am typing, and I click back, it's back up at 250, but then immediately starts dropping again back down to 210. I guess the rendering of frames takes up some of the FPS.

Year 4. FPS is dipping down to as low as 180 now, but it still springs back up to 260. I guess there are too many crundles down there fighting it out with GCSes, and it's making these FPS readings a little too variable. Hopefully, if I can just keep the simulation running a little longer then the FPS will drop enough that the oscillations from that stuff will be drowned out more by the abuse I'm putting on the data structures.

Ugh... the game paused as one of the merchants apparently went berserk for no apparent reason instead of just sitting on the edge of the map and doing nothing like a good merchant who comes to a fortress that has walled itself in, and has never traded with you before, anyway.

Apparently, the guards had crossbows, the berserking merchant never stood a chance, and was promptly pincushioned with silver bolts. A yak cow also died, and there's now a bunch of useless trade crap sitting on the north end of my map. It's only about 40 items, however, so it shouldn't be too much of a drag on the FPS, considering the thousands of stone I already have.

For some reason, the bookkeeper seems bugged. He's been working nonstop at "updating stockpile records", and has hit legendary long ago, and is flashing purple, but I'm still at lowest precision in my stocks... I've finally gotten it working by unassigning my bookkeeper, unassigning the office, and then reassigning both.

... and the stupid berserk merchant just came back as a violent ghost. I had to make a craftsdwarf workshop to slab the stupid berserker. Amusingly, one of my workers was being attacked by the violent ghost the whole time, and didn't even stop working thanks to the NOEMOTION token. Her blood is splattered around her workshop, but she only seems to have a broken lip, and worked straight through it all.

FPS dropped as low as 150 when the caravan was on the map.

Year 5. Some of the merchants are still on the map for some stupid reason. Apparently, they got into a fight with a local wolverine. They might go berserk and start killing each other again, and then I'll need another slab... *sigh* why can't the other bugs leave me alone while I'm hunting the bug I'm after?

The merchants this year aren't going home, either... Some of them started going "stark raving mad" and attacking their yaks.

I'm building a trade depot now just to see if that stops them from behaving so buggy. Apparently, those stupid diplomats will never leave until they either die or speak to you, and walling them out is not an option (and when I un-walled my fort, I had 3 years worth of diplomats talk to me)... I have another bug report to make...

After un-walling my fort, I actually have regained almost all my FPS. This implies most of my losses in FPS were because of stupid merchant caravan problems in the first place.

I am at the start of year 6, so I have 5 full years under this experimental run.

I'm aborting this run, since I have too many silly things going on that have been mucking up the results. I'm reloading this from the fork again.

I'm going to try going back to the fork point, and restart this whole experiment with creating and destroying more stones at a time, while at the same time, not having my fortress walled up.

I've raised my maximum FPS again to an unreachable 3000 instead of 300. That way there aren't readings that are "off the charts" for FPS anymore. Restarting at the fork, I have an initial FPS of 400.

After letting it run for a game month, it's already down to 300 for some reason, although all I've done is set up a trade depot.

Caravan arrived. Just before it arrived, I was down to 260 FPS, after gradually dropping down from 300. When the caravan arrived and set up shop, it was down to 230 FPS. Then all my dwarves apparently smelled caravans at the trade depot, and half my dwarves decided to go on break all at the same time, and it shot up to 600 FPS. As soon as the caravan left, FPS went up even higher. I'm tapping 650 now.

Now it's year 3 (year 2 of experiment 2). FPS back down to 380, but it shoots up to 550 at times, especially when I leave it in the background to type something.

Year 4. FPS swings between 260 and 600. Mostly stays around 500, but it dips down to 300 or so at the turn of Autumn, but back up to 500 just before the caravans come. 350 while the caravans are here. 250 when they leave. 300 for all of winter. Winter seems to be the laggiest time of year.

Year 5. Game still running around 500 most of the time. Drops to 300 for caravan. Dips just below 180 at times as they get ready to leave.

Spoiler (click to show/hide)

Year 6. 480 most of the time, but it still swings up to 550. 320 during caravan.

Year 7. I'm only running this now to get 10 years of data. It dips as low as 300 or something occasionally, 200 for parts of the caravan, and then runs back up to 500. The average annual FPS is basically remaining stable.

Now, with year 11, the tenth year of the primary experimental run, I have an average FPS of 300 early in the year, going up to 400 and in the faster summer months, 500 again.

Basically, the run is over, and FPS has remained relative stable with no major degradation over the course of 10 years of playtime. This means my experiment has not reproduced the results that people were reporting earlier.

A poster in another thread named "o_O[WTFace]" suggested something that is worth investigating: I've been using stones, which have no particular data applied to them, and as such, I'm going to try running the experiment again, this time creating goblets instead of stones.

Starting year 2, the game is now flooding with announcements of masterpieces (thanks to me making the entire race legendary masons, and basing the reaction on masonry).

And it's getting really boring... I'm still not doing whatever it is that causes the gradual FPS death of forts that everyone always experiences when they make real forts, because I can't sink FPS below 200, and it goes through most of the same seasonal highs and lows.

Next up, atom-smashing, and seeing if that causes the FPS decay people talk about.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Doughnut189 on March 14, 2012, 09:49:13 pm

Delicious !!Science!!

Socks off to you for trying to cure our FPS-woes.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Malarauko on March 14, 2012, 09:51:05 pm

It'll be great to have a how to list for freeing up your FPS.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: tahujdt on March 14, 2012, 10:00:41 pm

There is a list on the wiki, so check that before you do any unnecessary !!SCIENCE!!

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Spiderking50 on March 14, 2012, 10:03:39 pm

Maybe the issue isn't within the sheer number of items created. I don't know ~~much~~ anything about the data vector, but the difference i see in this experiment is the lack of variance. If the data is stored in folders or groups (anything of that sort really) then you've created a single type of data file, whereas in an actual run you would have hundreds because of all the different things you need. I mean (and this may be totally off base because I am not a computer expert) you have a file that would be like:

[GRANITE STONE X 100000000000] Which may not be hard to track in a system that splits data into groups. However in a real game you'd have a file like:

[BASALT TABLE X 13]
[BASALT STONE X 302]
[ASH CHAIR X 30]
[PLUMP HELMET SPAWN X 56723]
[DEMON SILK X 471]

And that would continue on into eternity for each type of item you have, not to mention keeping track of the quality of the items (which stone doesn't really have, but your goblet idea may solve for that if your getting variation at least at the beginning like you would for a starting mason). Does any of that make sense or am I off base?

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 14, 2012, 10:13:17 pm

I got FPS as low as 140 during the last year of the goblet test while the caravan was there, but I never would have thought I would have difficulty sinking my FPS.

I can also try adding engravings, or making statues, instead. If they have descriptions, it's worth trying to add on...

I can also still try just upping the number of items that a caravan brings into the fort, and seeing how much that will increase fps drain.

There's also isolating Siegers specifically, as I've had them shut off for the purposes of me not having to set up any military.

It might also just be that the effects are too subtle after "only" running a 10-year fort, but still present, although that's not really a satisfying answer.

For those who want to play our Home Game, I'm putting saves up on DFFD. They include annual saves for each experiment:
Fork Save (http://dffd.wimbli.com/file.php?id=5883)
Boulder Experiment (http://dffd.wimbli.com/file.php?id=5884)
Goblet Experiment (http://dffd.wimbli.com/file.php?id=5885)

If someone wants to either help run some alternate tests, or else wants to try just continuing some of these experiments for another 10 or 20 years to see if you can get some further FPS degradation, that would help.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Mapleguy555 on March 14, 2012, 10:14:26 pm

You... have FPS over 100?

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 14, 2012, 10:15:16 pm

Quote from: Mapleguy555 on March 14, 2012, 10:14:26 pm

You... have FPS over 100?

And I am trying and failing to get it below 100.

Funny world, ain't it?

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Kofthefens on March 14, 2012, 10:18:40 pm

Great !!Science!! You might also consider breeding and killing animals rapidly. It could be that the game has to keep track of all the cats, then as they are born and die, the game slows down.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: wierd on March 14, 2012, 10:21:30 pm

Encrust with gems. Creating 2x stone, cutting 1/2 as cabochons, and making the rest into useless trade goods, and then encrusting with the cabochons will creat epic asstons of unique items with pictures, spikes, rings, etc.

This should prevent single entries in the vector with multiple referenced instances, and should force each instance to be a unique entry.

That should definately show your desired curve, if your hypothesis is correct.

*edit

I discovered something similarly stupid going on in the saved game files for both pc and xbox versions of morrowind many many years ago. The game persistently tracked items created, npcs talked to, (even if the npc data did not change), and comprehensively tracked every creature killed, when, and where. It did not cull entries, so if you brewed a potion, you just added several kilobytes to the save file, even if you immediately drank the potion and as such, destroyed it. If you are an alchemy fiend like I am\was, your save file could grow to several megabytes of unneeded item data. On resource limited platforms like the xbox, this led to problems where the time taken to read the save file would exceed the hard coded disk access timeout, causing a dirty disc error. Manually purging all the useless data and regenerating the digital signature on the save file would neatly solve the problem 100% of the time. Bethesda did nothing about the problem, despite all my data on it.... so, I am familiar with what you are looking for, and why.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Girlinhat on March 14, 2012, 10:32:05 pm

Quote from: tahujdt on March 14, 2012, 10:00:41 pm

There is a list on the wiki, so check that before you do any unnecessary !!SCIENCE!!

The whole point here it to challenge what's known. We're working on age-old assumptions on how items cause FPS decay, but I do wonder how many are grounded in fact and how many are old rumors that are taken as true.

I propose another experiment though: Start producing infinite socks and destroying them. I theorize that clothing will cause more FPS decay than rocks or goblets, because clothing will track its state of decay. It may be that when clothing is atom-smashed, that it still silently checks if it's growing older, while such checks aren't applied to goblets.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: wierd on March 14, 2012, 10:35:53 pm

Whole entities (like kittens!) Should also be tested.

(I hate to say this....)

....'increase'.... the reproduction rate of cats, and lock them in an atom smashing room with 2 tiles, where only 1 gets smashed. Regularly smash the kittens in the smoosh zone to create persistent dead entities.

Dead kittens don't create ghosts, so its the way to go.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 14, 2012, 10:39:25 pm

Quote from: Girlinhat on March 14, 2012, 10:32:05 pm

I propose another experiment though: Start producing infinite socks and destroying them. I theorize that clothing will cause more FPS decay than rocks or goblets, because clothing will track its state of decay. It may be that when clothing is atom-smashed, that it still silently checks if it's growing older, while such checks aren't applied to goblets.

I have quite a few things to experiment on, already. I don't suppose you could help by running your own experiment on this?

Download the Fork Save (http://dffd.wimbli.com/file.php?id=5883), go into that save's raws, and edit "reaction_testy.txt" so that you are creating socks instead of boulders. (and set it to create 200 and destroy 100 while you're at it.)

You do this by changing [PRODUCT:100:20:BOULDER:NONE:INORGANIC:TESTSTONE] into [PRODUCT:100:200:SHOES:ITEM_SHOES_SOCKS:INORGANIC:TESTONE] (I THINK it might still let you make stone socks. Otherwise change that to make these things out of pig tail or something.)

EDIT:
And here's a fork save where I have set up an atom-smasher, so that atom-smashing can be tested compared to simple reaction annihilation. http://dffd.wimbli.com/file.php?id=5886

EDIT 2:

Oh, and remember to up your max FPS to something like 1000 FPS in your init file.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Frogwarrior on March 14, 2012, 10:41:02 pm

Seconding the suggestion for kittensmashing. The other thing old forts tend to amass is hordes in the dead list, esp. with sieges.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Girlinhat on March 14, 2012, 10:41:58 pm

Also valid, and old forts are liable to have PLENTY of dead units on the list (goblins if nothing else).

I may warm up the save tomorrow, it's a bit late now and I don't want to science before bed.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Frogwarrior on March 14, 2012, 10:57:29 pm

Usually goblins, yeah. I definitely get to the point where my units list is a couple pages of live dorfs and a couple pages for each flavor of dead goblin invader, not to mention the butchered kittens.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 14, 2012, 10:59:54 pm

If you want to test kittensmashing, that's fine, but this is specifically in reference to the people who see permanent FPS loss even when they are trying to avoid the things that cause normal FPS loss. Huge killcounts and catsplosions are those specific things such players avoid.

I actually want to test things like huge caravan sizes, and seeing if having a huge caravan can permanently cripple your FPS, and if cutting yourself off from caravans entirely will preserve long-term FPS.

Siegers are another thing that fits on that list, as well - I'm specifically not dealing with siegers, since it's so difficult to compare it well to a control.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: bombzero on March 14, 2012, 11:03:11 pm

posting to watch this, could be informative.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 14, 2012, 11:22:02 pm

Well, my atom smashing setup has managed to get me below 100 FPS.

The problem is I'm not sure if this is just because I have a backlog of 10,000 mugs to chuck down the smashy-chute.

EDIT:
Heh, the lever-puller went on break, and my FPS shot up from 100 to 180, just because it wasn't actually smashing things anymore.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Girlinhat on March 14, 2012, 11:36:54 pm

Of course for this instance, your control would be a room full of mugs, and your test would be an empty room of recently atom-smashed mugs. Then again, you'd also need a control of no mugs to start with...

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Frogwarrior on March 14, 2012, 11:37:45 pm

... Perhaps the control could be with invasions turned off, and the experiment could be with invasions turned on but the entire fort sealed off? Hm, have to figure out what to do about caravans though.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 14, 2012, 11:48:31 pm

Quote from: Girlinhat on March 14, 2012, 11:36:54 pm

Of course for this instance, your control would be a room full of mugs, and your test would be an empty room of recently atom-smashed mugs. Then again, you'd also need a control of no mugs to start with...

Control is just pulling the lever without building or smashing any mugs.

Because building and destroying mugs repeatedly did not lead to lag, then there must be a properly working clean-up function. The test of the atom smasher is to see if this clean-up function works in all situations.

For example, Peterix was talking about how you can use DF Hack to eliminate many objects, but that because it is a memory hacking tool, it doesn't actually always trigger all the proper routines, and can lead to undesirable behavior, such as eliminating magma, but not actually changing the temperature of the tile back down to non-magma temperatures, so it still melts anything in the tile.

Likewise, magma-casting, ice-forming, or other "put a wall over it" destructions of items can lead to very strange behaviors, especially when you carve them back out.

Further, there are reports of events like magma dumped objects not properly being cleaned up.

By testing each of these different cases in isolation, I can try to zero in on what specific problems there might be in the cleanup routines, and file bug reports for them.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: bombzero on March 15, 2012, 12:34:21 am

I wonder how much various user science bits have helped Toady over the years.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: CursedBurger on March 15, 2012, 12:36:43 am

This community is by far the best alpha-testing group granite-spiked socks can buy.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Khym Chanur on March 15, 2012, 01:39:27 am

Posting to watch the thread.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Kar98 on March 15, 2012, 02:24:10 am

Very interesting tests. I've always held the belief that it's not so much items but space that causes the FPS death that people experience. Perhaps it could be a combination of both

Alternatively, perhaps you could set up 20 miners, mine entire Z levels to 'produce' rock then atom smash it later and see if that has an effect on FPS. And for consistancy it might be best to turn off caverns in advance world generation so we don't see these random FPS spikes.

As for the FPS spikes when you leave DF, I would say it has something to do with the process not being in focus and it might throw off the FPS calculations - pure speculation

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Kogut on March 15, 2012, 02:35:22 am

Quote from: bombzero on March 15, 2012, 12:34:21 am

I wonder how much various user science bits have helped Toady over the years.

Recently somebody found what caused adamantine spires, hell on embark, collapsing caverns in the sky and general world corruption.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: bombzero on March 15, 2012, 02:42:01 am

Thats what i mean, players have solved many bugs for him, with or without his consent.
take the poll in your sig for example, major help to Toady, but nobody asked you to do it.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Frogwarrior on March 15, 2012, 02:44:01 am

Quote from: Kogut on March 15, 2012, 02:35:22 am

Quote from: bombzero on March 15, 2012, 12:34:21 am
I wonder how much various user science bits have helped Toady over the years.
Recently somebody found what caused adamantine spires, hell on embark, collapsing caverns in the sky and general world corruption.

Wh... what was it?

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: bombzero on March 15, 2012, 02:50:20 am

knowing DF it was a small tiny ass thing like a missing bracket in some obscure file, or 1 number wrong in a data pointer...

see fun thing about DF's complexity, little issue = big bug.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: DuckBoy2 on March 15, 2012, 02:58:11 am

You need more controls on your atom smashing experiment, anything with repeated toggling that causes pathing calculations to fire is going to be hell on your fps.

On a 4x4 zone, I can drop my fps from whatever its capped to down to 96 with a single lever toggled bridge, or 88 with a row of 10 hatches, even if no one is doing anything requiring pathing.

Ive got a science fort set up right now for doing automatic chutes and drop pods, and I can drop my fps from 100 to ~20 with the flick of a lever that flips 9 hatches, dropping my meeting hall onto floating pressure plates that toggle floodgates to drop my dwarves 10 stories onto a pile of ducks. And I can do about the same just flipping the hatches and floodgates.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: bombzero on March 15, 2012, 03:00:12 am

Quote from: DuckBoy2 on March 15, 2012, 02:58:11 am

4x4 zone, single lever toggled bridge,no pathing.

so... you locked your dwarves in a room with a lever controlling a drawbridge that would smash them all.... awesome..

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: GalenEvil on March 15, 2012, 03:28:40 am

This may or may not be relevant to your post, but it seems appropriate to at least post this in a !!SCIENCE!! thread instead of making my own since this is probably not viable !!SCIENCE!!...

Assumptions:
* FPS is reduced by a non-sorted vector list of items (your assumption if I am reading this correctly)
* FPS is reduced by the A* or A* equivalent pathing algorithm used by this game

My Theorems:
* Creation and subsequent destruction of like-typed items (as in your experiment) will not create any appreciable FPS loss
* Creation and subsequent destruction of variable numbers of non-like-typed items may create FPS loss (IE. create 10 bins, create 9 mugs, destroy 3 bins, create 10 bins, destroy 3 mugs, create 9 mugs, destroy 15 bins, destroy 10 mugs, create....etc) such that entire sets of item-creation jobs are not being immediately destroyed, and could possibly create empty vector indices within the lists as it is not guaranteed that an entire stack of a created good are destroyed entirely, which could, and logically would, free up the memory location if done haphazardly.
* Corollary to the above: or at least a simplification of it. Each job set of a specific non-unique item could be creating a list set in the item vector list. If the above holds true then destroying only part of the list would not necessarily free up the memory associated with said list set to allow that set to be used for something else. Iff, (if and only if) the entirety of the item-set is destroyed the memory is freed.

Repercussions for this experiment:
* With the terms of the experiment you, the player, are destroying objects immediately after creation, thus possibly voiding the memory set soon after its creation. This may be the cause of inconsistent results with your initial hypothesis.
* Forcing the objects to being completely unique, by way of encrusting with gems or by other means may not alleviate the problem if the objects are being treated as unique within the lists, and the encrusting of said item(s) is only modifying the data that the object pointer is pointing to instead of creating an entirely new item.
* As only a single type of item is being created possibly only a single list of entries is being created, and as such the number of iterations the engine needs to go through to access a particular object's entry is severely limited. Different types of items would be needed in order to create a "realistic" array of objects for the engine to search through to find a single item.
* There may or may not be a separation between the following informations within the item data: Creator of item, location created (the object id # of the workshop that created the item), the quality of the created item, and any alterations made to the created item (such as encrustings, sewn on images, etc). More !!SCIENCE!! would be needed to figure this one out and if it has any effect on the item lists.

My general thoughts and musings that dont specifically have anything to do with this experiment:
* A* pathfinding is pretty rediculous sometimes and doesn't always net the "best" result, especially if it is being checked every frame (leading to FPS death via creatures that are trapped and want to go elsewhere or otherwise extremely complicated path possibilities...)
* This is a really good experiment, though I believe that much more !!SCIENCE!! will be needed to come to an accurate conclusion...perhaps a grant of some sort should be set up for research into this !!SCIENCE!! ? Lol
* I may or may not be speaking entirely out of my rump right now as I do have a little bit of C++ experience as well as Java, and am in the process of creating a game engine to support a few of my game ideas....probably closer to the "may" than "may not" since everything is still in the ver 0.0000001a stages.

Hope that some things spark interesting musings within anyone who reads this, but not expecting it. Looking forward to seeing the conclusion to your !!SCIENCE!! :D

GalenEvil

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Kogut on March 15, 2012, 03:46:26 am

Quote from: Frogwarrior on March 15, 2012, 02:44:01 am

Quote from: Kogut on March 15, 2012, 02:35:22 am
Quote from: bombzero on March 15, 2012, 12:34:21 am
I wonder how much various user science bits have helped Toady over the years.
Recently somebody found what caused adamantine spires, hell on embark, collapsing caverns in the sky and general world corruption.

Wh... what was it?

http://www.bay12games.com/dwarves/mantisbt/view.php?id=5077

0005077: Browsing world gen map causes corrupted feature files

Spoiler: Also described as... (includes "3/4 of the map is a big hole going straight to hell") (click to show/hide)

http://www.bay12games.com/dwarves/mantisbt/view.php?id=5077#c20165

Lightning4: "I've discovered this bug exists as long as feature files have gone into the /current/ folder while browsing the map."

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Di on March 15, 2012, 04:32:39 am

Hey, nice science you have here.
I'd suggest you deleting all the creature raws except creature_standard (and deleting everyone out of it except dwarves) for a clear result. This will also prevent traders bugs from hindering you in your search for other bugs, since traders won't come without trade animals.
By the way, neither amount of raws, nor the duration of worldgen have noticeable effect on fps. (This can be verified by using the same seeds. I was testing that alongside with buying 150 pet dwarves on the embark in order to bring fps into standard range.)

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Sus on March 15, 2012, 06:10:40 am

Quote from: CursedBurger on March 15, 2012, 12:36:43 am

This community is by far the best alpha-testing group granite-spiked socks can buy.

Agreement.
*Gives NW_Kohaku his ¤hematite sock¤ for great ‼SCIENCE‼*

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Sphalerite on March 15, 2012, 08:17:45 am

When doing this type of dedicated science fortress, I usually wall off the map edge with raising bridges. While that does take a year or two to do even with a 2x2 embark, once you've done it you won't be bothered by immigrants, traders, invaders, wild animals, diplomats, or anything else spawning on the map edge.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Quietust on March 15, 2012, 08:30:15 am

Quote from: Frogwarrior on March 15, 2012, 02:44:01 am

Quote from: Kogut on March 15, 2012, 02:35:22 am
Quote from: bombzero on March 15, 2012, 12:34:21 am
I wonder how much various user science bits have helped Toady over the years.
Recently somebody found what caused adamantine spires, hell on embark, collapsing caverns in the sky and general world corruption.

Wh... what was it?

It was failing to clean up intermediate files after aborting an embark and then incorporating them into the next world you generated. The files in question were map feature data, so the result was the game placing map features (cavern layers, the magma sea, the Underworld, adamantine spires, deep pits and magma pools, etc.) with totally invalid data and breaking the landscape.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 15, 2012, 12:28:46 pm

Quote from: DuckBoy2 on March 15, 2012, 02:58:11 am

You need more controls on your atom smashing experiment, anything with repeated toggling that causes pathing calculations to fire is going to be hell on your fps.

Actually, my controls for the atom smashing experiment will be to have a run where I start from the same save where I've set up the atom smasher, keep it running by flipping the lever, and just don't make or smash goblets.

The point of the experiment is to measure whether or not atom-smashed objects still have an impact on lag (and therefore, if atom-smashing objects is actually as good for your lag as people think it is), not whether or not drawbridges are bad for lag (which they clearly are, but that's not the experiment).

I can say, however, that after going to sleep letting this thing run, what with my setup requiring that I manually (well, by macro) designate all those goblets in the workshops for dumping, simply having large numbers of objects on the map has a clear impact on FPS.

10,000 goblets on the map - runs at 120 FPS.
30,000 goblets on the map - runs at 60 FPS.

I've been trying to manage to keep this at around 10,000 goblets on the map while I was watching it, so as to keep a decent perspective on the FPS as it rises or declines, but I will finish my experiment off with no goblets left un-smashed so as to compare it to the control. And basically, the control could just be the fork save itself, as I don't have any noticable FPS decay as of yet.

What I'm finding may just be that my whole assumption on how this lag was being caused was wrong, and the only thing really causing lag this whole time was the animals. Although I still want to test a large caravan save, an item-improvement save, and some others.

Again, if someone wants to help set up some sample data by running this stuff themselves, this is really brain-dead stuff to run (basically, you only have to get rid of the trader, but you just leave it running on its own for spring-autumn and post-trader to winter.) It just takes basically 4 hours of simulation running time to actually accrue the 10 years of sample data. Which means that it takes the better part of my day per experiment I have to run if I'm only running off my own computer.

Someone helping out would make this go much faster.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: kaijyuu on March 15, 2012, 12:39:04 pm

Dunno how relevant this might be, but my FPS drops usually happen when my metalsmithing gets into full swing. I usually make 20-30 magma smelters and let them have at it for a few years. Digging out the veins doesn't cause it, but once dwarves start running all over the map, making tons of bars, my FPS drops (and never returns, even if I cancel all the jobs). Notably, this causes no increase in total items; once I get steel production going, it actually causes a drop.

Could be jobs somehow causing FPS death, maybe items in buildings (as my bar stockpiles are always overflowing).

Really though, my suspicion is the cause being units. Dead units probably still eat up CPU time, though not to the degree of alive ones. I wonder if Toady sticks the dead ones in a separate vector when cycling through each unit's behavior; we know they still exist (to some degree) in memory due to the dead/missing list.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 15, 2012, 12:44:35 pm

Quote from: kaijyuu on March 15, 2012, 12:39:04 pm

Dunno how relevant this might be, but my FPS drops usually happen when my metalsmithing gets into full swing. I usually make 20-30 magma smelters and let them have at it for a few years. Digging out the veins doesn't cause it, but once dwarves start running all over the map, making tons of bars, my FPS drops (and never returns, even if I cancel all the jobs). Notably, this causes no increase in total items; once I get steel production going, it actually causes a drop.

Could be jobs somehow causing FPS death, maybe items in buildings (as my bar stockpiles are always overflowing).

Could you describe your metalsmithing process?

As in, do you use coal or charcoal from cutting down aboveground/underground trees, and do you set up special farms for those?

Do you use magma forges?

What types of items do you make? (Steel only, or do you make non-steel crafts? Do you only make weapons or do you make craft items for sale, as well?)

Do you trade your metal items away to caravans?

There are different potential points for FPS loss for different ways in which you operate your industry...

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: kaijyuu on March 15, 2012, 12:49:51 pm

Certainly.

Magma smelters/forges entirely.
Don't do strip mining; I do exploratory mining. Emptied passages/veins are sealed off for pathing purposes.
20-30 magma smelters, as I said before.
Never really any big stockpiles, so most bars stay in smelters.
I make a ton of bolts and shields to level up my weaponsmith/armorsmith.
Bins to level up my blacksmith.
Bins/weapons/armor are emptied almost immediately so there's no buildup there.
Steel is usually done with coal/lignite. These do produce a net gain of total items, I know, but not by any huge amount (few thousand with a ton of coal). Never really make tree farms or anything.
Metal items are usually kept, though I melt down the non-masterwork stuff. I trade away stone crafts (usually mechanisms).

The funny thing is, I don't usually start this up until I have a significant amount mined out. It's mostly to give my idlers and miners something to do. So as far as total items goes, this isn't what boosts the item count on my maps usually (that'd be farming). I have 250 FPS forts allll the way until my industry's set up, then, I'm down to 140 and steadily sinking.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 15, 2012, 01:06:38 pm

Quote from: kaijyuu on March 15, 2012, 12:49:51 pm

Magma smelters/forges entirely.
Don't do strip mining; I do exploratory mining. Emptied passages/veins are sealed off for pathing purposes.
20-30 magma smelters, as I said before.

There are two major things that stand out - first, you need to know what the total number of items are in your fortress. There are checks (like temperature) that take place per item, so having large numbers of total items will cause major problems. (Although stack items like 25 bone bolts will probably be counted as just one.)

The other is your magma forge. How do you supply the magma to your magma forge? Unless you set your forges up directly on top of the magma sea, you might be introducing some liquid motion, which brings up the fluid mechanics that are real FPS drains. Magma motion also brings up more temperature checks that can be a serious strain on FPS.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: kaijyuu on March 15, 2012, 01:17:00 pm

Always the magma sea, pipes, or volcanoes. I literally never have built a single pump in my entire DF career.

And temperature's always turned off for me, by the way.

Might be coincidence and something else, I dunno. I do try to limit the number of items I produce, and am constantly destroying stuff (like stone). FPS still drops. My bets are still on units; buildup of vermin is possible, along with dead/gone units still being counted somehow.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: rooth on March 15, 2012, 01:35:57 pm

Posting to watch and a small question;

Wouldn't it be more efficient to use DF hack's ''autodump destroy'' instead of atomsmashing? It, as far as I know, essentially does the same but gives you much faster work results.

some other science on the subject;

I've done a ''huge focus on fps'' fort on 34.05 on a 3x3 embark and currently have +/-150 dwarves, first cavern acces on a deep map, about 200 animals in cages, 200 on the loose breeding bounce between 135 and 140[my cap] fps after 17 gameyears. The ''one lever that ruines pathing'' hypothesis is one i can fully get behind, it's the only method I could so far use to get my fps to drop below 70 yet, it jumping back to 140 when the ''pathing cooled down'' [for example; forest titan appears, use alarm to get people in side, close drawbridges, release them from alert, restabilizes after a short while]

I'm really glad Toady is working on clothing as I used to have 30 fps forts after 20 years and the biggest change in fps for me was getting rid of clothes, that literally was the difference between 20 and 80 fps on old forts. All the other tricks like efficient building, conserving itemload, caging pets,turning off temp etc can get me to my cap but the clothing fix did not change my game in any way, while losing temp or havign to create your own magma forges with Dfhack kinda removes some of the game's FUN aspects :-[

I've even considered lowering my fps cap as now that my 60 children are growing up, I'm aiming to work out some narratives and for some reason I could not get the same connection to my dwarves on 140 fps as I used to have on my older laggy forts; everything just flew by :o!

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 15, 2012, 01:55:26 pm

I am testing atom-smashing and autodump destroy separately because I specifically don't know whether they have the same effect or not.

In fact, I believe I have discovered permanent FPS decay in this Atom-smashing test, as I am now permanently at 80 FPS.

This implies that atom-smashing is not properly cleaning up what it smashes.

This only significantly occurred after the one point where I had 30,000 goblets on the map, however, and ever since that point, even after I smashed away the glut of goblets keeping me at 60 FPS, I still have an FPS that only recovered to around 80.

Either this means the problem is that atom-smashing isn't as clean as previously thought, or that the problem is not so much individual items entering and exiting the vector, but the overall size of the vector itself never recovers.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: bombzero on March 15, 2012, 02:50:13 pm

so maybe its like uninstalling programs in that you leave lots of 'blank' data behind? insignificant in a single instance but cumulative over time?

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NonconsensualSurgery on March 15, 2012, 02:52:01 pm

Conclusions so far:

1. Ignoring traders causes permanent FPS drop.

-what if they're never allowed on the map with raised drawbridges?

2. Having many many items and then atomsmashing them causes permanent FPS drop.

-what about magma disposal? I have a feeling that dropping 30,000 goblets down a volcano or flooding the chamber with magma will do something.

3. Trying to limit dwarf pathing with raised drawbridges or doors just makes it worse.

-what about constructed walls, obsidian or cave-ins blocking pathing?

The kitten crushing test should have predictable results because we already know dead units aren't cleaned up completely. We can still see them on the units screen years later. Just how many you have to kill to have a distinguishable effect is unknown; having a value of kittens atomized per FPS lost would be... interesting.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: kaijyuu on March 15, 2012, 03:05:27 pm

I can confirm that destroying 95% of the items on a 60,000+ item map restores quite a bit of FPS. Went from ~50 to ~140 on one of my old forts. So, destroying items isn't pointless.

Did it with magma dumping, which may be different than atom smashing, though.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 15, 2012, 03:08:17 pm

Quote from: NonconsensualSurgery on March 15, 2012, 02:52:01 pm

Conclusions so far:

1. Ignoring traders causes permanent FPS drop.

-what if they're never allowed on the map with raised drawbridges?

2. Having many many items and then atomsmashing them causes permanent FPS drop.

-what about magma disposal? I have a feeling that dropping 30,000 goblets down a volcano or flooding the chamber with magma will do something.

3. Trying to limit dwarf pathing with raised drawbridges or doors just makes it worse.

-what about constructed walls, obsidian or cave-ins blocking pathing?

1 is not true, per se. Blocking traders causes temporary FPS drop for as long as they are blocked.

Being as creatures can exist off the borders of the map, and may exist there permanently, and take up FPS for being there, blocking them off the edges of the map may cause more problems than it solves.

2 is still under testing. My FPS has climbed back up to 120 while smashing is going on, but that's because my goblet total dropped to 8000. It may be the effects are more subtle than I at-first thought.

I have not done anything to support conclusion 3. There is a very notable lag every time the drawbridge goes up and down. My FPS goes up 50% whenever my lever-puller goes on break. So, that's going from 80 to 120 from that alone.

I have completely walled in the drawbridge, so there is nothing that can path to the drawbridge unless you are flying in the dumping pit. It doesn't matter, it's still causing lag.

I presume this means that every time the bridge raises or lowers, it has to recalculate the entire connectivity chart of the whole map, regardless of whether or not things like caverns have never been breached. There have been talks before about saving connectivity charts with bridges up and down before to save processor time, and this seems to support it.

Quote from: bombzero on March 15, 2012, 02:50:13 pm

so maybe its like uninstalling programs in that you leave lots of 'blank' data behind? insignificant in a single instance but cumulative over time?

I think it might be more to do with the arrays in the vector being generated, but never sorted - merely eliminated when the whole array becomes empty, but when, if a single goblet's pointer remains in that array, the array remains behind.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 15, 2012, 03:11:29 pm

Quote from: kaijyuu on March 15, 2012, 03:05:27 pm

I can confirm that destroying 95% of the items on a 60,000+ item map restores quite a bit of FPS. Went from ~50 to ~140 on one of my old forts. So, destroying items isn't pointless.

Did it with magma dumping, which may be different than atom smashing, though.

Magma dumping is acutally more likely to be problematic than atom-smashing. Magma dumping leaves behind melted stone items that never quite go all the way away.

The thing is, an item that is improperly cleaned up is better than an item that is still there, but you shouldn't compare the FPS to when the object was there, you should compare the FPS to if the object had never existed at all. If there is a full cleanup, then I should be able to create and destroy millions of items forever without any loss of FPS, but if there is a lingering footprint in memory, then even though destroying items grants a temporary memory boost, it creates a gradual decay of the data structure that leads to lag even when the objects no longer exist.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: khearn on March 15, 2012, 04:00:38 pm

Have you looked at dfhack and runesmith? They do a lot of things involving the internal datastructures, including deleting things from them. You might learn more about how things are structured by looking at their code or talking to their developers. You may find that the structures you are guessing about are already well known.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 15, 2012, 04:02:10 pm

I am suspending my atom-smashing test for now to check on the contraction theory, instead.

I am going to try to have a million stones on my map at a single point in time before eliminating them all.

I am apparently up to roughly 100,000 stones on the map at once, but it appears as though the sheer numbers have completely overwhelmed my bookkeeper, or else that bug is back, because I'm down to lowest possible precision again.

FPS has plummeted way down to 30 from "merely" having 100,000 stones on the map.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: blue sam3 on March 15, 2012, 04:04:19 pm

Right, I've done some testing on open space. All testing was done with modded (nosleep/drink/eat, speed 0) dwarves digging out areas of white sand, in full screen, with as little as possible running in the background.

Results:

initial FPS: 2000
FPS whilst digging out a small area (600 ish tiles): 50
FPS after digging out said small area: 1500
FPS whilst digging out a larger area (maybe 1500 tiles or so): 5
FPS after digging out said larger area: 1500
NOTE: at this point, several things happened:
1) First hardcoded migrant wave arrived and a ghost appeared
2) I finally remembered to turn weather etc. off
FPS after above changes: 2600
FPS whilst digging out another small area: 3
FPS after digging out said small area: 2300 (NOTE: unreliable, as I was only able to observe for a short time due to another migrant wave and a caravan arriving. After the caravan left, FPS was down at 2100)
FPS whilst digging out 7 tiles: 5
FPS whilst digging out another small area: 20
FPS after digging out said small area: 2100
FPS with an entire inaccessible z level designated: 1950
FPS after undesignating said inaccessible z level: 2050
NOTE: At this point, two migrant waves arrived, half the fortress got married, a child was born the elven caravan arrived and two ghosts appeared.
FPS after above note: 1000
NOTE: the above changed by +/- 100 points with seasonal variations, away from autosaves
FPS whilst digging out another large area: 2
FPS after digging out said large area: 900
FPS after digging out another small area and a really annoying migrant wave: 730
FPS after digging out another small area, a really annoying dwarven caravan (still present) and three really annoying births: 600
FPS after caravan left and digging out another small area: 600
FPS after digging out another small area: 600

At this point, I decided to test whether open space and floored space had the same effects, so I started channelling out all of the areas I'd previously dug out.

FPS after collapsing first area (two deaths, one birth, one lightly mangled baby, two lightly injured miners): 420
FPS after collapsing second area (one light injury, one birth): 380
FPS after collapsing ridiculously massvie area: 300
FPS after digging out another small area: 280
FPS after channelling that area out the slow way:230

Conclusions:
Empty space slows stuff up.
The accessibility of space has no noticeable effect.
Channelled out space is actually worse than floored over space.
Designating things does slow stuff down, but nothing like as much as actually having them accessible.
Weather etc. has a significant impact on FPS.
There are significant seasonal variations in FPS.
Caravans still slow things up after leaving the map.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 15, 2012, 04:12:26 pm

I don't think I'll be able to get to 1,000,000 objects, as the game is getting extremely laggy just trying to look at some of these workshops that have 10,000 objects in them, apiece.

Apparently, just looking at a workshop will cause lag based upon the number of items it can be related to.

This includes the workshops I didn't even use in the experiment for lack of any worker to staff them - apparently, it's loading all the boulders in the entire fortress any time I look at the workshop.

Looking at the mason's workshop and butcher's shop causes no lag.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 15, 2012, 05:05:20 pm

Creating 1,000,000 simultaneous objects is harder than it seems. Apparently, even DF has some sanity checks, and it doesn't let you create 100,000 objects in a single reaction.

So, I'm up to creating 500,000 for the stress test, and waiting on the other reactions to finish creating 1,000,000.

FPS has gone from 600 to 6. It will probably be 3 by the time I hit 1,000,000 boulders.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Girlinhat on March 15, 2012, 05:41:36 pm

I think it's been confirmed that bridges/hatches/doors/etc cause an instant FPS drop, but when pathing settles down it returns to normal. That is, there's a moment of lag when the dwarves realize "oh shit, something has changed. Let me figure out what I'm capable of now!" And once they realize where they can path, FPS returns to normal.

Also does "magma dumping" refer to "Into the magma sea and SMR" or "magma was placed atop it"? SMR may trigger clean deletion, while atom smashing causes a messy deletion.

Either way, it seems like Toady could easily implement a few lines of code that will perform a loop every time you save. Run through the array, "if defunct, remove this entry". If it runs on every save, then seasonal autosave would keep FPS pretty damn high.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: wierd on March 15, 2012, 05:58:11 pm

That might work, but could also lead to save file corruption more frequently. (The last thing you want is a race condition, or an overflow causing problems in garbage collection just before you say "ok, set everything in stone now!")

Seasonal garbage collection without saves, say when merchants are supposed to show up would be better, since the game autopauses (most of the time...) when they do, leaving the cleanup loop free to do its thing without stuff happening, and where if it crashes\smashes, it won't take the whole world with it.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 15, 2012, 06:04:41 pm

My contraction test has caused the entire game to go completely unresponsive. I am unsure why.

It might be that the game just completely blows its top when you hit 1,000,000 boulders, or it may be an aspect of the custom reactions I had to made to trick the system into doing more with one reaction than it normally can (destroying 100 sets of 100 items at a time).

Performing further testing...

A quick test shows that the boulder destruction reaction causes massive lag. The 100 step process just shut my game down for 4 straight seconds only doing it once...

Since I will need to perform this reaction over 100 times, I suppose that's the cause of the non-responsiveness.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Kogut on March 15, 2012, 06:08:52 pm

In my current test (create object, destroy object with [SPEED:0] dwarves) I see a constant FPS drop, from 4500 to 3000. I will try to reproduce it again (without changes to RAWs during game, with disabled internet and antivirus etc), maybe we will see proper bug report.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Psieye on March 15, 2012, 06:22:38 pm

Quote from: blue sam3 on March 15, 2012, 04:04:19 pm

The accessibility of space has no noticeable effect.

What exactly do you mean here? Your data dump mentioned nothing about walling off the huge swaths of empty space you dug out. If you meant what I think you mean, then I have a fort that directly counters that statement. A large area of sand was dug out to train some new miners and FPS bombed. When I installed and locked doors to seal off the dug out space, FPS recovered.

Quote from: NW_Kohaku on March 15, 2012, 04:12:26 pm

I don't think I'll be able to get to 1,000,000 objects, as the game is getting extremely laggy just trying to look at some of these workshops that have 10,000 objects in them, apiece.

Apparently, just looking at a workshop will cause lag based upon the number of items it can be related to.

Requesting a control: dump (but don't destroy) the items that are being churned out from the workshops. Alternatively, just deconstruct the workshops and rebuild elsewhere.

Ah heck, give me a couple days and I'll try to make time to run some !!SCIENCE!! from your fork save.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 15, 2012, 06:28:15 pm

Quote from: Psieye on March 15, 2012, 06:22:38 pm

Requesting a control: dump (but don't destroy) the items that are being churned out from the workshops. Alternatively, just deconstruct the workshops and rebuild elsewhere.

Ah heck, give me a couple days and I'll try to make time to run some !!SCIENCE!! from your fork save.

Deconstructing a workshop takes actually looking at it, unfortunately.

My plan was to go back to the initial setup save, and queue up 8 sets of "build 10,000 boulders" each to get to over 1,000,000 boulders between the workshops, and then the ninth queued task was the "destroy 100 sets of 100 boulders" task set on infinite repeat.

The idea was that if I never needed to touch the workshops again, they could destroy them all automatically, but the problem is that the game lags out with that "destroy 100 sets of 100 boulders" operation.

I'm trying to just leave the game alone for a couple hours and seeing if it will actually manage to complete the operation, anyway, at this point, and hoping for the best... It's just not done yet.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Gizogin on March 15, 2012, 06:35:39 pm

Excellent !!SCIENCE!! here, posting to watch.
Also, I started reading when there were only three pages, but in the time it took me to read those three pages, the number had grown to five.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Psieye on March 15, 2012, 06:36:54 pm

Quote from: NW_Kohaku on March 15, 2012, 06:28:15 pm

Quote from: Psieye on March 15, 2012, 06:22:38 pm
Requesting a control: dump (but don't destroy) the items that are being churned out from the workshops. Alternatively, just deconstruct the workshops and rebuild elsewhere.

Ah heck, give me a couple days and I'll try to make time to run some !!SCIENCE!! from your fork save.

Deconstructing a workshop takes actually looking at it, unfortunately.

Ah, so it doesn't care whether you're looking at it in 'q' or 't' view. Hmm, and it'd get silly if we were to mess around with making the workshops vaporise or something. Ok, I'm starting to see what I want to do with my experiment.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 15, 2012, 06:54:09 pm

Hahahaha... This is really pitiful... I left it up for about an hour before it rendered another frame.

I guess I'm just going to have to leave this thing running overnight before I get results on the next few frames of the game.

I'm honestly waffling on whether or not to leave it running, or try to come back and see if I can't make a less self-destructive operation.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: robertheinrich on March 15, 2012, 07:02:37 pm

This thread is cute <3
and soooo pointless.

Using a modded version of the game.
Trying to find reasons for FPS decay.

Without access to the source.
Which you will never have.

Without attention of the coder.
Which you will never get.

But it made me chuckle a bit after I was quite frustrated that my recent fortress was eradicated while I was trying to pierce the aquifer and my last adventurer got both his arms cut off by thieves. Sometimes it helps to know that there are people out there who waste their time witn stuff much more pointless than I do.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Kofthefens on March 15, 2012, 07:04:15 pm

Quote from: robertheinrich on March 15, 2012, 07:02:37 pm

This thread is cute <3
and soooo pointless.

Using a modded version of the game.
Trying to find reasons for FPS decay.

Without access to the source.
Which you will never have.

Without attention of the coder.
Which you will never get.

But it made me chuckle a bit after I was quite frustrated that my recent fortress was eradicated while I was trying to pierce the aquifer and my last adventurer got both his arms cut off by thieves. Sometimes it helps to know that there are people out there who waste their time witn stuff much more pointless than I do.

No need to be rude, if you think this isn't helpful. However, many people, myself included, think that this !!Science!! is interesting.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Sphalerite on March 15, 2012, 07:05:59 pm

This thread is far from pointless, and as someone who has seen many long-running fortresses become unplayable due to FPS drop, I'm finding the science fascinating.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 15, 2012, 07:10:59 pm

Quote from: robertheinrich on March 15, 2012, 07:02:37 pm

This thread is cute <3
and soooo pointless.

Using a modded version of the game.
Trying to find reasons for FPS decay.

Without access to the source.
Which you will never have.

Without attention of the coder.
Which you will never get.

But it made me chuckle a bit after I was quite frustrated that my recent fortress was eradicated while I was trying to pierce the aquifer and my last adventurer got both his arms cut off by thieves. Sometimes it helps to know that there are people out there who waste their time witn stuff much more pointless than I do.

Actually, some reverse-engineering of the code has taken place with the DF Hack project, and talking with them has shown me that some of my deductions were correct, and some of them were incorrect. The game does use a global item index vector, although it seems to clean itself better than I initially thought it would, considering the complaints I have heard out of others who made restricted functionality forts.

The purpose is to isolate the actual causes of FPS decay, which makes it much more likely that they will be addressed, and if nothing else, dispells some myths about the game.

Further, this does have the ability to get the attention of Toady, as this science is simply the pre-requisite for proving where the flaws are in the code to get it on the bug tracker, and Toady is ramming through the bug tracker bugs at this very moment.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: kaijyuu on March 15, 2012, 07:24:58 pm

Hell even if Toady does squat, we'll know exactly what to avoid.

And open space that isn't pathable definitely contributes to framerate issues. Make two identical worlds/embarks, with the sole exception of the z-levels above the surface. Even only having 1 z level gives me a noticeable bump at high framerates (got 1300 at the start of my latest embark, woo).

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Kogut on March 15, 2012, 07:41:38 pm

Quote from: Kofthefens on March 15, 2012, 07:04:15 pm

Without attention of the coder.
Which you will never get.

See poll in my signature. Compare with recent devlogs.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Vorthon on March 15, 2012, 08:18:26 pm

Quote from: robertheinrich on March 15, 2012, 07:02:37 pm

This thread is cute <3
and soooo pointless.

Using a modded version of the game.
Trying to find reasons for FPS decay.

Without access to the source.
Which you will never have.

Without attention of the coder.
Which you will never get.

But it made me chuckle a bit after I was quite frustrated that my recent fortress was eradicated while I was trying to pierce the aquifer and my last adventurer got both his arms cut off by thieves. Sometimes it helps to know that there are people out there who waste their time witn stuff much more pointless than I do.

I smell a troll... Smells like onions and unwashed hair.

Also, posting to watch.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Girlinhat on March 15, 2012, 08:29:13 pm

Quote from: kaijyuu on March 15, 2012, 07:24:58 pm

Hell even if Toady does squat, we'll know exactly what to avoid.

And open space that isn't pathable definitely contributes to framerate issues. Make two identical worlds/embarks, with the sole exception of the z-levels above the surface. Even only having 1 z level gives me a noticeable bump at high framerates (got 1300 at the start of my latest embark, woo).

That's different. Available Z levels are known to cause issues, but the number of total levels is static. If you have a layer of solid stone and a layer of totally mined out stone, it's still a layer. The difference is, if the dwarf can path through it or not. If they can, you incur pathing lag atop of world size lag. If they cannot, you only have standard lag.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: kaijyuu on March 15, 2012, 08:39:04 pm

But sealing off that newly opened space doesn't really increase framerate. I doubt the pathing engine is so stupid as to check places it can't possibly reach, so pathing is not the (most significant) cause of increased lag with mined out areas, and not a cause at all for sealed ones.

Besides, increased map size wouldn't cause issues if map tiles themselves didn't eat up CPU. Remove all flying units and check again if you're worried that too is pathing. On top of that, I do think it safe to assume non-revealed tiles cause less issues than revealed ones (no reason to to temperature checks/etc), so it could very well be a major source of FPS drain on older forts.

Tangentially related: I have a save that's right before a huge FPS drop that I can't pinpoint the cause of. It seems to be based on time of the year. Should I toss it on the bug tracker?

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 15, 2012, 08:45:30 pm

Caverns have stuff happening in them regardless of whether they have been revealed or not. In fact, revealing the caverns after 5 years or so can result in caverns that have been almost completely taken over by fungal trees and underground crop shrubs.

Crundle packs and Giant Cave Spiders will fight it out even if you never know, as will FBs and any hidden cave civ, and there is a reason the caverns will be covered in cave spider webs when you open them for the first time.

HFS is the only thing where nothing spawns or moves until you reveal it, and HFS produces MASSIVE lag if you reveal and then seal it.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Psieye on March 15, 2012, 08:55:02 pm

Quote from: Vorthon on March 15, 2012, 08:18:26 pm

Quote from: robertheinrich on March 15, 2012, 07:02:37 pm
But it made me chuckle a bit after I was quite frustrated that my recent fortress was eradicated while I was trying to pierce the aquifer and my last adventurer got both his arms cut off by thieves. Sometimes it helps to know that there are people out there who waste their time witn stuff much more pointless than I do.
I smell a troll... Smells like onions and unwashed hair.

No I smell something similar but not quite troll - someone who needed a quick frustration-dump and thought this thread would do the job. Well ok, that he then spoke his thoughts pretty much makes him a troll.

Quote from: NW_Kohaku on March 15, 2012, 08:45:30 pm

Caverns have stuff happening in them regardless of whether they have been revealed or not. In fact, revealing the caverns after 5 years or so can result in caverns that have been almost completely taken over by fungal trees and underground crop shrubs.

Crundle packs and Giant Cave Spiders will fight it out even if you never know, as will FBs and any hidden cave civ, and there is a reason the caverns will be covered in cave spider webs when you open them for the first time.

HFS is the only thing where nothing spawns or moves until you reveal it, and HFS produces MASSIVE lag if you reveal and then seal it.

Hmm, I might decide to make a new world based on the fork save's raws to eliminate caverns and as much of the surface vegetation as possible.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Meansdarling on March 15, 2012, 08:58:26 pm

Posting to watch.
I hope you discover the cause. Reading about all this is very interesting.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: rtg593 on March 15, 2012, 09:16:11 pm

Post to watch as well. I've had several forts die of fps, and it's normally after I've mined out a massive area. Lost about 100 fps off the last one, started dropping when I began digging out a 140z pillar, settled at 30 fps when I finished it. Abandoned cuz I couldn't handle it going so slow :p

Also, my pocket world's stay at at a considerably higher framerate for much longer than my large, or largest worlds. Not to mention the autosaves being only a few seconds, vs a minute for the largest :p

Cool stuff:)

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: schismatise on March 15, 2012, 10:38:01 pm

Quote from: kaijyuu on March 15, 2012, 08:39:04 pm

But sealing off that newly opened space doesn't really increase framerate. I doubt the pathing engine is so stupid as to check places it can't possibly reach, so pathing is not the (most significant) cause of increased lag with mined out areas, and not a cause at all for sealed ones.

Besides, increased map size wouldn't cause issues if map tiles themselves didn't eat up CPU. Remove all flying units and check again if you're worried that too is pathing. On top of that, I do think it safe to assume non-revealed tiles cause less issues than revealed ones (no reason to to temperature checks/etc), so it could very well be a major source of FPS drain on older forts.

My experience is inconsistent with this.

A few forts ago, i had a massive, around 100 z-level tall 3rd cavern layer. I pierced it at about 6 different points at varying heights, in order to reveal it completely so i could build around it. My FPS started dying horribly even after the first piercing, and continued to get worse. Then i sealed up all the holes i made, and my FPS slowly returned to normal. No noticable difference. This happened over a period of maybe 1 game month, not too long.

I did notice, however, that simply viewing the cavern i had now revealed still gave me huge amounts of lag. As soon as i hotkeyed back to the surface, lag was gone. I found this rather strange, as i had not really noticed it before, but since then i have paid attention to this, and it seems to remain true - scrolling down the z-levels of every fort since then, my FPS drops while looking through the significantly large caverns (30+ z-levels).

Also, posting to watch.

Edit: It may be worth noting that every hole i made in the caverns was above the floor level of that area - ie. there was never an accessable path into the caverns for my dwarves. Obviously any flying creatures in the cavern (can't say i noticed any specifically) would have had full access to my fort.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: o_O[WTFace] on March 15, 2012, 11:30:51 pm

Revealed tiles seem to cause some amount of lag even if no stone is produced and no one tries to path through them.

Quote

Also, my pocket world's stay at at a considerably higher framerate for much longer than my large, or largest worlds. Not to mention the autosaves being only a few seconds, vs a minute for the largest :p

Other people have reported this too. If worldgen information is causing slowdowns then tracked events that occur in forts would cause lag as well, which might explain some of the issues caused by sieges and caravans.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 16, 2012, 12:55:51 am

OK, so I just checked before going to sleep, and found that DF was actually responding again, so I thought that maybe I had actually managed to destroy all those darn boulders, and was looking at a result...

I wasn't. I still have 890,000 boulders left to go, this was just a few frames where nobody was actually destroying boulders.

This was after 5 hours, so the boulder-destroying process appears as if it will take roughly three days of non-stop processing.

But it's at a point where I can save and try again with some different types of reactions to see if I can reduce the problems.

EDIT:
This is game-killing lag, here.

Even setting this to only search for one stone to destroy at a time, this is murderously slow. This isn't just tapping "q" or "t", I think the game is actually looking through a list of every stone in the fort per stone I am slated to destroy, resulting in a 5-hour long frame when the dwarves are looking at the locations of all 1,000,000 stones 10,000 times in a row for every individual stone to see which stone is closest.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Kogut on March 16, 2012, 01:30:47 am

Quote from: kaijyuu on March 15, 2012, 08:39:04 pm

Tangentially related: I have a save that's right before a huge FPS drop that I can't pinpoint the cause of. It seems to be based on time of the year. Should I toss it on the bug tracker?

Maybe - but what happens during this time (the best answer - nothing changes but FPS is lower)? Probably you may try, maybe it will be a good enough to find what is wrong.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 16, 2012, 01:42:46 am

I'll keep the super-contraction-test for a possible bug report on the way in which reaction object claiming works. Surely that can be optimized.

I'm basically forced now to restart this with a much smaller (130,000) test sample, which may not provide the same amount of data, but won't involve my computer exploding trying to calculate what is going on.

I also put a product into the reaction - a single mug per hundred boulders destroyed. If my earlier speculation about keeping an array open if there is just one item still in it is true, then this will be what keeps the game lagging more than the initial state.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 16, 2012, 02:17:39 am

Contraction Experiments on DFFD (http://dffd.wimbli.com/file.php?id=5906)

I would like to have other people try running the End State and the Control versions of the save for a long period of time (like a year or so), and record what they see in terms of average FPS.

I think I got a result, but the FPS bounces around seasonally, so I want more observations to be more certain.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Kogut on March 16, 2012, 02:19:55 am

Quote from: robertheinrich on March 15, 2012, 07:02:37 pm

Without access to the source.
Which you will never have.

Trollfeeding but I was unable to resist: It is called black-box testing. http://en.wikipedia.org/wiki/Black-box_testing

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Hotaru on March 16, 2012, 02:49:35 am

Hm,

I admit I'm not good with computers. I tried reading DFHack's source code but couldn't get the answer.

But, how does the game, being able to use only a finite amount of RAM, store a boundless amount of items, etc? Does it write to hard disk, or does it wait for more memory to become available?

Thanks for this awesome thread, by the way. You're a genius.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Kogut on March 16, 2012, 02:59:08 am

Quote from: Hotaru on March 16, 2012, 02:49:35 am

But, how does the game, being able to use only a finite amount of RAM, store a boundless amount of items, etc? Does it write to hard disk, or does it wait for more memory to become available?

Amount of items is not boundless but limited. It is hard to hit this limit as increasing amount of items is resulting in lower FPS, resulting in FPS death.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Hotaru on March 16, 2012, 03:07:47 am

Quote from: Kogut on March 16, 2012, 02:59:08 am

Quote from: Hotaru on March 16, 2012, 02:49:35 am
But, how does the game, being able to use only a finite amount of RAM, store a boundless amount of items, etc? Does it write to hard disk, or does it wait for more memory to become available?
Amount of items is not boundless but limited. It is hard to hit this limit as increasing amount of items is resulting in lower FPS, resulting in FPS death.

Yes, I understand. The reason why I ask is, both the game waiting for memory becoming available and having to write to HD would probably result in exactly the game slowing down a lot.

I've actually been theorizing that that's the cause, because the game seems to run with excellent speed on my laptop with a SSD compared to another computer of similar processor and RAM but 5400 RPM HD. Unless I'm just imagining it.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Kogut on March 16, 2012, 07:08:12 am

Quote from: Hotaru on March 16, 2012, 03:07:47 am

Quote from: Kogut on March 16, 2012, 02:59:08 am
Quote from: Hotaru on March 16, 2012, 02:49:35 am
But, how does the game, being able to use only a finite amount of RAM, store a boundless amount of items, etc? Does it write to hard disk, or does it wait for more memory to become available?
Amount of items is not boundless but limited. It is hard to hit this limit as increasing amount of items is resulting in lower FPS, resulting in FPS death.

Yes, I understand. The reason why I ask is, both the game waiting for memory becoming available and having to write to HD would probably result in exactly the game slowing down a lot.

I've actually been theorizing that that's the cause, because the game seems to run with excellent speed on my laptop with a SSD compared to another computer of similar processor and RAM but 5400 RPM HD. Unless I'm just imagining it.

It is likely as operating system will use hard drive as RAM (way, way slower) if RAM is completely used.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Kogut on March 16, 2012, 07:42:27 am

Quote from: Kogut on March 15, 2012, 06:08:52 pm

In my current test (create object, destroy object with [SPEED:0] dwarves) I see a constant FPS drop, from 4500 to 3000. I will try to reproduce it again (without changes to RAWs during game, with disabled internet and antivirus etc), maybe we will see proper bug report.

I am unable to reproduce this problem, now I will try with checking whatever list of dead units is eating FPS.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Stefrist on March 16, 2012, 11:12:06 am

Just a short reply for me to keep reading the thread. Takes too long, my boss might not approve :p
I'm going to use a current save for !!SCIENCE!! as well, but it wont have a scientific control group. (or the control group is the FPS drop itself).

I'll keep it posted, interesting subject here.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 16, 2012, 11:43:26 am

Quote from: Hotaru on March 16, 2012, 03:07:47 am

Yes, I understand. The reason why I ask is, both the game waiting for memory becoming available and having to write to HD would probably result in exactly the game slowing down a lot.

I've actually been theorizing that that's the cause, because the game seems to run with excellent speed on my laptop with a SSD compared to another computer of similar processor and RAM but 5400 RPM HD. Unless I'm just imagining it.

Hard drive is never used, thankfully. If Virtual Memory (using the hard drive instead of RAM) was ever used, you would know it.

As far as I can tell, DF runs almost completely from memory during actual play with the exception of when it is tracking "off-board" units like historical figures, which it loads from the files in your save directory on the fly, and causes serious slowdown when it does. This, and load/save time would be the only times hard disk speed would ever matter.

The thing is, memory is about a million times slower than the CPU, which is exactly why DF lags so much - it crunches so much raw data that it can't store anywhere but in RAM because there is so much of it, that something close to 99.9999% of the cycle time is spent waiting on memory fetches.

Hard disks are significantly slower even than that, generally a hundred times slower, off the top of my head.

Anyway, items in this game have a data storage space-saving feature in the form of only recording items as pointers. This causes more waiting on memory fetches, but saves more memory overall, and is why the game is ever even capable of storing such huge amounts of items. The game basically stores an item without much data attached to it as a pointer to a "shape", such as "boulder" or "goblet", and a "material", both of which are only a single instance in memory that every item of that type or material all point back to in order to get their information.

Pointers are small. I always like to think of RAM as a giant filing cabinet system, each cabinet a number inside of a box which is labelled. A pointer doesn't actually contain real information inside of itself, it just tells you what cabinet to look in to get the information you need. This way, if it's a really large amount of information, you can just have everything point to the one large object, rather than storing a lot of data all over the place. You also only have to update a single object if you just have pointers to a single piece of data, and the pointers will still be pointing to the right object with the new data.

You would also need some extra pointers for special data, like how worn out clothes are, or decorations, and creator info, so any given individual object in memory would consist of only about 2-6 pointers (depending on how Toady set it up) in a container in this giant vector.

Because pointers are small, and you only need a couple pointers, it might only take 4 bytes of memory to store these things. Because this is a 32-bit system, the hard limit (that most computers have more than) of memory in this game is 2 GB of RAM... so we have roughly enough space for half a billion objects... and my extreme case test was only a million. (And it effin' killed FPS with the number of pointer traces it had to do, already.)

For reference, I kept Task Manager up when things really got going on the tests. Just running DF normally? 350 megs of RAM. (Remember, map data takes up a LOT of data, as it records around five million tiles in a standard embark, each taking up several bytes.) Running DF with a million boulders clogging the system? 550 megs of RAM. So, basically, 200 bytes total per item (across all the data structures and pointers that would be used) when you have a ceiling of 2 billion bytes of RAM. Of course, clothing items would take up more than a boulder, as has already been mentioned in this thread.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Hotaru on March 16, 2012, 12:04:23 pm

Quote from: NW_Kohaku on March 16, 2012, 11:43:26 am

snip

Excellent. Thanks for explaining it. And... I had forgotten to check completely! The computer that gets smoother DF performance has DDR3 1333 MHz ram while the older one has DDR2 667 MHz, despite having the same amount. Maybe that explains it.

So... at this time you know items on the map as well as empty space on the map lead to slowdown, and that the game does sort the hypothetical main item vector. Where can you go from there?

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: blue sam3 on March 16, 2012, 12:28:59 pm

Quote from: Psieye on March 15, 2012, 06:22:38 pm

Quote from: blue sam3 on March 15, 2012, 04:04:19 pm
The accessibility of space has no noticeable effect.
What exactly do you mean here? Your data dump mentioned nothing about walling off the huge swaths of empty space you dug out. If you meant what I think you mean, then I have a fort that directly counters that statement. A large area of sand was dug out to train some new miners and FPS bombed. When I installed and locked doors to seal off the dug out space, FPS recovered.

Sorry, forgot to put that in the data dump. When I was collapsing the areas, I first channelled around the edges, leaving them supported by a single pillar in the centre, and there was no impact on FPS. It could just be that the shear scale of all of the other effects involved completely blanked it out, I guess. It is also possible that the fact that there was no reason to path through those areas (or anywhere else, really, since all that ever happened was me digging stuff out, and that massacred FPS even on a small scale) and the relatively small population reduced the effects.

Quote from: Girlinhat on March 15, 2012, 08:29:13 pm

Quote from: kaijyuu on March 15, 2012, 07:24:58 pm
Hell even if Toady does squat, we'll know exactly what to avoid.

And open space that isn't pathable definitely contributes to framerate issues. Make two identical worlds/embarks, with the sole exception of the z-levels above the surface. Even only having 1 z level gives me a noticeable bump at high framerates (got 1300 at the start of my latest embark, woo).
That's different. Available Z levels are known to cause issues, but the number of total levels is static. If you have a layer of solid stone and a layer of totally mined out stone, it's still a layer. The difference is, if the dwarf can path through it or not. If they can, you incur pathing lag atop of world size lag. If they cannot, you only have standard lag.

Not true, actually. Large inaccessible areas had almost identical effects on framerates for me as large accessible areas, and large channelled out areas were actually worse. (No flyers in game).

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 16, 2012, 01:53:09 pm

Quote from: Hotaru on March 16, 2012, 12:04:23 pm

Quote from: NW_Kohaku on March 16, 2012, 11:43:26 am
snip

Excellent. Thanks for explaining it. And... I had forgotten to check completely! The computer that gets smoother DF performance has DDR3 1333 MHz ram while the older one has DDR2 667 MHz, despite having the same amount. Maybe that explains it.

So... at this time you know items on the map as well as empty space on the map lead to slowdown, and that the game does sort the hypothetical main item vector. Where can you go from there?

Yeah, as I said, DF has to routinely check through tens of megabytes of data in memory before it can complete the computations for a single frame, which means the overwhelming bottleneck of DF is in waiting on memory fetching. As such, RAM latency is probably more important than your CPU in determining how fast DF actually runs.

What I'm trying to do, however, is find the ways in which this vector breaks down. DF appears to really just use a C++ STL (standard template library) vector in order to handle all the heavy lifting in this regard. There are two ways to go with this...

One, there is always the possibility that the cleanup routines are not being properly invoked in every instance - which is why I am testing things like atom smashing, and will try testing out magma dumping. This is the primary reason I started this thread, because there are so many people out there who talk about having "unavoidable FPS decay" when they run long-term forts. I am trying to isolate why that FPS decay occurs, so that if there are any errors in the maintenance of the vector, they can be fixed.

Two, that the stl vector itself might be better of replaced with a custom-built data type. Standard vectors are not really well-suited for the removal of data from any point in the vector except the last element of data put into them. Especially in the cases that I am talking about, where I stuff a million items into that vector, and then start eliminating them from the vector, it basically takes 5 hours to resolve one single instance of the removal process.

STL vectors, and STL stuff in general is made to be as versatile as possible, but that comes at a cost of not necessarily being as fast in specialized circumstances, so when there's a data structure that's going to do some very heavy lifting at the core of your most significant bottlenecks, like this global item index vector, it can pay to have custom-built methods that are optimized for the task at hand, like handling large-scale and very frequent element removals from the arrays. As far as I can tell, when I order the destruction of 10,000 boulders, the game has to re-sort that vector one by one for every single boulder that is removed from that vector, leading to nightmarish lag.

Of course, at the same time, it might just be the game is also searching through a million objects in a vector for other reasons, like trying to pathfind to the closest boulder of one million ten thousand separate times, which causes lag on its own.

Either way, though, this is potentially an area for significant optimization, even if it is a rather heavily construed situation I put the game in to make the point.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Hotaru on March 16, 2012, 02:20:57 pm

Okay. That sounds really good, but just to be practical, since you will need to contact Toady with the results anyway, wouldn't it be easier to do it with the idea asap? Of course that would detract from the awesome, but... slowdown is the worst "bug" of all (not that I've polled). It's one most players face eventually and it does tend to kill the best forts.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Girlinhat on March 16, 2012, 02:32:57 pm

Toady reads the forums, rest assured. I'm fairly sure that FPS drag over a long time is on his list of "issues of not very significance." but if someone gave him a sheet of paper that said "do this to fix EVERYTHING" then he'd have a lot less work to do and could easily knock out that issue.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: wierd on March 16, 2012, 03:21:15 pm

One thing he might consider doing is to make his application multiprocessor aware.

There is a *lot* of concurrency in DF, being shoehorned into serial execution. (Or rather, there are a lot of computations that would benefit from parallel processing.)

The ram speed bottleneck is unavoidable, but toady can limit the amount of actual time wasted waiting bay processing several things at once.

For instance, the movement of the bluejay 3 zlevels away is not dependent on fluid calculations.

I understand that parallelism is hard, but he could still simply multithread with some glue.

Getting another core in on the action, even if it is spending most of its time waiting for ram like the main thread's cpu, could speed up actual game time by reducing the size of the process queue. Other tricks might be creatively using 64bit cpu registers on multiple cores, since you can read a register way faster than a fetch from ram. (Eg, you allocate a dummy thread on other cores, just so you can make use of registers on those cores. The communication never leaves the chip dye, so access will be very fast. 64bit registers can hold a surprising amount of data. Not several megabytes.. no... but for things like a flag, or a temporary holding point for pointers, and a location for an accumulator... registers beat ram any day of the week. Course, toady would probably need inline assembler to do that.)

I really think DF would benefit insanely from splitting the main thread into independent subthreads, and pushing them on different cores if available.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Hotaru on March 16, 2012, 03:31:26 pm

It's something those of us with 64bit multi-cores would really appreciate, but my understanding is that it's been discussed before and it's generally understood it would take so much effort that he does not consider it economical. Of course if you can present a simple way to do it, maybe it would be different?

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Girlinhat on March 16, 2012, 03:33:39 pm

Go up to the search bar and type "multi-core" or "multithreading" or any variation there of. There's a literal endless flood of threads over "baww it needs multithreading!"

You're not the first to think of it, although everyone seems to think they are. Every week or so you get someone who's like "I've got a great never-before-seen idea that's totally unique!" and then you look and it's like "we should multithread" or "dwarves should wear clothes" or "prepared meals are too expensive".

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 16, 2012, 03:47:45 pm

Quote from: Girlinhat on March 16, 2012, 03:33:39 pm

Go up to the search bar and type "multi-core" or "multithreading" or any variation there of. There's a literal endless flood of threads over "baww it needs multithreading!"

You're not the first to think of it, although everyone seems to think they are. Every week or so you get someone who's like "I've got a great never-before-seen idea that's totally unique!" and then you look and it's like "we should multithread" or "dwarves should wear clothes" or "prepared meals are too expensive".

I doubt he thinks he's the first to say it, and he does have a point - avoiding the wait on memory fetches is the reason threading exists in the first place. There have also been well explained arguments on ways in which multi-threading of pathfinding could be implemented without causing too many conflicts (as entirely different creatures pathfinding need not wait on the results of the other creature pathfinding), although these still have problems of waiting on conflict resolution and raise the question of just how many pathfinding operations take place concurrently in an average fort. (Pathfinding checks don't necessarily take place every frame.)

It's also not that Toady has categorically said that he would never do 64 bit ever, and he's basically tacitly admitted he would try to get around to it, eventually, but that he's putting it off for now.

There is a reason to believe that keeping the topic alive and trying to argue the reasons for something like that, while also explaining the easiest ways to approach it to help Toady approach the subject from the right angle might eventually meet success.

For the time being, however, I'm focusing in on optimizing with what we already have, and looking at ways in which the current system might be buggy.

I'd like to ask once again for someone to try out on their own computer the results of one of my last experiments - http://dffd.wimbli.com/file.php?id=5906

Play with the "FPS Bomb - Small Contraction Experiment - Control" and "FPS Bomb - Small Contraction Experiment - End State" and compare the FPS you get on the two without really doing anything, just letting the game run.

I think there might be a difference in the FPS lag in that, but want to get some second opinions before I go off with that.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Hotaru on March 16, 2012, 04:00:37 pm

It's downloading. But if you don't mind, could you maybe upload it to mediafire or similar? That file server is absurdly slow. Waiting 15 minutes for it to arrive is very disenchanting.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Hotaru on March 16, 2012, 04:33:40 pm

So yeah - 64bit Windows 7, intel core i7 2667m, 4 gigs DDR3 1333 MHz ram - both are running steadily 5 minutes into the test and hovering between 55,000 FPS and 53,000 FPS. I can see no difference between them.

Update: 15 minutes into the test, they're still hovering seemingly randomly between 55,000 and 53,000 FPS both. I can see no difference between them, it's more like watching random motion. I think I'll shut this down unless there's a reason to continue, and focus on home security instead :P

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: bombzero on March 16, 2012, 04:37:17 pm

@multithreading... i have a 64 bit system, you may have one, but what about people with 32 bit? switching to multi-threading would strain 32 bit processors. Also, switching the entire game code would take forever, and introduce a slew of bugs. So long term gain, yes. but with the cost of a portion of the fanbase who have older computers, and a few years of development time, which would drive off another portion of the fanbase.

mostly the calculations need to be optimized, which Toady is trying very hard at, and what NW's experiment could potentially help with.

Also, it is better to improve a single thread process' algorithms then it is to make that process multi-threaded.
having 2,4,6, or even 20 cores with 1 thread a piece wont improve the framerate of the game if the same code issues are dragging it down.

tl;dr: would screw the last few 32 bit users, wouldn't help till the code bugs are fixed, would introduce many new bugs.

@Hataru, im breaking into your house and stealing your computer, just thought id let you know in advance.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 16, 2012, 04:38:03 pm

Quote from: Hotaru on March 16, 2012, 04:00:37 pm

It's downloading. But if you don't mind, could you maybe upload it to mediafire or similar? That file server is absurdly slow. Waiting 15 minutes for it to arrive is very disenchanting.

I'm actually trying the contraction experiment again, this time with a "medium contraction" of a quarter million items. I'm still going through the destruction phase, however, and it will continue to "bake" for what appears to be about another hour.

The length of time it takes to destroy all these items, however, definitely displays some geometric complexity growth. I could run the whole small contraction test in roughly 5 minutes, and I estimate the large contraction test would have taken several days to complete. This is the difference in time it takes when you are destroying 130,000 objects compared to 1,040,000, so a factor of eight times as much data takes around a thousand times as much time to complete.

The medium contraction test I am running right now is double the number of boulders of the small, and is looking like it will take about two hours (I should have marked when I started...)

here's a mediafire link: http://www.mediafire.com/?t2n236cdd3sdxo5

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 16, 2012, 04:39:39 pm

Quote from: Hotaru on March 16, 2012, 04:33:40 pm

So yeah - 64bit Windows 7, intel core i7 2667m, 4 gigs DDR3 1333 MHz ram - both are running steadily 5 minutes into the test and hovering between 55,000 FPS and 53,000 FPS. I can see no difference between them.

Wow, I know my computer's old, but damn. I'm only getting 600 FPS at the best.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Hotaru on March 16, 2012, 04:52:08 pm

As I said, this Asus ux31 I have is really, really fast for DF for some reason. In the world I genned for "Salore Flowerpetals'" adventure, where the earth is about 20 z-levels deep, I can run a 16x16 embark at playable speed levels unless there is a river there. It also will gen a large world to the year 1000 in 30 minutes.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: bombzero on March 16, 2012, 04:57:02 pm

Quote from: Hotaru on March 16, 2012, 04:52:08 pm

As I said, this Asus ux31 I have is really, really fast for DF for some reason. In the world I genned for "Salore Flowerpetals'" adventure, where the earth is about 20 z-levels deep, I can run a 16x16 embark at playable speed levels unless there is a river there. It also will gen a large world to the year 1000 in 30 minutes.

As i mentioned, it may not be there in the morning :P

anyways, im assuming you have a very fast processor?
fun fact, i bought a 400$ computer and a 70$ graphics card and i can play almost every single game on mid-high graphics... just need a better processor and ill have a qualified gaming computer.

speaking of processors, NW based on your observations do you think multi-threading would help or hurt in the short and long term of DF development?
just a slight question, not trying to derail the thread on a multi-threading talk.

also small idea for your experiment, test whether items traded TO caravan affect fps, if you are correct about the fps issues then the mass dump of stone goods on a caravan is a fps killer and common in long term forts, if trade=bad then this is even more urgent for Toady to fix seeing that this is the caravan arc of development.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Hotaru on March 16, 2012, 05:08:47 pm

Quote from: bombzero on March 16, 2012, 04:57:02 pm

As i mentioned, it may not be there in the morning :P

anyways, im assuming you have a very fast processor?

Oh, but it's morning already and I'm a night owl in the weekends :D

The processor is Intel i7 2677m. I don't think it's that fast. But I can recommend this laptop, it's really great all round. Best computer I've ever had, and I've owned computers like 15 years.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: kaijyuu on March 16, 2012, 05:12:22 pm

I thought my computer was decent and I only get 8000 fps in the normal arena map with 0 units :(

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: bombzero on March 16, 2012, 05:13:11 pm

how much did it cost? im not exactly rich so i prefer building my own stuff, more for less, and always exactly as you want it, just have to get the few thousand ill need for my ultimate gaming computer that will be able to run DF at THOUSANDS OF FPS!!!!!!!! and less importantly any other game released by any company for the next few years...

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 16, 2012, 05:13:32 pm

Quote from: bombzero on March 16, 2012, 04:57:02 pm

speaking of processors, NW based on your observations do you think multi-threading would help or hurt in the short and long term of DF development?
just a slight question, not trying to derail the thread on a multi-threading talk.

I haven't done all that much with multi-threading, so I can't say whether the benefits or the costs are under or overstated when I see these things, however, I do know that some things are typically on different threads in many programs. Mouse and keyboard input, for example, can be put on its own thread so that when the game is going through some serious calculations, like long worldgen periods between years, the game can still recognize requests to pause the process. Graphic output can also be put on its own thread fairly easily. Pathfinding (concurrently in the same frame) can be "embarrassingly parallel" as someone put it in the suggestions forum a while ago, as traversing the connectivity grid is something that can be done without having any interference from the other pathfinders (unless you were trying to pathfind to the point where another character was pathfinding, but there aren't any such events in the game, already) provided you separate out the claiming of jobs (so that two different haulers don't try to pathfind to the same sock to haul away concurrently). It might be entirely possible to do something like splitting temperature checks up into multiple threads where you do something like cut up the map into quarters and go through every item in those quarters in individual threads, since temperature checks shouldn't spill over across tiles, although that might depend on how temperature checks actually iterate.

Quote from: bombzero on March 16, 2012, 04:57:02 pm

also small idea for your experiment, test whether items traded TO caravan affect fps, if you are correct about the fps issues then the mass dump of stone goods on a caravan is a fps killer and common in long term forts, if trade=bad then this is even more urgent for Toady to fix seeing that this is the caravan arc of development.

I'll try to get to that. I still need to do magma-dumping, huge caravans, and then huge tradeaways to caravans, as well as obsidian-casting items, sock destruction, and ludicrous animal gibbing. Maybe something else I've forgotten. Too many things to check...

*Ding*! I finished baking the Medium Contraction Experiment. I have it set to [SPEED:0] dwarves, so maybe that'll help tamp down some of the noise, or maybe not? I just have to do the quick control run and I'll try to see if I get more notable results on this one.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 16, 2012, 05:23:03 pm

Again, I think I'm getting a small, but present result.

I seem to get 310 FPS (again, I put in SPEED:0 dwarves this time) with the medium contraction control, and 280 FPS with the medium contraction end state.

The saves on DFFD: http://dffd.wimbli.com/file.php?id=5913
Mediafire: http://www.mediafire.com/?d1zmnrvg39gey8c

EDIT:
Actually, going back to the control, I'm getting closer to 400 FPS now, so it represents a much larger drop than I at-first thought.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: bombzero on March 16, 2012, 05:26:09 pm

Quote from: NW_Kohaku on March 16, 2012, 05:13:32 pm

I haven't done all that much with multi-threading, so I can't say whether the benefits or the costs are under or overstated when I see these things, however, I do know that some things are typically on different threads in many programs. Mouse and keyboard input, for example, can be put on its own thread so that when the game is going through some serious calculations, like long worldgen periods between years, the game can still recognize requests to pause the process. Graphic output can also be put on its own thread fairly easily. Pathfinding (concurrently in the same frame) can be "embarrassingly parallel" as someone put it in the suggestions forum a while ago, as traversing the connectivity grid is something that can be done without having any interference from the other pathfinders (unless you were trying to pathfind to the point where another character was pathfinding, but there aren't any such events in the game, already) provided you separate out the claiming of jobs (so that two different haulers don't try to pathfind to the same sock to haul away concurrently). It might be entirely possible to do something like splitting temperature checks up into multiple threads where you do something like cut up the map into quarters and go through every item in those quarters in individual threads, since temperature checks shouldn't spill over across tiles, although that might depend on how temperature checks actually iterate.

well my thought was that fluid calculations and temperature checks are interdependent on eachother, a dwarfs body needs to check its temperature as well as its medical condition, water can interrupt pathfinding, dwarfs need to know where other dwarfs will be in a few frames to pathfind effectively, overall a lot of things in DF are directly connected with checks that must be preformed before certain things can happen, my main concern is you would get threads waiting on threads.

seperating keyboard/mouse from everything else would be nice, figuring when sieges, caravans and migrants show up and with what could be its own thread, but if too many things are split up issues could develop worse then what it solves, DF is a LOT more complex then most games, and has MANY more calculations to make every second.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: wierd on March 16, 2012, 05:27:54 pm

Quote from: bombzero on March 16, 2012, 04:37:17 pm

@multithreading... i have a 64 bit system, you may have one, but what about people with 32 bit? switching to multi-threading would strain 32 bit processors. Also, switching the entire game code would take forever, and introduce a slew of bugs. So long term gain, yes. but with the cost of a portion of the fanbase who have older computers, and a few years of development time, which would drive off another portion of the fanbase.

mostly the calculations need to be optimized, which Toady is trying very hard at, and what NW's experiment could potentially help with.

Also, it is better to improve a single thread process' algorithms then it is to make that process multi-threaded.
having 2,4,6, or even 20 cores with 1 thread a piece wont improve the framerate of the game if the same code issues are dragging it down.

tl;dr: would screw the last few 32 bit users, wouldn't help till the code bugs are fixed, would introduce many new bugs.

@Hataru, im breaking into your house and stealing your computer, just thought id let you know in advance.

Actually, multithreading and 64bit address space are different beasties. Multithreading means you divide the program into different subprocesses, instead of a single enormous one. This let's the program make use of multiple cpus and/or multiple cores.

The 64bit advantage is "huge" registers inside each core, and access to a huge memory space.

Again, multithreading is not tied to 64bit arch, you just need to have more than one cpu, or have a cpu that at least does intel's hyperthreadding.

Also, I indeed did not presume that toady doesn't know about multithreading. I presumed he is avoiding it because concurrency is a royal PITA, caused by a jackhammer without lube. (At least compared to a simple single thread process structure.) However, given the stagnation of cpu speed in the marketplace over the past decade, and the market trend for more cores instead, along with the expected feature set of this game, toady is going to have to bite the bullet and switch to multithtreading someday. (I can't see the war and caravan arc releases operating without it. Not at playable fps.) The sooner he starts building his MT framework, the less blood he will pass rectally later while trying to add features.

For the time being, I was suggesting simply creating "dummy" threads on other cores, so he could get access to their registers, because doing so would greatly speed up processing of the primary thread under certain types of processing conditions. (Accumulators, flags, pointer arrays, etc could be stored in the vacant cores' registers, even though the process is still single threaded otherwise. The access to the other core registers is cheap compared to a ram access. Other things that might help are dummy operations on the other cores to get data into the shared cpu cache while the main core is busy as a kind of prefetching. This way the main thread makes more efficient use of the cpu instruction cache, reducing the need to hit ram.)

Those things re not full blown multithreading, but would allow a multicore cpu to benefit playing DF.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 16, 2012, 05:33:27 pm

Yeah, when I get the control up to the same seasonal time-frame as the test case, I have FPS around 450 (summer is a fast season) ranging from 350 to 500, compared to 260 only rarely spiking up into 300 on the test case. I think I am getting reliably 25% framerate drops from having done this test case.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: bombzero on March 16, 2012, 05:36:01 pm

ahhh dummy threads, good thinking. i remember helping make a mod for a open-source single thread game along those lines, one of my first actual coding experiences.

anyways, essentially the plan would be to move more stuff away from RAM and instead into the registry? hmm... temperature, pathing, item indexing, and combat would be priorities i imagine, some of the other stuff is perfectly fine operating on the current system, but everything higher frequency could run off the registry, without hurting 32 bit users.

anyways on topic: NW is it possible that its one particular set of pointers not being deleted when atom smashing? the fact that you get 'some' fps improvement but not total improvement seems to suggest that.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: wierd on March 16, 2012, 05:45:41 pm

A cpu has readable/writable "slots" in it called registers.

Take a simple addition instruction. It has 3 registers. Operand1, operand2, and output.

Assembly programs can void accessing ram entirely in many cases by PUSHing the output from the last operation into another register for the next instruction.

The idea here is that we put frequenly accessed data and pointer values inside the registers of unused cores. No instructions are being done with those registers, so they are sitting there doing nothing.

Fetching data/pushing data from/to these outside registers is faster than waiting for ram, because the registers are almost directly connected to each other internally inside the cpu die. The latency is much lower, so the core doing the heavy lifting waits less while it gets the data it needs.

The cache prefetching basically does a similar operation to what the main thread will do, so that the cpu's branch prediction will store the instruction and its output in the cpu cache. The next time the instruction is called (on any core, because they share the same cache) it can grab data from there instead of doing the actual process cycle, or fetching from ram, depending on the instruction.

The goal is to reduce the number of waitstates in the main thread using clever tricks.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 16, 2012, 05:50:19 pm

Quote from: bombzero on March 16, 2012, 05:36:01 pm

anyways on topic: NW is it possible that its one particular set of pointers not being deleted when atom smashing? the fact that you get 'some' fps improvement but not total improvement seems to suggest that.

I'm not atom smashing right now, I'm using a reaction.

I set up the reaction so that the deletion of 100 stones creates 1 goblet as a by-product. For the control, I created an equal number of goblets just straight-out.

The theory behind the contraction test is that the arrays are never sorted, so that if I created a huge number of items, and then left a small number of items still in those arrays, but spread out across a large swath of these arrays that the arrays would never be cleaned up - you'd wind up with huge numbers of arrays that were empty except for a single item in them.

Since I'm getting FPS decay for trying this, it seems like the theory worked. The contraction left a lot of mostly-empty arrays behind that are never sorted, and chew up some FPS being iterated through.

Again, if I could get some outside corroboration on these saves:
The saves on DFFD: http://dffd.wimbli.com/file.php?id=5913
Mediafire: http://www.mediafire.com/?d1zmnrvg39gey8c

I find a notable drop in FPS performance, although I'm not sure how notable it might be on Hotaru's damn supercomputer.

This might be the evidence I was looking for, and a process of players destroying large numbers of objects while keeping a few objects in their stockpiles forever is definitely the sort of thing that occurs in long-term fortresses that might lead to gradual FPS decay.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Mego on March 17, 2012, 01:08:12 am

Posting to watch and help. I'll start running those experiments either Saturday or Sunday.

Specs for reference:

Toshiba Satellite A215-S4747
Windows Home Premium x64, SP1
AMD Turion 64 x2 Mobile Technology TL-56 1.80 GHz
ATI Radeon X1200 Graphics Card
2.50 GB DDR2 RAM

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Hotaru on March 17, 2012, 05:24:54 am

Quote from: bombzero on March 16, 2012, 05:13:11 pm

how much did it cost? im not exactly rich so i prefer building my own stuff, more for less, and always exactly as you want it, just have to get the few thousand ill need for my ultimate gaming computer that will be able to run DF at THOUSANDS OF FPS!!!!!!!! and less importantly any other game released by any company for the next few years...

How much did it cost? Well, it seems like we live in different countries, so it may be best to google. This "Zenbook" (what an auspicious name, too!) seems to cost about $1200 in the USA.

I can run more tests if you like Kohaku. But since my results seem to be so much outside the norm with tens of thousands of FPS and no significant difference, I'm not sure if they're useful at all.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 17, 2012, 11:55:19 am

Quote from: Hotaru on March 17, 2012, 05:24:54 am

How much did it cost? Well, it seems like we live in different countries, so it may be best to google. This "Zenbook" (what an auspicious name, too!) seems to cost about $1200 in the USA.

I can run more tests if you like Kohaku. But since my results seem to be so much outside the norm with tens of thousands of FPS and no significant difference, I'm not sure if they're useful at all.

Why don't you try running some different experiments, instead of testing results?

For example, get the fork save, and try testing giant caravans. Go to the creature_domestic.txt and creature_equipment.txt and add two zeros to their TRADE_CAPACITY. That should result in a hundred times more objects arriving with the caravan, resulting in plenty of possible caravan overflow that might generate lag.

Let that run for as many years as you can stand. Try for at least 10.

Please keep a before-and-after set of saves for comaprison.

Thanks!

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: dizzyelk on March 17, 2012, 02:07:42 pm

Ran your med contraction for a year on my athlon II 2.8 Ghz with 4 GB DDR3 1333 RAM...

Control:
Started out with 290-315, which slowly decreased to 205-215 by the start of summer. About halfway through summer it shot up quickly to 310-345, usually on low side of the scale, but regularly popping up to the high end. By the start of autumn it was steadily 330-340 but occasionally spiking to 345-350. It rained and dropped to 215-230, staying there after the weather cleared, with occasional spikes to ~260. Rained again, then shot up to 310-330 after that rain ended. Was fluctuating about 225-275 right before the caravan showed up, then 150-185 while they were unloading. Was 220-240 at the start of winter. Dropped slightly to 210-235 while the merchants packed, increasing to 290-315 once they were gone. Slowly decreased to 245-275 by the start of spring. Finally talked to the liaison right then, with an immediate increase to 300-320.

End state:
Started at 240-260, but rapidly increased to 320-335. Stayed there for a short while, then would slowly spike down to 275 a few times before ending up steady at 285-300. Was at 235-245 before the caravan showed up, and stayed the same while they were there. Shortly after winter there was a human interest story as Generic 12 and Generic 13 got married. I d'awwwwwed. Its nice to know that even in this unholy pit of sweatshop despair love can blossom. Was at 245-260 as the merchants packed to leave, then raised to 285-295 when they left, with slow spikes up to 295-315, before staying steady at 285-300 after talking to the liaison. That slowly decreased to 270-280 after the start of spring. with spikes as low as 250. Summer came, and the framerate dropped down to 265-285, but would spike as high as 310. However, it slowly dropped to be around 220-235 by autumn.

It seems to me that this experiment would be better done on a map with no rain, as not only would the FPS drop during rain, but sometimes I would see the range of FPS be 10-30 lower after the rain ended, before slowly raising to prerain numbers, if it would raise at all. I also noticed that the control never really spiked significantly downward (i.e. more than 10) during the control, but would during the end state.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 17, 2012, 02:41:00 pm

I'm going back to finish the atom-smashing experiment now, with [SPEED:0] dwarves this time.

The game runs much slower like this, as the craftsmen built a much larger number of goblets and there are much more pathfinds taking place per average frame. I'll only keep it like this for a year or two, but since I'm crushing about 10 times as many objects in the same period of time, it should produce results (if any) faster.

Once this is done, I want to work on different experiments, like evaporating/melting materials. I figure it would be faster to just set objects to evaporate than it would be to magma dump things, since that's basically testing the same temperature-based destruction, anyway, and it wouldn't have to involve the extra step of needing to actually dump objects, which requires manually stopping the game to designate.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Hotaru on March 17, 2012, 03:32:47 pm

Quote from: NW_Kohaku on March 17, 2012, 11:55:19 am

Quote from: Hotaru on March 17, 2012, 05:24:54 am
How much did it cost? Well, it seems like we live in different countries, so it may be best to google. This "Zenbook" (what an auspicious name, too!) seems to cost about $1200 in the USA.

I can run more tests if you like Kohaku. But since my results seem to be so much outside the norm with tens of thousands of FPS and no significant difference, I'm not sure if they're useful at all.

Why don't you try running some different experiments, instead of testing results?

For example, get the fork save, and try testing giant caravans. Go to the creature_domestic.txt and creature_equipment.txt and add two zeros to their TRADE_CAPACITY. That should result in a hundred times more objects arriving with the caravan, resulting in plenty of possible caravan overflow that might generate lag.

Let that run for as many years as you can stand. Try for at least 10.

Please keep a before-and-after set of saves for comaprison.

Thanks!

I started running it as you described.

However, strangely, after some in-game time the FPS dropped from the 10ks into hovering ~ 200.

There's only two explanations I can think of - either I forgot to unpause the previous time (I wonder if I could be that silly :D) or it only started some pathfinding routine when I locked the door. Well, we'll see how it goes. Unless I fall asleep.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Hotaru on March 17, 2012, 04:15:11 pm

I think I have something.

I made caravans bring 1,000 times the normal amount of items with the previous mod.

Before a caravan arrived, the game was running at about 200 FPS. After the caravan and diplomat had left, the FPS is still lingering at 95. While the caravan was here, it was around 50. I can post the save file if you think it would be helpful.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: bombzero on March 17, 2012, 07:00:11 pm

seems to imply that atom smashing and caravans leaving delete items in the same way, now we must atom smash the caravans to further test this.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 17, 2012, 11:00:11 pm

Quote from: Hotaru on March 17, 2012, 04:15:11 pm

I think I have something.

I made caravans bring 1,000 times the normal amount of items with the previous mod.

Before a caravan arrived, the game was running at about 200 FPS. After the caravan and diplomat had left, the FPS is still lingering at 95. While the caravan was here, it was around 50. I can post the save file if you think it would be helpful.

If you could, that would be helpful.

Also, let the diplomat in, and go through all his speech, he adds lag trying to pathfind to you infinitely if you don't let him in.

Having several years of data to see if it has a lingering impact is important, as well.

I have atom-smash tests complete.

I have a control save that runs at a usual 500-600 FPS around early spring. I am advancing my experimental save to the end of the year as well for the closest comparison I can make.

Atom-smash experiment after I have shut off the atom smasher, and eliminated the goblets seems to start the year bouncing around between 250 and 350.

I'm going to leave this running for a while longer to see if it will spike back up in the summer, or something, but in the meantime, I'd like to see if others get the same result I'm getting on the atom-smash test.

Atom Smasher Experiment saves on DFFD (http://dffd.wimbli.com/file.php?id=5926)

I'd like to see if someone else gets results on this test, as well, before I go announcing something.

EDIT:

I keep getting inconsistent readings on this, however.

First, I had a really slow game - 200 or so, but then, I end process the game, and reload the same save, and now, in the same season, I'm getting 400, and it's basically made up most of the FPS losses.

The same thing with those medium contraction tests - when I play back the same saves over and over, I lose all the FPS loss.

Maybe there's just a gremlin in the machine and so many variables beyond my control in this that I'm getting too much noise interfering making my data register false positives or false negatives when I should be getting positives, or else there actually is something about the way that the game is saved that "heals" the damage to the FPS that I've inflicted by doing all these tests. Perhaps the vectors are not repopulated in the same order between saves, and that is performing an inadvertent clean-up function which results in a FPS boost if you save, close the game, and then reload?

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Kogut on March 18, 2012, 12:51:16 am

Quote from: NW_Kohaku on March 17, 2012, 11:00:11 pm

Perhaps the vectors are not repopulated in the same order between saves, and that is performing an inadvertent clean-up function which results in a FPS boost if you save, close the game, and then reload?

Quite possible, I checked my FPS after saving DF, restarting computer (as lag may be caused by memory leaks from DF or something else). Caravan test looks quite promising, I will try to check this one.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 18, 2012, 01:17:10 am

Quote from: Kogut on March 18, 2012, 12:51:16 am

Quite possible, I checked my FPS after saving DF, restarting computer (as lag may be caused by memory leaks from DF or something else). Caravan test looks quite promising, I will try to check this one.

It's not really memory leaks, it's that the lag I am looking for would be specifically caused by the vectors not being sorted properly in all conditions - if the act of saving and loading results in completely restructuring the vectors from the beginning, then it means that this isn't the "memory leak" we are looking for.

I'm going to start on the temperature test. If others could test the atom smasher test for what FPS they get, it would help.

Well, I got myself down to 4 FPS rather quickly by making 1,000,000 objects that are melted, but not going away.

Liquids disappear on the season change, right? Maybe I should drastically cut down on the number of stones I'm melting... I'm still at the 16th of Granite.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Kogut on March 18, 2012, 01:27:15 am

Quote from: NW_Kohaku on March 18, 2012, 01:17:10 am

Quote from: Kogut on March 18, 2012, 12:51:16 am
Quite possible, I checked my FPS after saving DF, restarting computer (as lag may be caused by memory leaks from DF or something else). Caravan test looks quite promising, I will try to check this one.

It's not really memory leaks, it's that the lag I am looking for would be specifically caused by the vectors not being sorted properly in all conditions - if the act of saving and loading results in completely restructuring the vectors from the beginning, then it means that this isn't the "memory leak" we are looking for.

Yes, but it is an attempt to block all influences that may or may not affect FPS. Argh, I found two new (I hope) bugs during checking why my modded dwarves are not sending caravans.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Cellmonk on March 18, 2012, 01:50:42 am

This is great. I hope we uncover some things. For now, posting to watch. but I'll see if there's any way I can contribute, with my rusty old comp.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Kogut on March 18, 2012, 02:00:56 am

Quote from: NW_Kohaku on March 17, 2012, 11:55:19 am

Quote from: Hotaru on March 17, 2012, 05:24:54 am
How much did it cost? Well, it seems like we live in different countries, so it may be best to google. This "Zenbook" (what an auspicious name, too!) seems to cost about $1200 in the USA.

I can run more tests if you like Kohaku. But since my results seem to be so much outside the norm with tens of thousands of FPS and no significant difference, I'm not sure if they're useful at all.

Why don't you try running some different experiments, instead of testing results?

For example, get the fork save, and try testing giant caravans. Go to the creature_domestic.txt and creature_equipment.txt and add two zeros to their TRADE_CAPACITY. That should result in a hundred times more objects arriving with the caravan, resulting in plenty of possible caravan overflow that might generate lag.

With [TRADE_CAPACITY:15000000] caravan arrived with only 31 pages of goods - but FPS drop is still noticeable. I may try to trade away products to increase FPS drop.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Hotaru on March 18, 2012, 02:43:15 am

http://www.mediafire.com/?eceu6k6kvbk94zc

Here you are. The starting save was the fork save. The capacities were multiplied by 1000. The caravan arrived and left peacefully. A diplomat arrived and left unhappy after I sacked the outpost leader to get rid of him. Before the caravan arrived fps was at 200 or so. After the caravan left fps is hovering at around 90 or so for me. Checked three times.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Kogut on March 18, 2012, 06:04:06 am

I confirmed permanent FPS drop after caravan visit, 1900-2100 to 1700-1800 FPS. NW_Kohaku - I think that you can request reopening of http://www.bay12games.com/dwarves/mantisbt/view.php?id=5637

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 18, 2012, 10:06:57 am

OK, apparently, liquids are NOT cleaned up seasonally.

I restarted the fort, made around 1,000,000 boulders just before the season change (day 18 of the third month in Summer because Spring passed me by when I was in another window), and I left my fort running overnight to get to the season change.

It was still Autumn when I woke up.

I'm going to have to rethink how I'm doing this liquid test.

For now, I think I'll just try the vaporizing temperature test, instead, but first, I want to corroborate the caravan data.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Hotaru on March 18, 2012, 10:17:17 am

You should do it two ways

1) See that the save I posted gets you a lower FPS than the virginal fork save (the FPS drop has to do with the saved content proper)
2) See that the same process happens to you (the FPS drop happens in several instances of DF)

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 18, 2012, 12:01:55 pm

Vaporizing tests are going smoothly, so to speak.

Running at 40 FPS relatively reliably, so it'll basically take all day to run this test for a year.

Spoiler: Some of these guys really need some Beano (click to show/hide)

I've downloaded the trading save, and will run it when this thing is done.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 18, 2012, 01:58:57 pm

SDFLKJSDFLKSDF!

Power cut out in late winter, and I hadn't saved the progress on the vaporizor tests. That's basically the last day's worth of leaving the simulation running down the drain, since the liquification tests are going to need to be rerun, as well.

I guess I'll just run through Hotaru's data sample, and then run my own large caravan w/ large tradeaways test after that, and just leave the vaporization tests for when I go to sleep again.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 18, 2012, 02:38:44 pm

Hotaru - I downloaded your save, and don't notice any drop in FPS. The memory consumption in Task Manager (which I think is a more reliable meter at this time than just watching the FPS count) is also only 10 megs higher than normal.

I also looked in your save's raws, and the trade capacity isn't any higher than normal, either.

It's also only in the winter of the first year, with what I normally see as winter seasonal FPS drop.

Are you sure you uploaded the right save?

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Hotaru on March 18, 2012, 02:55:18 pm

That's... unexpected. It's the correct save, the dates modified confirm that.

I guess I must have screwed up and got excited over nothing. I changed the raws in the main DF raws folder only. I don't have experience with the winter slowdown, so I may very well have confused it with the caravan leaving - because they left as winter arrived, and when they were on the map FPS was markedly lower. Actually there wouldn't be any way to tell them apart other than wait untir winter has passed, which I of course didn't.

Sorry for wasting your time.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 18, 2012, 03:08:35 pm

Quote from: Hotaru on March 18, 2012, 02:55:18 pm

That's... unexpected. It's the correct save, the dates modified confirm that.

I guess I must have screwed up and got excited over nothing. I changed the raws in the main DF raws folder only. I don't have experience with the winter slowdown, so I may very well have confused it with the caravan leaving - because they left as winter arrived, and when they were on the map FPS was markedly lower. Actually there wouldn't be any way to tell them apart other than wait untir winter has passed, which I of course didn't.

Sorry for wasting your time.

As the saying goes, mistakes don't become errors until you refuse to learn from them.

Savegames have their own raws - this is a feature so that people who mod their games can upload saves where the effects of their mods can take place (because if a savegame requires something from a mod, and the raws aren't there for that item, the game will explode). Go into the save folder, and you will see a raw folder, objects folder, and then the raws for that particular save.

Your standard directory raws are only used for the creation of a new game or if you select it in the arena.

This is also why it's important to have several years' worth of data - a yearly set of backup autosaves will give you a bunch of data points at exactly the same time of year for comparison. That will smooth over seasonal FPS changes because you are always measuring from the 1st of Granite.

Again, for the sorts of things we are targeting as a source of FPS drop, I believe a more accurate gauge of FPS decline would actually be in your Task Manager's display of how much memory the game is actually consuming. The more objects in the game's memory, the more memory used, the more memory the game has to go over when iterating items.

When I start out with the fork save, I have around 350 megs of memory dedicated to DF. When I have a million objects in the game, even if they are nothing but puddles of melted stone, I am using 600 megs of memory. If that memory is not cleaned up, then even when the million objects are gone, you should still be using up over 350 megs of memory. It's not a clear result until you can push that number to something unambiguously larger than normal, like 400 megs of memory with the same number of objects, or else a much larger save file than normal.

EDIT:
Also, be aware that changing trade capacity has no effect on the first year you do it - the size of the caravan is apparently set at the start of the year, or else when the last caravan is resolved.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: bombzero on March 18, 2012, 04:16:31 pm

caverns could be screwing up your results more than a bit.

spiders make webs, webs are objects.

plants grow, plants are objects.

trees grow, trees are objects.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 18, 2012, 04:19:05 pm

Quote from: bombzero on March 18, 2012, 04:16:31 pm

caverns could be screwing up your results more than a bit.

spiders make webs, webs are objects.

plants grow, plants are objects.

trees grow, trees are objects.

I ran several of my tests for 10 years, so those trees should be growing at an even pace over all those years, and the FPS difference between them all is negligible, because my results were that the FPS drop (and amount of memory consumed by the game) were negligible.

Boulder Experiment (http://dffd.wimbli.com/file.php?id=5884) contains ten years of data, with all ten years included.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Kogut on March 18, 2012, 06:10:54 pm

Quote from: bombzero on March 18, 2012, 04:16:31 pm

caverns could be screwing up your results more than a bit.

spiders make webs, webs are objects.

plants grow, plants are objects.

trees grow, trees are objects.

I disabled caverns in my test.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 18, 2012, 06:23:09 pm

OK, I'm starting to pick up some trackable result - large caravans are producing a larger "unit-1.dat" file.

I'm going to have to change some of my stuff, because I need teststone to have an actual value in order to make producing it bring in larger caravans.

Before, I had caravans with 500,000 excess trade capacity.

Initial fork save has 13 kb "unit-1.dat" files, while trading away some of my junk to it gave me 72 kb for the first year, but I wasn't really trying to do much besides test some things out.

Next trading cycle, I have 10,000 goblets ready to go.

After this, I want to test the effects of improved goblets.

Then I want to test mass sock manufacture, and possibly mass improved sock manufacture. Then I'll try temperature tests again.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: arphen on March 18, 2012, 06:26:35 pm

i highly appreciate your work.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Cellmonk on March 18, 2012, 06:47:41 pm

This is going somewhere. Once your done with this cycle, I'll try to replicate the results using a game with most other factors modded out. Such as caverns, liquids, rock types, invaders, plants (yep, there won't even be any plants), and animals (I'll leave yaks or something, but make them biome specific or not appear in the wild at all), and worn clothing and armor. I'll also gen a world with no vampires or any sort of sentient creature besides dwarves (who I will make year round caravans). Then I will play with capacity.

I might want to consider making the dwarves capable of only creating gears or something, so that the caravan only brings one type of stuff.

Now, I should test the end product by putting max fps at 4 or something, then recording the cpu usage when I tell a certain number (I could set migrants to zero so that both tests will start and end with the same number of dwarves) of dwarves to restockpile the specific item type that was mass destroyed. both should end with the same number of that item (aprox) in existance (except for control 2, which will have that same number reachable by dwarves, the rest walled away.)

I should probably turn trances off too.

ok. so 5 tests.
control 1 (nothing created),
control 2 (certain amount created through manager but not sold to caravan, instead walled in somewhere),
Caravan destruction (control 2, but sold to caravan),
Bridge destruction (control 2, but destroyed under bridge),
fire destruction (control 2, but dropped into magma sea).

am i missing anything?

Of course, the number of items created will be in the course of three thousand (ill make them weigh 0 or something so i will be sure to fit them on the caravan). Idk if that is enough. thats 100 manager designations I'll need to do, but that can be done pre divergence. In fact, all the creation can be done pre-divergence. Unless i need to upgrade to 30,000 or something

I wonder If I can make a reaction that creats 30,000 identical mugs.. that would make this a lot simpler.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 18, 2012, 07:13:54 pm

SWEET JEBUS we need to have a better management system for trading.

I just set a macro for pushing 10,000 goblets to the trade depot, and it took A FULL HOUR TO COMPLETE. I can run a full year in the time it takes just to select the damn crap I'm trading. And that's just to push it onto the trade depot, I still have to give it all away.

I'm writing a new suggestion post/thread after this.

Only managed to get around 4600 mugs onto the Trade Depot before the traders left. That limitation on not sending objects to the trade depot until you are ready to trade continues to raise my ire.

Also, I managed to get my broker to legendary appraiser in one trade... heh.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 18, 2012, 07:16:11 pm

Quote from: Cellmonk on March 18, 2012, 06:47:41 pm

I wonder If I can make a reaction that creats 30,000 identical mugs.. that would make this a lot simpler.

They won't be identical in that they all roll for quality separately, and there's a sanity check on the number of items you can create, but I can create 10,000 mugs at once, but not 100,000 mugs.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Psieye on March 18, 2012, 10:14:42 pm

Kohaku, you may want to make a new thread with just the summary links to all the saves so everyone else can dive in and try them out for FPS measurements. Make it clear in the new thread's OP that commentary can go in this thread and that thread's purpose is to summarise and to record others' FPS readings.

Anyway, I've started up another fork save:

Fork save - Another (http://dffd.wimbli.com/file.php?id=5936)

Quote from: dffd description

This one was made with animal and plant testing in mind. Plump helmets give huge stacks and grow quickly. There are only 2 non-vermin animals: the catbird and the blue peahen. Both lay large clusters of eggs and the former has cat behaviour tags. As neither have the tags for beasts of burden, no caravans will arrive. This particular world was generated to have lots of badlands (no rain, no vegetation) but with 1 cavern layer (for the plump helmet experiment).

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

The intentions are:

1) See if an abundance of plants causes lag by virtue of the game having to check whether they're rotting or not (even if they are in a food stockpile)
2) Experiment on different ways of animal disposal and how they affect FPS

It's late where I am - I'm going to bed now but I've put up the save in case someone wants to get started in my stead. Incidentally, I have 19 adults and 1 child - I got a mood. Thankfully a stone-only mood.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 18, 2012, 11:08:22 pm

Quote from: Psieye on March 18, 2012, 10:14:42 pm

Kohaku, you may want to make a new thread with just the summary links to all the saves so everyone else can dive in and try them out for FPS measurements. Make it clear in the new thread's OP that commentary can go in this thread and that thread's purpose is to summarise and to record others' FPS readings.

I'll do something like that when I get more results that I think matter. Right now, I'm pretty much just marching down the line through things that produce the same result - that I'm not hitting the cause of fortress FPS decay yet.

Right now, all I can say is that simply consuming your items in reactions does not seem to cause lingering FPS decay, nor do creator/quality data, probably atom smashing does not, either, and I'm still working on some of the others.

Quote from: Psieye on March 18, 2012, 10:14:42 pm

Anyway, I've started up another fork save:

Fork save - Another (http://dffd.wimbli.com/file.php?id=5936)

Quote from: dffd description
This one was made with animal and plant testing in mind. Plump helmets give huge stacks and grow quickly. There are only 2 non-vermin animals: the catbird and the blue peahen. Both lay large clusters of eggs and the former has cat behaviour tags. As neither have the tags for beasts of burden, no caravans will arrive. This particular world was generated to have lots of badlands (no rain, no vegetation) but with 1 cavern layer (for the plump helmet experiment).

Spoiler: "Screenshots" (click to show/hide)
(http://i35.photobucket.com/albums/d159/Psieye/th_AnotherForkFarms.png) (http://s35.photobucket.com/albums/d159/Psieye/?action=view&current=AnotherForkFarms.png)(http://i35.photobucket.com/albums/d159/Psieye/th_AnotherForkPots.png) (http://s35.photobucket.com/albums/d159/Psieye/?action=view&current=AnotherForkPots.png)(http://i35.photobucket.com/albums/d159/Psieye/th_AnotherForkEggs.png) (http://s35.photobucket.com/albums/d159/Psieye/?action=view&current=AnotherForkEggs.png)

The intentions are:

1) See if an abundance of plants causes lag by virtue of the game having to check whether they're rotting or not (even if they are in a food stockpile)
2) Experiment on different ways of animal disposal and how they affect FPS

It's late where I am - I'm going to bed now but I've put up the save in case someone wants to get started in my stead. Incidentally, I have 19 adults and 1 child - I got a mood. Thankfully a stone-only mood.

I removed the child and baby tag so that all dwarves are born adults.

I would recommend you mod crops to have a much shorter growing season unless you want to test the lag effect of a growing plant. You can basically leave them as having a GROWDUR of 1, I believe, and that should vomit up plenty. CLUSTERSIZE might or might not help.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Psieye on March 18, 2012, 11:22:41 pm

I've set it to GROWDUR 3 and cluster size 50, with all dwarves having natural 20 in farming (as well as mining and masonry). Hmm yeah, I'll have to just force this child to grow up fast by editing the CHILD tag since I've already generated the world.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Psieye on March 19, 2012, 11:08:41 am

"UristMcNoEmotion cancels Plant Seed: Getting Married"

Apparently all the tags we added to the dwarves won't stop them from forging relationships. That they're speed:1 dwarves probably speeds this up considerably in my case.

Edit: Reminder to self - set artefacts to OFF...

Edit2: Confirming that clustersize doesn't help with farming - set it to 50 and it's the same 1~6 stacks as vanilla.

Edit3: RATS! EATING MY SHROOMS! I always had cats around in my normal forts so it's cool to see vermin actually attack food in stockpiles that aren't stored in barrels. I don't see any tatter marks though - maybe it's happening so fast (hundreds of FPS) that I don't see it.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 19, 2012, 12:39:27 pm

Well, I've done about all I have patience for doing with regards to these trade caravans, which is roughly 30,000 goblets traded away. Unit-1.txt is now up to 310 kbs. Memory consumption in the main game is at 383 megs, which is more than normal, but hardly any more than normal.

I'm going to call this as something that will slow the game down, but by a negligible amount, considering how the actual act of trading this damn many objects takes more time than just running an entire year.

... Actually, I can think of one more test to perform that wouldn't take too much more time...

I can just make an object worth some obscenely high value, and trade that away, and then see how much the FPS crashes when you get caravans.

Anyway, I have saves here:
Large Caravan Tests (http://dffd.wimbli.com/file.php?id=5942)

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 19, 2012, 01:19:20 pm

Odd result - when I traded 240,000,000 worth of goods to the caravan for a single steel bar, the result was that the trader said he was "Unwilling to trade" instead of the normal "ecstatic", and immediately left.

It's sort of like when you offend the elves, or something.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Kogut on March 19, 2012, 01:20:45 pm

Quote from: NW_Kohaku on March 19, 2012, 01:19:20 pm

Odd result - when I traded 240,000,000 worth of goods to the caravan for a single steel bar, the result was that the trader said he was "Unwilling to trade" instead of the normal "ecstatic", and immediately left.

It's sort of like when you offend the elves, or something.

Heh, integer overflow.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: dbay on March 19, 2012, 01:33:25 pm

I only read up to page seven, so forgive me if this has been mentioned before, but another popular method of garbage removal is throwing it into eerie glowing pits/chasms (which are now gone).

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 19, 2012, 02:15:49 pm

Quote from: Kogut on March 19, 2012, 01:20:45 pm

Quote from: NW_Kohaku on March 19, 2012, 01:19:20 pm
Odd result - when I traded 240,000,000 worth of goods to the caravan for a single steel bar, the result was that the trader said he was "Unwilling to trade" instead of the normal "ecstatic", and immediately left.

It's sort of like when you offend the elves, or something.
Heh, integer overflow.

Yeah, it's an integer overflow. It turns out Toady uses a "mere" integer, so the maximum value for trades is a "mere" 2,147,483,647. Because my extreme value goblets are 500,000,000 apiece, they cause integer overflows easily.

I apparently caused an integer overflow with 2,000,000,000 value trade deals, so apparently, it's calculating the whole caravan's value when doing this.

I'll try trading one masterwork and one exceptional, for a total of 1,700,000,000 and seeing if that doesn't cause an overflow...

EDIT: 1,000,000,000 was the limit I could trade to them without causing an overflow. I guess they were already carrying over 1,000,000,000 in trade goods already. I shouldn't have traded more than about 40,000,000 to them, already, so these caravans really balloon in size. (Of course, I have a massive TRADE_CAPACITY boost...)

Extreme value trade did not raise the save file significantly. Apparently, only the data on the goblets I trade away is saved. The caravan junk that isn't traded is simply deleted.

Memory use is also at 370 megs, which is actually less than last year, somehow...

Memory stays at 370 megs even with caravans on the map.

Even after trading them over a billion in value last time, they aren't arriving with more goods, and have 10 million in excess weight with which to bring those goods. I think I'm hitting some sort of caravan cap, which is at roughly 100 total goods (counting stacks as 1).

Integer Overflow Example Save (http://dffd.wimbli.com/file.php?id=5944)

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: kaijyuu on March 19, 2012, 04:42:59 pm

Quote from: dbay on March 19, 2012, 01:33:25 pm

I only read up to page seven, so forgive me if this has been mentioned before, but another popular method of garbage removal is throwing it into eerie glowing pits/chasms (which are now gone).

They still exist in hell, but that's sliiiightly more dangerous than tossing junk into magma flows.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Mego on March 19, 2012, 04:48:45 pm

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.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Psieye on March 19, 2012, 04:59:47 pm

Quote from: kaijyuu on March 19, 2012, 04:42:59 pm

Quote from: dbay on March 19, 2012, 01:33:25 pm
I only read up to page seven, so forgive me if this has been mentioned before, but another popular method of garbage removal is throwing it into eerie glowing pits/chasms (which are now gone).
They still exist in hell, but that's sliiiightly more dangerous than tossing junk into magma flows.

Set worldgen params to have nobody populate hell. Then it's safe (if you haven't modded in your own) - or so I hear, I haven't tried.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 19, 2012, 05:35:46 pm

Quote from: Mego on March 19, 2012, 04:48:45 pm

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.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Psieye on March 19, 2012, 06:35:12 pm

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.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: kaijyuu on March 19, 2012, 06:37:07 pm

Possibly of note to this discussion:

I turned off invasions in my latest fort because I was sick of dying to year 1 necromancer invasions. 9 years in and I've kept a good FPS far longer than usual. Hovering around 150 instead of dipping to 70 or so like normal. Still have boatloads of items, such as plants and metal ore/bars, but twice the normal framerate.

It may have something to do with units and items entering and/or leaving the map, period. Not just traders.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Psieye on March 19, 2012, 07:21:47 pm

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.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: orbcontrolled on March 19, 2012, 08:35:43 pm

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.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Mego on March 19, 2012, 09:01:24 pm

Quote from: NW_Kohaku on March 19, 2012, 05:35:46 pm

Quote from: Mego on March 19, 2012, 04:48:45 pm
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.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 20, 2012, 12:07:36 am

Quote from: Psieye on March 19, 2012, 06:35:12 pm

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.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 20, 2012, 12:11:57 am

Quote from: orbcontrolled on March 19, 2012, 08:35:43 pm

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.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Psieye on March 20, 2012, 05:48:05 pm

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 (http://www.bay12forums.com/smf/index.php?topic=104643.msg3106918#msg3106918).

=== The Saves ===
http://dffd.wimbli.com/file.php?id=5954 (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 (http://www.bay12forums.com/smf/index.php?topic=104643.msg3115576#msg3115576), now with item destruction to measure permanent FPS loss.
A study of cleanup during save/quit/reload (http://www.bay12forums.com/smf/index.php?topic=104643.msg3118504#msg3118504).

=== 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.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Shadowkx on March 20, 2012, 07:10:17 pm

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.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: mogthew on March 20, 2012, 09:09:41 pm

Quote

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.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: arphen on March 20, 2012, 09:26:28 pm

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

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 20, 2012, 09:36:08 pm

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.)

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: white_darkness on March 20, 2012, 09:45:04 pm

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

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 20, 2012, 09:46:09 pm

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.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Shadowkx on March 20, 2012, 10:07:37 pm

@ 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.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: rtg593 on March 20, 2012, 10:25:19 pm

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

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 20, 2012, 10:33:07 pm

Quote from: rtg593 on March 20, 2012, 10:25:19 pm

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.)

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Psieye on March 21, 2012, 10:38:37 am

Quote from: NW_Kohaku on March 20, 2012, 09:46:09 pm

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.

Agreed, but cross-checking results is the basic tenet of science and I never said this plant fort's experiment is over. In doing this my way, I've come across another potential lead - when people build with FPS-longevity in mind, they tightly control pathing and try to minimise items. But never have I heard anyone say they've minimised the number of stockpiles they have, or the number of workshops they have. I might decide to try out a new !!SCIENCE!! fort just to test out stockpiles and workshops, but first I'm going to try destroying these megashrooms in various ways, with and without DFhack.

So on that note, further test results:

=== Methodology ===

Install DFhack.

Take the 100k megashroom save and test various ways of destroying the shrooms and wine pots with DFhack. Also see effect of removing all the stockpile designations.

Then take the 30k megashroom save and compare manually atomsmashing all the megashrooms and wine pots to using DFhack to teleport the items into the atomsmasher.

=== Results ===

**100k save**

- Start: I decided not to wait for FPS to crawl ever so slowly up from 2 to 66 like last time. After confirming it was climbing back up, I went to the next step at 50 FPS.
memory = 55.6 MB

- After setting every megashroom for dump with no garbage zones: FPS bombed down to 2 again, but did recover all the way back to 66. Also, it is now summer not spring but this doesn't have any meaningful effect on this fort's FPS.
memory = 56.1 MB

- After also setting every wine pot for dump through the stock screen (didn't take as long to load this time, maybe because liquid stacks in pots are treated differently): FPS bombed down to 1 this time, but again crawls back up. Didn't wait until it fully recovered before proceeding to next step.
memory = 56.0 MB

> DFhack's "autodump destroy" command: FPS shoots up to 1300+ and then gradually decreases to 950 +/- 50, similar to (but faster than) how FPS slowly increased after bombing to 2 on load or mass designations before.
memory = 57.5 MB

> DFhack's "autodump" command to move everything to one location, then atomsmash: 1230 +/- 10 after the FPS settled down from the initial spike.
memory = 60.1 MB

> Remove all stockpiles, but don't destroy any items: FPS settled down and then plateaued up to 330 before the megashrooms wilted. After wilting, FPS was around 470 before they disappeared into nothingness. FPS then went to 740-ish.
memory = 57.6MB

** 30k save **

- After mass dump designations of megashrooms and all pots through stock menu: FPS = 389 +/- 2
memory = 47.7MB

> DFhack's "autodump" command, then atomsmash: FPS is settling down to 1040 +/- 10
memory = 48.3MB

> Manually dump and then atomsmash after all dumping: FPS is around 200 while the dwarves are doing the hauling. Most of the megashrooms are wilting and decaying away before the atomsmash lever is pulled, as I only want to pull this thing once instead of putting it on repeat. FPS after the lever got pulled = 1170 +/- 5
memory = 47.8MB

=== Conclusions ===

The FPS of the 100k save only rose up very, very slowly if nothing at all changed while waiting for measurements. Any change, e.g. an item set to dump or a stockpile made/removed, will ruin the 'status quo' and the FPS will bomb right back down to 2 while the game tries to find a new equilibrium.

Job queues likely only affect FPS when they're being changed. Needs a better experiment to investigate.

For FPS-longevity: manually dump & atomsmashing > autodump & atomsmashing > "autodump destroy"
However, autodump leaves more of a memory footprint than "autodump destroy".

Stockpiles take up FPS just by existing, whether they are filled or not and regardless of if there is no hauling job they generate. With lots and lots of stockpiles, this is a considerable FPS burden.

That's all I have time for today. Feel free to take my saves from the previous post and try atomsmashing as the dumping is going on.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 21, 2012, 01:30:32 pm

I was about to call the vaporization project to a close after only three years (because I can vaporize several million stones per year), but then I was checking results, and noticed a small increase in the amount of memory being consumed by the game, so I think I'll leave it running for another five or so years, and seeing if I can get something substantial enough to call a result.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: ratchet freak on March 21, 2012, 03:39:05 pm

are you also going to check owned items (claimed scattered clothes) or are you going to wait until .06 when we a speedup there

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 21, 2012, 04:00:58 pm

Quote from: ratchet freak on March 21, 2012, 03:39:05 pm

are you also going to check owned items (claimed scattered clothes) or are you going to wait until .06 when we a speedup there

Probably wait. There's no point in checking something being fixed right now for if it is broken.

I will try testing clothing in general, however. I don't think Toady is going to deal directly with that in his changes.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Frogwarrior on March 21, 2012, 04:53:55 pm

Do you have some sort of "summary" post in this thread, where you say in brief form the results of your experiments, i.e. "this definitely does cause FPS drop, this does not" sort of thing?

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 21, 2012, 07:20:19 pm

Quote from: Frogwarrior on March 21, 2012, 04:53:55 pm

Do you have some sort of "summary" post in this thread, where you say in brief form the results of your experiments, i.e. "this definitely does cause FPS drop, this does not" sort of thing?

No, although I will when I get more definitive results.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Draxxalon on March 21, 2012, 08:16:49 pm

In reference to memory usage post-smashing (via any method), you may want to also do a save + reload.

It's quite possible that the memory footprint doesnt decrease substantially while running, but on a reload, only allocates enough for the items that are presently in existance.

It's also quite possible that there are cleanup routines built into the save and/or load process, which could affect your results.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Elone on March 22, 2012, 05:20:48 am

Minecraft.

Do you remember those times when you could hit F3 to see mob IDs? It showed their internal ID numbers abovehead through walls and everywhere (and was removed cause it's too much a form of a wallhack).

I dont know whether these IDs were shared between all entities or just mobs in MC. I do know however that the game always spawns mobs (even if they are ineligible, then they get deleted on the next frame). The numbers often get into 6-7 digits as I keep playing. I'll take a guess that particles might be handled in the same unsorted ID manner.

I stand next to a sheep with a ~ 7 digit ID. I save and close the game (actually just unload the map and go to the main menu) and then I reload. The sheep in front of me now has a 1-2 digit ID number.

Indeed these unsorted list could be creating memory leaks, but once the game is saved and afterwards read from the save file, all the vars are just packed as they are read, they are not returned to their old addresses. The solution would be to restart the game every once in a while (both MC and DF) which resets the memory leak. Note that they could somewhat easily be resorted during gameplay, but that would cause periodic lag spikes which may be even more undesirable to the player than a memory leak that builds up over many hours before it's an issue.

What I would like to see are some results where you reload the game and see how the FPS was affected, for example "400fps before test, 200fps after the test, but 350 fps after reload" which would confirm that the drop is, actually, permanent.

What happens when you deleet stuff FROM certain dat files (like unit dats), leaving them blank?

EDIT: Scienced. First I tried deleting data from a single random (well biggest) unit dat file. The game ran without a crash. Then I deleted ALL the unit files from the folder, humming innocently all along, and surprisingly the game did not seem to mind! All the units and dorfs were just where they were before. What gives? I got a minor boost (from about 89fps to 93fps, from the same save point) but it might be worth looking into this. None of my forts has the clothing modded out so that's an undesirable factor right there. Thoughts?

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: RadHazard on March 22, 2012, 08:23:36 am

I'm not sure as I haven't really played with it, but I believe the unit.dat files only store non-local historical figures. If they're missing, when the game tries to load a historic figure (such as a migrant or trader) from one of the missing files it will give you the infamous "Nemesis Unit Load Error".

I have had one of those errors in 0.34.XX. I accidentally opened up a second Dwarf Fortress with the same executable in the same game. I believe the problem was that the second copy of DF cleared out the "current" folder, which stores any unit.dat files that have changed since you started that game. The game ran fine at first, but after I fast traveled to a town that I had visited previously, it crashed with that error. I'm assuming the same principle applies to fort mode.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Psieye on March 22, 2012, 08:31:45 am

Let's try the reload check with the quicker destruction methods on the 45k megashroom save:

- All megashrooms (but no wine pots) designated for dump but dwarves still walled in:
FPS = 215 +/- 5
memory = 48.9 MB

> "Autodump destroy"
FPS = 960 +/- 10 (takes a long time to stabilise after the spike up, this might not be the lowest it is)
memory = 49.6 MB

> "Autodump destroy" & save/reload
FPS = 760 +/- 10 (FPS slowly increases before plateauing off - this might not be the highest it can be)
memory = 47.9 MB

> "Autodump destroy", save, QUIT, load
FPS = 960 +/- 10
memory = 46.3 MB

> "Autodump" atomsmash
FPS = 980 +/- 10
memory = 50.6 MB

> "Autodump" atomsmash, save/reload
FPS = 770 +/- 10
memory = 49.3 MB

> "Autodump" atomsmash, save/QUIT/load
FPS = 970 +/- 10
memory = 45.7 MB

> Manual dump & atomsmash, save/QUIT/load
FPS = 960 +/- 10
memory = 46.0 MB (a whole year went by while getting this dumped so extra memory being used is not surprising)

Ok, so we can conclude that there is some sort of memory cleanup on a save/reload and especially on a save/QUIT/load cycle. In this test fort though, there was no FPS gain as a consequence (stockpiles were still around though). In fact, failing to quit before loading again led to an FPS decrease that was recovered by quitting. In much larger forts, I would think that a save/quit/load cycle will help recover some FPS.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Elone on March 22, 2012, 09:27:06 am

Thanks, Hazard! That makes sense. So there is no easy way to deal with people outside the map? What about items? Kohaku's post said that the stuff that caravans bring (but you dont buy) is deleted when the caravan clears the map, but that the items that you sell to them actually add to one of the files. Could those entries, wherever they were, be wiped without problems?

Thanks Psieye! Just what had me curious! This is a great insight into the powers of atomsmashing, autodumping, and also the arbitrarily expanding arrays! And you laid it out in a very readable manner. Atomsmash and destroy seem very comparable, meaning that both remove the items in the same way.

I'm kinda puzzled that you actually do not lose those ~200 fps of yours as long as you keep playing... If the arrays were growing as was suggested earlier, then you would be feeling a slowdown just from those fragmented arrays? Unless there's that bit where you do manage to delete everything in the array, after which the whole array goes.

Spoiler: memory from my experience (click to show/hide)

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 22, 2012, 11:57:45 am

Quote from: Elone on March 22, 2012, 09:27:06 am

Thanks, Hazard! That makes sense. So there is no easy way to deal with people outside the map? What about items? Kohaku's post said that the stuff that caravans bring (but you dont buy) is deleted when the caravan clears the map, but that the items that you sell to them actually add to one of the files. Could those entries, wherever they were, be wiped without problems?

The "cure" to the nemesis load fail problem was that you could take the data from an older save, and copy that over into your save folder, except for the "world.sav" stuff, which was your actual fortress. This also had the effect of any historical figures you had killed suddenly never-being-dead again. Global retcon of sorts.

If you wanted to reset your trading status, overwriting that unit-1.txt or whatever with data from old saves should also reset your caravan status without risking the game exploding.

That isn't to say I guarantee you won't run into problems at all - it might make the next caravan believe you never traded with the mountainhomes or something.

Quote from: Elone on March 22, 2012, 09:27:06 am

From my understanding, apps cannot easily clean up their memory. At the very best, they can mark certain RAM areas as overwritable (by removing/invalidating the old pointers), and they are filled with new data as it becomes needed. Take Firefox for example, at the very moment I have 24 tabs on top (which is tame, i went as high as 140 tabs and they used to reload for 45 minutes due to all the processing, swapping, and transfer). They are set to load when selected, but when I start the Firefox, only one tab will be autoloaded and the RAM usage will be minimal. As I select more tabs, the RAM usage grows. So when I get an arbitrary feeling that Firefox has taken up enough, and I finished browsing with some tabs, I close Firefox and let it reload from the minimum RAM and full performance, the only downside being the 10 seconds that it took to restart.

It seems Toady is more careful about memory management than many webpages. I don't believe this is strictly Firefox's fault, as I believe part of the problem is that many websites don't always play by firefox's rules, although I know that Chrome is supposed to specifically run each tab as a separate thread, so that closing a tab completely reclaims all memory attached to it. (I haven't used Chrome, however, so I'm not talking about this first-hand.)

There is an advantage in being a sole coder with the awareness that you are going to be creating and destroying a huge number of items from vectors in this regard. Thus far, the data structures have been surprisingly robust, and handled much of what I can throw at them, with a few very notable exceptions, although these are not strictly unexpected exceptions. (Although the "pressing t causes the game to chug for 20 minutes" thing was unexpected.)

I suspect that the real culprits in this FPS decay test will turn out to be some of the things we already suspected just being worse than we thought - dead creatures, decaying clothes, invasions, fluid flow, general item count, and pathfinding.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: arphen on March 22, 2012, 02:57:55 pm

i'm pretty sure it runs in different processes, not threads.
keep up the good work, but tell me... do i dfhack autodestroy or melt or ... your last data shows no difference between the methods , correct?

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 22, 2012, 03:09:19 pm

Quote from: arphen on March 22, 2012, 02:57:55 pm

i'm pretty sure it runs in different processes, not threads.
keep up the good work, but tell me... do i dfhack autodestroy or melt or ... your last data shows no difference between the methods , correct?

I haven't tested dfhack's tools yet, so I don't know there. It should probably be safe, though, given what I've heard from the developer of that tool.

Atomsmashing should definitely be safe, as should custom reactions that destroy objects with no products, and I'm still running tests on vaporizing, but they should be safe if you do that, but just melting (instead of vaporizing) leaves items in memory as a lump of melted goo.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Nil Eyeglazed on March 22, 2012, 03:20:40 pm

Quote from: NW_Kohaku on March 22, 2012, 03:09:19 pm

I haven't tested dfhack's tools yet, so I don't know there. It should probably be safe, though, given what I've heard from the developer of that tool.

I've had DF crashes with autodump-- suggests that there are things DF is doing with dumping/destroying items that aren't happening with autodump. Think I'd stay away from it for framerate testing purposes.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: GeorgiaPeanuts on March 22, 2012, 03:36:20 pm

I highly doubt the items would just be stored in some giant vector. Even at minimum something where specific item types store themselves as a separate vector.

I'd think something like a cached octtree would be ideal too having a dorf find a needed item nearest quickly as he could quickly eliminate whole regions of the map as not containing said item. So instead of having to iterate a whole list of an item to determine the nearest you just trawl through an octtree till you reach the closest leaf node.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 22, 2012, 04:28:17 pm

Quote from: GeorgiaPeanuts on March 22, 2012, 03:36:20 pm

I highly doubt the items would just be stored in some giant vector. Even at minimum something where specific item types store themselves as a separate vector.

I'd think something like a cached octtree would be ideal too having a dorf find a needed item nearest quickly as he could quickly eliminate whole regions of the map as not containing said item. So instead of having to iterate a whole list of an item to determine the nearest you just trawl through an octtree till you reach the closest leaf node.

The DF Hack guys have been pulling apart and labeling the code, though, and they did identify a global item vector. See: https://github.com/peterix/df-structures/blob/master/df.world.xml#L297

It seems as though there are several psuedo-redundant types of item vectors, however. So, there are things like a global vector for temperature purposes, but then another vector just for boulders, and other vectors for sectors of the game map for local area checks.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 22, 2012, 10:27:11 pm

I am concluding the vaporization tests.

My memory use actually went down. Saving then reloading, it went back up. There appears to have been no memory leakage at all. Vaporizing stone is perfectly safe for FPS, as tested with several million stone vaporizations.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Psieye on March 22, 2012, 11:27:39 pm

Quote from: arphen on March 22, 2012, 02:57:55 pm

i'm pretty sure it runs in different processes, not threads.
keep up the good work, but tell me... do i dfhack autodestroy or melt or ... your last data shows no difference between the methods , correct?

If you must use DFhack for quick item destruction, teleporting them into an atomsmasher with autodump is slightly better than "autodump destroy". Though you are recommended to save, quit and load.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: MarcAFK on March 23, 2012, 01:01:51 am

Posting to watch.
I've been meaning to run something like this myself, and i'm loving the informating gleaned from this so far.
However wasn't a bug recently fixed that caused fort FPS to slowly become unusable, what if all this testing is only going to show what temporarily screws up FPS, but it turns out the slow fpsdeath problem has actually been fixed?
That said any insight into what causes actual FPS loss temp or otherwise is significant and very useful.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Elone on March 23, 2012, 02:10:26 am

What if you set all those unit files to readonly? I'd science that but I dont know about all the specifics (i did not even know that it would give an error or that its okay to copy the old stuffs). Besides, my clothing is STILL not modded out, does anyone have a handy link on how to do that? I'd prefer it short and factual, because I've sought such guides before and I found them incomplete, as if you already have to know what you are doing to understand the guide, except there's no point then. So far I have removed clothing and subterranian clothing tags, and still embarked with clothes.

One more thing, one that no one seems to ever mention. If you embark with no clothing, doesnt that make your dorfs tremendously squishier? Like, even their constant pushing with animals could be harmful, as I've seen it mostly blocked by clothing otherwise?

Although, hopefully it becomes moot soon, if the clothing fix turns out to be what we expected. And I agree with the line that says that it will likely turn out to be something that we expected, like tons of items, or clothing.

Ah! How does one disable actual historical figures? Any easy way (like removing vampires) as opposed to genning a 2 year world?

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: schismatise on March 23, 2012, 03:16:29 am

Quote from: Elone on March 23, 2012, 02:10:26 am

Besides, my clothing is STILL not modded out, does anyone have a handy link on how to do that?

Simple, my friend!

I find the best way to do it is simply turn clothing into armor. This has the effect of stopping your dwarves from claiming or wearing clothing, unless it is specified via military uniform. This should only take you 1-2 minutes.

Find the 5 raw files (.txt files) that pertain to the 5 main types of body protection - in raw/objects, these are:

item_armor.txt
item_gloves.txt
item_helm.txt
item_pants.txt
item_shoes.txt

In each of these files, add [ARMORLEVEL:1] to each item that doesn't already have an [ARMORLEVEL:x] tag.

Example:

Spoiler (click to show/hide)

Simple as that.

Edit: The best part of this, of course, is the ~10-20% FPS gain you get due to the clothing wear bug (http://www.bay12games.com/dwarves/mantisbt/view.php?id=3942). Of course, it's all fixed in the coming patch, anyway.

Quote from: Elone on March 23, 2012, 02:10:26 am

One more thing, one that no one seems to ever mention. If you embark with no clothing, doesnt that make your dorfs tremendously squishier? Like, even their constant pushing with animals could be harmful, as I've seen it mostly blocked by clothing otherwise?

Cloth provides very little protection. I've been running military forts without clothing for a while now and haven't noticed any difference at all.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: kaijyuu on March 23, 2012, 03:55:17 am

The attacked that glance off clothes will do pitiful damage to an unclothed dwarf. Some dents and bruises, maybe.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Elone on March 23, 2012, 05:19:58 am

Yaaay! That's precisely what I wished to have! After seeing such a super simple little guide, I start wondering why all the others had to take up a screen or more =O !

Now, if I get the unit files and set them to readonly, and it DOESNT mess my game up, that's two fps decay issues gone already. lthough for obvious reasons I am not quite keen on staring a new fort now. Soon enough, all of this might change.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 23, 2012, 10:38:10 am

Minor damage is still something that causes pain, however.

An elephant can be knocked unconscious and killed by three hoary marmots (http://www.bay12games.com/dwarves/mantisbt/view.php?id=4590), just because the game has no way of differentiating the amount of pain generated by having a giant slash across your whole arm, or a tiny nibble mark from something weighing in at 0.002% of your body mass.

It's like being killed by fly bites.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Elone on March 23, 2012, 11:44:53 am

Yeah, I remember a thread where someone discovered that a bunch of bunnies can knock out anything that feels pain by gnawing. Then someone thought it not damaging enough, and put bunnies on fire to gain the extra efficiency from it.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on March 25, 2012, 09:19:12 pm

OK, so I did some more liquid rock tests, and they don't get cleaned up at the end of the year - don't melt things, kids, they never go away!

I took too long of a break on this testing stuff, can't remember what else I was going to test.

I know I wanted to test engravings, and then test socks, maybe engraved socks.

After that, it would be large-scale crittercides.

Can't remember what else I needed to test.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: MarcAFK on March 25, 2012, 10:12:10 pm

I would like to test constructions, i have a suspicion that somewhere in the game might still count them as objects that need to be checked frequently enough to cause lag. I'm thinking of a way of testing this with minimum of variables. Perhaps Modding a game to remove caverns, clothes, invaders, traders all the uncontrollable stuff etc. Then simply dig out whole levels and replace them with solid blocks of stone. I would compare framerate/ram usage before the digging, after digging (atomsmash all stones to get a clear reading on the difference from having all that mined space), then using a custom reaction i would create enough stone to block off all the mined space checking the fps/ram at this point also, then finally build it all and check FPS/ram once more too.
Also going by what's been discovered earlier i'll need to conduct before/after save/quit/reload Fps/ram checks just to be thorough.
This should show if theres some difference since even a 2x2 embark would have 2209 tiles to build.
For better results i might continue the test over 5 levels.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: expwnent on April 02, 2012, 10:56:34 am

A few thoughts, assuming you're right:

1. Even if you have a huge array like that, it's completely possible to minimize this effect: just use a skip list (google will probably have better descriptions than I can quickly give). This would make the effects of "holes" in the array minimal. If Toady does this, it would be difficult to measure the effects because they'd be so small. He could also "defragment" the array any time he needs to iterate through the whole thing, but that might mess things up if other things have indexes into the array instead of pointers to the actual objects the array points to.

2. Even if he doesn't do this, it could be that the end of the array gets trimmed properly when things are deleted from it. It looked like in a lot of your tests, you just mass-produced one thing then deleted that one thing in various ways. A better way might be to mass produce two things, then delete one of them, and compare against mass-producing just one thing.

3. It could also be a giant hash table that he never decreases in size, so searching for things that aren't there would take longer and longer (slightly) as the size increases.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Kogut on April 02, 2012, 11:16:34 am

Or there is a garbage collector effect on saving/loading (confirmed in my test) - probably degenerated vector/sth else is saved and on loading all gaps are removed. And I must say that my new fort is progressing nicely as I keep total item count below 10k.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: GhostDwemer on April 02, 2012, 01:18:10 pm

Very interesting thread, and good science all around but it seems to me that no one has ever really verified the underlying hypothesis. Find a fort that is suffering from FPS problems and put it entirely back to starting conditions. Kill off excess dwarfs and animals, destroy excess items, block off every single path, then use dfhack's revflood to rehide the map.

Has anyone ever done that? If so, what happened?

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: runlvlzero on April 18, 2012, 07:30:34 am

Reclaims don't suffer terribly, at least not for awhile, loading the reclaim may take long. But look at a fort like sword thunders, many people had quite playable FPS after reclaiming.

But its not the same as killing an active fort entirely with magma while saving a few dwarves to continue and test the cleaned fort, or save without relclaiming.

It would be a megaproject to design that experiment alone. Just a fort that's designed to ~~die~~ be renewed in 5 yrs time in game.

Not something I'm volunteering for...

But I recommend one big flat level fort thats easy to fill with magma, and obsidianize. Two Z levels tops. (not that the idea behind that is different then vaporizing or smashing stone)

Also some objects will survive, so the fort would need t be zero constructions and in some kind of melt able stone layer? no metals...

But what are the results have we established some curve graph with an outward life expectancy of a fort... like 25 yrs in game, without reclaiming? Does artificially removing items decrease that to say 10 years?

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on April 18, 2012, 01:56:14 pm

Yeah, sorry for not updating this, I've been otherwise diverted...

I'll get around to the sock test sometime, I swear.

Anyway, I haven't found a definite source of permanent FPS decay in the system yet. Granted, none of my experiments have gone beyond 10 years, but in those 10 years, I have had no notable gradual creep in memory consumption or decay in FPS.

This IS, however, with several controls -

First, nothing is dying except for a few rattlesnakes that get killed by the caravan guards a few years into the game. We have not yet set up the puppy-smasher fortress that will test the effects of large-scale death on FPS.

Second, there has yet to be a large-scale clothing rot test.

Third, the fortress is not expanding in any way, and as such, no new dwarves are pathfinding, no new items are being (permanently) added, and there isn't more and more open space to pathfind over.

In order for a full and complete test, all other factors have to be gradually eliminated as we move in on the true source of gradual FPS decay, however, all current signs point to the notion that, basically, it's something done by the player that is causing all this permanent FPS loss.

If you were to very meticulously prevent any clothing rot or excavation or construction or warfare, you could run a fortress hypothetically forever...

... Of course, why would you WANT to run a fortress where you didn't build anything or kill anything, but that's a different story.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: runlvlzero on April 18, 2012, 02:18:20 pm

Quote from: NW_Kohaku on April 18, 2012, 01:56:14 pm

Yeah, sorry for not updating this, I've been otherwise diverted...

I'll get around to the sock test sometime, I swear.

... Of course, why would you WANT to run a fortress where you didn't build anything or kill anything, but that's a different story.

Thanks for the update, I figured possibly as much since the OP was not edited with a summary. And of course even if we knew exactly what slowed forts down, we'd probably still do it cause it was fun =)

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on April 18, 2012, 02:25:11 pm

Quote from: runlvlzero on April 18, 2012, 02:18:20 pm

Thanks for the update, I figured possibly as much since the OP was not edited with a summary. And of course even if we knew exactly what slowed forts down, we'd probably still do it cause it was fun =)

I can say this: Open space kills your FPS. Pathfinding becomes geometrically less efficient (As in twice as much open space = four times longer to path) the more space there is in a fortress, so cram as much together as possible, and avoid those large rectangular open rooms. Sprawl vertically, not horizontally when possible.

Also, eliminate anything that you don't need from the game. Magma-dump old socks, stones you aren't going to use, extra trade crap you can't sell, etc. If your stockpiles overflow, don't dig out more stockpiles, dump and atomsmash your excess.

You can "undig" some parts of your fortress using DFHack. I haven't done it, but I'm told that if you seal off and unreveal parts of your fortress, you can get some FPS back from the game.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: expwnent on April 18, 2012, 06:10:24 pm

Pathable open space or any open space? Does above ground air count?

I'm planning a megaproject and I'd like to not die of FPS boredom.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: RadHazard on April 18, 2012, 10:40:21 pm

How much do well-placed traffic designations help alleviate the open space issue? That could be another thing to test when you get around to the open-space testing.

It would be interesting to see if designating traffic zones like below would improve FPS noticeably, with larger rooms, of course.

Code: [Select]

F = Forbidden
H = High Traffic
╔══┼══╗
║FFHFF║
║FFHFF║
┼HHHHH┼
║FFHFF║
║FFHFF║
╚══┼══╝

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on April 18, 2012, 10:54:42 pm

Quote from: blue sam3 on March 15, 2012, 04:04:19 pm

Right, I've done some testing on open space. All testing was done with modded (nosleep/drink/eat, speed 0) dwarves digging out areas of white sand, in full screen, with as little as possible running in the background.

Spoiler: Kohaku spoiled to get to the good bits (click to show/hide)
Results:

initial FPS: 2000
FPS whilst digging out a small area (600 ish tiles): 50
FPS after digging out said small area: 1500
FPS whilst digging out a larger area (maybe 1500 tiles or so): 5
FPS after digging out said larger area: 1500
NOTE: at this point, several things happened:
1) First hardcoded migrant wave arrived and a ghost appeared
2) I finally remembered to turn weather etc. off
FPS after above changes: 2600
FPS whilst digging out another small area: 3
FPS after digging out said small area: 2300 (NOTE: unreliable, as I was only able to observe for a short time due to another migrant wave and a caravan arriving. After the caravan left, FPS was down at 2100)
FPS whilst digging out 7 tiles: 5
FPS whilst digging out another small area: 20
FPS after digging out said small area: 2100
FPS with an entire inaccessible z level designated: 1950
FPS after undesignating said inaccessible z level: 2050
NOTE: At this point, two migrant waves arrived, half the fortress got married, a child was born the elven caravan arrived and two ghosts appeared.
FPS after above note: 1000
NOTE: the above changed by +/- 100 points with seasonal variations, away from autosaves
FPS whilst digging out another large area: 2
FPS after digging out said large area: 900
FPS after digging out another small area and a really annoying migrant wave: 730
FPS after digging out another small area, a really annoying dwarven caravan (still present) and three really annoying births: 600
FPS after caravan left and digging out another small area: 600
FPS after digging out another small area: 600

At this point, I decided to test whether open space and floored space had the same effects, so I started channelling out all of the areas I'd previously dug out.

FPS after collapsing first area (two deaths, one birth, one lightly mangled baby, two lightly injured miners): 420
FPS after collapsing second area (one light injury, one birth): 380
FPS after collapsing ridiculously massvie area: 300
FPS after digging out another small area: 280
FPS after channelling that area out the slow way:230

Conclusions:
Empty space slows stuff up.
The accessibility of space has no noticeable effect.
Channelled out space is actually worse than floored over space.
Designating things does slow stuff down, but nothing like as much as actually having them accessible.
Weather etc. has a significant impact on FPS.
There are significant seasonal variations in FPS.
Caravans still slow things up after leaving the map.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Khym Chanur on April 19, 2012, 02:08:40 am

Quote from: NW_Kohaku on April 18, 2012, 02:25:11 pm

You can "undig" some parts of your fortress using DFHack. I haven't done it, but I'm told that if you seal off and unreveal parts of your fortress, you can get some FPS back from the game.

So revealing (and exploring) the caverns will cause a permanent FPS drop?

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on April 19, 2012, 10:31:32 am

It's not the revealing, it's the connection. The larger the open space, the more it hurts FPS. Caverns have large amounts of open space, and they hurt your FPS even before you reveal them. What happens when you completely seal off a region, though, is that you can semi-permanently prevent them from interfering with pathfinding.

The open sky is bad for FPS, as well. Making less sky above ground level in worldgen makes the game run faster.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: GavJ on April 21, 2012, 03:25:22 pm

Quote from: NW_Kohaku on April 18, 2012, 01:56:14 pm

... Of course, why would you WANT to run a fortress where you didn't build anything or kill anything, but that's a different story.

Well, of course you wouldnt want to play a fort doing NONE of those things. But it may well turn out that only ONE thing in particular seems to murder FPS in more normal gameplay. For instance, it's always pretty much the kill list, or something.

If that's the case, then it would still be very useful to know, because we could play very fun fortresses for a long time, doing all the fun stuff, but simply avoiding too much of that one fun thing. Not to mention the likelihood of toady fixing it being higher if it can be pinpointed (i.e. the whole point of the thread).

Posting to make the above inane comments and to follow.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: GavJ on April 23, 2012, 12:23:30 am

I have the pleasure to announce the results of my mass bunny smashing experiment.

Start of the fortress = 1700 FPS
2 waves of migrants + wild animals roaming + a couple caravans come and gone + about 30 baby bunnies = 950 FPS
Same as above + 22,500 bunnies = 0.2 FPS
Same as above minus 22,500 bunnies smashed = 150FPS
Same as above + all the rest of the bunnies + all but 7 dwarves smashed = 225 FPS

Time it takes to save the game now = about 1 minutes (interestingly it stalls on "cleaning game objects").

So 22,500 corpses listed in the missing page seems to reduce my FPS by a factor of 4. Not really as bad as expected.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: runlvlzero on April 23, 2012, 12:50:18 am

Quote from: GavJ on April 23, 2012, 12:23:30 am

I have the pleasure to announce the results of my mass bunny smashing experiment.

Start of the fortress = 1700 FPS
2 waves of migrants + wild animals roaming + a couple caravans come and gone + about 30 baby bunnies = 950 FPS
Same as above + 22,500 bunnies = 0.2 FPS
Same as above minus 22,500 bunnies smashed = 150FPS
Same as above + all the rest of the bunnies + all but 7 dwarves smashed = 225 FPS

Time it takes to save the game now = about 1 minutes (interestingly it stalls on "cleaning game objects").

So 22,500 corpses listed in the missing page seems to reduce my FPS by a factor of 4. Not really as bad as expected.

Haha, thanks for the test run, that gives a little perspective. The way I play I would imagine reaching 22,500 missing and dead might take a few minutes :P

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: MarcAFK on April 23, 2012, 01:05:20 am

Is that final result after saving Quitting, and reloading?

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: GavJ on April 23, 2012, 01:59:13 am

Quote from: MarcAFK on April 23, 2012, 01:05:20 am

Is that final result after saving Quitting, and reloading?

yup

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Daenyth on April 24, 2012, 01:46:17 am

Posting to watch. This thread is fascinating.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Kogut on April 24, 2012, 05:34:29 am

Quote from: GavJ on April 23, 2012, 01:59:13 am

Quote from: MarcAFK on April 23, 2012, 01:05:20 am
Is that final result after saving Quitting, and reloading?
yup

Hm, this should NOT happen. How you created bunnies? Is it still happening after butchering bunnies and smashing products?

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: MarcAFK on April 24, 2012, 05:57:18 am

It's not too bad, but then again i've never had 25000 corpses. :'(

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: MuseOD on April 24, 2012, 11:47:59 am

average FPS of 80, woot, woot. My computer fucking sucks, that's why.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: blue sam3 on April 24, 2012, 12:07:31 pm

Quote from: MuseOD on April 24, 2012, 11:47:59 am

average FPS of 80, woot, woot. My computer fucking sucks, that's why.

The FPSs quoted here are largely from modded and specifically generated fortresses designed for testing things. As such, they largely have no wild animals, very few dwarves (unless that's what they're testing), no caverns, small areas, low heights, no moving water, and basically everything else possible to minimise extraneous FPS hits that aren't being tested. As such, the starting FPSs can be ridiculous. Mine, for example, was about 5,000, but my normal FPS struggles to get above 50.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: GavJ on April 24, 2012, 12:37:46 pm

Quote from: Kogut on April 24, 2012, 05:34:29 am

Quote from: GavJ on April 23, 2012, 01:59:13 am
Quote from: MarcAFK on April 23, 2012, 01:05:20 am
Is that final result after saving Quitting, and reloading?
yup
Hm, this should NOT happen. How you created bunnies? Is it still happening after butchering bunnies and smashing products?

Bunnies were created by modding the bunnies' litter size to several thousand (and turning off their eating, etc. so theyd stay in the smasher with no grass). Then I just smashed the bunnies, no butchering. The hypothesis was that the game having to keep track of the entire list of all 22,500 individual corpses in the {u} -> {dead/deceased} menu will slow down FPS.

quitting and reloading does not change what is listed in the dead/deceased list, so if that hypothesis is right, you should not expect to alleviate any of the lag by quitting and restarting. Killing stuff adds permanent and unique entries into that list, and therefore will inevitably wear away at your fps over time.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: NW_Kohaku on April 24, 2012, 10:11:49 pm

GavJ is correct - this is one of the evils of stl vectors. It's also why the game gets so slow in general when you have any sort of item list tens of thousands of items long (which is entirely possible in a normal game). In order to find anything on the list, it has to iterate through numerous pointers to find the portion of the vector that contains the specified creature - and likely enough, there may just be an iterator going through every creature in the creature vector every frame, and having to check the status of every creature to see what it's doing, and then seeing a "still dead" status before moving on to check the next one.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: GenJeFT on April 24, 2012, 10:50:07 pm

Quote from: GalenEvil on March 15, 2012, 03:28:40 am

My Theorems:
* Creation and subsequent destruction of variable numbers of non-like-typed items may create FPS loss (IE. create 10 bins, create 9 mugs, destroy 3 bins, create 10 bins, destroy 3 mugs, create 9 mugs, destroy 15 bins, destroy 10 mugs, create....etc) such that entire sets of item-creation jobs are not being immediately destroyed, and could possibly create empty vector indices within the lists as it is not guaranteed that an entire stack of a created good are destroyed entirely, which could, and logically would, free up the memory location if done haphazardly.
* Corollary to the above: or at least a simplification of it. Each job set of a specific non-unique item could be creating a list set in the item vector list. If the above holds true then destroying only part of the list would not necessarily free up the memory associated with said list set to allow that set to be used for something else. Iff, (if and only if) the entirety of the item-set is destroyed the memory is freed.

I think this is the problem. To show what I am talking about I am going to mention my first "successfull" adventure carecter.

The water flask (or waterskin or whatever) you get when you start an adventure guy holds three water. Normaly when you go to drink it says waterskin (3) or whatever saying how much water you have. One day I drank two of the three water and refilled the waterskin when I noticed something like this (note, none of this is exact, its midnight and I am not loading the game right now to worry about it).

waterskin (2)
water

Which means this. When I first filled the waterskin it created a stack of three water. I drank two of the three water. So the item list went like this.

water (3)

to

water

When I refilled the waterskin instead of combining the stack of two water with the water already there it instead created this setup.

water (2)
water

Therefore creating TWO enteries in the item list because the system does not combine like items in inventories like it should. Logicaly it should have combined them into water (3). BUT the game does not do that and instead kept the old entry of water and just added a new entry of water (2).

These errors can easily add up over time and decrease FPS while increasing file save size. Will do more !SCIENCE! tomarrow to see if this continues.

*edit*

Confirmed. Instead of combining like entries the system creates a new entry. Tested several different ways in adventure mode.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Kogut on June 06, 2012, 04:15:00 am

There is an evidence that job-seeking iterates over all units, including dead ones ( http://www.bay12games.com/dwarves/mantisbt/view.php?id=5986#c22859 )

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: luppolo on June 06, 2012, 05:28:37 am

Quote from: Kogut on June 06, 2012, 04:15:00 am

There is an evidence that job-seeking iterates over all units, including dead ones ( http://www.bay12games.com/dwarves/mantisbt/view.php?id=5986#c22859 )

somehow, useless migrants causing trouble even after 50 levels drop or magma bath doesn't surprise me at all

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: MarcAFK on June 06, 2012, 07:26:25 am

Well you never know when friendly zombie soapmakers may come in handy after a future update.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Kogut on June 06, 2012, 09:18:31 am

Quote from: MarcAFK on June 06, 2012, 07:26:25 am

Well you never know when friendly zombie soapmakers may come in handy after a future update.

Or friendly converted zombie troll administrators.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: FearfulJesuit on June 06, 2012, 11:38:36 am

I think we're going to need to do more science on what FPS killers kill FPS linearly and which ones kill it geometrically. Even if 25,000 corpses cut your FPS from its highest possible level by a factor of 4, you don't really know what's going on until you check 50,000 corpses and see if it cuts it by a factor of 8 or a factor of 16.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Bulwersator on June 07, 2012, 03:42:18 am

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Kofthefens on June 07, 2012, 11:22:03 am

Why the new account?

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Kogut on June 07, 2012, 01:19:36 pm

Quote from: Kofthefens on June 07, 2012, 11:22:03 am

Why the new account?

To reset list of watched threads ( http://www.bay12forums.com/smf/index.php?action=unreadreplies )

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Xen0n on June 07, 2012, 01:23:29 pm

Quote from: Kogut on June 07, 2012, 01:19:36 pm

Quote from: Kofthefens on June 07, 2012, 11:22:03 am
Why the new account?

To reset list of watched threads ( http://www.bay12forums.com/smf/index.php?action=unreadreplies )

Ha! I was actually just asking myself how I coul go about doing that last week, and I guess you've given me an answer! Thanks!

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: ghostwoods on June 26, 2012, 02:08:50 pm

I've been worried by the reports that open space causes FPS loss, even when it's not being pathed through. If it's inevitable, it's inevitable, but I wanted to see if pattern played a part.

HYPOTHESIS: There may be a different in FPS impact of open space, depending on layout.

METHODOLOGY: Set up a fort with food-, sleep- and booze-proof Dwarf miners in a flat place with a low cloud ceiling and no enemy civs. Wall them in and prepare a suite of craftshops on the first stone layer. Fork this fort. In one fork, dig out a 50x50 square of tiles. In the other fork, dig out a 2500-long snaking passageway. Collect all stone in a quantum pile, in the same spot near the craftshops. Set the craftshops running on the same task, and compare FPS. Once out of stone, wall off the 2500-tile gap, wait until the first caravan has come and gone, and compare FPS whilst everyone idles at a surface-side statue.

NOTES: Used autodump to collect the stone in a pile, then reclaimed it and slapped a 1-square stockpile over it. After the crafting, dug out a bit more stone around the craftshops until there was enough there to wall off the stairs. (Totally forgot I'd brought some wood for that purpose). The two migrant waves weren't quite the same size -- 11 adults and 1 child in the square fork; 6 adults, 2 horses, 2 cats and a child in the snake fork.

RESULTS

All results are +/- 15ish FPS. Fort was saved and DF fully quitted between each of the measurements

Code: [Select]

                                               SQUARE             SNAKE

DURING CRAFTING                                390                470 
IDLING BEFORE CARAVAN                          370                445
DURING CARAVAN                                 335                410
AFTER CARAVAN                                  350                425

CONCLUSION

Holy hell. The Snake layout is a consistent 20% faster than the Square layout right across the board. And that's off just 2500 squares. I've used twice that just mining marble to trade on one layer of my current fort.

I suggest a new strategy, Artoo. TUNNEL EVERYTHING!

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Xenos on June 26, 2012, 07:33:00 pm

I will try some testing once my new computer parts arrive and I build my new baby. Since I am busting out an AMD 3100 MHz octocore processor I can run multiple tests concurrently and boost efficiency! :D (I only bought 8GB RAM since I wanted to save a little money but I can easily buy another stick soon to run more than 2-3 tests at once.)

Let me know what you want me to test more specifically.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Xen0n on June 26, 2012, 07:46:42 pm

Quote from: ghostwoods on June 26, 2012, 02:08:50 pm

I've been worried by the reports that open space causes FPS loss, even when it's not being pathed through. If it's inevitable, it's inevitable, but I wanted to see if pattern played a part.

HYPOTHESIS: There may be a different in FPS impact of open space, depending on layout.

METHODOLOGY: Set up a fort with food-, sleep- and booze-proof Dwarf miners in a flat place with a low cloud ceiling and no enemy civs. Wall them in and prepare a suite of craftshops on the first stone layer. Fork this fort. In one fork, dig out a 50x50 square of tiles. In the other fork, dig out a 2500-long snaking passageway. Collect all stone in a quantum pile, in the same spot near the craftshops. Set the craftshops running on the same task, and compare FPS. Once out of stone, wall off the 2500-tile gap, wait until the first caravan has come and gone, and compare FPS whilst everyone idles at a surface-side statue.

NOTES: Used autodump to collect the stone in a pile, then reclaimed it and slapped a 1-square stockpile over it. After the crafting, dug out a bit more stone around the craftshops until there was enough there to wall off the stairs. (Totally forgot I'd brought some wood for that purpose). The two migrant waves weren't quite the same size -- 11 adults and 1 child in the square fork; 6 adults, 2 horses, 2 cats and a child in the snake fork.

RESULTS

All results are +/- 15ish FPS. Fort was saved and DF fully quitted between each of the measurements
Code: [Select]
SQUARE SNAKE DURING CRAFTING 390 470 IDLING BEFORE CARAVAN 370 445 DURING CARAVAN 335 410 AFTER CARAVAN 350 425
CONCLUSION

Holy hell. The Snake layout is a consistent 20% faster than the Square layout right across the board. And that's off just 2500 squares. I've used twice that just mining marble to trade on one layer of my current fort.

I suggest a new strategy, Artoo. TUNNEL EVERYTHING!

Spoiler: Oh wow! That's some impressive SCIENCE, and potentially gamechanging, design-wise. (click to show/hide)

So I'm understanding correctly, in both cases the 2500 tiles of empty space were totally walled off and inaccessible, the only difference was the shape? The snaking passageway was one single curving hallway, or a branching maze? And both of these were on a single z-level?

Makes me curious what the difference between a 50 x 50 x 50 cube of open air vs. 125000 tiles of passages (one 1 or across several z-levels),

Spoiler: but I do not have the chops to set something like that up :P (click to show/hide)

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Bulwersator on June 27, 2012, 12:59:15 am

I think that this may be explained by different migrant waves. To eliminate this problem in my test I walled entire map using drawbridges or waited for hardcoded waves and then lowered migrant/child cap to 0.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: ghostwoods on June 27, 2012, 07:43:30 am

Xen0n: Thanks :) Both spaces were on a single z-layer, and the strip was just one long twisty passage, not a maze.

You could do a 2744-cubed open space by channeling a 14x14 block down 14 levels, but in order to avoid !!FUN!! you'd probably need to assign it as one strip of 14 squares at a time. You _really_ wouldn't want to have to do that 50x50x50! A similar space in one strip could be done with staircases in a 27x27x14 block (you don't need to leave a blank layer between z-levels, as mining leaves a floor).

Bulwersator: It's possible, but the first figures recorded are from the six weeks before any migrants arrived, and they show almost exactly the same discrepancy.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Urist Da Vinci on June 27, 2012, 08:57:45 am

Quote from: ghostwoods on June 26, 2012, 02:08:50 pm

I've been worried by the reports that open space causes FPS loss, even when it's not being pathed through. If it's inevitable, it's inevitable, but I wanted to see if pattern played a part.

HYPOTHESIS: There may be a different in FPS impact of open space, depending on layout.

...

CONCLUSION

Holy hell. The Snake layout is a consistent 20% faster than the Square layout right across the board. And that's off just 2500 squares. I've used twice that just mining marble to trade on one layer of my current fort.

I suggest a new strategy, Artoo. TUNNEL EVERYTHING!

I'd like to verify that the FPS loss isn't because the space IS being pathed through. I'd suggest repeating the 50x50 open space test when the map is painted with a large high traffic zone. I get the feeling that the results will be equal to the tunnel method.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: expwnent on June 27, 2012, 08:58:37 am

Better yet, put it past a forbidden door.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Xen0n on June 27, 2012, 10:38:35 am

Quote from: Urist Da Vinci on June 27, 2012, 08:57:45 am

Quote from: ghostwoods on June 26, 2012, 02:08:50 pm
I've been worried by the reports that open space causes FPS loss, even when it's not being pathed through. If it's inevitable, it's inevitable, but I wanted to see if pattern played a part.

HYPOTHESIS: There may be a different in FPS impact of open space, depending on layout.

...

CONCLUSION

Holy hell. The Snake layout is a consistent 20% faster than the Square layout right across the board. And that's off just 2500 squares. I've used twice that just mining marble to trade on one layer of my current fort.

I suggest a new strategy, Artoo. TUNNEL EVERYTHING!

I'd like to verify that the FPS loss isn't because the space IS being pathed through. I'd suggest repeating the 50x50 open space test when the map is painted with a large high traffic zone. I get the feeling that the results will be equal to the tunnel method.

I was actually about to suggest the same thing, or editing the 'Normal' traffic values to =1. I'm also curious about a control fort, with no spaces mined out, but maybe an equivalent amount of stone hacked in to keep the # of items + crafting consistent, just to see how big of a hit mining out a space like this is compared to not mining at all.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: ghostwoods on June 27, 2012, 04:43:25 pm

Wouldn't it be a bug if pathing was being calculated through solid stone walls? The 2500-square empty spaces were completely walled off after the initial construction phase, in both cases. Xen0n, I'm not that much of a hacker. I'll be interested to hear what you find out.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Xen0n on June 27, 2012, 04:58:02 pm

Quote from: ghostwoods on June 27, 2012, 04:43:25 pm

Wouldn't it be a bug if pathing was being calculated through solid stone walls? The 2500-square empty spaces were completely walled off after the initial construction phase, in both cases. Xen0n, I'm not that much of a hacker. I'll be interested to hear what you find out.

Haha, I was hoping somebody would know if doing something like was even possible. As much as I'd like to try something like this out, I spend so much time doing science IRL that I barely have time to log a couple hours into DF per week :P

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: WJLIII3 on June 27, 2012, 06:41:45 pm

Quote from: NW_Kohaku on March 15, 2012, 04:02:10 pm

I am suspending my atom-smashing test for now to check on the contraction theory, instead.

I am going to try to have a million stones on my map at a single point in time before eliminating them all.

I am apparently up to roughly 100,000 stones on the map at once, but it appears as though the sheer numbers have completely overwhelmed my bookkeeper, or else that bug is back, because I'm down to lowest possible precision again.

FPS has plummeted way down to 30 from "merely" having 100,000 stones on the map.

No bug, I shouldn't think. You create and destroy 240 units of stone every tick. The bookkeeper is trying to keep track of them, which is completely impossible.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Xob Ludosmbax on June 27, 2012, 08:03:58 pm

Testing effects of open space on FPS using dfhack.

The goal is to increase understand of long term FPS loss with the hope of discovering how to decrease or eliminate it.

Summary of Conclusions:

Pathfinding is a lot more significant than open space with regards to FPS. Clearing a large section of the map only has about a 12% effect on FPS in and of itself. Pathfinding through that space while unable to reach the destination had about 5 times more effect on FPS. I didn't count the number of flying clowns. Visible but non-open tiles do not seem to have a significant effect.

Also, we could probably get better results by timing how long it takes to finish the season rather than a subjective evaluation of the FPS meter, then timing the second season, as paths and such would be cached by then.

Further research questions:

Spoiler (click to show/hide)

Baseline parameters:

Spoiler (click to show/hide)

Test 0: Save with no changes
FPS seems stableish at 400.

Test 1: 129 z-levels of open air (with clown introduced measurement error)

Spoiler (click to show/hide)

FPS seems to be at a stable 200, sometimes dropping to 160-180, went all the way up to 250.

Test 2: 3 z-levels of open air (with clown introduced measurement error)

Spoiler (click to show/hide)

FPS eventually stabilised in the 300-320 range, with spikes to 360.

Conclusions for tests 1 & 2:
We can conclude that ~1M tiles of inaccessible empty space drops FPS by ~68%, or put differently, every 15k visible tiles drops FPS by ~1% (assuming it's linear).

Oops, I made a mistake. Flying clowns need to pathfind through all that space. That invalidates the results as pathfinding and open space have became conflated.

It should be noted that if no path to the destination is available A* will do a complete and exhaustive search of every tile accessible to the unit, which is a huge performance hit. This is pretty much worst case for A* pathfinding.

Let's try this again without clowns.

Test 3: 128 z-levels of visible open air.

Spoiler (click to show/hide)

FPS eventually stabilised in the 340-360 range, with spikes to 400.

Test 4: 3 levels of visible open air

Spoiler (click to show/hide)

FPS eventually stabilises at 400, spiking to 420 and dropping to 360.

Conclusion for Tests 3 & 4:

We can conclude that ~1M tiles of inaccessible empty space drops FPS by ~12%, or put differently, every 83k visible tiles drops FPS by ~1% (assuming it's linear, which it probably isn't).

Further, we can attempt to unconflate pathfinding from the first run through. It seems ~84.6% of the FPS drop in the first run through can be attributed to pathfinding. Therefore FPS reduced by pathfinding through 98k empty tles is about 58%. Put another way, every 98k visible tiles reduced FPS by 1% due to pathfinding. (same linear disclaimer as above.)

-- Additional experiments --

Test 5: 128 z-levels of visible stone wall.

Spoiler (click to show/hide)

FPS eventually stabilises at 380-400.

Conclusion for test 5:
Visible, unopen space had no noticable effect on FPS.

Test 6: 128 z-levels of floor

Spoiler (click to show/hide)

FPS seems a lot more variable, fluctuating from at least several seconds of stability at many values between 140 and 400. If I had to pick a number, I would say 200, but I definitely did not get a good reading.

No conclusions drawn due to poor measurements

Test 7: 128 z levels of visible air with access via stairs

Spoiler (click to show/hide)

FPS: 340-360 It seemed to take longer to reach the stable point than test 3, but that wasn't measured.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: expwnent on June 27, 2012, 09:51:37 pm

Great work! I'll stop worrying so much about non-pathable open space.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Xen0n on June 27, 2012, 11:16:25 pm

Quote from: Xob Ludosmbax on June 27, 2012, 08:03:58 pm

SCIENCE!

Spoiler: Amazing! (click to show/hide)

That definitely helps put things in perspective. I assume these were all conducted wit the default traffic settings (normal=2, high=1), and the whole map set to normal (=2) traffic value?

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: Xob Ludosmbax on June 28, 2012, 02:43:52 am

Each test was exactly this process:

* extract FPS Bomb - Fork.rar into DF/data/save (fresh each time)
* start DF
* continue playing
* select "FPS Bomb - Fork"
* follow the test process as listed
* unpause
* when the season ended, "die" in dfhack

No changes were made to traffic settings, or anything else.

Also, I think I figured out why "Test 6: 128 z-levels of floor" went so poorly. There may have been something pathing on those new floors. I didn't check. Maybe for the next test I should make sterilization with lava one of the steps.

Time for some !!SCIENCE!!.

I just reran test 6 with everything filled with lava by liquids, and the FPS meter swung for for a bit, going up to 420 with spikes to 430 at one point. It then settled back down to a pretty steady 200, which is our reading. It seemed strange that the final reading was lower than some of the intermediate readings. None of the other tests had that effect. The 200 was more steady than the other tests. Anyway, two variables were changed, so it doesn't tell us much beyond the need for sterilization or worldgen without caverns.

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: ghostwoods on June 28, 2012, 09:17:12 am

Quote from: Xob Ludosmbax on June 28, 2012, 02:43:52 am

Time for some !!SCIENCE!!

Very interesting stuff. Thank you.

When I get a chance -- probably not today -- I'll run a few more tests with inaccessible open flooring. The question of whether (discovered cavern floor) == (DFhacked inaccessible floor) == (mined+resealed floor) is a damned good one.

Xen0n, I'll also have a go at running a crafting test like you suggested, and I'll make sure I do it after the two hard-coded migrant waves just to reduce that variable. Seems to me that I could get hold of a huge stack of "free" stone with grotesque abuse of the embark points :D

Title: Re: !!SCIENCE!! Thread: Operation FPS Bomb
Post by: expwnent on June 28, 2012, 10:45:09 am

Did you remember to save and reload before measuring? That can improve FPS.

Bay 12 Games Forum

Dwarf Fortress => DF Dwarf Mode Discussion => Topic started by: NW_Kohaku on March 14, 2012, 09:33:28 pm