There is major difference between traditional software and Tickator. In Tickator are all elements - ticklets - still alive. That means, in every tick element can’t react on input or produce output. It works in the same way as transistor in your CPU or cell in your body. Each of such element is just still alive - there is no sleeping time when it is sleeping and is not responsible. Of course it may decide not to react on environment events but it is purely its internal and conscious choice.
In Tickator you don’t have to care about flow in your program. You just connect elements and change is spread automatically and in parallel.
This image shows activated cells (blue) and spreading change (arrow):
Compare this with threads used in traditional software - no matter if your program is functional or procedural. There is one or more threads - executed by processor cores - that for short time woke up software elements (objects, functions, methods, …) from sleeping state. Right after execution elements again fall asleep. One can say number of active elements is equal to number of CPU cores. Programmer must control execution in the way that threads reaches proper elements in proper time.
Imagine how would that work in case of your body cells if only small fractions can run simultaneously.
This is how it would look like:
Can you see analogy to traditional software systems?
Of course Tickator uses threads for implementation - it is easiest way for now, but performance and energy efficiency are suffering. Various optimizations are used which allows it to run on nowadays CPUs. There is map of connections between ticklets, so when output is changed it exactly knows which ticklets should be activated in next tick.
In near future may be build dedicated Tickator processor based of FPGA, in far future even physical made of silicon. One may imagine processor consisted of thousands cores, each executing one (best case) to many ticklets.