<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000;text-align: left" dir="ltr">
Hi Christoph --<div><br></div><div>-1</div><div><br></div><div>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.</div><div><br></div><div>It is also not good to have a dependency from the Kernel package to Chronology.</div><div><br></div><div>Please keep on looking for more realistic scenarios for such changes. :-)</div><div><br></div><div>Best,</div><div>Marcel</div><div class="mb_sig"></div>
<blockquote class="history_container" type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">
<p style="color: #AAAAAA; margin-top: 10px;">Am 28.03.2022 22:55:11 schrieb christoph.thiede@student.hpi.uni-potsdam.de <christoph.thiede@student.hpi.uni-potsdam.de>:</p><div style="font-family:Arial,Helvetica,sans-serif">
<b>=============== Summary ===============</b><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>
<span style="color: #000000">[</span><span style="color: #800000">1</span><span style="color: #000000"> </span><span style="color: #000080">microSeconds</span><span style="color: #000000"> </span><span style="color: #000080">busyWait</span><span style="color: #000000">]</span><span style="color: #000000"> </span><span style="color: #000080">bench</span><span style="color: #FF0000"> '6,240,000 per second. 160 nanoseconds per run. 0.67973 % GC time.'</span><br>
<br>
Moves #busyWait implementation back to Duration and invokes it from Delay. Not sure whether we need the latter hook, though.<br>
<br>
<b>=============== Diff ===============</b><br>
<br>
<b>Delay>>busyWait {delaying} · ct 3/28/2022 22:36 (changed)</b><br>
busyWait<br>
<s><span style="color: #0000FF">- "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>
</span></s><span style="color: #FF0000">+ "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>
</span><br>
<s><span style="color: #0000FF">- | proceedTime |<br>
- proceedTime := Time utcMicrosecondClock + (delayDuration "milliseconds" * 1000).<br>
- [Time utcMicrosecondClock >= proceedTime] whileFalse.<br>
</span></s><span style="color: #FF0000">+ ^ self delayDuration microSeconds busyWait</span><br>
<br>
<b>Duration>>busyWait {squeak protocol} · ct 3/28/2022 22:39 (changed)</b><br>
busyWait<br>
<s><span style="color: #0000FF">- "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>
</span></s><span style="color: #FF0000">+ "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>
</span><br>
<s><span style="color: #0000FF">- ^ self asDelay busyWait<br>
</span></s><span style="color: #FF0000">+ | proceedTime |<br>
+ proceedTime := Time utcMicrosecondClock + self asMicroSeconds.<br>
+ [Time utcMicrosecondClock >= proceedTime] whileFalse.</span><br>
<br>
["fix-busyWait-precision.1.cs"]<br>
<br>
<span style="color: #808080">---<br>
</span><span style="color: #808080"><i>Sent from </i></span><span style="color: #808080"><i><a href="https://github.com/hpi-swa-lab/squeak-inbox-talk"><u><span style="color: #808080">Squeak Inbox Talk</span></u></a></i></span><br>
["fix-busyWait-precision.1.cs"]
</div></blockquote></div>