Smalltalk › Pharo › Pharo Smalltalk Users

Slower

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

15 messages Options

HilaireFernandes

Slower

Hi,

I discover this Dr. Geo Smalltalk sketch to animate is about 60% slowler
on P7 compare to P3:

| fig point comment x y random inArc tries|
"Monte-Carlo PI approximation"
fig := DrGeoCanvas new fullscreen scale: 400.
fig arcCenter: 0@0 from: 1@0 to: 0@1.
fig polygon: { 0@0. 0@1. 1@1. 1@0 }.
comment := fig texte: '' a: 0@ -0.1.
random := Random seed: Time millisecondClockValue.
tries := 500.
inArc := 0.
[1 a: tries faire: [: try |
     x := random next.
     y := random next.
     point := (fig point: x@y) small.
     (x squared + y squared) > 1
         ifTrue: [point color: Color blue ]
         ifFalse: [inArc := inArc + 1 ].
comment text: 'Tries: ', try asString, '
approx: ', (inArc * 4 / try) asFloat asString.
World doOneCycle.
] ] timeProfile

The log are enclosed to compare. The mains differences seems to be
during the world update. Years ago when porting to P3 I also see an
important time performance degradation[1] and it remained unresolved.

[1] http://forum.world.st/Slowness-question-tt4761717.html

--
Dr. Geo
http://drgeo.eu

timeToRunDrGeos.zip (7K) Download Attachment

http://drgeo.eu

Clément Béra

Re: Slower

Hi Hilaire,

Do you have to use the world or Morphic at all ?

I wrote 2 different real-time 2D games at 50fps in Pharo [1,2]. I tried using Morphic but that was crazy slow I could not even get 20fps. Instead I use direct bindings to Cairo surface and SDL2 window and I don't open the world morph at all to avoid the delays due to its cycles which are also crazy (I open Pharo in headless, then the Pharo code opens a SDL2 window and draws on it using Cairo). Then I was just careful on the number of allocations, especially closures, in between frame rendering and also on algorithms (I had 60% of time spent creating rectangle in corner: since it performs a lot of min max computation, rewriting that to fastCorner method without min max greatly improved the performance in my case). I still have frame drops from time to time but that's hardly noticeable.

If you're scared of using Cairo / SDL2 because you deploy on specific platforms like mobiles, you can still use BitBlt. The point being not to run WorldMorph cycles at all but instead manage yourself what is drawn. If possible don't use Morph at all too, it has many features that likely you don't use, slowing down your system and wasting battery on mobiles for nothing.

[1] https://github.com/clementbera/wizard-battle-arena

[2] https://github.com/clementbera/SpiderInvasion

On Wed, Apr 4, 2018, 15:49 Hilaire <[hidden email]> wrote:

Hi,

I discover this Dr. Geo Smalltalk sketch to animate is about 60% slowler
on P7 compare to P3:

| fig point comment x y random inArc tries|
"Monte-Carlo PI approximation"
fig := DrGeoCanvas new fullscreen scale: 400.
fig arcCenter: 0@0 from: 1@0 to: 0@1.
fig polygon: { 0@0. 0@1. 1@1. 1@0 }.
comment := fig texte: '' a: 0@ -0.1.
random := Random seed: Time millisecondClockValue.
tries := 500.
inArc := 0.
[1 a: tries faire: [: try |
     x := random next.
     y := random next.
     point := (fig point: x@y) small.
     (x squared + y squared) > 1
         ifTrue: [point color: Color blue ]
         ifFalse: [inArc := inArc + 1 ].
comment text: 'Tries: ', try asString, '
approx: ', (inArc * 4 / try) asFloat asString.
World doOneCycle.
] ] timeProfile

The log are enclosed to compare. The mains differences seems to be
during the world update. Years ago when porting to P3 I also see an
important time performance degradation[1] and it remained unresolved.

[1] http://forum.world.st/Slowness-question-tt4761717.html

--
Dr. Geo
http://drgeo.eu

HilaireFernandes

Re: Slower

Hi Clement,

I know about your SDL games demo. But DrGeo is really Morphic based, so
yes it is mandatory. I suspect there is may be something going on
between Cairo/Athens/Morph. For regular mouse use of DrGeo it is just
fine. It is when pusing to the limite with Smalltalk sketch and
animating the resulting sktech.

Le 04/04/2018 à 17:33, Clément Bera a écrit :
> Hi Hilaire,
>
> Do you have to use the world or Morphic at all ?
>

--
Dr. Geo
http://drgeo.eu

http://drgeo.eu

Stephane Ducasse-3

Re: Slower

In reply to this post by Clément Béra

Clement

if it would be nice to have the fastCorner and friends added to rectangle.

On Wed, Apr 4, 2018 at 5:33 PM, Clément Bera <[hidden email]> wrote:

> Hi Hilaire,
>
> Do you have to use the world or Morphic at all ?
>
> I wrote 2 different real-time 2D games at 50fps in Pharo [1,2]. I tried
> using Morphic but that was crazy slow I could not even get 20fps. Instead I
> use direct bindings to Cairo surface and SDL2 window and I don't open the
> world morph at all to avoid the delays due to its cycles which are also
> crazy (I open Pharo in headless, then the Pharo code opens a SDL2 window and
> draws on it using Cairo). Then I was just careful on the number of
> allocations, especially closures, in between frame rendering and also on
> algorithms (I had 60% of time spent creating rectangle in corner: since it
> performs a lot of min max computation, rewriting that to fastCorner method
> without min max greatly improved the performance in my case). I still have
> frame drops from time to time but that's hardly noticeable.
>
> If you're scared of using Cairo / SDL2 because you deploy on specific
> platforms like mobiles, you can still use BitBlt. The point being not to run
> WorldMorph cycles at all but instead manage yourself what is drawn. If
> possible don't use Morph at all too, it has many features that likely you
> don't use, slowing down your system and wasting battery on mobiles for
> nothing.
>
> [1] https://github.com/clementbera/wizard-battle-arena
> [2] https://github.com/clementbera/SpiderInvasion
>
>
> On Wed, Apr 4, 2018, 15:49 Hilaire <[hidden email]> wrote:
>>
>> Hi,
>>
>> I discover this Dr. Geo Smalltalk sketch to animate is about 60% slowler
>> on P7 compare to P3:
>>
>> | fig point comment x y random inArc tries|
>> "Monte-Carlo PI approximation"
>> fig := DrGeoCanvas new fullscreen scale: 400.
>> fig arcCenter: 0@0 from: 1@0 to: 0@1.
>> fig polygon: { 0@0. 0@1. 1@1. 1@0 }.
>> comment := fig texte: '' a: 0@ -0.1.
>> random := Random seed: Time millisecondClockValue.
>> tries := 500.
>> inArc := 0.
>> [1 a: tries faire: [: try |
>> x := random next.
>> y := random next.
>> point := (fig point: x@y) small.
>> (x squared + y squared) > 1
>> ifTrue: [point color: Color blue ]
>> ifFalse: [inArc := inArc + 1 ].
>> comment text: 'Tries: ', try asString, '
>> approx: ', (inArc * 4 / try) asFloat asString.
>> World doOneCycle.
>> ] ] timeProfile
>>
>> The log are enclosed to compare. The mains differences seems to be
>> during the world update. Years ago when porting to P3 I also see an
>> important time performance degradation[1] and it remained unresolved.
>>
>>
>> [1] http://forum.world.st/Slowness-question-tt4761717.html
>>
>>
>>
>>
>> --
>> Dr. Geo
>> http://drgeo.eu
>>
>

Stephane Ducasse-3

Re: Slower

In reply to this post by HilaireFernandes

Hilaire

do you want to see an animation?

Stef

On Wed, Apr 4, 2018 at 3:49 PM, Hilaire <[hidden email]> wrote:

> Hi,
>
> I discover this Dr. Geo Smalltalk sketch to animate is about 60% slowler on
> P7 compare to P3:
>
> | fig point comment x y random inArc tries|
> "Monte-Carlo PI approximation"
> fig := DrGeoCanvas new fullscreen scale: 400.
> fig arcCenter: 0@0 from: 1@0 to: 0@1.
> fig polygon: { 0@0. 0@1. 1@1. 1@0 }.
> comment := fig texte: '' a: 0@ -0.1.
> random := Random seed: Time millisecondClockValue.
> tries := 500.
> inArc := 0.
> [1 a: tries faire: [: try |
> x := random next.
> y := random next.
> point := (fig point: x@y) small.
> (x squared + y squared) > 1
> ifTrue: [point color: Color blue ]
> ifFalse: [inArc := inArc + 1 ].
> comment text: 'Tries: ', try asString, '
> approx: ', (inArc * 4 / try) asFloat asString.
> World doOneCycle.
> ] ] timeProfile
>
> The log are enclosed to compare. The mains differences seems to be during
> the world update. Years ago when porting to P3 I also see an important time
> performance degradation[1] and it remained unresolved.
>
>
> [1] http://forum.world.st/Slowness-question-tt4761717.html
>
>
>
>
> --
> Dr. Geo
> http://drgeo.eu
>

HilaireFernandes

Re: Slower

It is already animated :)
https://twitter.com/GNUDrGeo/status/981583820037160961

But canvas get slow when I push to 500 montecarlo iterations, for example.

Le 04/04/2018 à 19:03, Stephane Ducasse a écrit :
> Hilaire
>
> do you want to see an animation?
>
> Stef

--
Dr. Geo
http://drgeo.eu

http://drgeo.eu

Thierry Goubier

Re: Slower

Le 04/04/2018 à 19:31, Hilaire a écrit :
> It is already animated :)
> https://twitter.com/GNUDrGeo/status/981583820037160961
>
> But canvas get slow when I push to 500 montecarlo iterations, for example.

Can you profile a refresh / a redraw?

We've seen many times Morphic being qualified as slow, and the culprit
were very badly programmed widgets.

Thierry

>
> Le 04/04/2018 à 19:03, Stephane Ducasse a écrit :
>> Hilaire
>>
>> do you want to see an animation?
>>
>> Stef
>

HilaireFernandes

Re: Slower

You mean one iteration?

Hilaire

Le 04/04/2018 à 20:05, Thierry Goubier a écrit :
>
> Can you profile a refresh / a redraw?
>
> We've seen many times Morphic being qualified as slow, and the culprit
> were very badly programmed widgets.
>
> Thierry

--
Dr. Geo
http://drgeo.eu

http://drgeo.eu

HilaireFernandes

Re: Slower

In reply to this post by Thierry Goubier

Looking at the profile, Athens spend time on some of my widgets:

1. LabelMorph with a workaround in the draw method as:

drawOnAthensCanvas: aCanvas
"Work around for the conflicting size font problem"
     aCanvas pathTransform restoreAfter: [
     aCanvas pathTransform scaleBy: 1.00001.
         "draw text here"
         super drawOnAthensCanvas: aCanvas].

Do we still need to do that, may be not.

2. TextMorph with another workaround:

drawOnAthensCanvas: aCanvas
     | cached |
     myForm ifNil: [myForm := self imageForm].
     cached := aCanvas cacheAt: myForm ifAbsentPut: [
         myForm asAthensPaintOn: aCanvas.    ].
     aCanvas setPaint: cached.
     aCanvas paintTransform restoreAfter: [
         aCanvas paintTransform translateBy: self fullBounds origin
truncated.
         aCanvas drawShape: self fullBounds].

It should be faster but it is slower.

3. PointMorph, painting as round shape is slow, painting point as square
is way faster.

It reduces by 50% the time to execution. Need to check if this trick #1
and #2 are still needed at P7 time.

Hilaire

Le 04/04/2018 à 22:31, Hilaire a écrit :
> From the profile, there are a lot of activities with Athens. I can't
> say if it is normal... Someone with good knowledge could dig on it. I
> can provide the environment to test.

--
Dr. Geo
http://drgeo.eu

http://drgeo.eu

HilaireFernandes

Re: Slower

After some more investigation, I think it is not the greated bottleneck.

When I render points not as discs but as Square, Athens is happy. I
guess the Cairo way of doing this is very slow because its seems Cairo
does not come with dedicated disc rendering code, it must be render with
portion of arc, as far as I remember.

If I prevent to render empty text label attached with each point, Athens
is even happier. Text font rendering through Athens seems to be slow.

Hilaire

Le 04/04/2018 à 23:05, Hilaire a écrit :
> It reduces by 50% the time to execution. Need to check if this trick
> #1 and #2 are still needed at P7 time.

--
Dr. Geo
http://drgeo.eu

http://drgeo.eu

Stephane Ducasse-3

Re: Slower

if I remember correctly that Cairo does not support arc and that igor
was doing point interpolation to support it.

stef

On Thu, Apr 5, 2018 at 11:33 AM, Hilaire <[hidden email]> wrote:

> After some more investigation, I think it is not the greated bottleneck.
>
> When I render points not as discs but as Square, Athens is happy. I guess
> the Cairo way of doing this is very slow because its seems Cairo does not
> come with dedicated disc rendering code, it must be render with portion of
> arc, as far as I remember.
>
> If I prevent to render empty text label attached with each point, Athens is
> even happier. Text font rendering through Athens seems to be slow.
>
> Hilaire
>
>
> Le 04/04/2018 à 23:05, Hilaire a écrit :
>>
>> It reduces by 50% the time to execution. Need to check if this trick #1
>> and #2 are still needed at P7 time.
>
>
> --
> Dr. Geo
> http://drgeo.eu
>
>
>

Henrik Sperre Johansen

Re: Slower

In reply to this post by HilaireFernandes

HilaireFernandes wrote

> After some more investigation, I think it is not the greated bottleneck.
>
> When I render points not as discs but as Square, Athens is happy. I
> guess the Cairo way of doing this is very slow because its seems Cairo
> does not come with dedicated disc rendering code, it must be render with
> portion of arc, as far as I remember.
>
> If I prevent to render empty text label attached with each point, Athens
> is even happier. Text font rendering through Athens seems to be slow.
>
> Hilaire
>
>
> Le 04/04/2018 à 23:05, Hilaire a écrit :
>> It reduces by 50% the time to execution. Need to check if this trick
>> #1 and #2 are still needed at P7 time.
>
> --
> Dr. Geo
> http://drgeo.eu

My notes after looking at the profile for a short while, if anyone feels the
urge to optimize;
UFFI:

> 8.8% {11475ms}
> CairoFreetypeFontRenderer>>convertString:len:ofFont:toGlyphs:numGlyphs:x:y:
> | 4.7% {6098ms} ExternalAddress>>packToArity:
> | 4.5% {5789ms} ExternalAddress>>pointerAutoRelease
> | 2.6% {3439ms} ExternalAddress>>unpackFromArity:

The lifespan of arguments that need arity packing/unpacking is well known,
rewriting to use explicit free should lessen the overhead somewhat.

CAIRO:

> 26.6% {34593ms} CairoFreetypeFontRenderer>>glyphsOf:from:to:
> | 12.2% {15842ms} CairoGlyphsArray class>>new:

With this kind of overhead just to create the array to hold results, it
might be worthwhile to use a buffer array (of sufficient size) for the
primitive, and copyFrom:to: to return the actual glyphs...

DRGEO:

> 20.9% {27116ms} DrGPointMorph>>drawOnAthensCanvas:
> |16.7% {21720ms} AthensCairoCanvas(AthensCanvas)>>createPath:

Storing the path in DrGPointMorph, rather than recreating for each draw:,
should save alot of time.

> 7.7% {9962ms} DrGTextMorph>>drawOnAthensCanvas:
> | 7.7% {9962ms} Form>>asAthensPaintOn:

Same thing here, only storing the paint, rather than converting from form
each draw.

Cheers,
Henry

--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

philippeback

Re: Slower

On Thu, Apr 5, 2018, 16:09 Henrik Sperre Johansen <[hidden email]> wrote:

HilaireFernandes wrote
> After some more investigation, I think it is not the greated bottleneck.
>
> When I render points not as discs but as Square, Athens is happy. I
> guess the Cairo way of doing this is very slow because its seems Cairo
> does not come with dedicated disc rendering code, it must be render with
> portion of arc, as far as I remember.
>
> If I prevent to render empty text label attached with each point, Athens
> is even happier. Text font rendering through Athens seems to be slow.
>
> Hilaire
>
>
> Le 04/04/2018 à 23:05, Hilaire a écrit :
>> It reduces by 50% the time to execution. Need to check if this trick
>> #1 and #2 are still needed at P7 time.
>
> --
> Dr. Geo
> http://drgeo.eu

My notes after looking at the profile for a short while, if anyone feels the
urge to optimize;
UFFI:

> 8.8% {11475ms}
> CairoFreetypeFontRenderer>>convertString:len:ofFont:toGlyphs:numGlyphs:x:y:
> | 4.7% {6098ms} ExternalAddress>>packToArity:
> | 4.5% {5789ms} ExternalAddress>>pointerAutoRelease
> | 2.6% {3439ms} ExternalAddress>>unpackFromArity:

The lifespan of arguments that need arity packing/unpacking is well known,
rewriting to use explicit free should lessen the overhead somewhat.

CAIRO:

> 26.6% {34593ms} CairoFreetypeFontRenderer>>glyphsOf:from:to:
> | 12.2% {15842ms} CairoGlyphsArray class>>new:

With this kind of overhead just to create the array to hold results, it
might be worthwhile to use a buffer array (of sufficient size) for the
primitive, and copyFrom:to: to return the actual glyphs...

DRGEO:

> 20.9% {27116ms} DrGPointMorph>>drawOnAthensCanvas:
> |16.7% {21720ms} AthensCairoCanvas(AthensCanvas)>>createPath:

Storing the path in DrGPointMorph, rather than recreating for each draw:,
should save alot of time.

> 7.7% {9962ms} DrGTextMorph>>drawOnAthensCanvas:
> | 7.7% {9962ms} Form>>asAthensPaintOn:

Same thing here, only storing the paint, rather than converting from form
each draw.

This would also be beneficial to Roassal when zooming in and out of vusualization with a ton of labels.

Phil

Cheers,
Henry

--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

HilaireFernandes

Re: Slower

In reply to this post by Henrik Sperre Johansen

Le 05/04/2018 à 16:09, Henrik Sperre Johansen a écrit :
>
> DRGEO:
>
>> 20.9% {27116ms} DrGPointMorph>>drawOnAthensCanvas:
>> |16.7% {21720ms} AthensCairoCanvas(AthensCanvas)>>createPath:
> Storing the path in DrGPointMorph, rather than recreating for each draw:,
> should save alot of time.

Indeed should work nicely for point with round shape. For rectangle
shape it is not necessary, this what I did in the demo.
>> 7.7% {9962ms} DrGTextMorph>>drawOnAthensCanvas:
>> | 7.7% {9962ms} Form>>asAthensPaintOn:
> Same thing here, only storing the paint, rather than converting from form
> each draw.
In my demo, the text changes at each iteration. Useful for static
geometric item label thought. But I already optimized this by discarding
empty label

The cache suggestions will be find for static surface, it does not apply
always though.
In the scenario where Dr.Geo is used for animated demonstration, I
already found a few optimization for Dr.Geo itself without touching to
the Athens layer.

Thanks for your review

Hilaire

--
Dr. Geo
http://drgeo.eu

http://drgeo.eu

Stephane Ducasse-3

Re: Slower

In reply to this post by Henrik Sperre Johansen

Thanks for your analysis.
Should we open a enhancement issue for UFFI?

Stf

On Thu, Apr 5, 2018 at 4:09 PM, Henrik Sperre Johansen
<[hidden email]> wrote:

> HilaireFernandes wrote
>> After some more investigation, I think it is not the greated bottleneck.
>>
>> When I render points not as discs but as Square, Athens is happy. I
>> guess the Cairo way of doing this is very slow because its seems Cairo
>> does not come with dedicated disc rendering code, it must be render with
>> portion of arc, as far as I remember.
>>
>> If I prevent to render empty text label attached with each point, Athens
>> is even happier. Text font rendering through Athens seems to be slow.
>>
>> Hilaire
>>
>>
>> Le 04/04/2018 à 23:05, Hilaire a écrit :
>>> It reduces by 50% the time to execution. Need to check if this trick
>>> #1 and #2 are still needed at P7 time.
>>
>> --
>> Dr. Geo
>> http://drgeo.eu
>
> My notes after looking at the profile for a short while, if anyone feels the
> urge to optimize;
> UFFI:
>
>> 8.8% {11475ms}
>> CairoFreetypeFontRenderer>>convertString:len:ofFont:toGlyphs:numGlyphs:x:y:
>> | 4.7% {6098ms} ExternalAddress>>packToArity:
>> | 4.5% {5789ms} ExternalAddress>>pointerAutoRelease
>> | 2.6% {3439ms} ExternalAddress>>unpackFromArity:
>
> The lifespan of arguments that need arity packing/unpacking is well known,
> rewriting to use explicit free should lessen the overhead somewhat.
>
> CAIRO:
>
>> 26.6% {34593ms} CairoFreetypeFontRenderer>>glyphsOf:from:to:
>> | 12.2% {15842ms} CairoGlyphsArray class>>new:
>
> With this kind of overhead just to create the array to hold results, it
> might be worthwhile to use a buffer array (of sufficient size) for the
> primitive, and copyFrom:to: to return the actual glyphs...
>
> DRGEO:
>
>> 20.9% {27116ms} DrGPointMorph>>drawOnAthensCanvas:
>> |16.7% {21720ms} AthensCairoCanvas(AthensCanvas)>>createPath:
>
> Storing the path in DrGPointMorph, rather than recreating for each draw:,
> should save alot of time.
>
>
>> 7.7% {9962ms} DrGTextMorph>>drawOnAthensCanvas:
>> | 7.7% {9962ms} Form>>asAthensPaintOn:
>
> Same thing here, only storing the paint, rather than converting from form
> each draw.
>
> Cheers,
> Henry
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>