[Vm-dev] [Pharo-dev] Squeak and Pharo speed differences

[Ben Coman]

On Sun, 17 May 2020 at 15:06, Ronie Salgado <roniesalg at gmail.com> wrote:

>
> By the release of Pharo 7 the idle time was increased to 50 ms in order to
> reduce the CPU usage on the cloud and reduce costs. If I remember correctly
> Ben Coman did a PR that changes the way the delays are scheduled in order
> to select the most appropriate time for sleeping, but since the PR was to
> close to a Pharo release, it was decided to not be included for safeness
> reasons. We should resurrect that change soon because the default latency
> is really bad.
>

hi Ronie,

The PR that comes to mind essentially did two things:
1. Moved the native-sleep from the Idle-thread to the DelayScheduler-thread
2. Added an Idle-flag set in the Idle-thread and reset when the
DelayScheduler-thread wakes a delayed-thread.

It was based on the following logic...

1. When the existing Idle-thread is running, its knows that there are no
other runable threads and so should native-sleep.  However there are
probably some delays that expire soon, but the Idle-thread doesn't know
when, so it native-sleeps for a fixed period - possibly sleeping past a
delay expiry.

2. If the Idle-thread were to send messages to discover how long until the
next delay-expiry, that could race with an actual delay-expiry firing the
timingSemaphore to premptively wake the DelayScheduler-thread, which
subsequently wakes the delayed-thread - and I couldn't reason through the
combination of multithreaded line-by-line sequences.

3. It simplified things to ensure there is only ONE sequence to reason
about... where the only thing the Idle-thread does is set an Idle-flag then
immediately fire the timingSemaphore to invoke the DelayScheduler-thread.
When that sees the Idle-flag it native-sleeps the appropriate time until
the next delay expiry.  Upon waking from that it immediately schedules the
delayed-thread and resets the Idle-flag.

It shouldn't be too hard to recreate, but it may be redundant.  I'd need
direction from those working on the IdleVM

cheers -ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20200519/3e0ac742/attachment-0001.html>