Wait 1 Theory
No summary available.
Link
Posted date unknown
First off, I'd like to say that the biggest reason this demo got 3 stars and no lower is because it tries to spread the message that wait 1 commands should be used in Robotic, and correctly states that they can be used to properly time code over multiple robots. However, most of what else is stated in this is sneaky and not particularly useful.
Test #1 correctly displays a robot that uses wait 1s versus a robot that busyloops, but Test #2 is totally misleading bogus. The counter raises at the same rate in both tests -- once per cycle, thanks to a wait 1. However, the display robots busy loop if you turn wait 1s off, wasting quite a bit of processor with redundant write overlay commands. The moral of this story should not be "Wait 1 makes your code faster," but instead "Not ending the robot's cycle when a it's done everything it needs to do per cycle is wasteful of resources," and Gemini completely fails to distinguish these two different message. This demo also says nothing the effects of raising the commands counter, which is something that actually CAN speed up code (but will also lock up Megazeux in a busyloop if you raise it enough and fail to end every robot's cycle properly); however, this is mostly the result of the demo having been made before the commands counter was introduced, not only making this demo inaccurate, but also outdated.
In conclusion: keep using wait 1s or cycle 1s to end robots' cycles, but do not, for an INSTANT, believe that doing so speeds up your code. It optimizes it, and nothing more.
Test #1 correctly displays a robot that uses wait 1s versus a robot that busyloops, but Test #2 is totally misleading bogus. The counter raises at the same rate in both tests -- once per cycle, thanks to a wait 1. However, the display robots busy loop if you turn wait 1s off, wasting quite a bit of processor with redundant write overlay commands. The moral of this story should not be "Wait 1 makes your code faster," but instead "Not ending the robot's cycle when a it's done everything it needs to do per cycle is wasteful of resources," and Gemini completely fails to distinguish these two different message. This demo also says nothing the effects of raising the commands counter, which is something that actually CAN speed up code (but will also lock up Megazeux in a busyloop if you raise it enough and fail to end every robot's cycle properly); however, this is mostly the result of the demo having been made before the commands counter was introduced, not only making this demo inaccurate, but also outdated.
In conclusion: keep using wait 1s or cycle 1s to end robots' cycles, but do not, for an INSTANT, believe that doing so speeds up your code. It optimizes it, and nothing more.
Link
Last modified 2012-01-30 09:56:22
Lachesis is mostly right and, yes, use wait 1 where it is necessary to avoid busyloops and no more.
However, I'm giving this 1 star because it is filled with dirty lies. The behaviour this code is intended to reproduce* is muddled between the nature of MZX cycle ending commands and an obscure secondary way in which cycles end in MZX. Gemini did not test his 'theory' very well and it doesn't come close to explaining what actually happens. Hence not only is this not a useful document now, it was never correct.
*The code does not 'work' (produce the intended functionality) in any currently released (up to 2.83) version of the MZX port due to a piece of rather obtuse cycle ending code not being implemented in current versions.
However, I'm giving this 1 star because it is filled with dirty lies. The behaviour this code is intended to reproduce* is muddled between the nature of MZX cycle ending commands and an obscure secondary way in which cycles end in MZX. Gemini did not test his 'theory' very well and it doesn't come close to explaining what actually happens. Hence not only is this not a useful document now, it was never correct.
*The code does not 'work' (produce the intended functionality) in any currently released (up to 2.83) version of the MZX port due to a piece of rather obtuse cycle ending code not being implemented in current versions.