Goonhub
02-19-2020, 02:07 PM
(This post was last modified: 02-20-2020, 10:59 AM by Naksu. Edited 2 times in total.)
Patch in https://github.com/goonstation/goonstati...ree-bucket
Older, uncleaned commit in https://github.com/goonstation/goonstati...et-testing if you want to do your own A:B testing
Basically what this does is changes the machines global list into a multi-level list like so:
1: list of one list
2: list of 2 lists
3: list of 4 lists
4: list of 8 lists
5: list of 16 lists
The first list is the "full processing" list, where everything goes by default. The second one is "half processing", and in this patch plantpots are added there, the rest are so far unused though there is a commented-out suggestion to solars you could try if you want to. it Seems to work, but honestly I don't know your codebase well enough yet to spot what immediate issues there might be.
Every processing tick, the full processing list is processed, one half of the half processing list is processed, one quarter of the quarter processing list is processed etc. like in this reference image:
![[Image: V0tkS3S.png]](https://i.imgur.com/V0tkS3S.png)
This spreads the processing load of things that don't need to process every processing tick, and also avoids the proc call overhead of calling process() only for the process to early return because of a ticker modulo check. The machines can also find out how often they are processing, and can use it to multiply the amount of "work" being done (example in the solar panel code).
This change should be performance neutral, there is a very slight increase in machinery instantiation cost due to having to figure out which bucket the machinery goes, and also a very slight increase in machinery processing self time. The increased self time is most likely recouped by saving a handful of empty proc calls from plantpots.
The solar panel change (or other follow-up changes anyone might make) will push this into a performance benefit, and I've a plan to tack on a "simple processing" tier where the processing system itself checks for brokenness and consumes energy, thus avoiding a proc call completely. It could be also spread evenly over multiple processing ticks. I've also a mind to replace the subscribe/unsubscribe procs with a macro, and have machines start processing when there's work to be done and stop when there's not.
Thank you for coming to my ted talk.
Oh yeah and you could save a couple of trifling cycles spent on looping a known-empty list by adding something like #define PROCESSING_MAX_IN_USE PROCESSING_HALF and using it in place of 5 in a couple of loops. I can add it to the branch if you want. Done in current commit, along with another cleanup
Older, uncleaned commit in https://github.com/goonstation/goonstati...et-testing if you want to do your own A:B testing
Basically what this does is changes the machines global list into a multi-level list like so:
1: list of one list
2: list of 2 lists
3: list of 4 lists
4: list of 8 lists
5: list of 16 lists
The first list is the "full processing" list, where everything goes by default. The second one is "half processing", and in this patch plantpots are added there, the rest are so far unused though there is a commented-out suggestion to solars you could try if you want to. it Seems to work, but honestly I don't know your codebase well enough yet to spot what immediate issues there might be.
Every processing tick, the full processing list is processed, one half of the half processing list is processed, one quarter of the quarter processing list is processed etc. like in this reference image:
This spreads the processing load of things that don't need to process every processing tick, and also avoids the proc call overhead of calling process() only for the process to early return because of a ticker modulo check. The machines can also find out how often they are processing, and can use it to multiply the amount of "work" being done (example in the solar panel code).
This change should be performance neutral, there is a very slight increase in machinery instantiation cost due to having to figure out which bucket the machinery goes, and also a very slight increase in machinery processing self time. The increased self time is most likely recouped by saving a handful of empty proc calls from plantpots.
The solar panel change (or other follow-up changes anyone might make) will push this into a performance benefit, and I've a plan to tack on a "simple processing" tier where the processing system itself checks for brokenness and consumes energy, thus avoiding a proc call completely. It could be also spread evenly over multiple processing ticks. I've also a mind to replace the subscribe/unsubscribe procs with a macro, and have machines start processing when there's work to be done and stop when there's not.
Thank you for coming to my ted talk.
Oh yeah and you could save a couple of trifling cycles spent on looping a known-empty list by adding something like #define PROCESSING_MAX_IN_USE PROCESSING_HALF and using it in place of 5 in a couple of loops. I can add it to the branch if you want. Done in current commit, along with another cleanup
