<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body>
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;" dir="ltr">
<p>Hi all,</p>
<p><br>
</p>
<p><span style="font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols; font-size: 16px;">> </span><span style="font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols; font-size: 12pt;">The
scenario of simulating some work is interesting. I would do "1 to: 10000 do: [:ea | Object new]" instead.</span></p>
<div style="font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols; font-size: 16px;">
<br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols; font-size: 16px;">
But this gives you even fewer guarantees. A perfect VM might optimize that away ...</div>
<p></p>
<p><br>
</p>
<p>> <span style="font-size: 12pt;">We should watch out to not make Kernel depend on Chronology. So, maybe #busyWait should be in a *Chronology extension then.</span></p>
<div><br>
</div>
<div>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. :-)</div>
<div>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?</div>
<div><br>
</div>
<div>Best,</div>
<div>Christoph</div>
<div>
<div></div>
</div>
<p></p>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>Von:</b> Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von Taeumel, Marcel<br>
<b>Gesendet:</b> Freitag, 8. April 2022 10:09:35<br>
<b>An:</b> squeak-dev<br>
<b>Betreff:</b> Re: [squeak-dev] Review Request: fix-busyWait-precision.1.cs</font>
<div> </div>
</div>
<div>
<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000;text-align: left" dir="ltr">
Hi all --
<div><br>
</div>
<div>We should watch out to not make Kernel depend on Chronology. So, maybe #busyWait should be in a *Chronology extension then.</div>
<div><br>
</div>
<div>The scenario of simulating some work is interesting. I would do "1 to: 10000 do: [:ea | Object new]" instead.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>This is a new feature. Not just a bugfix.</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 02.04.2022 03:15:28 schrieb David T. Lewis <lewis@mail.msen.com>:</p>
<div style="font-family:Arial,Helvetica,sans-serif">On Mon, Mar 28, 2022 at 10:54:57PM +0200, christoph.thiede@student.hpi.uni-potsdam.de wrote:<br>
> =============== Summary ===============<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>
> ????[1 microSeconds busyWait] bench '6,240,000 per second. 160 nanoseconds per run. 0.67973 % GC time.'<br>
> <br>
> Moves #busyWait implementation back to Duration and invokes it from Delay. Not sure whether we need the latter hook, though.<br>
> <br>
<br>
+1<br>
<br>
This makes sense to me, because when I send #busyWait to a Duration,<br>
I expect it to be burning CPU cycles in the context of a process.<br>
This seems different from the behavior of a Delay, which wakes up<br>
a process after some delay that is evaluated in the "outside world"<br>
(the VM and operating system).<br>
<br>
So I prefer the original Chronology-Core-ct.67 approach of letting<br>
Duration be responsible for doing a #busyWait.<br>
<br>
Dave<br>
<br>
</div>
</blockquote>
</div>
</div>
</body>
</html>