[Enh][VM] primitiveApplyToFromTo for the heart of the enumeration of collections?

The issue that triggered this whole thing about the primative was the fact
that it was demonstrated that rolling you own count: using do: and a temp
variable was faster then using the library count:.

This is a problem, yes?  The library count: shouldn't be 3 times slower (I
think that was the number) then rolling your own.  Klaus has tried to come
up with a solution to this.  Do you have another solution to it?

Now I understand your objection about not wanting to add a speed
optimization that actually slows down the common case, but I don't see where
the message sends get slower.  Does that have something to do with another
primative being added?  Does every new primative add a speed hit?

A JIT is certainly important.  Especially in deployment mode.  I'm glad it's
being worked on.

>Anthony Hannan's send performance work was rejected even though it
>did speed up sends and came with proper block closures. Proper block
>closures are something we really should have.
>

Why was this rejected?

J J writes:
 > The issue that triggered this whole thing about the primative was the fact
 > that it was demonstrated that rolling you own count: using do: and a temp
 > variable was faster then using the library count:.
 >
 > This is a problem, yes?  The library count: shouldn't be 3 times slower (I
 > think that was the number) then rolling your own.  Klaus has tried to come
 > up with a solution to this.  Do you have another solution to it?

Exupery already optimises do: by a factor of 50%. At that point I
stopped because it was not providing any benefits for any of the large
benchmarks I'm tracking. I do this by optimising message send, return,
and byte code execution. My current implementation of value: is
possibly worse than the interpreters or equally as bad. Adding a fast
compiled value: to Exupery would be easy but there are no realistic
benchmarks that would benefit from it.

The library should also be readable. This is Smalltalk, we all read
the library code all the time. But I'm repeating myself. There is
a value judgement between readability and speed. We differ in I don't
feel speed is worth it at all costs.

Personally, I'd prefer a library that I can easily understand that is
fast enough for 99% of it's uses. That for 1% of cases, I need to use
a custom solution is an acceptable trade off for understandability.

I've spent many hours looking at Klaus's changes, I have not yet spent
enough time to be sure they are bug free. commonSend and return are a
messy part of the system. There is a lot of state tucked away in
globals that effects decision making. There are many infrequent cases
due to optimisations that are already there. When I talk about
maintainability issues I am talking about code that I am very familiar
with, have studied it both as code and in the debugger.

 > Now I understand your objection about not wanting to add a speed
 > optimization that actually slows down the common case, but I don't see where
 > the message sends get slower.  Does that have something to do with another
 > primative being added?  Does every new primative add a speed hit?

The speed hit comes from the code in commonSend and
commonReturn. Adding a primitive, only effects performance when it's
executed.


As yet no-one has demonstrated a single practical use of occurencesOf:
where the speed difference would matter. No one has shown any
realistic benchmarks where speeding up do: and friends would matter.

We should remove the optimisation to ifNotNil: that is buggy unless
someone can provide realistic benchmarks where it matters. I would be
surprised if such code was in any critical inner loop. Try explaining
when the compiled version is used and when the byte code inlined
version is used to someone new to Smalltalk. If only one or two
cases need to be inlined then still remove it.

At some point, we've got to value maintainability and simplicity
otherwise the system will die. The issue here is one of values,
values that matter for the survivability, reliability, and
maintainability of the system. I care more about the values here
than the specific change.

Speed is not the ultimate goal. Speed is neither necessary nor
sufficient for Squeak's success. Speed does help though.

I want a system that is easy to change. Changes like Klaus's will
make it harder for the next person to change it. Klaus's ability to
make that change is worth a slight loss of performance.

Bryce

On Sun, 17 Sep 2006 22:04:39 +0200, Bryce Kampjes wrote:
JJ, with "code in commonSend and commonReturn" the code which I added is  
meant (est. slow down was calculated 1% to 15%), not the unchanged code  
(slowdown 0%).

While I'm here I can report that slowdown of #commonSend is now back to  
where it was. Now #comonReturn wants my attention ;-)

/Klaus

Klaus D. Witzel writes:
 > JJ, with "code in commonSend and commonReturn" the code which I added is  
 > meant (est. slow down was calculated 1% to 15%), not the unchanged code  
 > (slowdown 0%).

Be careful about relying on any single measure of performance these
days. I've removed pointless jumps and seen the code slow down. This
was with Exupery so I know that it wasn't compiler monkey business
that I was unaware of.

So don't fully trust either static analysis or any benchmark. There's
a few percentage points of statistical noise. Change something and
there will be a random effect on performance caused by CPU level
optimisations.

Several early RISCs made the mistake of assuming that the SPEC
benchmarks were big enough to rely on. That's one reason why they left
out byte accessing instructions. For SPEC, they were not worth the
cost but they are required for business apps. Hennessy and Patterson's
Computer Architecture, A Quantitative Approach is a good introduction
to thinking about optimisations. David Ungar's The Design and
Evaluation of a High Performance Smalltalk System is another.

Bryce

me too :)
I always have in mind the nice sentence of dan about the fact that  
someone alone could understand smalltalk

On 17 sept. 06, at 22:04, Bryce Kampjes wrote:

> Personally, I'd prefer a library that I can easily understand that is
> fast enough for 99% of it's uses. That for 1% of cases, I need to use
> a custom solution is an acceptable trade off for understandability.

Hi Stef,

on Mon, 18 Sep 2006 09:11:16 +0200, you wrote:
> me too :)
> I always have in mind the nice sentence of dan about the fact that  
> someone alone could understand smalltalk

Look into data centres where the big servers run applications or look into  
offices where thousands of workstations run applications.

If you can save them a significant portion of CPU time then you save them  
$$$ investment, and perhaps win a contract against your competitor.

Also, look into complex applications which can neither be created nor be  
maintained by a single person, or understood by a single person.

Why shouldn't Squeak become a #1 choice in such situations.

I doubt that application developers want to understand the internals of a  
VM or the internals of a library (Collections in our case here, libc as an  
example in other cases), perhaps their boss (the $$$ decision maker) also  
doesn't want that. I doubt because of long time experience.

Let's bring Squeak to the masses. Or, am I wrong with this? I run a  
commercial business and want to base my success on Squeak. Anyone out  
there telling me that I should not invest into Squeak, please let me know,  
in squeak-dev or off-list. Thank you.

Please don't misunderstand: I'm not asking that primitiveApplyToFromTo  
must be in each and every VM. Neither do I have something against the  
preferences of developers. But I want freedom for making decisions.

/Klaus

> On 17 sept. 06, at 22:04, Bryce Kampjes wrote:
>
>> Personally, I'd prefer a library that I can easily understand that is
>> fast enough for 99% of it's uses. That for 1% of cases, I need to use
>> a custom solution is an acceptable trade off for understandability.
>
>
>

Sure!
But I understand what Bryce concerns.
Now if we would start to really benchmark central part of squeak I'm  
sure that we would get some surprises.

Stef


On 18 sept. 06, at 11:17, Klaus D. Witzel wrote:

On Mon, 18 Sep 2006 11:48:01 +0200, stephane ducasse wrote:

> Sure!
> But I understand what Bryce concerns.

And neither the concerns of Bryce nor your's (someone alone could  
understand smalltalk) can be generalized. But thanks to Squeak, such  
different concerns can be addressed very conveniently :)

> Now if we would start to really benchmark central part of squeak I'm  
> sure that we would get some surprises.

What do you expect, are there areas which are important for your work to  
be benchmarked.

/Klaus

> >Anthony Hannan's send performance work was rejected even though it
> >did speed up sends and came with proper block closures. Proper block
> >closures are something we really should have.
> >
>
> Why was this rejected?


I don't know about the send performance, but the closures rewrite in
general got stalled because nobody ever updated the debugger.  The
update was not completely trivial: the new closures sometimes miss
information about their surrounding scope.


Anyway, I'm sure the code is available online if someone wants to try
to finish this last missing piece.  Indeed, real closures would be
nice to have; these language feature should be what it looks like.

(Although, it's pretty impressive how little anyone cares in practice;
whenever you have complicated nesting, it's usually nicer anyway to
make explicit classes....)


-Lex

On 9/18/06, Klaus D. Witzel <[hidden email]> wrote:
Scientific applications can be CPU bound, but most business
applications are not.  Usually they are limited by the network or the
database.  In a typical office with thousands of workstations, most of
them never are CPU bound, and the processors on average is 90% idle.

> Also, look into complex applications which can neither be created nor be
> maintained by a single person, or understood by a single person.
>
> Why shouldn't Squeak become a #1 choice in such situations.

Smalltalk in general, and Squeak in particular, is no better at very
large applications than other languages.  Its lack of modularity can
make it worse.  Where it shines is when it allows a system that would
otherwise need 50 people to be built with a small number.

There have been a number of Smalltalk projects with dozens, sometimes
hundreds, of people on them.  None have been successful.  On large
projects, politics and management issues overwhelm technical decisions
and the value of Smalltalk gets lost.  If you can keep the group of
developers small then the technical advantages of Smalltalk can
dominate.

-Ralph Johnson

Hi Ralph,

thank your your comments!

On Mon, 18 Sep 2006 12:42:39 +0200, you wrote:
It makes a difference if your graphics / windows / etc open / get drawn /  
save / etc, at 50% or at 100%. Response time (perceived interruption of  
the user's workflow) is more critical for the average user than anything  
else (during an acceptance test: response time v.s. utility, what will  
make it).

I should have mentioned such earlier. But for the rest of it (incl. the  
below): O.K. that is what I hope for :)

Thanks again.

/Klaus

> Let's bring Squeak to the masses. Or, am I wrong with this?  

No you are right here, but we need to get organized and support the
community that is needed to take over from the previous "owners" of squeak.

> I run a commercial business and want to base my success on Squeak.

[+1 big]

When do nominations for the foundation start!

Ron

P.S. Klaus have you looked at the StrongTalk VM yet?

This is not my experience.  What I have noticed is that very large companies
that focus on Smalltalk alone do quite well.  They are able to build very
powerful systems with a large number of developers with no problem.  The
product they develop has created a definite advantage.  The problems that I
have seen is when political decisions and hype for changing to something
like C++, .net or Java fragments the development group into competing camps.
In almost every case that I've seen where Smalltalk was going to be replaced
with something like Java, the replacement has failed.  Many groups have
given up their Java efforts to focus again on Smalltalk, or have failed
outright.  

Ron Teitelbaum

Hi Ron,

I've asked David Griswold who posts over in vm-dev about reusing Squeak's  
ObjectMemory, the answer was: rather not (because slangish, because  
squeakish). And earlier Craig asked him if they want the VM be written in  
Smalltalk, the answer was: too huge a project for now, but in the long  
term self-hosting and self-debugging would be great.

BTW the Strongtalk list is @
- http://tech.groups.yahoo.com/group/strongtalk/

This perhaps looks like a not so fast development project; also  
performance for them is critical due to startup and compilation pauses.  
But perhaps they will find acceptable material - resuable things - and  
also funds and hands with VM knowledge.

Time will show. Indeed, David wrote that their goal is producing a version  
of the Strongtalk VM for Squeak ...

/Klaus

On Mon, 18 Sep 2006 16:29:15 +0200, Ron wrote:

Interesting questions.  I've been watching the Strongtalk group.  Does
either of these issues, reusing ObjectMemory, or having a smalltalk vm limit
in your opinion the benefits of the Strongtalk vm?  From Dan's comments and
from the apparent speed and packaging benefits I would think that we should
support a Strongtalk VM for squeak in what ever way they could provide it.  

If we accepted that the base VM is C++ then couldn't plugins still be slang,
(or the slang plugins still be supported by the base Strongtalk vm) or is
this too much for the squeak community to accept?

Ron

> From: Klaus D. Witzel
> Sent: Monday, September 18, 2006 11:41 AM

On Mon, 18 Sep 2006 17:55:52 +0200, Ron wrote:
And the license.

> If we accepted that the base VM is C++ then couldn't plugins still be  
> slang,
> (or the slang plugins still be supported by the base Strongtalk vm) or is
> this too much for the squeak community to accept?

There will be clever hackers, moving sources back and forth between VM's,  
there always are clever hackers.

/Klaus

Ron Teitelbaum wrote:
> If we accepted that the base VM is C++ then couldn't plugins still be slang,
> (or the slang plugins still be supported by the base Strongtalk vm) or is
> this too much for the squeak community to accept?

Note that when the Squeak project was started there was already an Open
Source (BSD license) Smalltalk VM written in C++. I am talking about
Self 4.0 hosting GNU Smalltalk, which at the time outperformed all
available VMs including the commercial ones. And this work had been done
by the group from which one of Squeak's creators had come from, so we
can be sure he was very familiar with it.

I think it would be true to say that Squeak was started as a reaction
against what you are suggesting. The goal was portability and not
performance, though projects such as Ian's Jitter were encouraged. I had
a very good experience using Jitter 2 back in the Squeak 2.3 days, for
example, but didn't care enough about performance to keep at it and
found myself using the regular VM just as often (and exclusively on
later Squeaks).

A more radical change to the Squeak VM was Anthony Hannan's VI4 work,
which gave us better performance and real closures. But though his new
bytecodes were cleaner, my impression is that he felt the gain wasn't
enough to justify losing the historical connection to the "blue book"
design. I always worry about the implementation itself as an educational
object (and not just the eToys layer) and so like to take these issues
into consideration. Recent versions of Little Smalltalk, for example,
are much improved over the original but now they no longer match the
book and are less valuable as a teaching tool. Anthony later created the
"closure compiler" which worked with unmodified VMs and my impression
was that this, unlike what Lex said, actually has been included in
official Squeak.

While I am very glad that Strongtalk has finally been open sourced (and
so has Klein, the "Self written in Self" VM which probably matches
Squeak's goals better) even if someone does adapt it to run Squeak I
wouldn't bet on it being officially adopted by the community. I think
Ian's current work has a far better chance.

-- Jecel

Jecel,

Thanks for your response!

The performance improvements of a Strongtalk VM appear to be quite
substantial.  There are a number of other things that interest me, including
the compiling of code based on what code is used.  It would be difficult,
considering the people involved in the strongtalk project and given Dan's
comments, to dismiss this opportunity with, "been there, done that".  I
assume that the Strongtalk community will develop with or without Squeak,
the real question is should we as a community work closely with strongtalk
so that a strongtalking squeak vm is an option, even if it is not fully
adopted by the community?

I do understand the argument of compatibility vs. performance, but
performance should not be discounted, especially if the gains are
significant, if this community is ready to move into business application
development.  

Ron

But I'm not talking about Exupery.  In fact I don't think anyone (else) is.

I do thing Exupery is a good thing.  I hope you can get it going so fast it
competes
with c++ and beats Java.  But even if it does, we will still want to develop
smalltalk
code in the interpreted environment, so speed counts there too.

>
>The library should also be readable. This is Smalltalk, we all read
>the library code all the time. But I'm repeating myself. There is
>a value judgement between readability and speed. We differ in I don't
>feel speed is worth it at all costs.
>

You and I don't differ on this.  I think readability is important.  In fact
that is what this whole
thing is about for me.  Right now people are writing algorythms directly
instead of using
the library, because the library code is 3 times slower.  That hurts
redability and
maintainability.

>As yet no-one has demonstrated a single practical use of occurencesOf:
>where the speed difference would matter. No one has shown any
>realistic benchmarks where speeding up do: and friends would matter.
>

I don't get it.  Right now occurencesOf: impliments a counter.  Instead of
using the
library message count: it duplicates the code.  Why?  Well maybe because
count: didn't
exist when it was made.  So we asked about just changing it, and then
Andreas (I think it was)
pointed out that that change would make the occurencesOf: method 3 times
slower.
This is a problem.  You agree right?

If Klaus' proposal is wrong ok.  But what is right.  There must be some way
to make count:
not have such a high cost of use compared to just reimplimenting it over and
over.