Hi Marcel,<br>
<br>
thanks for the critique.<br>
<br>
For reference, normal <font color="#000080">#wait</font> also does not wait long enough for small durations:<br>
<br>
<font color="#000000">[</font><font color="#800000">1</font><font color="#000000"> </font><font color="#000080">microSecond</font><font color="#000000"> </font><font color="#000080">wait</font><font color="#000000">]</font><font color="#000000"> </font><font color="#000080">bench</font><font color="#FF0000"> '1,440,000 per second. 696 nanoseconds per run. 12.2 % GC time.' </font><br>
<br>
Then again, one of my main scenarios when I proposed the original version of <font color="#000080">#busyWait</font> 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? :-)<br>
<br>
> It is also not good to have a dependency from the Kernel package to Chronology.<br>
<br>
Fair point. Still, we could duplicate these three lines.<br>
<br>
Best,<br>
Christoph<br>
<br>
<font color="#808080">---<br>
</font><font color="#808080"><i>Sent from </i></font><font color="#808080"><i><a href="https://github.com/hpi-swa-lab/squeak-inbox-talk"><u><font color="#808080">Squeak Inbox Talk</font></u></a></i></font><br>
<br>
On 2022-03-29T09:05:53+02:00, marcel.taeumel@hpi.de wrote:<br>
<br>
> Hi Christoph --<br>
> <br>
> -1<br>
> <br>
> 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.<br>
> <br>
> It is also not good to have a dependency from the Kernel package to Chronology.<br>
> <br>
> Please keep on looking for more realistic scenarios for such changes. :-)<br>
> <br>
> Best,<br>
> Marcel<br>
> Am 28.03.2022 22:55:11 schrieb christoph.thiede at student.hpi.uni-potsdam.de <christoph.thiede at student.hpi.uni-potsdam.de>:<br>
> =============== Summary ===============<br>
> <br>
> Change Set: fix-busyWait-precision<br>
> Date: 28 March 2022<br>
> Author: Christoph Thiede<br>
> <br>
> 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:<br>
> <br>
> [1 microSeconds busyWait] bench '6,240,000 per second. 160 nanoseconds per run. 0.67973 % GC time.'<br>
> <br>
> Moves #busyWait implementation back to Duration and invokes it from Delay. Not sure whether we need the latter hook, though.<br>
> <br>
> =============== Diff ===============<br>
> <br>
> Delay>>busyWait {delaying} · ct 3/28/2022 22:36 (changed)<br>
> busyWait<br>
> - "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.<br>
> - <br>
> - The following lists the precision (in milliseconds) of #wait on a Microsoft Surface Pro 6, Windows 10 21H1, OSVM 202104182333:<br>
> - 100 -> 100<br>
> - 50 -> 51.1 ... 102.2%<br>
> - 10 -> 11.6 ... 105.5% ... maybe use #busyWait<br>
> - 5 -> 5.93 ... 118.6% ... use #busyWait but check process priorities<br>
> - 1 -> 1.41 ... 141.0% ... use #busyWait but check process priorities<br>
> - <br>
> - 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"<br>
> - <br>
> - "[5 milliSeconds busyWait] bench"<br>
> + "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."<br>
> <br>
> - | proceedTime |<br>
> - proceedTime := Time utcMicrosecondClock + (delayDuration "milliseconds" * 1000).<br>
> - [Time utcMicrosecondClock >= proceedTime] whileFalse.<br>
> + ^ self delayDuration microSeconds busyWait<br>
> <br>
> Duration>>busyWait {squeak protocol} · ct 3/28/2022 22:39 (changed)<br>
> busyWait<br>
> - "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."<br>
> + "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.<br>
> + <br>
> + The following lists the precision (in milliseconds) of #wait on a Microsoft Surface Pro 6, Windows 10 21H1, OSVM 202104182333:<br>
> + 100 -> 100<br>
> + 50 -> 51.1 ... 102.2%<br>
> + 10 -> 11.6 ... 105.5% ... maybe use #busyWait<br>
> + 5 -> 5.93 ... 118.6% ... use #busyWait but check process priorities<br>
> + 1 -> 1.41 ... 141.0% ... use #busyWait but check process priorities<br>
> + <br>
> + 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"<br>
> + <br>
> + "[5 milliSeconds busyWait] bench"<br>
> <br>
> - ^ self asDelay busyWait<br>
> + | proceedTime |<br>
> + proceedTime := Time utcMicrosecondClock + self asMicroSeconds.<br>
> + [Time utcMicrosecondClock >= proceedTime] whileFalse.<br>
> <br>
> ["fix-busyWait-precision.1.cs"]<br>
> <br>
> ---<br>
> Sent from Squeak Inbox Talk [https://github.com/hpi-swa-lab/squeak-inbox-talk]<br>
> ["fix-busyWait-precision.1.cs"]<br>
> -------------- next part --------------<br>
> An HTML attachment was scrubbed...<br>
> URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220329/d7489060/attachment-0001.html><br>
> <br>
>