[squeak-dev] Review Request: fix-busyWait-precision.1.cs
Marcel Taeumel
marcel.taeumel at hpi.de
Tue Mar 29 07:05:53 UTC 2022
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>
More information about the Squeak-dev
mailing list
|