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

On Sep 18, 2006, at 12:05 PM, J J wrote:
Has anyone ever played with a simple self-sends inliner?  No de-
inlining when debugging, no post-inlining optimization, no attempt to  
deal with polymorphism, just inlining monomorphic self-sends...

Avi

Why is this?  Is there something that could be identified and fixed to make
it
more usable by larger groups?  It has monticello for group work.  What does
it need? I
can't believe this is not a fixable problem.

Ron Teitelbaum wrote:
> The performance improvements of a Strongtalk VM appear to be quite
> substantial.

Indeed, but you can get the same results by getting a faster machine and
running Squeak on that.

> There are a number of other things that interest me, including
> the compiling of code based on what code is used.

My own interest in this kind of thing is not new:
http://www.merlintec.com/old-self-interest/msg00190.html

> 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".

People have worked hard in the past with the expectation that our
community would adopt their work (see first exceptions package, modules
for 3.3, various GUI enhancements) and then became very frustrated when
that failed to happen. My intention is not at all to discourage such a
project.

> I
> assume that the Strongtalk community will develop with or without Squeak,

Is that true? I am asking because I really have no idea. In the past Sun
has tended to release stuff as open source when it no longer has any
interest in investing in it further and the developers have been
diverted to work full time on Java related things.

> 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?

"We as a community" can't really do anything to help. But a few of us as
individuals have the needed knowledge for such a project and I am sure
that anyone doing it will be able to find the information they need
here, in #squeak and on the vm list.

> 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.  

Note that I have focused on the performance side of things and mostly
ignored compatibility. But the community is large (far larger than you
would think from just looking at squeak-dev, at least) and diverse so
people have different interests. So one person feels that Squeak must
have native widgets or it will die while another likes that the GUI is
identical on all platforms. Another would like access to all the neat
libraries in their OS while someone else wants to run Squeak on the raw
hardware and prefers plug-ins developed in Squeak itself. So I don't
think it is possible for the community to move in any particular
direction.

-- Jecel

Avi Bryant wrote:
> Has anyone ever played with a simple self-sends inliner?  No de-
> inlining when debugging, no post-inlining optimization, no attempt to  
> deal with polymorphism, just inlining monomorphic self-sends...

Due to inheritance you do have to deal with polymorphism before you can
inline self sends. Unless you want to add Java silliness like "final".

One curious detail - I never implement "super" in my VMs but instead
handle it by inlining the code. No need to worry about polymorphism in
that case...

-- Jecel

On Mon, 18 Sep 2006 21:15:36 +0200, Avi Bryant wrote:

> Has anyone ever played with a simple self-sends inliner?  No de-inlining  
> when debugging, no post-inlining optimization, no attempt to deal with  
> polymorphism, just inlining monomorphic self-sends...

I thought about that *) but , how about stack overflow?

*) for methods which send only special selectors (and have no ordinary  
sends) which the compiler can mark so. But I didn't find much caller /  
callee combinations which would benefit.

Your self-send inliner is damn more general. Was it already used?

/Klaus

> Avi

This is very interesting.  

While it is true that computers are going faster now then most people could
possibly use them and bottle neck issues are usually not cpu related but
network related, performance improvements could be significant for a number
of projects, especially large server projects.

I understand.  This has been difficult for me to really understand but I
have seen the frustration around the base image, and giving credit and
assigning responsibilities where appropriate.  

> > I
> > assume that the Strongtalk community will develop with or without
> Squeak,
>
> Is that true? I am asking because I really have no idea. In the past Sun
> has tended to release stuff as open source when it no longer has any
> interest in investing in it further and the developers have been
> diverted to work full time on Java related things.

I guess that is still yet to be determined.  But from what I see on the
strongtalk group, and if I read Dan's reaction appropriately, and the
possibility of his participation, it appears that they are moving along.
They are already receiving some community submissions.  People are helping
get the vm compiled on newer software platforms.
I definitely appreciate this comment.  It seems to me that the community is
suffering from exactly what you describe.  Although I do believe that you
are correct in many respects, I feel that this community would benefit from
more organization and direction, especially since it appears that the
community having trouble with the transition to a volunteer driven
community.  The volunteer's still need to stand up and take over before this
community will move forward.  I also feel that no matter your interest
everyone will benefit from organization and direction.  If we find a way to
provide tools for business developers (which I'm pushing for), which include
security, deployment support, multiple window support, business protocols,
and yes native widgets these things could still benefit even those that are
developing eToys, $100 laptops or even 3d virtual spaces!  (Imagine sending
out hundreds of thousands of $100 laptops only to have them all crash with a
single virus).  Organization and direction is the way to go, even if not
everyone agrees with it, or it doesn't help everyone.  Besides we could try
to agree on the process and the rules for getting things included to help
bring back in discouraged contributors.  

- Ron

On Sep 18, 2006, at 12:48 PM, Jecel Assumpcao Jr wrote:

> Avi Bryant wrote:
>> Has anyone ever played with a simple self-sends inliner?  No de-
>> inlining when debugging, no post-inlining optimization, no attempt to
>> deal with polymorphism, just inlining monomorphic self-sends...
>
> Due to inheritance you do have to deal with polymorphism before you  
> can
> inline self sends. Unless you want to add Java silliness like "final".

No, of course we don't want "final", but we can always recompile  
(without inlining) when someone overrides something we've inlined.  
There are enough cases that are never overridden to make the inlining  
worthwhile, I think.

Avi

Avi Bryant writes:
 >
 > On Sep 18, 2006, at 12:48 PM, Jecel Assumpcao Jr wrote:
 >
 > > Avi Bryant wrote:
 > >> Has anyone ever played with a simple self-sends inliner?  No de-
 > >> inlining when debugging, no post-inlining optimization, no attempt to
 > >> deal with polymorphism, just inlining monomorphic self-sends...
 > >
 > > Due to inheritance you do have to deal with polymorphism before you  
 > > can
 > > inline self sends. Unless you want to add Java silliness like "final".
 >
 > No, of course we don't want "final", but we can always recompile  
 > (without inlining) when someone overrides something we've inlined.  
 > There are enough cases that are never overridden to make the inlining  
 > worthwhile, I think.

>From where I stand it, inlining self sends is almost identical to
inlining general sends with a type test (jump the other way if it's
not the right type).

Type feedback is not hard. You could do it just using the normal
profiler. The profiler does not see primitives though. That's one
reason Exupery has PICs now. At one point I wanted to leave PICs until
after full message inlining.

The hard task is will be figuring out what the stack does across
inlined messages. It's the optimisation of ifTrue:, ifFalse:, and
whileTrue: that makes this hard. The code to do this in Exupery used
to all be in ByteCodeReader. Figuring out what the stack does is not
a hard analysis. Optimisations can make later optimisations harder.

The biggest commercial cost to a stripped down inliner is you loose
the ability to debug in production. That can be a major competitive
advantage. You will also interfere with reflection on contexts unless
you also provide dynamic de-optimisation.

How-ever inlining byte-code is not going to be that much easier than
inlining intermediate code. Add an inliner to Exupery and it is
architecturally comparable to Strongtalk. The type feedback is all
there now. There is even primitive inlining. (*)

Bryce

(*) Exupery will not get inlining until after 1.0. 1.0 is everything
needed to usefully use inlining except inlining. 1.0 also has to be
useful.

Jecel Assumpcao Jr wrote:
> Ron Teitelbaum wrote:
>>I assume that the Strongtalk community will develop with or without Squeak,
>
> Is that true? I am asking because I really have no idea. In the past Sun
> has tended to release stuff as open source when it no longer has any
> interest in investing in it further and the developers have been
> diverted to work full time on Java related things.

Unless new resources are brought to Squeak with this effort
(maybe from Sun), then I see a potential negative, if effort
is expended on a StrongtalkVM instead of on Exupery. Can someone
elaborate on what optimization techniques are done in the
StrongtalkVM that couldn't be done in Exupery (and likely
coded more easily using Smalltalk, instead of C++).

IIUC, quite a bit of the heavy-lifting has been done already in
Exupery (thanks Bryce), to be able to manipulate and execute native
code. Now it's a case of applying the optimization techniques
that were pioneered by the StrongtalkVM, and any new techniques
that have developed in the intervening 10 years (or maybe techniques
pioneered by Exupery).

One possible advantage of the C++ based VM is that porting to
other platforms is a matter of compiling C++, instead of writing
a code generator. But, then the end result would depend somewhat
on the quality of the C++ compiler optimizations. Exupery would
be much closer to the bare metal. I'm assuming that the StrongtalkVM
does not manipulate native machine code directly, so I may be
mistaken here.

However, the strong typing aspects may be worth porting,
if the additional type information can be used to speed up
execution somehow.

Just my opinions. Is this issue important enough that the
Squeak board should take a position? If you don't set an agenda,
then someone else may set one for you.

I agree with what you wrote, but just to clear up two points:

Yanni Chiu wrote:
> One possible advantage of the C++ based VM is that porting to
> other platforms is a matter of compiling C++, instead of writing
> a code generator. But, then the end result would depend somewhat
> on the quality of the C++ compiler optimizations. Exupery would
> be much closer to the bare metal. I'm assuming that the StrongtalkVM
> does not manipulate native machine code directly, so I may be
> mistaken here.

Strongtalk is like Self in that it has a code generator. Of course, now
that even Apple uses the x86 porting it to other processors is certainly
less of a priority. But if it needs to be done you can bet it would take
less time for a code generator written in Smalltalk than one written in
C++ (just ask the Self/Klein guys who did it both ways).
 
> However, the strong typing aspects may be worth porting,
> if the additional type information can be used to speed up
> execution somehow.

It has no effect on performance at all, but is still interesting for
other reasons.

-- Jecel

Hi Yanni--

> Is this issue important enough that the Squeak board should take a
> position?

        For what it's worth, I've voiced my opinion[1].


-C

[1]

http://lists.squeakfoundation.org/pipermail/vm-dev/2006-September/000827.html

--
Craig Latta
http://netjam.org/resume

Jecel Assumpcao Jr wrote:
> Strongtalk is like Self in that it has a code generator.

Thanks for clearing that up.

>>However, the strong typing aspects may be worth porting,
>>if the additional type information can be used to speed up
>>execution somehow.
>
> It has no effect on performance at all, but is still interesting for
> other reasons.

That's somewhat surprising. So, the only thing keeping Java (the
language) in the static typing world, is stubbornness.

It seems to me that adding strong typing (or whatever the correct
term is) to Squeak would chip away a one more perceived "deficiency",
and win some political points in the "language wars". That should
end the arguments: we've got both.

No, there's dogma too. :-)

On Sep 18, 2006, at 9:32 PM, Yanni Chiu wrote:
>  So, the only thing keeping Java (the
> language) in the static typing world, is stubbornness.

Actually the Java and .Net worlds are both coming to the conclusion that
dynamic typing is the future.  Both communities are learning that the cost
of maintaining all that typing information is a larger problem than the one
it solves.  Namely that type errors are just not all that common, and are
easily found with adequate testing, which is required even with static
typing.  MS has invested more than Java, but both are finding that for the
bulk of their customers doing business computing the better tradeoff is
dynamic typing.  In the book Beyond Java the author makes many good
arguments for moving away from Java for most uses.  For highly technical or
complex enterprise scale problems, the JVM is still hard to argue with given
its performance and the size of the libraries, and the raw amount of testing
with enterprise scale projects.  But, for the vast majority of projects
which are on a smaller scale, it is overkill and heading fast in the
direction of more complexity not simplicity.

Michael

> It seems to me that adding strong typing (or whatever the correct
> term is) to Squeak would chip away a one more perceived "deficiency",
> and win some political points in the "language wars". That should
> end the arguments: we've got both.

Only if you consider manifest types to be a good thing, most
Smalltalkers don't.

Ramon Leon wrote:
>> It seems to me that adding strong typing (or whatever the correct
>> term is) to Squeak would chip away a one more perceived "deficiency",
>> and win some political points in the "language wars". That should
>> end the arguments: we've got both.
>
>
> Only if you consider manifest types to be a good thing, most
> Smalltalkers don't.

I see it purely as a marketing issue. If typing is something
that's blocking wider adoption (whether justified or not),
and we have a way to fix it, then just do it and move on.
But it's possible that we won't have to, if the mindset has
changed (as Michael points out in his message).

On a similar vein, a C++ based VM (and the Strongtalk mystique)
might have some marketing points (but, once again, don't sacrifice
scarce developer resources). But the message might just end up:
"we now have the Smalltalk technology that the Java VM
implementers bought and adapted (nearly 10 years ago)."

Another point about typing:  would the typing information
be useful for improving the developer tools (e.g. refactoring
could be more precise)?

On 9/19/06, Yanni Chiu <[hidden email]> wrote:
> Another point about typing:  would the typing information
> be useful for improving the developer tools (e.g. refactoring
> could be more precise)?
>

It is. I notice this using Eclipse, that Java refactorings can be more
precise. But if, for that, I have to spell out each and every type,
the net gain is quite likely negative. As usual, a type inference
engine seems to be the best of both worlds here...

Type system probably does not have direct impact on Strongtalk speed up.
But refactoring of kernel library in order to reduce polymorphic (megamorphic) cases did probably speed up a lot, and type system probably helped achieving this.
We must not forget this indirect impact.
That's how i interpret it.

Nicolas


________________________________________________________________________
iFRANCE, exprimez-vous !
http://web.ifrance.com

On Sep 18, 2006, at 20:09 , Jecel Assumpcao Jr wrote:

The Klein Paper lists what they perceived to be problematic about the C
++ VM:

- 120KLOC of C++
- replicated code:  common ops implemente 3 times (runtime, slow+fast  
compiler)
- debugging difficult: difficult to access self objects as such from  
the VM level
- slow turnaround:  change to C++ headers caused > 5 min. recompile
- complexity + brittleness

and how they wanted to address these problems:

- use a (pure) dynamic OO language
- be metacircular, using the same language for VM+environment means  
lots of code sharing
- foster code reuse through language features, architecture,  
environmental support
- allow VM to be changed quickly, even while running
- exploiting mirror-based reflection for debugging the VM

Of course, they were a long way from producing a practically useful VM.

Squeak's Slang addresses a few of these problems, making it possible  
to pseudo-test changes very quickly by running the Slang code within  
an existing image ('pseudo-test because there can be issues in the  
translated/compiled code that do not show up in Slang).  However,  
Slang isn't really an OO language, it's really BCPL with Smalltalk  
syntax, and therefore none of the code-reuse or other OO benefits  
apply, and having the non-applicable syntax/semantics is rather  
confusing.  But it *is* practical, up to a point.

I think the fundamental problem is that for some bits of a VM, C/C++  
is much better suited, whereas for other parts, a high-level OO  
language is the better choice.  However it's either/or and the systems  
listed, as well as Strongtalk and the commercial VMs, have to make the  
coice one way or another and then try to deal with the consequences.

<BrokenRecord>
Objective-C shows that the choice doesn't have to be either/or, it can  
be a smooth blend of "a bit of both" where needed.  For example,  
Objective-Smalltalk heavily leverages the Foundation classes  
(dictionaries, arrays, etc.) in its "VM" implementation, but those  
same classes are also available to the Objective-Smalltalk programs  
running on top.

It is also quite possible to start a particular implementation with  
objects and then incrementally replace these with lower-level C  
constructs, all without crossing any boundaries.  For example, my  
first implementation of message sending stored the evaluated arguments  
of a message expression in an array object (an NSArray).  Profiling  
showed that this was taking a lot of time so I changed it to  
allocating an array of object pointers on the C stack (no object), and  
performance was duly improved.  However, this means that the API for  
message-sending isn't pure objects any longer, so I might change it a  
bit so it uses a light-weight, stack-allocated array object in the  
future.

And yes, due to the fact that Objective-C is a dynamic OO language,  
recompiles don't take minutes but seconds, making exploration possible.
</BrokenRecord>

Marcel

 > I see it purely as a marketing issue. If typing is something
 > that's blocking wider adoption (whether justified or not),
 > and we have a way to fix it, then just do it and move on.
 > But it's possible that we won't have to, if the mindset has
 > changed (as Michael points out in his message).

The addition of manifest types, to a dynamic languages, is a MASSIVE
change, not a marketing issue.  StrongTalk is an interesting experiment,
mostly for the VM optimizations, but that's all it is, an experiment,
it's not some production ready proven dialect that's ready for prime
time.  Adding types to Smalltalk, is a mistake, and isn't in the spirit
of the language, and frankly, imho, would ruin the language.  It's not
something you can just add and move on.

Types aren't blocking wider adoption, ignorance is.  The wider community
is generally ignorant of the benefits of Smalltalk, dynamic typing,
image based development, language aware source control, etc., etc, etc.
  Smalltalk doesn't need to come to them, they need to come to
Smalltalk, and they are, slowly but surely, every major language has
been moving closer and closer to Smalltalk for years.

VM's, refactoring, Object Orientation, IDE's, garbage collection, and
extreme programming are all now common, a sure sign of the direction of
the mainstream.  A few more years, and they might catch up to Smalltalk
72. ;)

 > Another point about typing:  would the typing information
 > be useful for improving the developer tools (e.g. refactoring
 > could be more precise)?

Yes, and the cost would be much bloated and hard to maintain code, a net
negative result.  I'm sure there's some interesting things to be gleaned
from the StrongTalk VM, but Squeak, needs to remain Squeak, StrongTalk
is the wrong direction.