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):
Time millisecondsToRun: [ 100000 factorial ]. "3585"
Pharo 9 64-bit:
Time millisecondsToRun: [ 100000 factorial ]. 4074
My time is comparable to yours.
This surprises me more than you, in fact because I was expecting similar times
(VM is the same, after all).
The algos are different:
Pharo 8:
Integer>>factorial
"Answer the factorial of the receiver."
self = 0 ifTrue: [^ 1].
self > 0 ifTrue: [^ self * (self - 1) factorial].
self error: 'Not valid for negative integers'
Pharo 9:
Integer>>factorial
| nex nexnext acc |
"Guard for know cases (0,1,2,error)"
self < 3
ifTrue: [ ^ self < 0
ifTrue: [ self
error: 'Not valid for negative integers' ]
ifFalse: [ self
> 0
ifTrue: [ self ]
ifFalse: [ 1 ] ] ].
acc := 2.
nex := 2.
nexnext := 10.
self // 2 - 1
timesRepeat: [ nex := nex + nexnext.
nexnext := nexnext + 8.
acc := acc * nex ].
self odd
ifTrue: [ acc := acc * self ].
^ acc
In any case, no user of Pharo or Squeak will ever complain that the VM and math
classes are too efficient. Why is there not always just one basic image and VM
for both?
Basically, all this benchmarks are very unreliable and depend a lot on the
machine you are running and ultimately, "weather conditions".
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?
In general , since VM is the same, if changes are in VM they are already in
Pharo.
Okay. By “in general” do you mean that forked deviations from a single target
VM are few and transient/short-lived?
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?
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?
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.
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.
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.
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.
Yes, so it seems. The Squeak debugger is as nimble and quick as the new Pharo
Launcher. Why wasn’t the Squeak debugger adapted to Pharo when the speed
difference was noticed? It’s not a small difference, and if the slowness is
not mostly about a text rendering problem, then adapting the Squeak debugger
architecture to Pharo makes sense.
Not speed-related:
- How can I load additional fonts into Squeak? Pharo does this with the font
dialog’s Update button.
You’ll have to ask in squeak list, the sis not the appropriate place for that :)
Okay.
- 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.
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
