Smalltalk › Pharo › Pharo Smalltalk Developers

Super fast delay

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

32 messages Options

Ben Coman

Re: Super fast delay

This is the issue [1]. I did a fix a while ago, but its preload (see issue) stops Delay processing while it loads, which locked up the UI loop and Integration Tool. That was recently fixed by issue [2], but I wanted to rebase the [1] on the latest Pharo - but first I should strip out #newCodeEnabled: wrappers to make review of [1] easier. There is a new issue [3] for that.

Now if you tell me you are keen to review [3] and [1] when they are ready, I'll bump them to the top of my queue.

[1] https://pharo.fogbugz.com/default.asp?14669 "Delay refactoring (part 2) - change from milliseconds to microseconds"

[2] https://pharo.fogbugz.com/default.asp?14669 "Delay refactoring (part 2a) - avoid UI locking up when timer event loop is stopped"

[3] https://pharo.fogbugz.com/default.asp?14942 "Delay refactoring (part 2b) - clean out newCodeEnabled wrappers"

cheers -ben

On Mon, Feb 16, 2015 at 4:01 PM, Holger Hans Peter Freyther <[hidden email]> wrote:

On Thu, Oct 30, 2014 at 06:32:48PM -0400, stepharo wrote:

Good Morning Ben, Stef,

> We really need people to have a look at the code of Ben.

I downloaded a Pharo-4 image today and executed:

time pharo --nodisplay --headless ./Pharo-40490.image eval "(Delay forSeconds: 5) wait"
a Delay(5000 msecs)

real 0m1.254s
user 0m1.192s
sys 0m0.060s

So the first delay doesn't appear to wait the five seconds. I
would like to work on kqueue/epoll and remove polling and it
looks this involves code with Delay as well. I wonder if you
could provide an overview of what needs to be done and what is
done?

thanks
holger

stepharo

Re: Super fast delay

would be so great to get that in pharo 40.

Le 16/2/15 15:21, Ben Coman a écrit :

This is the issue [1]. I did a fix a while ago, but its preload (see issue) stops Delay processing while it loads, which locked up the UI loop and Integration Tool. That was recently fixed by issue [2], but I wanted to rebase the [1] on the latest Pharo - but first I should strip out #newCodeEnabled: wrappers to make review of [1] easier. There is a new issue [3] for that.

Now if you tell me you are keen to review [3] and [1] when they are ready, I'll bump them to the top of my queue.

[1] https://pharo.fogbugz.com/default.asp?14669 "Delay refactoring (part 2) - change from milliseconds to microseconds"

[2] https://pharo.fogbugz.com/default.asp?14669 "Delay refactoring (part 2a) - avoid UI locking up when timer event loop is stopped"

[3] https://pharo.fogbugz.com/default.asp?14942 "Delay refactoring (part 2b) - clean out newCodeEnabled wrappers"

cheers -ben

On Mon, Feb 16, 2015 at 4:01 PM, Holger Hans Peter Freyther <[hidden email]> wrote:

On Thu, Oct 30, 2014 at 06:32:48PM -0400, stepharo wrote:

Good Morning Ben, Stef,

> We really need people to have a look at the code of Ben.

I downloaded a Pharo-4 image today and executed:

time pharo --nodisplay --headless ./Pharo-40490.image eval "(Delay forSeconds: 5) wait"
a Delay(5000 msecs)

real 0m1.254s
user 0m1.192s
sys 0m0.060s

So the first delay doesn't appear to wait the five seconds. I
would like to work on kqueue/epoll and remove polling and it
looks this involves code with Delay as well. I wonder if you
could provide an overview of what needs to be done and what is
done?

thanks
holger

Ben Coman

Re: Super fast delay

In reply to this post by Holger Freyther

On Mon, Feb 16, 2015 at 4:01 PM, Holger Hans Peter Freyther <[hidden email]> wrote:

On Thu, Oct 30, 2014 at 06:32:48PM -0400, stepharo wrote:

Good Morning Ben, Stef,

> We really need people to have a look at the code of Ben.

I downloaded a Pharo-4 image today and executed:

To clarify. The fix is not yet in Pharo-4.

time pharo --nodisplay --headless ./Pharo-40490.image eval "(Delay forSeconds: 5) wait"
a Delay(5000 msecs)

real 0m1.254s
user 0m1.192s
sys 0m0.060s

So the first delay doesn't appear to wait the five seconds. I
would like to work on kqueue/epoll and remove polling and it
looks this involves code with Delay as well. I wonder if you
could provide an overview of what needs to be done and what is
done?

The pre-requisite issue 14942 is waiting for review. It really should take only 10 minutes to review...

1. In latest Pharo 4, inspect "Delay newCodeEnabled" and observe that it is "true".

2. Open the Pharo4Inbox and filter on 14942.

3. Select newest slice and <Merge>.

4. Observe the diff shows all "false" parts removed (it doesn't really get much simpler than this to review).

5. Click <merge> to finish.

6. Observe the image continues to run smoothly.

7. Report your observations on https://pharo.fogbugz.com/default.asp?14942

I need to refresh myself on the fix I did back in 2-Dec. Its languished while some support infrastructure was added to help the system ride-through the change.

cheers -ben

Ben Coman

Re: Super fast delay

On Thu, Feb 19, 2015 at 9:50 PM, Ben Coman <[hidden email]> wrote:

On Mon, Feb 16, 2015 at 4:01 PM, Holger Hans Peter Freyther <[hidden email]> wrote:
On Thu, Oct 30, 2014 at 06:32:48PM -0400, stepharo wrote:

Good Morning Ben, Stef,

> We really need people to have a look at the code of Ben.

I downloaded a Pharo-4 image today and executed:

To clarify. The fix is not yet in Pharo-4.

time pharo --nodisplay --headless ./Pharo-40490.image eval "(Delay forSeconds: 5) wait"
a Delay(5000 msecs)

real 0m1.254s
user 0m1.192s
sys 0m0.060s

So the first delay doesn't appear to wait the five seconds. I
would like to work on kqueue/epoll and remove polling and it
looks this involves code with Delay as well. I wonder if you
could provide an overview of what needs to be done and what is
done?

The pre-requisite issue 14942 is waiting for review. It really should take only 10 minutes to review...
1. In latest Pharo 4, inspect "Delay newCodeEnabled" and observe that it is "true".
2. Open the Pharo4Inbox and filter on 14942.
3. Select newest slice and <Merge>.
4. Observe the diff shows all "false" parts removed (it doesn't really get much simpler than this to review).
5. Click <merge> to finish.
6. Observe the image continues to run smoothly.
7. Report your observations on https://pharo.fogbugz.com/default.asp?14942

btw, after the cleanup done by Issue 14942, Issue 14966 can delete ten class variables from Delay.

When 14942 is integrated, can 14966 be integrated very soon after that. I am basing the change of Delay to microsecond delay off 14966.

cheers -ben

I need to refresh myself on the fix I did back in 2-Dec. Its languished while some support infrastructure was added to help the system ride-through the change.

cheers -ben

Ben Coman

Re: Super fast delay

I've updated this fix for build 40504. The following slice is read for review.

SLICE-Issue-14353-Delay-refactoring-part-2---change-from-milliseconds-to-microseconds-BenComan.6

Even if you do not feel up to reviewing the code, it would be good for a few people to merge this to get a broad sample of symptoms fixed or caused.

1. Open up Monticello and get ready to load the above slice from Pharo4Inbox repository.

2. In a workspace, do "Delay stopTimerEventLoop". Ignore the #intercyclePause: message that stream by.

3. Merge slice.

4. In a workspace, do "Delay startTimerEventLoop". The stream of #interCyclePause message should fade.

5. Operate as you normally would. Test some cases that previously caused an error.

cheers -ben

On Thu, Feb 19, 2015 at 11:17 PM, Ben Coman <[hidden email]> wrote:

On Thu, Feb 19, 2015 at 9:50 PM, Ben Coman <[hidden email]> wrote:

On Mon, Feb 16, 2015 at 4:01 PM, Holger Hans Peter Freyther <[hidden email]> wrote:
On Thu, Oct 30, 2014 at 06:32:48PM -0400, stepharo wrote:

Good Morning Ben, Stef,

> We really need people to have a look at the code of Ben.

I downloaded a Pharo-4 image today and executed:

To clarify. The fix is not yet in Pharo-4.

time pharo --nodisplay --headless ./Pharo-40490.image eval "(Delay forSeconds: 5) wait"
a Delay(5000 msecs)

real 0m1.254s
user 0m1.192s
sys 0m0.060s

So the first delay doesn't appear to wait the five seconds. I
would like to work on kqueue/epoll and remove polling and it
looks this involves code with Delay as well. I wonder if you
could provide an overview of what needs to be done and what is
done?

The pre-requisite issue 14942 is waiting for review. It really should take only 10 minutes to review...
1. In latest Pharo 4, inspect "Delay newCodeEnabled" and observe that it is "true".
2. Open the Pharo4Inbox and filter on 14942.
3. Select newest slice and <Merge>.
4. Observe the diff shows all "false" parts removed (it doesn't really get much simpler than this to review).
5. Click <merge> to finish.
6. Observe the image continues to run smoothly.
7. Report your observations on https://pharo.fogbugz.com/default.asp?14942

btw, after the cleanup done by Issue 14942, Issue 14966 can delete ten class variables from Delay.
When 14942 is integrated, can 14966 be integrated very soon after that. I am basing the change of Delay to microsecond delay off 14966.
cheers -ben

I need to refresh myself on the fix I did back in 2-Dec. Its languished while some support infrastructure was added to help the system ride-through the change.

cheers -ben

stepharo

Fwd: Re: Super fast delay

Please help us to push ben code.

-------- Message transféré --------

Sujet :	Re: [Pharo-dev] Super fast delay
Date :	Wed, 25 Feb 2015 02:00:25 +0800
De :	Ben Coman [hidden email]
Répondre à :	Pharo Development List [hidden email]
Pour :	Pharo Development List [hidden email]

I've updated this fix for build 40504. The following slice is read for review.

SLICE-Issue-14353-Delay-refactoring-part-2---change-from-milliseconds-to-microseconds-BenComan.6

Even if you do not feel up to reviewing the code, it would be good for a few people to merge this to get a broad sample of symptoms fixed or caused.

1. Open up Monticello and get ready to load the above slice from Pharo4Inbox repository.

2. In a workspace, do "Delay stopTimerEventLoop". Ignore the #intercyclePause: message that stream by.

3. Merge slice.

4. In a workspace, do "Delay startTimerEventLoop". The stream of #interCyclePause message should fade.

5. Operate as you normally would. Test some cases that previously caused an error.

cheers -ben

On Thu, Feb 19, 2015 at 11:17 PM, Ben Coman <[hidden email]> wrote:

On Thu, Feb 19, 2015 at 9:50 PM, Ben Coman <[hidden email]> wrote:

On Mon, Feb 16, 2015 at 4:01 PM, Holger Hans Peter Freyther <[hidden email]> wrote:

On Thu, Oct 30, 2014 at 06:32:48PM -0400, stepharo wrote:

Good Morning Ben, Stef,

> We really need people to have a look at the code of Ben.

I downloaded a Pharo-4 image today and executed:

To clarify. The fix is not yet in Pharo-4.

time pharo --nodisplay --headless ./Pharo-40490.image eval "(Delay forSeconds: 5) wait"
a Delay(5000 msecs)

real 0m1.254s
user 0m1.192s
sys 0m0.060s

So the first delay doesn't appear to wait the five seconds. I
would like to work on kqueue/epoll and remove polling and it
looks this involves code with Delay as well. I wonder if you
could provide an overview of what needs to be done and what is
done?

The pre-requisite issue 14942 is waiting for review. It really should take only 10 minutes to review...

1. In latest Pharo 4, inspect "Delay newCodeEnabled" and observe that it is "true".

2. Open the Pharo4Inbox and filter on 14942.

3. Select newest slice and <Merge>.

4. Observe the diff shows all "false" parts removed (it doesn't really get much simpler than this to review).

5. Click <merge> to finish.

6. Observe the image continues to run smoothly.

7. Report your observations on https://pharo.fogbugz.com/default.asp?14942

btw, after the cleanup done by Issue 14942, Issue 14966 can delete ten class variables from Delay.

When 14942 is integrated, can 14966 be integrated very soon after that. I am basing the change of Delay to microsecond delay off 14966.

cheers -ben

I need to refresh myself on the fix I did back in 2-Dec. Its languished while some support infrastructure was added to help the system ride-through the change.

cheers -ben

Ben Coman

Re: Fwd: Re: Super fast delay

This is not going to get as much use before Release as I had hoped, so I refactored it to be able to easily switch between the existing and new code by making two schedulers...

* DelayMillisecondScheduler - essentially the existing code

* DelayMicrosecondScheduler - based off new primitive

which are switchable on the fly via a System Setting.

To try to make it easier to review, I've separated changes into three stages:

* SLICE.10 accumulates changes the Delay class to add some better semantics to instance variables and method renames

* SLICE.14 accumulates changes to split DelayScheduler into two subclasses for the two different schedulers (use the incoming code in the merge conflict)

* SLICE.17 accumulates changes to modify DelayMicrosecondScheduler, plus a couple of polishing things.

I've added some review notes to the issue

https://pharo.fogbugz.com/default.asp?14353

fyi, Tomorrow I start a new job at Buewaters Power Station [1] (2 x 208MW generators). They've been without an electrical engineer for three months leading up to their annual outage in five weeks, so I'm probably flat there playing catch-up for the next two months. Today (GMT+8) would be a really good time to engage me with feedback and queries. I'll try to hang out on IRC as much as possible to speed up discussion.

[1] http://www.bluewatersps.com.au/

cheers -ben

On Mon, Mar 2, 2015 at 3:09 AM, stepharo <[hidden email]> wrote:

Please help us to push ben code.

-------- Message transféré --------

Sujet : Re: [Pharo-dev] Super fast delay

Date : Wed, 25 Feb 2015 02:00:25 +0800

De : Ben Coman <[hidden email]>

Répondre à : Pharo Development List <[hidden email]>

Pour : Pharo Development List <[hidden email]>

I've updated this fix for build 40504. The following slice is read for review.

SLICE-Issue-14353-Delay-refactoring-part-2---change-from-milliseconds-to-microseconds-BenComan.6

Even if you do not feel up to reviewing the code, it would be good for a few people to merge this to get a broad sample of symptoms fixed or caused.

1. Open up Monticello and get ready to load the above slice from Pharo4Inbox repository.

2. In a workspace, do "Delay stopTimerEventLoop". Ignore the #intercyclePause: message that stream by.

3. Merge slice.

4. In a workspace, do "Delay startTimerEventLoop". The stream of #interCyclePause message should fade.

5. Operate as you normally would. Test some cases that previously caused an error.

cheers -ben

On Thu, Feb 19, 2015 at 11:17 PM, Ben Coman <[hidden email]> wrote:

On Thu, Feb 19, 2015 at 9:50 PM, Ben Coman <[hidden email]> wrote:

On Mon, Feb 16, 2015 at 4:01 PM, Holger Hans Peter Freyther <[hidden email]> wrote:

On Thu, Oct 30, 2014 at 06:32:48PM -0400, stepharo wrote:

Good Morning Ben, Stef,

> We really need people to have a look at the code of Ben.

I downloaded a Pharo-4 image today and executed:

To clarify. The fix is not yet in Pharo-4.

time pharo --nodisplay --headless ./Pharo-40490.image eval "(Delay forSeconds: 5) wait"

a Delay(5000 msecs)

real 0m1.254s

user 0m1.192s

sys 0m0.060s

So the first delay doesn't appear to wait the five seconds. I

would like to work on kqueue/epoll and remove polling and it

looks this involves code with Delay as well. I wonder if you

could provide an overview of what needs to be done and what is

done?

The pre-requisite issue 14942 is waiting for review. It really should take only 10 minutes to review...

1. In latest Pharo 4, inspect "Delay newCodeEnabled" and observe that it is "true".

2. Open the Pharo4Inbox and filter on 14942.

3. Select newest slice and <Merge>.

4. Observe the diff shows all "false" parts removed (it doesn't really get much simpler than this to review).

5. Click <merge> to finish.

6. Observe the image continues to run smoothly.

7. Report your observations on https://pharo.fogbugz.com/default.asp?14942

btw, after the cleanup done by Issue 14942, Issue 14966 can delete ten class variables from Delay.

When 14942 is integrated, can 14966 be integrated very soon after that. I am basing the change of Delay to microsecond delay off 14966.

cheers -ben

I need to refresh myself on the fix I did back in 2-Dec. Its languished while some support infrastructure was added to help the system ride-through the change.

cheers -ben

Ben Coman

Re: Fwd: Re: Super fast delay

This is solved with the integration of issue 14353 into build 40548.

On an OSX > Virtualbox > LinuxMint17 with the following script...

for i in `seq 1 10` ;

(time $MYPHAROVM $MYIMAGE \

eval "(Delay forSeconds: 1) wait") 2>&1 > /dev/null | grep real

done

Build 40547 gives...

real 0m1.288s

real 0m1.256s

real 0m1.258s

real 0m0.254s

real 0m0.269s

real 0m0.274s

real 0m0.260s

real 0m0.245s

real 0m0.254s

real 0m1.260s

Build 40548 gives...

real 0m1.285s

real 0m1.259s

real 0m1.260s

real 0m1.280s

real 0m1.267s

real 0m1.265s

real 0m1.293s

real 0m1.267s

real 0m1.278s

HTH,

cheers -ben

On Mon, Mar 2, 2015 at 12:08 PM, Ben Coman <[hidden email]> wrote:

This is not going to get as much use before Release as I had hoped, so I refactored it to be able to easily switch between the existing and new code by making two schedulers...
* DelayMillisecondScheduler - essentially the existing code
* DelayMicrosecondScheduler - based off new primitive
which are switchable on the fly via a System Setting.

To try to make it easier to review, I've separated changes into three stages:
* SLICE.10 accumulates changes the Delay class to add some better semantics to instance variables and method renames
* SLICE.14 accumulates changes to split DelayScheduler into two subclasses for the two different schedulers (use the incoming code in the merge conflict)
* SLICE.17 accumulates changes to modify DelayMicrosecondScheduler, plus a couple of polishing things.

I've added some review notes to the issue
https://pharo.fogbugz.com/default.asp?14353

fyi, Tomorrow I start a new job at Buewaters Power Station [1] (2 x 208MW generators). They've been without an electrical engineer for three months leading up to their annual outage in five weeks, so I'm probably flat there playing catch-up for the next two months. Today (GMT+8) would be a really good time to engage me with feedback and queries. I'll try to hang out on IRC as much as possible to speed up discussion.

[1] http://www.bluewatersps.com.au/

cheers -ben

On Mon, Mar 2, 2015 at 3:09 AM, stepharo <[hidden email]> wrote:

Please help us to push ben code.

-------- Message transféré --------
Sujet : Re: [Pharo-dev] Super fast delay
Date : Wed, 25 Feb 2015 02:00:25 +0800
De : Ben Coman <[hidden email]>
Répondre à : Pharo Development List <[hidden email]>
Pour : Pharo Development List <[hidden email]>

I've updated this fix for build 40504. The following slice is read for review.
SLICE-Issue-14353-Delay-refactoring-part-2---change-from-milliseconds-to-microseconds-BenComan.6

Even if you do not feel up to reviewing the code, it would be good for a few people to merge this to get a broad sample of symptoms fixed or caused.

1. Open up Monticello and get ready to load the above slice from Pharo4Inbox repository.
2. In a workspace, do "Delay stopTimerEventLoop". Ignore the #intercyclePause: message that stream by.
3. Merge slice.
4. In a workspace, do "Delay startTimerEventLoop". The stream of #interCyclePause message should fade.
5. Operate as you normally would. Test some cases that previously caused an error.

cheers -ben

On Thu, Feb 19, 2015 at 11:17 PM, Ben Coman <[hidden email]> wrote:

On Thu, Feb 19, 2015 at 9:50 PM, Ben Coman <[hidden email]> wrote:

On Mon, Feb 16, 2015 at 4:01 PM, Holger Hans Peter Freyther <[hidden email]> wrote:
On Thu, Oct 30, 2014 at 06:32:48PM -0400, stepharo wrote:

Good Morning Ben, Stef,

> We really need people to have a look at the code of Ben.

I downloaded a Pharo-4 image today and executed:

To clarify. The fix is not yet in Pharo-4.

time pharo --nodisplay --headless ./Pharo-40490.image eval "(Delay forSeconds: 5) wait"
a Delay(5000 msecs)

real 0m1.254s
user 0m1.192s
sys 0m0.060s

So the first delay doesn't appear to wait the five seconds. I
would like to work on kqueue/epoll and remove polling and it
looks this involves code with Delay as well. I wonder if you
could provide an overview of what needs to be done and what is
done?

The pre-requisite issue 14942 is waiting for review. It really should take only 10 minutes to review...
1. In latest Pharo 4, inspect "Delay newCodeEnabled" and observe that it is "true".
2. Open the Pharo4Inbox and filter on 14942.
3. Select newest slice and <Merge>.
4. Observe the diff shows all "false" parts removed (it doesn't really get much simpler than this to review).
5. Click <merge> to finish.
6. Observe the image continues to run smoothly.
7. Report your observations on https://pharo.fogbugz.com/default.asp?14942

btw, after the cleanup done by Issue 14942, Issue 14966 can delete ten class variables from Delay.
When 14942 is integrated, can 14966 be integrated very soon after that. I am basing the change of Delay to microsecond delay off 14966.
cheers -ben

I need to refresh myself on the fix I did back in 2-Dec. Its languished while some support infrastructure was added to help the system ride-through the change.

cheers -ben

Max Leske

Re: Super fast delay

Great work Ben!

On 10 Mar 2015, at 17:44, Ben Coman <[hidden email]> wrote:

This is solved with the integration of issue 14353 into build 40548.

On an OSX > Virtualbox > LinuxMint17 with the following script...
for i in `seq 1 10` ;
do
(time $MYPHAROVM $MYIMAGE \
eval "(Delay forSeconds: 1) wait") 2>&1 > /dev/null | grep real
done

Build 40547 gives...
real 0m1.288s
real 0m1.256s
real 0m1.258s
real 0m0.254s
real 0m0.269s
real 0m0.274s
real 0m0.260s
real 0m0.245s
real 0m0.254s
real 0m1.260s

Build 40548 gives...
real 0m1.285s
real 0m1.259s
real 0m1.260s
real 0m1.260s
real 0m1.280s
real 0m1.267s
real 0m1.265s
real 0m1.293s
real 0m1.267s
real 0m1.278s

HTH,
cheers -ben

On Mon, Mar 2, 2015 at 12:08 PM, Ben Coman <[hidden email]> wrote:

This is not going to get as much use before Release as I had hoped, so I refactored it to be able to easily switch between the existing and new code by making two schedulers...
* DelayMillisecondScheduler - essentially the existing code
* DelayMicrosecondScheduler - based off new primitive
which are switchable on the fly via a System Setting.

To try to make it easier to review, I've separated changes into three stages:
* SLICE.10 accumulates changes the Delay class to add some better semantics to instance variables and method renames
* SLICE.14 accumulates changes to split DelayScheduler into two subclasses for the two different schedulers (use the incoming code in the merge conflict)
* SLICE.17 accumulates changes to modify DelayMicrosecondScheduler, plus a couple of polishing things.

I've added some review notes to the issue
https://pharo.fogbugz.com/default.asp?14353

fyi, Tomorrow I start a new job at Buewaters Power Station [1] (2 x 208MW generators). They've been without an electrical engineer for three months leading up to their annual outage in five weeks, so I'm probably flat there playing catch-up for the next two months. Today (GMT+8) would be a really good time to engage me with feedback and queries. I'll try to hang out on IRC as much as possible to speed up discussion.

[1] http://www.bluewatersps.com.au/

cheers -ben

On Mon, Mar 2, 2015 at 3:09 AM, stepharo <[hidden email]> wrote:

Please help us to push ben code.

-------- Message transféré --------
Sujet : Re: [Pharo-dev] Super fast delay
Date : Wed, 25 Feb 2015 02:00:25 +0800
De : Ben Coman <[hidden email]>
Répondre à : Pharo Development List <[hidden email]>
Pour : Pharo Development List <[hidden email]>

I've updated this fix for build 40504. The following slice is read for review.
SLICE-Issue-14353-Delay-refactoring-part-2---change-from-milliseconds-to-microseconds-BenComan.6

Even if you do not feel up to reviewing the code, it would be good for a few people to merge this to get a broad sample of symptoms fixed or caused.

1. Open up Monticello and get ready to load the above slice from Pharo4Inbox repository.
2. In a workspace, do "Delay stopTimerEventLoop". Ignore the #intercyclePause: message that stream by.
3. Merge slice.
4. In a workspace, do "Delay startTimerEventLoop". The stream of #interCyclePause message should fade.
5. Operate as you normally would. Test some cases that previously caused an error.

cheers -ben

On Thu, Feb 19, 2015 at 11:17 PM, Ben Coman <[hidden email]> wrote:

On Thu, Feb 19, 2015 at 9:50 PM, Ben Coman <[hidden email]> wrote:

On Mon, Feb 16, 2015 at 4:01 PM, Holger Hans Peter Freyther <[hidden email]> wrote:
On Thu, Oct 30, 2014 at 06:32:48PM -0400, stepharo wrote:

Good Morning Ben, Stef,

> We really need people to have a look at the code of Ben.

I downloaded a Pharo-4 image today and executed:

To clarify. The fix is not yet in Pharo-4.

time pharo --nodisplay --headless ./Pharo-40490.image eval "(Delay forSeconds: 5) wait"
a Delay(5000 msecs)

real 0m1.254s
user 0m1.192s
sys 0m0.060s

So the first delay doesn't appear to wait the five seconds. I
would like to work on kqueue/epoll and remove polling and it
looks this involves code with Delay as well. I wonder if you
could provide an overview of what needs to be done and what is
done?

The pre-requisite issue 14942 is waiting for review. It really should take only 10 minutes to review...
1. In latest Pharo 4, inspect "Delay newCodeEnabled" and observe that it is "true".
2. Open the Pharo4Inbox and filter on 14942.
3. Select newest slice and <Merge>.
4. Observe the diff shows all "false" parts removed (it doesn't really get much simpler than this to review).
5. Click <merge> to finish.
6. Observe the image continues to run smoothly.
7. Report your observations on https://pharo.fogbugz.com/default.asp?14942

btw, after the cleanup done by Issue 14942, Issue 14966 can delete ten class variables from Delay.
When 14942 is integrated, can 14966 be integrated very soon after that. I am basing the change of Delay to microsecond delay off 14966.
cheers -ben

I need to refresh myself on the fix I did back in 2-Dec. Its languished while some support infrastructure was added to help the system ride-through the change.

cheers -ben

Sven Van Caekenberghe-2

Re: Super fast delay

+1

I have a lot of respect for you taking such a long path, for being patient & persistent.

> On 10 Mar 2015, at 18:06, Max Leske <[hidden email]> wrote:
>
> Great work Ben!
>
>> On 10 Mar 2015, at 17:44, Ben Coman <[hidden email]> wrote:
>>
>> This is solved with the integration of issue 14353 into build 40548.
>>
>> On an OSX > Virtualbox > LinuxMint17 with the following script...
>> for i in `seq 1 10` ;
>> do
>> (time $MYPHAROVM $MYIMAGE \
>> eval "(Delay forSeconds: 1) wait") 2>&1 > /dev/null | grep real
>> done
>>
>> Build 40547 gives...
>> real 0m1.288s
>> real 0m1.256s
>> real 0m1.258s
>> real 0m0.254s
>> real 0m0.269s
>> real 0m0.274s
>> real 0m0.260s
>> real 0m0.245s
>> real 0m0.254s
>> real 0m1.260s
>>
>> Build 40548 gives...
>> real 0m1.285s
>> real 0m1.259s
>> real 0m1.260s
>> real 0m1.260s
>> real 0m1.280s
>> real 0m1.267s
>> real 0m1.265s
>> real 0m1.293s
>> real 0m1.267s
>> real 0m1.278s
>>
>> HTH,
>> cheers -ben
>>
>>
>> On Mon, Mar 2, 2015 at 12:08 PM, Ben Coman <[hidden email]> wrote:
>>
>> This is not going to get as much use before Release as I had hoped, so I refactored it to be able to easily switch between the existing and new code by making two schedulers...
>> * DelayMillisecondScheduler - essentially the existing code
>> * DelayMicrosecondScheduler - based off new primitive
>> which are switchable on the fly via a System Setting.
>>
>> To try to make it easier to review, I've separated changes into three stages:
>> * SLICE.10 accumulates changes the Delay class to add some better semantics to instance variables and method renames
>> * SLICE.14 accumulates changes to split DelayScheduler into two subclasses for the two different schedulers (use the incoming code in the merge conflict)
>> * SLICE.17 accumulates changes to modify DelayMicrosecondScheduler, plus a couple of polishing things.
>>
>> I've added some review notes to the issue
>> https://pharo.fogbugz.com/default.asp?14353
>>
>> fyi, Tomorrow I start a new job at Buewaters Power Station [1] (2 x 208MW generators). They've been without an electrical engineer for three months leading up to their annual outage in five weeks, so I'm probably flat there playing catch-up for the next two months. Today (GMT+8) would be a really good time to engage me with feedback and queries. I'll try to hang out on IRC as much as possible to speed up discussion.
>>
>> [1] http://www.bluewatersps.com.au/
>>
>> cheers -ben
>>
>>
>>
>> On Mon, Mar 2, 2015 at 3:09 AM, stepharo <[hidden email]> wrote:
>>
>> Please help us to push ben code.
>>
>>
>>
>> -------- Message transféré --------
>> Sujet : Re: [Pharo-dev] Super fast delay
>> Date : Wed, 25 Feb 2015 02:00:25 +0800
>> De : Ben Coman <[hidden email]>
>> Répondre à : Pharo Development List <[hidden email]>
>> Pour : Pharo Development List <[hidden email]>
>>
>>
>> I've updated this fix for build 40504. The following slice is read for review.
>> SLICE-Issue-14353-Delay-refactoring-part-2---change-from-milliseconds-to-microseconds-BenComan.6
>>
>> Even if you do not feel up to reviewing the code, it would be good for a few people to merge this to get a broad sample of symptoms fixed or caused.
>>
>> 1. Open up Monticello and get ready to load the above slice from Pharo4Inbox repository.
>> 2. In a workspace, do "Delay stopTimerEventLoop". Ignore the #intercyclePause: message that stream by.
>> 3. Merge slice.
>> 4. In a workspace, do "Delay startTimerEventLoop". The stream of #interCyclePause message should fade.
>> 5. Operate as you normally would. Test some cases that previously caused an error.
>>
>> cheers -ben
>>
>> On Thu, Feb 19, 2015 at 11:17 PM, Ben Coman <[hidden email]> wrote:
>>
>>
>> On Thu, Feb 19, 2015 at 9:50 PM, Ben Coman <[hidden email]> wrote:
>>
>>
>> On Mon, Feb 16, 2015 at 4:01 PM, Holger Hans Peter Freyther <[hidden email]> wrote:
>> On Thu, Oct 30, 2014 at 06:32:48PM -0400, stepharo wrote:
>>
>> Good Morning Ben, Stef,
>>
>> > We really need people to have a look at the code of Ben.
>>
>> I downloaded a Pharo-4 image today and executed:
>>
>> To clarify. The fix is not yet in Pharo-4.
>>
>>
>> time pharo --nodisplay --headless ./Pharo-40490.image eval "(Delay forSeconds: 5) wait"
>> a Delay(5000 msecs)
>>
>> real 0m1.254s
>> user 0m1.192s
>> sys 0m0.060s
>>
>>
>> So the first delay doesn't appear to wait the five seconds. I
>> would like to work on kqueue/epoll and remove polling and it
>> looks this involves code with Delay as well. I wonder if you
>> could provide an overview of what needs to be done and what is
>> done?
>>
>> The pre-requisite issue 14942 is waiting for review. It really should take only 10 minutes to review...
>> 1. In latest Pharo 4, inspect "Delay newCodeEnabled" and observe that it is "true".
>> 2. Open the Pharo4Inbox and filter on 14942.
>> 3. Select newest slice and <Merge>.
>> 4. Observe the diff shows all "false" parts removed (it doesn't really get much simpler than this to review).
>> 5. Click <merge> to finish.
>> 6. Observe the image continues to run smoothly.
>> 7. Report your observations on https://pharo.fogbugz.com/default.asp?14942
>>
>> btw, after the cleanup done by Issue 14942, Issue 14966 can delete ten class variables from Delay.
>> When 14942 is integrated, can 14966 be integrated very soon after that. I am basing the change of Delay to microsecond delay off 14966.
>> cheers -ben
>>
>>
>>
>>
>> I need to refresh myself on the fix I did back in 2-Dec. Its languished while some support infrastructure was added to help the system ride-through the change.
>>
>> cheers -ben
>>
>>
>>
>>
>>
>

Torsten Bergmann

Re: Super fast delay

Sven wrote:
> +1
>
> I have a lot of respect for you taking such a long path, for being patient & persistent.

+100

Ben Coman

Re: Super fast delay

In reply to this post by Sven Van Caekenberghe-2

On Wed, Mar 11, 2015 at 1:28 AM, Sven Van Caekenberghe <[hidden email]> wrote:

+1

I have a lot of respect for you taking such a long path, for being patient & persistent.

Thanks. It was like a bone I just had to keep chewing until I got the marrow.

Actually the changes themselves weren't so hard. The hard part was to change-it-on-the-fly with the CI and Integration tools at arms length - which anyway led to learning more about those systems.

Future changes should be easier.

cheers -ben

> On 10 Mar 2015, at 18:06, Max Leske <[hidden email]> wrote:
>
> Great work Ben!
>
>> On 10 Mar 2015, at 17:44, Ben Coman <[hidden email]> wrote:
>>
>> This is solved with the integration of issue 14353 into build 40548.
>>
>> On an OSX > Virtualbox > LinuxMint17 with the following script...
>> for i in `seq 1 10` ;
>> do
>> (time $MYPHAROVM $MYIMAGE \
>> eval "(Delay forSeconds: 1) wait") 2>&1 > /dev/null | grep real
>> done
>>
>> Build 40547 gives...
>> real 0m1.288s
>> real 0m1.256s
>> real 0m1.258s
>> real 0m0.254s
>> real 0m0.269s
>> real 0m0.274s
>> real 0m0.260s
>> real 0m0.245s
>> real 0m0.254s
>> real 0m1.260s
>>
>> Build 40548 gives...
>> real 0m1.285s
>> real 0m1.259s
>> real 0m1.260s
>> real 0m1.260s
>> real 0m1.280s
>> real 0m1.267s
>> real 0m1.265s
>> real 0m1.293s
>> real 0m1.267s
>> real 0m1.278s
>>
>> HTH,
>> cheers -ben
>>
>>
>> On Mon, Mar 2, 2015 at 12:08 PM, Ben Coman <[hidden email]> wrote:
>>
>> This is not going to get as much use before Release as I had hoped, so I refactored it to be able to easily switch between the existing and new code by making two schedulers...
>> * DelayMillisecondScheduler - essentially the existing code
>> * DelayMicrosecondScheduler - based off new primitive
>> which are switchable on the fly via a System Setting.
>>
>> To try to make it easier to review, I've separated changes into three stages:
>> * SLICE.10 accumulates changes the Delay class to add some better semantics to instance variables and method renames
>> * SLICE.14 accumulates changes to split DelayScheduler into two subclasses for the two different schedulers (use the incoming code in the merge conflict)
>> * SLICE.17 accumulates changes to modify DelayMicrosecondScheduler, plus a couple of polishing things.
>>
>> I've added some review notes to the issue
>> https://pharo.fogbugz.com/default.asp?14353
>>
>> fyi, Tomorrow I start a new job at Buewaters Power Station [1] (2 x 208MW generators). They've been without an electrical engineer for three months leading up to their annual outage in five weeks, so I'm probably flat there playing catch-up for the next two months. Today (GMT+8) would be a really good time to engage me with feedback and queries. I'll try to hang out on IRC as much as possible to speed up discussion.
>>
>> [1] http://www.bluewatersps.com.au/
>>
>> cheers -ben
>>
>>
>>
>> On Mon, Mar 2, 2015 at 3:09 AM, stepharo <[hidden email]> wrote:
>>
>> Please help us to push ben code.
>>
>>
>>
>> -------- Message transféré --------
>> Sujet : Re: [Pharo-dev] Super fast delay
>> Date : Wed, 25 Feb 2015 02:00:25 +0800
>> De : Ben Coman <[hidden email]>
>> Répondre à : Pharo Development List <[hidden email]>
>> Pour : Pharo Development List <[hidden email]>
>>
>>
>> I've updated this fix for build 40504. The following slice is read for review.
>> SLICE-Issue-14353-Delay-refactoring-part-2---change-from-milliseconds-to-microseconds-BenComan.6
>>
>> Even if you do not feel up to reviewing the code, it would be good for a few people to merge this to get a broad sample of symptoms fixed or caused.
>>
>> 1. Open up Monticello and get ready to load the above slice from Pharo4Inbox repository.
>> 2. In a workspace, do "Delay stopTimerEventLoop". Ignore the #intercyclePause: message that stream by.
>> 3. Merge slice.
>> 4. In a workspace, do "Delay startTimerEventLoop". The stream of #interCyclePause message should fade.
>> 5. Operate as you normally would. Test some cases that previously caused an error.
>>
>> cheers -ben
>>
>> On Thu, Feb 19, 2015 at 11:17 PM, Ben Coman <[hidden email]> wrote:
>>
>>
>> On Thu, Feb 19, 2015 at 9:50 PM, Ben Coman <[hidden email]> wrote:
>>
>>
>> On Mon, Feb 16, 2015 at 4:01 PM, Holger Hans Peter Freyther <[hidden email]> wrote:
>> On Thu, Oct 30, 2014 at 06:32:48PM -0400, stepharo wrote:
>>
>> Good Morning Ben, Stef,
>>
>> > We really need people to have a look at the code of Ben.
>>
>> I downloaded a Pharo-4 image today and executed:
>>
>> To clarify. The fix is not yet in Pharo-4.
>>
>>
>> time pharo --nodisplay --headless ./Pharo-40490.image eval "(Delay forSeconds: 5) wait"
>> a Delay(5000 msecs)
>>
>> real 0m1.254s
>> user 0m1.192s
>> sys 0m0.060s
>>
>>
>> So the first delay doesn't appear to wait the five seconds. I
>> would like to work on kqueue/epoll and remove polling and it
>> looks this involves code with Delay as well. I wonder if you
>> could provide an overview of what needs to be done and what is
>> done?
>>
>> The pre-requisite issue 14942 is waiting for review. It really should take only 10 minutes to review...
>> 1. In latest Pharo 4, inspect "Delay newCodeEnabled" and observe that it is "true".
>> 2. Open the Pharo4Inbox and filter on 14942.
>> 3. Select newest slice and <Merge>.
>> 4. Observe the diff shows all "false" parts removed (it doesn't really get much simpler than this to review).
>> 5. Click <merge> to finish.
>> 6. Observe the image continues to run smoothly.
>> 7. Report your observations on https://pharo.fogbugz.com/default.asp?14942
>>
>> btw, after the cleanup done by Issue 14942, Issue 14966 can delete ten class variables from Delay.
>> When 14942 is integrated, can 14966 be integrated very soon after that. I am basing the change of Delay to microsecond delay off 14966.
>> cheers -ben
>>
>>
>>
>>
>> I need to refresh myself on the fix I did back in 2-Dec. Its languished while some support infrastructure was added to help the system ride-through the change.
>>
>> cheers -ben
>>
>>
>>
>>
>>
>