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 at 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 at mail.msen.com>:

On Mon, Mar 28, 2022 at 10:54:57PM +0200, christoph.thiede at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220505/04c0d9e4/attachment.html>