Re: Squeak and Pharo speed differences

Hi all.

 

 

Squeak 5.3: 

  Time millisecondsToRun: [ 100000 factorial  ] 6250

 

Pharo 8:

  Time millisecondsToRun: [ 100000 factorial  ] 7736

 

Why the difference?

 

Squeak 5.3 release notes describe arithmetic improvements.  Nice.  I crunch very big numbers, and these improvements therefore have value.  Why would they not be included in OSVM (forked or not) and the basic class-set for both Squeak and Pharo?

 

Playing with Squeak 5.3, I’ve noticed that the GUI is snappier.  Browser ergonomics are better too (for me at least), but that can be fixed/tuned in either environ to suit the developer.  (Still that’s some work I prefer not to do.)  Pharo GUIs are now generally slower, except for the Launcher, which is delightfully quick because it is written in Spec2.  I presume that all Pharo GUIs will eventually (ETA?) be written in Spec2 and that Pharo will then be quick in all its GUIs.  The obvious question is:  Will Squeak be improving GUI look/behavior and speed with Spec2?  If not, can I load Spec2 into Squeak so that I can do new GUI work there?

 

Both Squeak and Pharo have slow text selection.  Pick any word in any pane, and double click it to select it.  When I do this, I sense a 75 to 100 ms latency between the end of the double click and the selection highlight appearing on the word.   I thought I’d entered a wormhole.  So I did the same experiment in VW 8.3.2, VS Code, and Notepad, and all three showed undetectable latencies.   This matters to me.  I’m trying to port from VW to Pharo or Squeak (for a really long time now), and can’t push myself past the text-selection delay problem.  Can text-selection speed be improved to the level of VW’s?   Can someone sketch the algo used and/or point me to the right class/methods. 

 

The Squeak debugging experience step-to-step is much quicker.  The latencies in Pharo after button- release are very long.  I estimate 100 to 150 ms.   That’s too long for me to work productively.  I lose my mental thread with many of those delays, and have to restart the thought.  It’s a serious problem, caused mostly by acclimation to no detectable latency for many years (Dolphin and VW have quick GUIs).  Is speeding up the Pharo debugger with Spec2 a priority?  I can’t think of a better GUI-related priority for Pharo.

 

 

Not speed-related:

 

-  How can I load additional fonts into Squeak?  Pharo does this with the font dialog’s Update button.

 

- Where in the Squeak and Pharo images can I change mouse-selection behavior to be leading-edge?  Some of the Squeak panes have this; others don’t.  I want leading-edge action in all panes, and wish the feature were in Preferences/Settings.

 

 

 

Shaping

 

 

 

 

 

 

 

 

 

There is an issue about incorporating Squeak arithmetic changes in Pharo:

https://github.com/pharo-project/pharo/issues/3322

 

I start to understand what could be done and could not find time to do the changes.

You are welcome if you want to help.

 

 

Arithmetic speed is important if most of one’s work is math and modeling.

 

I want to help, but need to port first from VW, and I’m trying to choose Squeak or Pharo.  Both have speed problems.  Squeak has fewer, but Pharo could be much faster with broad use of Spec2.

 

Would reintegrating Squeak and Pharo development make more sense?

 

This change would effectively create more devs willing to work on any problem.  This change would also prevent fracturing of feature-sets across the two Smalltalks from happening in the first place.

 

Why can’t the OSVM be a single, unforked, maxed-out VM with all the best and fastest features working in Squeak and Pharo?   Why did the split happen?  It looks like a bad use of energy in a community that is small and needs to use its human resources efficiently.

 

Squeak and Pharo GUI styles are different.  So be it.  Can’t the GUI frameworks and conventions be separated in the same image, and configured as desired in GUI sections of Settings?

 

 

Shaping 

 

 

On Fri, May 15, 2020 at 12:48 PM Shaping <[hidden email]> wrote:

Hi all.

 

 

Squeak 5.3: 

  Time millisecondsToRun: [ 100000 factorial  ] 6250

 

Pharo 8:

  Time millisecondsToRun: [ 100000 factorial  ] 7736

 

Why the difference?

 

Squeak 5.3 release notes describe arithmetic improvements.  Nice.  I crunch very big numbers, and these improvements therefore have value.  Why would they not be included in OSVM (forked or not) and the basic class-set for both Squeak and Pharo?

 

Playing with Squeak 5.3, I’ve noticed that the GUI is snappier.  Browser ergonomics are better too (for me at least), but that can be fixed/tuned in either environ to suit the developer.  (Still that’s some work I prefer not to do.)  Pharo GUIs are now generally slower, except for the Launcher, which is delightfully quick because it is written in Spec2.  I presume that all Pharo GUIs will eventually (ETA?) be written in Spec2 and that Pharo will then be quick in all its GUIs.  The obvious question is:  Will Squeak be improving GUI look/behavior and speed with Spec2?  If not, can I load Spec2 into Squeak so that I can do new GUI work there?

 

Both Squeak and Pharo have slow text selection.  Pick any word in any pane, and double click it to select it.  When I do this, I sense a 75 to 100 ms latency between the end of the double click and the selection highlight appearing on the word.   I thought I’d entered a wormhole.  So I did the same experiment in VW 8.3.2, VS Code, and Notepad, and all three showed undetectable latencies.   This matters to me.  I’m trying to port from VW to Pharo or Squeak (for a really long time now), and can’t push myself past the text-selection delay problem.  Can text-selection speed be improved to the level of VW’s?   Can someone sketch the algo used and/or point me to the right class/methods. 

 

The Squeak debugging experience step-to-step is much quicker.  The latencies in Pharo after button- release are very long.  I estimate 100 to 150 ms.   That’s too long for me to work productively.  I lose my mental thread with many of those delays, and have to restart the thought.  It’s a serious problem, caused mostly by acclimation to no detectable latency for many years (Dolphin and VW have quick GUIs).  Is speeding up the Pharo debugger with Spec2 a priority?  I can’t think of a better GUI-related priority for Pharo.

 

 

Not speed-related:

 

-  How can I load additional fonts into Squeak?  Pharo does this with the font dialog’s Update button.

 

- Where in the Squeak and Pharo images can I change mouse-selection behavior to be leading-edge?  Some of the Squeak panes have this; others don’t.  I want leading-edge action in all panes, and wish the feature were in Preferences/Settings.

 

 

 

Shaping

 

 

 

 

 

 

 

 

 

--

Serge Stinckwic

​h​

https://twitter.com/SergeStinckwich

​

Squeak 5.3:  

  Time millisecondsToRun: [ 100000 factorial  ] 6250

Pharo 8:

  Time millisecondsToRun: [ 100000 factorial  ] 7736

Why the difference?

I have no idea. But I have to say that IN MY MACHINE: 

Squeak 5.3, just downloade: 

 Time millisecondsToRun: [ 100000 factorial ].  6289

Pharo (9, regular VM): 

In general , since VM is the same, if changes are in VM they are already in Pharo.

I don’t know about Squeak, this is not the appropriate place to ask Squeak questions. 

Where else would we discuss both?  On the Squeak list?  Would mentioning Pharo there also be inappropriate?  Is there a list where both a discussed?  I’m still discussing some Squeak issues with Robert in the context of parallelization of the VM.  That doesn’t seem to be a problem.  He even suggested that I work on the VM in Squeak, which I might do.  So he mentioned Squeak; that seems harmless. 

I don’t understand the split.  It looks silly.  Maybe someone can explain the split in terms of technical/architectural advantages, if any exist.

But yes, Pharo is in a battle to improve its GUI (we are basically rewriting all tools with Spec2, but even that some times is not enough since Morphic has become bloated, so our fight for performant tools is constant.

Pharo 9 will replace all glamour based tools (Playground, inspector and debugger), plus some more old tools, and all will improve there I think (GTTools are cool, but Glamour was slow).

The GT stuff is pretty good even if slow.  Do you mean that the same GT GUIs will be re-implemented in Spec2 for greater speed, or will there also be other changes to those GUIs?

I don’t know… I’m sure is possible, but someone has to do it :)

What I can tell you is that text model/operation is a big concern for us... 

Yes, it seems very important.  It’s the only thing stopping my port.

Yes, it is a priority, but it is still a WIP.

Part of this problems has nothing to do with GUI… thing is even if “debugger” is same concept, our debugger and the old debugger (which squeak continued) have a complete different machinery behind… still, yes we are working. 

You’ll have to ask in squeak list, the sis not the appropriate place for that :)

I do not understand what that is. 

It’s the behavior I notice first in any GUI interaction.

Leading-edge mouse event == button down

Trailing-edge mouse event == button up. 

So I want all mouse actions to be on the button-down event.  It’s already done in some places, but the lack of uniformity is a speed problem. 

Still, I guess the right answer would be: if it is not there, being (both) open source projects that are sustained by communities, and being you part of the community, I think it would be a nice contribution for everybody if you absolute need this and you invest some time on doing it. 

It would not be something that needs development.  I’m looking for the spot in the code to make the change.  It’s very simple.  I figure someone knows it because they’ve tweaked it already.  That would save some time.  I think I made the change myself in an older Pharo.  I forgot where I did it.

Cheers,

Shaping

Both Squeak and Pharo show the same delay for text selection latency.   The architecture difference is not likely causing that. 

How do we index or look up the word rectangle to render?   I’m think that is more likely the cause.  Is a map created at method compile time and updated  after text is moved during edits?

 

 Where is VisualWorks significantly faster than either Squeak or Pharo?  

 

VW 8.3.2 faster:

 

1. Text selection. 

 

2. Repeat-key rate in VW is smoother (not perfect; I see a few pauses).  Pharo’s repeat-key rate is the same or a little slower, there are more pauses, and distribution of those pause-times is slightly wider for Pharo 9, as if event flow isn’t as smooth as it could be (because text/cursor rendering is a not efficient?).  This is a minor issue, not a practical problem.  I did the test in a workspace in both cases.

 

 

Pharo 9 same or faster:

 

Everything else in the GUI, like window openings/closings, menu openings/closings work at nearly the same speed, or Pharo 9 is faster.

 

Opening a system browser in VW 8.3.2 and Pharo 9 takes about the same time.  If you scrutinize, you can see that Pharo system browser open times are often about 2/3 to 4/5 of the VW times.  This action is never faster in VW. 

 

Popup menus in Pharo 9 are noticeably faster than those in VW 8.3.2.   Instant--delightful.

 

 

Specifically which VisualWorks VM or lower level facilities are much faster than the Cog VM?  Do you have benchmarks?

 

No, I don’t, but I find the subject interesting, and would like to pursue it.  I’m trying to get some pressing work done in VW (as I contemplate jumping ship to Pharo/Squeak).  It’s not a good time for excursions, but here I am playing with Squeak/Pharo, anyway.  I want to dig deeper at some future date.

 

Do you have a specific procedure you like to use when benchmarking the VW VM? 

Any VM.  Express the benchmark as a block.  If the benchmark is not trying to measure JIT and/or GC overhead then before the block is run make sure to put the vm in some initialized state wrt hitting and/or GC, eg by voiding the JIT code cache,

How is the JIT code cache cleared?

and/or forcing a scavenge or a global GC.  Then run the block twice, reporting it’s second iteration, to ensure all code is JITted.

Okay, so the above procedure tests execution-engine efficiency apart from JIT and GC efficiency.

If attempting to measure JIT and/or GC overhead then do the same wet getting the vm to some baseline consistent initial state

Baseline state:  the only thing that comes to mind here is Collect All Garbage.

and then ensure, through the relevant introspection primitives,

What are these?  What state features am I introspecting after the test?  Sizes of heap subspaces?  I can do Time microsecondsToRun: on the blocks.

that after the benchmark has run the events desired to be benchmarked have actually taken place.

I’m thinking most checks on state will involve running more Smalltalk, not just primitives.

If a micobenchmark then ensure that eg loop, block invocation, arithmetic, overheads are either minimised wrt the code being benchmarked or subtracted from the code being benchmarked.

Okay.

i.e. make sure the benchmark is repeatable (benchmark an initial used state). make sure the benchmark measures what is intended to be benchmarked and not some overhead.

Right.  I don’t see how to guarantee some known starting state except to collect all garbage.

Shaping

Both Squeak and Pharo show the same delay for text selection latency.   The architecture difference is not likely causing that. 

 How do we index or look up the word rectangle to render?   I’m think that is more likely the cause.  Is a map created at method compile time and updated  after text is moved during edits?

My understanding is that damage rectangles are retrieved,

Right, but this is the potentially slow part—the retrieving or perhaps more specifically mapping a point to a rectangle containing a contiguous sequence of non-whitespace character (a word).

combined to produce a smaller (non-overlapping?) set, and that the entire morph tree is asked to render within these damage rectangles.  You can read the gods for yourself.

It’ll be a while.

….

I just tried some new experiments.  I should have thought of these earlier.  Character insertion and cursoring in any direction by one character have the same latency.  Collecting the damage rectangle at the cursor position and around the selected word are both taking about the same time as far as I can tell with my eye, and this time is longer than in VW or any Windows app.   But VW doesn’t use the Windows message queue directly.  All incoming Windows events are converted to Smalltalk equivalents and are queued on the Smalltalk side.  And it works well.   Why not mimic that pattern to get the extra speed?  Does something in Squeak/Pharo architecture prevent us from doing that?

How do we set a multi-process time profiler running so that we don’t need to eval blocks to get tallies.  I just want to use the editor and watch method hit distribution.  I see the Time profiler window; it seems to need a code snippet to work.

 

 

How is the JIT code cache cleared?

Dialect dependent.  In Squeak/Pharo/Cuis IIRC Smalltalk voidCogVMState.

Okay.

 Can’t remember how it’s done in VW.

CompiledMethod allInstancesWeakly do: [:compiledMethod | compiledMethod flushCachedVMCode]

 

Baseline state:  the only thing that comes to mind here is Collect All Garbage.

There’s also Smalltalk garbageCollectMost which just runs a scavenge.  IIRC someInstance has a side effect of running a scavenge in VW.

Okay.

 

and then ensure, through the relevant introspection primitives,

 

What are these?  What state features am I introspecting after the test?  Sizes of heap subspaces?  I can do Time microsecondsToRun: on the blocks.

In Squeak/Pharo/Cuis see Smalltalk vmParameterAt: or Smalltalk vm parameterAt: and senders.

Okay.  I see this list:

parameterAt: parameterIndex

                "parameterIndex is a positive integer corresponding to one of the VM's internal

                parameter/metric registers.  Answer with the current value of that register.

                Fail if parameterIndex has no corresponding register.

                VM parameters are numbered as follows:

                1              end (v3)/size(Spur) of old-space (0-based, read-only)

                2              end (v3)/size(Spur) of young/new-space (read-only)

                3              end (v3)/size(Spur) of heap (read-only)

                4              nil (was allocationCount (read-only))

                5              nil (was allocations between GCs (read-write)

                6              survivor count tenuring threshold (read-write)

                7              full GCs since startup (read-only)

                8              total milliseconds in full GCs since startup (read-only)

                9              incremental GCs (SqueakV3) or scavenges (Spur) since startup (read-only)

                10           total milliseconds in incremental GCs (SqueakV3) or scavenges (Spur) since startup (read-only)

                11           tenures of surving objects since startup (read-only)

                12-20 were specific to ikp's JITTER VM, now 12-19 are open for use

                20           utc microseconds at VM start-up (actually at time initialization, which precedes image load).

                21           root table size (read-only)

                22           root table overflows since startup (read-only)

                23           bytes of extra memory to reserve for VM buffers, plugins, etc (stored

                in image file header).

                24           memory threshold above which shrinking object memory (rw)

                25           memory headroom when growing object memory (rw)

                26           interruptChecksEveryNms - force an ioProcessEvents every N milliseconds             (rw) 27  number of times mark loop iterated for current IGC/FGC (read-only)              includes ALL marking

                28           number of times sweep loop iterated for current IGC/FGC (read-only)

                29           number of times make forward loop iterated for current IGC/FGC             (read-only) 30    number of times compact move loop iterated for current    IGC/FGC (read-only)

                31           number of grow memory requests (read-only)

                32           number of shrink memory requests (read-only)

                33           number of root table entries used for current IGC/FGC (read-only)

                34           number of allocations done before current IGC/FGC (read-only)

                35           number of survivor objects after current IGC/FGC (read-only)

                36           millisecond clock when current IGC/FGC completed (read-only)

                37           number of marked objects for Roots of the world, not including Root       Table entries for current IGC/FGC (read-only)

                38           milliseconds taken by current IGC (read-only)

                39           Number of finalization signals for Weak Objects pending when current   IGC/FGC completed (read-only)

                40           BytesPerOop for this image

                41           imageFormatVersion for the VM

                42           number of stack pages in use

                43           desired number of stack pages (stored in image file header, max 65535)

                44           size of eden, in bytes

                45           desired size of eden, in bytes (stored in image file header)

                46           machine code zone size, in bytes (Cog only; otherwise nil)

                47           desired machine code zone size (stored in image file header; Cog only;    otherwise nil)

                48           various header flags. See getCogVMFlags.

                49           max size the image promises to grow the external semaphore table to (0                sets to default, which is 256 as of writing)

                50-51 nil; reserved for VM parameters that persist in the image (such as eden above)

                52           root table capacity

                53           number of segments (Spur only; otherwise nil)

                54           total size of free old space (Spur only, otherwise nil)

                55           ratio of growth and image size at or above which a GC will be performed               post scavenge

                56           number of process switches since startup (read-only)

                57           number of ioProcessEvents calls since startup (read-only)

                58           number of ForceInterruptCheck calls since startup (read-only)

                59           number of check event calls since startup (read-only)

                60           number of stack page overflows since startup (read-only)

                61           number of stack page divorces since startup (read-only) 62           compiled code compactions since startup (read-only; Cog only; otherwise nil)

                63           total milliseconds in compiled code compactions since startup    (read-only; Cog only; otherwise nil)

                64           the number of methods that currently have jitted machine-code

                65           whether the VM supports a certain feature, MULTIPLE_BYTECODE_SETS is bit 0, IMMTABILITY is bit 1

                66           the byte size of a stack page

                67           the max allowed size of old space (Spur only; nil otherwise; 0 implies        no limit except that of the underlying platform)

                68           the average number of live stack pages when scanned by GC (at scavenge/gc/become et al)

                69           the maximum number of live stack pages when scanned by GC (at             scavenge/gc/become et al)

                70           the vmProxyMajorVersion (the interpreterProxy VM_MAJOR_VERSION)

                71           the vmProxyMinorVersion (the interpreterProxy VM_MINOR_VERSION)"

Shaping