=============== 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 ["fix-busyWait-precision.1.cs"]
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@student.hpi.uni-potsdam.de christoph.thiede@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"]
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@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"]
Hi Christoph, Marcel,
On 4/1/22 11:52, christoph.thiede@student.hpi.uni-potsdam.de wrote:
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? :-)
+1
You need quite precise delays when reading from certain hardware devices and real-time data streams. This is in addition to using it to simulate a very fast yet-unwritten method to ensure your program can keep up and not blow up the input buffer or starve the output buffer.
I feel supporting precision timekeeping would really open up Squeak's potential users to people who are stuck using some less ideal language (C family, Ada) because it can handle real-time streamed data and Squeak can't.
On Mon, Mar 28, 2022 at 10:54:57PM +0200, christoph.thiede@student.hpi.uni-potsdam.de wrote:
=============== 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.
+1
This makes sense to me, because when I send #busyWait to a Duration, I expect it to be burning CPU cycles in the context of a process. This seems different from the behavior of a Delay, which wakes up a process after some delay that is evaluated in the "outside world" (the VM and operating system).
So I prefer the original Chronology-Core-ct.67 approach of letting Duration be responsible for doing a #busyWait.
Dave
Hi all --
We should watch out to not make Kernel depend on Chronology. So, maybe #busyWait should be in a *Chronology extension then.
The scenario of simulating some work is interesting. I would do "1 to: 10000 do: [:ea | Object new]" instead.
Please, BE AWARE that if we start to give guarantees below 1 millisecond -- here: 1 nanosecond or 1 microsecond -- we have more maintenance effort in the future.
This is a new feature. Not just a bugfix.
Best, Marcel Am 02.04.2022 03:15:28 schrieb David T. Lewis lewis@mail.msen.com: On Mon, Mar 28, 2022 at 10:54:57PM +0200, christoph.thiede@student.hpi.uni-potsdam.de wrote:
=============== 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.
+1
This makes sense to me, because when I send #busyWait to a Duration, I expect it to be burning CPU cycles in the context of a process. This seems different from the behavior of a Delay, which wakes up a process after some delay that is evaluated in the "outside world" (the VM and operating system).
So I prefer the original Chronology-Core-ct.67 approach of letting Duration be responsible for doing a #busyWait.
Dave
Hi all,
The scenario of simulating some work is interesting. I would do "1 to: 10000 do: [:ea | Object new]" instead.
But this gives you even fewer guarantees. A perfect VM might optimize that away ...
We should watch out to not make Kernel depend on Chronology. So, maybe #busyWait should be in a *Chronology extension then.
If it wasn't already there, I would just keep #busyWait away from Delay. Delay is implemented using Semaphores, and this is not the way #busyWait works. :-) Would it be okay to remove Delay >> #busyWait again (it has not been overly long in the Trunk) and move the implementation to Duration as suggested?
Best, Christoph
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Freitag, 8. April 2022 10:09:35 An: squeak-dev Betreff: Re: [squeak-dev] Review Request: fix-busyWait-precision.1.cs
Hi all --
We should watch out to not make Kernel depend on Chronology. So, maybe #busyWait should be in a *Chronology extension then.
The scenario of simulating some work is interesting. I would do "1 to: 10000 do: [:ea | Object new]" instead.
Please, BE AWARE that if we start to give guarantees below 1 millisecond -- here: 1 nanosecond or 1 microsecond -- we have more maintenance effort in the future.
This is a new feature. Not just a bugfix.
Best, Marcel
Am 02.04.2022 03:15:28 schrieb David T. Lewis lewis@mail.msen.com:
On Mon, Mar 28, 2022 at 10:54:57PM +0200, christoph.thiede@student.hpi.uni-potsdam.de wrote:
=============== 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.
+1
This makes sense to me, because when I send #busyWait to a Duration, I expect it to be burning CPU cycles in the context of a process. This seems different from the behavior of a Delay, which wakes up a process after some delay that is evaluated in the "outside world" (the VM and operating system).
So I prefer the original Chronology-Core-ct.67 approach of letting Duration be responsible for doing a #busyWait.
Dave
The better solution would be to implement very short duration Delays properly.
tim — Give a man a compliment, he’ll feel good for a day. Teach a man to fish for compliments and he’ll never feel good enough for the rest of his life.
This could be good future work. But as described earlier, there is a real need for busy waiting. :-)
Best,
Christoph
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von tim Rowledge tim@rowledge.org Gesendet: Donnerstag, 5. Mai 2022 20:40:38 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] Review Request: fix-busyWait-precision.1.cs
The better solution would be to implement very short duration Delays properly.
tim — Give a man a compliment, he’ll feel good for a day. Teach a man to fish for compliments and he’ll never feel good enough for the rest of his life.
Hi Christoph --
[...] there is a real need for busy waiting. :-)
Well, you just want to simulate some work. Yes, using a busyWait implementation is one way of doing it. There are others. At best, you would do some actual domain-specific work for your test. Then it would be a good test. ;-)
Best, Marcel Am 05.05.2022 21:26:48 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de: This could be good future work. But as described earlier, there is a real need for busy waiting. :-)
Best, Christoph Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von tim Rowledge tim@rowledge.org Gesendet: Donnerstag, 5. Mai 2022 20:40:38 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] Review Request: fix-busyWait-precision.1.cs The better solution would be to implement very short duration Delays properly.
tim — Give a man a compliment, he’ll feel good for a day. Teach a man to fish for compliments and he’ll never feel good enough for the rest of his life.
On 2022-05-06, at 2:15 AM, Marcel Taeumel marcel.taeumel@hpi.de wrote: There are others. At best, you would do some actual domain-specific work for your test.
TechBro76574 says "do some DimWitCoin mining!"
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Sic faciunt omnes. = Everyone is doing it.
Merged via Chronology-Core-ct.80/Kernel-ct.1480 and tested via Chronology-Tests-ct.31. Thanks for all your feedback!
Best,
Christoph
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von tim Rowledge tim@rowledge.org Gesendet: Freitag, 6. Mai 2022 18:54:45 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] Review Request: fix-busyWait-precision.1.cs
On 2022-05-06, at 2:15 AM, Marcel Taeumel marcel.taeumel@hpi.de wrote: There are others. At best, you would do some actual domain-specific work for your test.
TechBro76574 says "do some DimWitCoin mining!"
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Sic faciunt omnes. = Everyone is doing it.
Hi Christoph --
Fixes #busyWait for durations < 1 milliSecond. [...]
Again, adding this kind of precision is a new feature. Not a fix of a bug or regression.
If you want to simulate some work in the context of a TestCase, why not implement something there? Why should the base system support #busyWait at all?
Best, Marcel Am 05.05.2022 21:26:48 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de: This could be good future work. But as described earlier, there is a real need for busy waiting. :-)
Best, Christoph Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von tim Rowledge tim@rowledge.org Gesendet: Donnerstag, 5. Mai 2022 20:40:38 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] Review Request: fix-busyWait-precision.1.cs The better solution would be to implement very short duration Delays properly.
tim — Give a man a compliment, he’ll feel good for a day. Teach a man to fish for compliments and he’ll never feel good enough for the rest of his life.
Hi Marcel,
Fixes #busyWait for durations < 1 milliSecond. [...]
Again, adding this kind of precision is a new feature. Not a fix of a bug or regression.
But it's the use case for which I originally proposed #busyWait. Maybe we should discuss the complete removal of that selector if you are afraid of too many problems with it?
If you want to simulate some work in the context of a TestCase, why not implement something there? Why should the base system support #busyWait at all?
It was not in the context of a test case but just a scripting/profiling aid in the interactive system. Similar to #inspectOnce/#haltOnce, which are also not used in production code.
Best, Christoph
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Freitag, 6. Mai 2022 11:18:46 An: squeak-dev Betreff: Re: [squeak-dev] Review Request: fix-busyWait-precision.1.cs
Hi Christoph --
Fixes #busyWait for durations < 1 milliSecond. [...]
Again, adding this kind of precision is a new feature. Not a fix of a bug or regression.
If you want to simulate some work in the context of a TestCase, why not implement something there? Why should the base system support #busyWait at all?
Best, Marcel
Am 05.05.2022 21:26:48 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de:
This could be good future work. But as described earlier, there is a real need for busy waiting. :-)
Best,
Christoph
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von tim Rowledge tim@rowledge.org Gesendet: Donnerstag, 5. Mai 2022 20:40:38 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] Review Request: fix-busyWait-precision.1.cs
The better solution would be to implement very short duration Delays properly.
tim — Give a man a compliment, he’ll feel good for a day. Teach a man to fish for compliments and he’ll never feel good enough for the rest of his life.
Hi Christoph --
Do want you think is best. I think that you are familiar with many of the constraints and best practices by now.
And don't forget about the tests. :-)
Best, Marcel Am 06.05.2022 11:44:13 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de: Hi Marcel,
> Fixes #busyWait for durations < 1 milliSecond. [...] Again, adding this kind of precision is a new feature. Not a fix of a bug or regression.
But it's the use case for which I originally proposed #busyWait. Maybe we should discuss the complete removal of that selector if you are afraid of too many problems with it?
If you want to simulate some work in the context of a TestCase, why not implement something there? Why should the base system support #busyWait at all?
It was not in the context of a test case but just a scripting/profiling aid in the interactive system. Similar to #inspectOnce/#haltOnce, which are also not used in production code.
Best, Christoph Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Freitag, 6. Mai 2022 11:18:46 An: squeak-dev Betreff: Re: [squeak-dev] Review Request: fix-busyWait-precision.1.cs Hi Christoph --
Fixes #busyWait for durations < 1 milliSecond. [...]
Again, adding this kind of precision is a new feature. Not a fix of a bug or regression.
If you want to simulate some work in the context of a TestCase, why not implement something there? Why should the base system support #busyWait at all?
Best, Marcel Am 05.05.2022 21:26:48 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de: This could be good future work. But as described earlier, there is a real need for busy waiting. :-)
Best, Christoph Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von tim Rowledge tim@rowledge.org Gesendet: Donnerstag, 5. Mai 2022 20:40:38 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] Review Request: fix-busyWait-precision.1.cs The better solution would be to implement very short duration Delays properly.
tim — Give a man a compliment, he’ll feel good for a day. Teach a man to fish for compliments and he’ll never feel good enough for the rest of his life.
On May 5, 2022, at 11:40 AM, tim Rowledge tim@rowledge.org wrote:
The better solution would be to implement very short duration Delays properly.
AFAIA the vm supports microsecond resolution delays. However, blocking interfaces used by the vm to block when there’s nothing to do, such as select(3), may offer only millisecond resolution.
(I’m pretty sure that) What the vm maintains is the time of the next delay expiry, in the utc microsecond clock,
Internally Delay is doing delayForMicroseconds:, not delayForMilliseconds:.
tim — Give a man a compliment, he’ll feel good for a day. Teach a man to fish for compliments and he’ll never feel good enough for the rest of his life.
+1 from me (see below).
Dave
On Thu, May 05, 2022 at 06:27:43PM +0000, Thiede, Christoph wrote:
Hi all,
The scenario of simulating some work is interesting. I would do "1 to: 10000 do: [:ea | Object new]" instead.
But this gives you even fewer guarantees. A perfect VM might optimize that away ...
We should watch out to not make Kernel depend on Chronology. So, maybe #busyWait should be in a *Chronology extension then.
If it wasn't already there, I would just keep #busyWait away from Delay. Delay is implemented using Semaphores, and this is not the way #busyWait works. :-) Would it be okay to remove Delay >> #busyWait again (it has not been overly long in the Trunk) and move the implementation to Duration as suggested?
Best, Christoph
Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Freitag, 8. April 2022 10:09:35 An: squeak-dev Betreff: Re: [squeak-dev] Review Request: fix-busyWait-precision.1.cs
Hi all --
We should watch out to not make Kernel depend on Chronology. So, maybe #busyWait should be in a *Chronology extension then.
The scenario of simulating some work is interesting. I would do "1 to: 10000 do: [:ea | Object new]" instead.
Please, BE AWARE that if we start to give guarantees below 1 millisecond -- here: 1 nanosecond or 1 microsecond -- we have more maintenance effort in the future.
This is a new feature. Not just a bugfix.
Best, Marcel
Am 02.04.2022 03:15:28 schrieb David T. Lewis lewis@mail.msen.com:
On Mon, Mar 28, 2022 at 10:54:57PM +0200, christoph.thiede@student.hpi.uni-potsdam.de wrote:
=============== 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.
+1
This makes sense to me, because when I send #busyWait to a Duration, I expect it to be burning CPU cycles in the context of a process. This seems different from the behavior of a Delay, which wakes up a process after some delay that is evaluated in the "outside world" (the VM and operating system).
So I prefer the original Chronology-Core-ct.67 approach of letting Duration be responsible for doing a #busyWait.
Dave
squeak-dev@lists.squeakfoundation.org