[DGD] change in tick accounting

[Dread Quixadhal]

Sounds like a win all-around.  Nicely done. 😊

Sent from Mail for Windows 10

From: Felix A. Croes
Sent: Sunday, June 24, 2018 13:12
To: dgd at dworkin.nl
Subject: Re: [DGD] change in tick accounting

Dread Quixadhal <quixadhal at gmail.com> wrote:

> Interesting.
>
> One assumes code that checks for resource limits will ask how much is left and then decide to keep running or continue in a new call_out(), so the net result should just be some code gets to run a little longer before it does that.  Runaway loops will still be caught nicely after a few extra iterations. 😊
>
> The only thing it may impact is profiling via eval cost, since 2 chunks of code that don’t loop will now return the same values, even if one is quite a bit longer.  Unless you added in an estimate, like the number of instructions times a constant, perhaps?

Many kfuns have their own tick cost.  Even operations like assignment and
array/mapping indexing have a cost.  If there are no loops the cost will
now be lower; for tight loops, it could actually be higher than before.
As an approximation of execution time it is less accurate, but only a
little.

JIT-compiled code will perform the same operations and call the same
kfuns, so the tick cost can be identical even though the execution time
will be much lower.

Regards,
Felix Croes