Timer / Timed Trigger / Pulse / Threshold recognition

[ssilk]

With the new changes to circuit network an interesting performance tweak was introduced. The state of the network is only calculated, when a value changes.
This behavior will enable circuits, that was unthinkable before.
But what, if you have signals, that change every tick? A time-signal (adding 1 every tick) for example? Or using values from logistic network, that can change also every tick. For that case the amount of CPU usage is the same as before.

So there is a simple solution:

Reduce the number of changes to the circuit network.

This device is a bit complex, cause it enables different functionality, but in general it works like so:

Code: Select all

                     interval
                     every X tick
                         |
                         v
                      triggers
                         |
   input signals         v         input signals
 ====================> switch ==================> 

There are three parts: Intervals, triggers and switch. A trigger is checked each interval. If it triggers, the switch switches the input signals through to the output.


I did some rework below, since yesterday. In general I added intervals to the second and third trigger. And I renamed operation to switch.

1. Triggers:

Intervall: Some (slider-like) control that let's choose how many ticks between two checks will pass by. It can be switched between ticks and seconds. Zero turns the interval off.
It displays also the frequency of the trigger in Herz.

An extended (normally hidden) functionality of the intervall is the shift. With this you control the synchronicity of the intervalls. You need to know that the intervall is triggered by a modulo-operation: game-time module X ticks. If that is equal to the shift-value, the intervall triggers.
By default the shift is a random value. But if you set the interval of two timer-devices to the same shift (and frequency, or multiples of the frequency of other intervalls of course) you can synchronize the changes, which might become very important for some cases.

The implementation of the timers allow to precalculate the next interval! This means the device can be turned off in the meantime, cause nothing changes without interval.


Thresholder: What input signal needs to change how much, before the switch will be triggered. This consists of four elements:
- An interval, which works exactly as above.
- The item you want to watch for
- The threshold: Just an a value, which represents the amount that the input signal must change, before it triggers the switch. A negative threshold-value will trigger only, if the signal is within the threshold.
- A switch: Integer, % of input value.
- A switch: input to buffer when triggered, input to buffer each interval
This uses any input signal and checks each interval-time, if the input signal and buffered signal and differs too much and will trigger the switch if the input signal changes more than the defined threshold of the previous buffered value.
By default the buffer (compare-value) will be overwritten only, if the switch is triggered. But it can be copied also each interval (the last switch). In that case this element will trigger the switch only, if there is a sudden change on the input signal.
The current buffer value is always shown somewhere.

Comperator: The comperator constists of two elements:
- An intervall, which works exactly as above.
- Input signal comparison - as known in inserters etc.
This element compares the chosen input signal every X ticks and triggers switch if condition goes from false to true.

You can use all elements at the same time.


2. Switch
The switch is simple: Every time the above explained is triggered the input signal is "switched through" to the output.

There are two switch-operation modes:
- Triggered: The input signals are copied to the output signal for one tick. At any other time there is no output signal at all.
- Hold: When triggered it copies all input signals into an buffer and outputs that signals until the next trigger.
- Triggered has a hidden value "Hold-time", which is by default 1 tick. If you change it, the output holds the signal longer.

Examples

Simple timer:
Constant combinator as input signal to the trigger. Interval to some value. Switch-operation to "triggered". Will output the input ever X ticks.

Blinking lights:
You want to make warning lights for the train crossing (two lamps continuously flash). Constant combinator, interval, switch-operation to triggered.
Now set the trigger-holding-time to 50% of the intervall. This outputs the signal for lamp one. Lamp two is the negation of this signal (simple combinator logic).


There are many, many more use cases for this, but I'm now too lazy to explain all.

[aeros1]

Umm why not short circuit (A<B)->A for timer.
Or if you need counter you may short circuit (A+B)->A and write to B pulses (not necessary 1) Just use different color wire for connection to timers and counters.
Btw you might look here[url = viewtopic.php?f=18&t=14556 ]Combinators 101[/url] for more things you can do. And look for last posts if you need few solutions from me. I added Memory cells and way to make inserters to haul any precise set of items.

So 1 is basically timer A<B->B with constant B. And you already may dynamically change timer interval. If you want it trigger. Use (A<1)->A(1) decider, to trigger everytime timer resets. If you need continous cell you may write value to memory cell and then erase value once process finished. or just (A=1)->A(1) decider.

Can't you do blinking lights with simple timer, which is already possible? Aka "(A<60)->A" with constant combinator A(1) And then one light on when A<30 second A>30

And if you don't like This solution it is quite possible to use belt loop with pulse detector for timer/trigger.

[ssilk]

Umm why not short circuit (A<B)->A for timer.

Cause that is exactly what this suggestion wants to avoid: A continuous change every tick.

This kind of timer can be precalculated. The device can be turned off in the meantime.

And I forgot yesterday to add an interval to the two other triggers because of this.

[aeros1]

Umm why not short circuit (A<B)->A for timer.

Cause that is exactly what this suggestion wants to avoid: A continuous change every tick.

This kind of timer can be precalculated. The device can be turned off in the meantime.

And I forgot yesterday to add an interval to the two other triggers because of this.

Don't see problem if you don't need output signal, why not set output gate A=1 it would be 0 all time but when output on timer 1? I don't think power and continous signal is big problem one solar battery and one accumulator solve problem with powering most combinators. Using triggers and not supplying power seems like stealing power from combinators.
And if you need offline data storage there are chests and chaff items. Not super fast storage but for everything you need to pay. And pretty sure you would be able to backup data before accumulator goes dry.
Edit: Also would seem good reason to use blueprints. And it is quite possible to forget setup timers. After all you don't need many timers and one is enough. Or it is blueprintable

[ssilk]

First: I made some changes to the suggestion. I hope it helps to understand it better. Sorry, I think I was a bit tired yesterday.

The switch has nothing to do with the electric switch, that is already in the game.

And I must admit, that I don't understand aeros1's answer. For me it sound, as you are talking about something completely different. Please have a look to my changes, I hope it explains a bit more, for what this device might be useful.

As a side-effect, this device provides super-useful functionality.


PS: I know of course, that everything can be rebuilt with current circuits. But the main purpose of this device should be to reduce the number of changes that the circuit network needs to calculate. Therefore the three types of triggers: To make clever guesses when it is worth to forward the new input signals. The disadvantage is: You lose granularity. But that is the point: As a player and when we are talking about control for production of items I had NEVER the need of a granularity of 1 tick. In most cases 1 second is more than enough (again: we are talking about production). I think only when we are talking about defense or so, there I need this granularity, yes, in most other cases not.

[Deadly-Bagel]

I believe what Ssilk is getting at is an actual timer entity. Currently the solution is a constant combinator linked to a decider combinator looped to itself and linked to another decider combinator that triggers once a certain number is reached (such as 0). Currently there is no problem with this as every tick the circuit network is recalculated so you aren't using any CPU that you weren't already.

However there are changes coming to the circuit network where only changes are calculated. If there are no changes, no (or very little) CPU is used. Throw in the above timer, you're forcing a change every second and so the network is constantly being recalculated again. It makes the optimisation of the circuit network pointless.

SO the obvious solution is a "Timer Combinator" that simply outputs a value every x [ticks/seconds]. This way the network is only being calculated when necessary, it greatly simplifies a LOT in building circuits and brings it in line with the optimisations. Should also be a pretty easy development.

That about the scope of it Ssilk?

Ooh, ooh, can I request a feature? Can we have the option of specifying a time of day to trigger as well? Even if you give it the number of ticks in a day, that is subject to change with mods and if you lose power it will throw the timer out.

[aeros1]

I believe what Ssilk is getting at is an actual timer entity. Currently the solution is a constant combinator linked to a decider combinator looped to itself and linked to another decider combinator that triggers once a certain number is reached (such as 0). Currently there is no problem with this as every tick the circuit network is recalculated so you aren't using any CPU that you weren't already.

However there are changes coming to the circuit network where only changes are calculated. If there are no changes, no (or very little) CPU is used. Throw in the above timer, you're forcing a change every second and so the network is constantly being recalculated again. It makes the optimisation of the circuit network pointless.

SO the obvious solution is a "Timer Combinator" that simply outputs a value every x [ticks/seconds]. This way the network is only being calculated when necessary, it greatly simplifies a LOT in building circuits and brings it in line with the optimisations. Should also be a pretty easy development.

That about the scope of it Ssilk?

Ooh, ooh, can I request a feature? Can we have the option of specifying a time of day to trigger as well? Even if you give it the number of ticks in a day, that is subject to change with mods and if you lose power it will throw the timer out.

Pretty sure if you isolate timer with gates, when you don't need constantly changing value via combinator only small part of circuit network would be inefficient. But not that I am against, just saying it is a bit pointless. As most likely code runs through each combinator already, so it is just faster to do operation than put extra decisions to decide if value changed CPU wise. After all not only decisions slower than just direct inputs (Ok deciders may be slow), but also you put more conditions which are slow in loop to check if value changed, and if changed you still need to do operation. So there is no win or even loses CPU wise.

[Deadly-Bagel]

More likely each device that is connected to a network posts its network in a table when its value changes, then the table is looped. No need to query every combinator.

Also you might have several timers, or even many in big bases, all for varying tasks. There are also some solutions where it would greatly affect performance because the timer count is being passed along the network either for ease of design or for an actual purpose.

[aeros1]

More likely each device that is connected to a network posts its network in a table when its value changes, then the table is looped. No need to query every combinator.

Also you might have several timers, or even many in big bases, all for varying tasks. There are also some solutions where it would greatly affect performance because the timer count is being passed along the network either for ease of design or for an actual purpose.

Exactly. Most likely each wire is some part of network and combinators assigned to networks. To tell the truth I don't believe such optimization would be any effective because even if it is faster to check first for some reason the amount of factors not changing values are near to nil. And combinators already only work when values changed. Need examples? Near every belt sensor no matter pulse or constant updates each frame(in fact constant would have to update each frame). Logistic networks. I wouldn't even say anything. Every time robot takes something puts something, or inserter takes from logistic chest. Maybe looks insignificant but in large factories still same. I dunno if such optimisations even help. What might help if it is not done already is not launch Lua every time combinator used, but precompile code and store in memory, or use internal library for combinators (at least base ones, lua compatibility still may stay). Lua quite slow.

[Deadly-Bagel]

Constant combinators don't change values, when in a loop with a decider combinator it's the decider that's changing the value. This is probably the trickiest case to solve because you have two entities theoretically both producing constants. There will probably have to be specialised code for looped combinators.

And again, it's not faster to check everything than it is to check nothing. Most likely a system is being implemented where anything that changes advertises that it needs recalculating.

For example, say you have 5,000 chests connected to circuit networks. Everything is idle for 100 ticks, then an item is inserted into one chest. You are saying to check 5,000 chests 100 times, so 500,000 IF statements. Too true this will not be much more efficient.

What -I- am saying is don't check any of the chests ever. When the item is inserted into a chest, there is processing going on in that chest where it consumes the item and adds it to its inventory. While doing this, the chest asks "Am I connected to a circuit network?" Because it is connected, it posts its connected circuit[s] to a "CircuitUpdated" list (if the circuit is not already present). Every tick this list is looped and only those circuits are updated. This way there are ~102 IF statements, significantly less than checking every chest. There might be an extra check performed every time something is changed, for example the contents of a chest, while it checks for connected networks but no doubt there are ways to mitigate that too.

[aeros1]

Constant combinators don't change values, when in a loop with a decider combinator it's the decider that's changing the value. This is probably the trickiest case to solve because you have two entities theoretically both producing constants. There will probably have to be specialised code for looped combinators.

And again, it's not faster to check everything than it is to check nothing. Most likely a system is being implemented where anything that changes advertises that it needs recalculating.

For example, say you have 5,000 chests connected to circuit networks. Everything is idle for 100 ticks, then an item is inserted into one chest. You are saying to check 5,000 chests 100 times, so 500,000 IF statements. Too true this will not be much more efficient.

What -I- am saying is don't check any of the chests ever. When the item is inserted into a chest, there is processing going on in that chest where it consumes the item and adds it to its inventory. While doing this, the chest asks "Am I connected to a circuit network?" Because it is connected, it posts its connected circuit[s] to a "CircuitUpdated" list (if the circuit is not already present). Every tick this list is looped and only those circuits are updated. This way there are ~102 IF statements, significantly less than checking every chest. There might be an extra check performed every time something is changed, for example the contents of a chest, while it checks for connected networks but no doubt there are ways to mitigate that too.

Which in the end spawns even more lag because check if connected, check if udated, recalculate. In the end you recalculate network nearly every frame anyway, because roboport logistic network, and belt/inserter. But now you run loop which checks objects for update and schedules them than you run through updating objects. Timer object would be marginally faster because it checks system time instead of doing additional arithmetic operations but still. If need allow players to reduce CPU load on some not critical combinators, may set refresh cycle for those but again it would most likely be slower because now you need check if x cycles past before update. And if you don't use so load heavy "Everything", "Any" signals most likely combinators change only one value in network which not adds lot to input. Though I guess you can win some processing time if you use internal functions for timers compared to combinator setups.

Another thing is even more bothers me, list sorting and list finding is pretty slow operation, you need to run through list of pointers just to check if something is present. So either update list would be pretty large with few networks(where production is stalled) offline and mostly active others. Would it save CPU dunno. And usually updating is not problem. Considering most combinators adhere to stream logic it can be done pretty quick if you for example use Videocard, for processing networks. Not saying it is rarely large update count is problem, especially if it is simple update operations and for combinators it is simple, but rather not optimized code. There are games updating >1k objects on screen and over 100k(and I think on newer PC's it is somewhere near 1 million) objects off screen.

After all all combinator logic is simple first push specified 2 values to stack, and second on exit pop from stack 2 values, do operation add to network value. The only problem is with Any, All and such encompasing values. And network I think erases every cycle it's table. But maybe I am too wrong. And even than network I meen wire values may trated as stream. You store values for one cycle than swap to next storage.

Because solution as it described by you not any better. First run all entities, and complete required actions, than run all networks to complete updates. You spawn extra cycles, instead of just doing it. In fact if circuit wires treated as stream aka store value for one cycle before purged or as stack. They don't care what changes are and super fast. They run over all connected items and just push their values. While each connected entity waits for value to pop, which is simple as well. And if you want free CPU you may use GPU which actually adapted for stream calculations and Factorio is not really GPU hungry.

Edit: And why check if item is in circuit network, if it already should be added there when you connect it to circuit network, seems even less logical, most likely networks. Why entity even aware it is part of network? What is required is for network access to entity storage data, and ability to run separately from entity. Then you don't need to check if something part of network. Because you are working with network and entity servicing network providing data.

[Deadly-Bagel]

Uh, the circuit network is its own cycle anyway, it can't be calculated every time a chest is changed and it can't be done in parallel. It has to be done only once everything else is finished because if two items gets added to a chest in the same tick (which is likely if you're using circuits) it needs to recognise both items have been added.

And the logistic network won't be updating every tick all the time, 60 items every second isn't normal unless you're doing a heavy logistic run or you've got a huge factory. Besides, the logistic network counts as a single circuit (I imagine), even if you send it to a combinator that's simply creating a new circuit network off the back of that and I don't see any reason you would have tons of big circuits all sending [*] signals all the way along from the logistics network. If you do, whatever, it's not going to stop you but most players won't.

Also I'm simplifying things here, I'm not versed in making code efficient to run 60 times a second and no doubt such logic isn't as easy to explain, this is more a "basic idea".

As for belts and inserters, neither of those are even capable of updating every tick, not even close (if belts are optimised they would update up to 20 ticks per second, the max throughput per lane). Even if you were to link a bunch of belts together, they still won't all update every tick because as items move on, others move off, and overall the value won't change every tick so the next circuit accepting these values doesn't need to update either.

At the end of the day the devs say they can save a lot of processing in the circuit network and they're the ones with the code, you going to argue this with them?

[ssilk]

For example, say you have 5,000 chests connected to circuit networks. Everything is idle for 100 ticks, then an item is inserted into one chest. You are saying to check 5,000 chests 100 times, so 500,000 IF statements. Too true this will not be much more efficient.

No, that is not the use-case.

OK, let's say we have some chests connected together, like so:

Screen Shot 2016-09-12 at 17.41.11.png (315.02 KiB) Viewed 11521 times

It could be of course some more complex, but we leave it like so. The current game runs so: Each tick the content of all chests are summarized somehow and the sum is in the circuit. That signals are taken by the invisible combinators to the right and they calculate each tick the result.
The coming game runs so: As above, but now the circuit looks, if the values in that network has changed. If so, the network triggers a wake up to the connected devices (the green wire, which goes to the right) to recalculate the output.
This can (and will) be optimized of course somehow (that kind of optimization is dangerous, cause the more clever you make such algorithms, the more CPU they will need.)

Now with this suggestion it could be done so:

Screen Shot 2016-09-12 at 17.46.37.png (281.77 KiB) Viewed 11521 times

Please take the combinator in the center as it would be this new timer/trigger-device. You see: Looks like nothing really changes. But now we can do some very clever optimization.

- Optimization #1: Even if the sum in the chest-network changes, it will only forwarded to the invisible devices to the right, if the interval triggers the switch. Only then the network to the right can change it's values and only then they need to be recalculated. It's clear, that this eventually reduces the number of calculations in the right network.

- Optimization #2: This is much more clever and I know it works only in special networks, like some you see here. It works so: Because now you know WHEN the summarized signal from the chest is really needed: Only when one of the intervals in the triggers is ready! (And of course when you hover with the mouse over the network.)
In any other case you won't need it! You won't need to look, if some chest content has changed. You won't need to sum it up.

This means: With this device it is not only possible to reduce the changes on the output side, no, we can reduce also the changes on the input side, cause the game engine knows, that it needs to calculate the input network only every X ticks. And it can do that in a way, that there is no delay of one tick between input and output.

[aeros1]

How to tell you. Hmm, let's say do you know why the fastest processes are usually stream based? No not because everyone likes to send information without right to change it. Because they are fast. If you come to some object and start woriking with it it is usually much faster finish working with it then continue rather than postponing for later. It would be much faster to complete combinator signal. because to decide if in your case in order to check if quantity changed youl already had to read each chest to compare with network value. Hence already you have values for items, why not just update network. If you start checking with value if changed, in situations it wasn't you lose a bit of CPU, in cases it did you lost alot. Even if each chest posts flag to it's network hey I changed value, hey listen. In the end spawns quite a bit problems, with checking flag then recalculating action. Far more then just start network processing, which in the end you would need to do anyway.

The only which can be done is simple priority shifting based in network activity, but even then if you think checking for every 10th frame for one element of network is faster than rethink, because it is check for each element of network. Now if network is it's own class, yes it can be optimized this way, because you encompass all sort of objects into one.
1)So if circuit networks would be optimised I would say shift to stream processing first.
2)Then if not enough, make priorities. Aka low priority networks, update whenever they are free, or too much data collected on them, normal priority checks on flag change, and high priority just updates every frame. As how this networks deal with eachother. Simple signals on entrance to low priority network keep accumulating till voided by network accepting them. While higher priority networks just lay dormant, waiting for input.
3)Don't use LUA for circuit networks. Every time LUA needs to change walue it makes CALL jump which is slowest even after comparison operation. Use "inline" public methods. Yes I know they bloat code, but they don't do unnecessary call jumps because they literally embedded into code during compilation.
4) if not done already, don't rely on garbage collector, free values yourself, free memory less, zero memory more. Every time you free memory you fragment it and longer it takes next time to find next free chunk on paged memory. Not saying garbage collector does it in slowest way possible, by requiring update on table every time you change pointer. While just freeing value yourself at least tells him done with this thing stop checking. Turn off garbage collector or reduce it's cycles if you want it to catch some leaks.

But agreed second case where you link etwork to combinator slightly otimizes by localizing high capacity calculations and updating only values you need, while even cutting out unnecessary values from chests that might appear.

[ssilk]

Sorry, but I really think you don't understand the basic idea.
Which is: slow down processing of some circuit networks (where you use that device). So that it is not needed to calculate it every tick.

I don't understand what you mean with network priorities; that ain't gonna work, that makes networks unpredictable, say good bye to the determinism.

I also don't understand, why you think, that LUA is involved here. And garbage collector (Factorio has a tweaked garbage collector).

[aeros1]

Sorry, but I really think you don't understand the basic idea.
Which is: slow down processing of some circuit networks (where you use that device). So that it is not needed to calculate it every tick.

I don't understand what you mean with network priorities; that ain't gonna work, that makes networks unpredictable, say good bye to the determinism.

I also don't understand, why you think, that LUA is involved here. And garbage collector (Factorio has a tweaked garbage collector).

Not really, when you not need high throughput you or large update count you keep low priority. Like blinking lights, When you need high processing power put it on high priority. Priority is simple and user defined. Signals not lost they are accumulated so even if network sleeping it may process accumulated values once it required to do so. Basic idea is to separate where you need high cycle count, by removing unnecessary checks and doing stream processing https://en.wikipedia.org/wiki/Stream_processing .
Basic idea you localise and run each network separately. Then you update either when there is free processing time (Low priority), when required (Normal priority), and every frame (high prirority). So now you have multiple network refresh rates which are not conflicting. Btw it is not compramizes determenism in any shape. Low priority , and it is more way for user to tell, this is not important do it at free time. When required is basically every time something acesses the stream (I don't see it faster then high priority, due to low oerations count, but it could be used. Aka inserter picks item, state changed.). High prirority is just processed every frame.

Now let's say you have high priority network dumping data in low priority, what happens is state of network dumps to low priority until low priority network gets chance to process it. So data still processed accurately just at later date.
Now let's say you want low priority network to feed data to high priority network, nothing happens, high priority network recieves data, then waits for low priority network to dump more data. Incorrect pririties may slow down calculations but hardly make them indeterministic. Unless you require pulses every frame, which again you use wrong tules for solving problem.

P.S. Ssilk We are talking at least now about same the more actions you do the more CPU GPU processing time you take. Hence why I am for keeping such simple processing as circuit networks as simple as possible, and not use multithreaded optimizations which made for considerably far CPU heavy processes than manager itself, and for such simple processes would be more harmful than useful.

[ssilk]

Now let's say you have high priority network dumping data in low priority, what happens is state of network dumps to low priority until low priority network gets chance to process it. So data still processed accurately just at later date.

I have two problems with that: You say there is no problem with determinism. Assume a belt-counter: When you count the items on a belt with such a low-priority network, you will miss items (or count them double).

So you see: There is a problem with determinism: You cannot forsee, if there is now enough CPU left or not.

And the second is, that low priority means for you: If there is no CPU left, the game just does not calculate low-prio networks. The idea is convincing, but what, if the player has decided to put his emergency-power-master-switch into such a low-prio-network. And then the electric power goes off and the biters come (cause no lasers) and eat 30% of his factory.

P.S. Ssilk We are talking at least now about same the more actions you do the more CPU GPU processing time you take. Hence why I am for keeping such simple processing as circuit networks as simple as possible, and not use multithreaded optimizations which made for considerably far CPU heavy processes than manager itself, and for such simple processes would be more harmful than useful.

Sorry, I don't see here any multiprocessing, nor GPU processing involved (cause you also mentioned stream-processing, which is in the same family).
Factorio works not like so: The update-process works currently on one CPU only. 60 times per second. And the point with this is: And everything, that can be turned off (even for one tick) will save CPU.

Think to long lists of things (entities like belts, assemblies, inserters, player, but also circuit networks, combinators etc.) which the update needs to calculate within one tick. If you are able to turn off one entity the entity will not be listed. No CPU will be used to calculate anything. This is the point of this suggestion: Keep circuit networks out of the list for some ticks.


There are plan to make inserters work in multiprocessing. But that has really nothing to do with this, cause in the end you need synchronization points, that cannot be optimized with more CPU power.

[Deadly-Bagel]

It could be of course some more complex, but we leave it like so. The current game runs so: Each tick the content of all chests are summarized somehow and the sum is in the circuit. That signals are taken by the invisible combinators to the right and they calculate each tick the result.
The coming game runs so: As above, but now the circuit looks, if the values in that network has changed.

Hmmm so if I understand correctly, the network connecting the chests to the combinator is calculated every tick. This is because it is constantly summing the contents of the chests. However because nothing is changing and its value remains the same, the circuit from the combinator going offscreen (and any subsequent circuits) are not updated.

This would surprise me actually. You would get better performance when you have several circuits strung together with only a single input (such as a chest), however if you have several inputs along the line then it won't make much of a difference. Would it not be more efficient to only update a network when the content of at least one of the chests has changed?

[ssilk]

I dunno, how you interpret all that from my post.

Would it not be more efficient to only update a network when the content of at least one of the chests has changed?

Sorry, but I don't know how that is calculated, so I don't know how to optimize that. I just know how you can reduce the needed number of operation in general and leave the details to the devs.

[Deadly-Bagel]

Heh yeah I hear that! Well at any rate we can be rest assured it will be quality stuff.