[squeak-dev] Review Request: fix-busyWait-precision.1.cs

David T. Lewis lewis at mail.msen.com
Thu May 5 20:01:58 UTC 2022


+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 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
> 

> 



More information about the Squeak-dev mailing list