Hi Marcel,

thanks for the critique.

For reference, normal #wait also does not wait long enough for small durations:

	[1 microSecond wait] bench '1,440,000 per second. 696 nanoseconds per run. 12.2 % GC time.' 

Then again, one of my main scenarios when I proposed the original version of #busyWait was exactly to program precise tiny delays. I used this to simulate any kind of - more or less expensive - computations in order to test progress bars and other status updates (for example, conversations filters in SIT). So, my #unknownCompute method will be called thousands or ten-thousands of times and I want to simulate that each computation takes about 10 microSeconds. Isn't this a fair scenario to you? :-)

> It is also not good to have a dependency from the Kernel package to Chronology.

Fair point. Still, we could duplicate these three lines.

Best,
Christoph

---
Sent from Squeak Inbox Talk

On 2022-03-29T09:05:53+02:00, marcel.taeumel at hpi.de wrote:

> Hi Christoph --
> 
> -1
> 
> The entire waiting protocol is only useful for milliseconds or higher. The compromise to wait less than 10 milliseconds was only for tests if I recall correctly.
> 
> It is also not good to have a dependency from the Kernel package to Chronology.
> 
> Please keep on looking for more realistic scenarios for such changes. :-)
> 
> Best,
> Marcel
> Am 28.03.2022 22:55:11 schrieb christoph.thiede at student.hpi.uni-potsdam.de <christoph.thiede at student.hpi.uni-potsdam.de>:
> =============== Summary ===============
> 
> Change Set:        fix-busyWait-precision
> Date:            28 March 2022
> Author:            Christoph Thiede
> 
> Fixes #busyWait for durations < 1 milliSecond. Since the original proposal (Chronology-Core-ct.67), the implementation had been moved from Duration to Delay (Chronology-Core-mt.71). However, Delay has only milliseconds precision, causing shorter durations to be handled as a delayDuration of 0 milliSeconds and leading to this erroneous output:
> 
>     [1 microSeconds busyWait] bench '6,240,000 per second. 160 nanoseconds per run. 0.67973 % GC time.'
> 
> Moves #busyWait implementation back to Duration and invokes it from Delay. Not sure whether we need the latter hook, though.
> 
> =============== Diff ===============
> 
> Delay>>busyWait {delaying} · ct 3/28/2022 22:36 (changed)
> busyWait
> -     "BEWARE! This method is more precise than #wait, but it sacrifices many CPU cycles for that precision. Also note that the GC runs more often. Also note that only processes with a higher priority can run while waiting.
> -     
> -     The following lists the precision (in milliseconds) of #wait on a Microsoft Surface Pro 6, Windows 10 21H1, OSVM 202104182333:
> -         100 -> 100
> -         50 -> 51.1 ... 102.2%
> -         10 -> 11.6 ... 105.5% ... maybe use #busyWait
> -         5 -> 5.93 ... 118.6% ... use #busyWait but check process priorities
> -         1 -> 1.41 ... 141.0% ... use #busyWait but check process priorities
> -     
> -     As of July 2021, the shortest delay that we can guarantee on all platforms is still 1 millisecond as the value of #utcMicrosecondClock might not change any faster than that. For more information, see http://lists.squeakfoundation.org/pipermail/squeak-dev/2021-July/215928.html"
> -     
> -     "[5 milliSeconds busyWait] bench"
> +     "BEWARE! This method is more precise than #wait, but it sacrifices many CPU cycles for that precision. Also note that the GC runs more often. Also note that only processes with a higher priority can run while waiting. See more detailed commentary in Duration >> #busyWait."
> 
> -     | proceedTime |
> -     proceedTime := Time utcMicrosecondClock + (delayDuration "milliseconds" * 1000).
> -     [Time utcMicrosecondClock >= proceedTime] whileFalse.
> +     ^ self delayDuration microSeconds busyWait
> 
> Duration>>busyWait {squeak protocol} · ct 3/28/2022 22:39 (changed)
> busyWait
> -     "BEWARE! This method is more precise than #wait, but it sacrifices many CPU cycles for that precision. Also note that only processes with a higher priority can run while waiting. See more detailed commentary in Delay >> #busyWait."
> +     "BEWARE! This method is more precise than #wait, but it sacrifices many CPU cycles for that precision. Also note that the GC runs more often. Also note that only processes with a higher priority can run while waiting.
> +     
> +     The following lists the precision (in milliseconds) of #wait on a Microsoft Surface Pro 6, Windows 10 21H1, OSVM 202104182333:
> +         100 -> 100
> +         50 -> 51.1 ... 102.2%
> +         10 -> 11.6 ... 105.5% ... maybe use #busyWait
> +         5 -> 5.93 ... 118.6% ... use #busyWait but check process priorities
> +         1 -> 1.41 ... 141.0% ... use #busyWait but check process priorities
> +     
> +     As of July 2021, the shortest delay that we can guarantee on all platforms is still 1 millisecond as the value of #utcMicrosecondClock might not change any faster than that. For more information, see http://lists.squeakfoundation.org/pipermail/squeak-dev/2021-July/215928.html"
> +     
> +     "[5 milliSeconds busyWait] bench"
> 
> -     ^ self asDelay busyWait
> +     | proceedTime |
> +     proceedTime := Time utcMicrosecondClock + self asMicroSeconds.
> +     [Time utcMicrosecondClock >= proceedTime] whileFalse.
> 
> ["fix-busyWait-precision.1.cs"]
> 
> ---
> Sent from Squeak Inbox Talk [https://github.com/hpi-swa-lab/squeak-inbox-talk]
> ["fix-busyWait-precision.1.cs"]
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220329/d7489060/attachment-0001.html>
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220401/5094c73a/attachment-0001.html>