[squeak-dev] C++ parser in Smalltalk?

Hi Peter,

Sorry for the late & nil answer - I am real busy right now - will write you
later.

I would prefer to use Michael Haupt's proposal - using GCCXML - but you have
to convert it to a DLL & use it via FFI.

Frank

Eliot Miranda writes:
 > > P.S. That's one reason I don't like the idea of a write protect bit in
 > > the object header. It adds yet another thing to check for every single
 > > write into an object. Small costs add up on common basic operations.
 >
 >
 > Actually one can be clever about this.  yes one has to check for inst var
 > assignment.  But for at:put: one can fold the check into other activities.
 >  For example, in my VisualWorks implementation the write-protect bit was put
 > very close to and more significant than the size field in the object header.

<snip, neat optimisation>

 > > Write protection could be implemented using similar tricks to the
 > > write barrier. Then send optimisation will help reduce the costs when
 > > it's used. When it's not used, there's no cost.
 >
 >
 > I don't understand this.  Can you explain the write-barrier tricks and the
 > send optimization that eliminates them?

Automatically create a new hidden subclass of the class that acts
appropriately for every write. The write protection can then be
encoded in the class. The only overhead is that required by dynamic
dispatch which we're already paying for.

 > I think per-object write-protection is very useful.  Its very useful for
 > read-only literals, OODBs, proxies (distributed objects), debugging, etc.
 >  Amongst Smalltalks I think VisualAge had it first and I did it for VW round
 > about 2002.  I did it again for Squeak at Cadence.  In both the VW and
 > Squeak cases the performance degradation was less than 5% for standard
 > benchmarks.  Its cheap enough not to be noticed and there's lots more fat in
 > the Squeak VM one can cut to more than regain performance.
 >
 > So unlike, say, named primitives for the core primitives, this is something
 > I am in favour of.  It is a cost well worth paying for the added
 > functionality.

And when we're twice as fast as VisualWorks is now it'll be a 10%
overhead. Twice as fast as VisualWorks is the original goal for
Exupery.

Immutability or change tracking can be provided more efficiently purely
inside the image when it's needed.

Bryce

2008/7/4  <[hidden email]>:
Yes, it looks more like a capability-based approach. It is better in a
ways, that we can introduce wide range of capabilities in future while
keep object formats intact. The question is however, how to introduce
such model without compatibility conflicts.
Some magic with mixins/traits come in mind: to be able to define a
behavior which can be turned on/off/switch for a particular object.
Really,  why we should pay with state(flags), when actually its a
subject of different capabilities, which should be reflected by
behavior.



--
Best regards,
Igor Stasenko AKA sig.

Eliot Miranda writes:
 > On Thu, Jul 3, 2008 at 2:56 PM, <[hidden email]> wrote:
 >
 > > Eliot Miranda writes:
 > >  > > Write protection could be implemented using similar tricks to the
 > >  > > write barrier. Then send optimisation will help reduce the costs when
 > >  > > it's used. When it's not used, there's no cost.
 > >  >
 > >  >
 > >  > I don't understand this.  Can you explain the write-barrier tricks and
 > > the
 > >  > send optimization that eliminates them?
 > >
 > > Automatically create a new hidden subclass of the class that acts
 > > appropriately for every write. The write protection can then be
 > > encoded in the class. The only overhead is that required by dynamic
 > > dispatch which we're already paying for.
 >
 >
 > Ah, ok.  This doesn't work in general.  e.g. one can't turn on immutablity
 > in the middle of a method that assigns to inst vars.  The method in the
 > subclass would need to be different and mapping pcs at runtime is, uh,
 > decidely nontrivial.  It works for access to arrays but not to objects in
 > general.

A more complicated variant would be to use compiler created accessors
for all variable access then rely on inlining to remove the overhead.

The catch here is this would force some de-optimisation when switching
write protection on and off. Worst case, de-optimisation of inlined
code can require a full object memory scan to find all the contexts
that require deoptimisation.

Fast deoptimisation is one of the strongest reasons I can see for a
context cache in a system that does inlining. For pure speed, the
value of the context cache will be reduced because inlining should
remove the most frequent sends.
 
 >  > I think per-object write-protection is very useful.  Its very useful for
 > >  > read-only literals, OODBs, proxies (distributed objects), debugging,
 > > etc.
 > >  >  Amongst Smalltalks I think VisualAge had it first and I did it for VW
 > > round
 > >  > about 2002.  I did it again for Squeak at Cadence.  In both the VW and
 > >  > Squeak cases the performance degradation was less than 5% for standard
 > >  > benchmarks.  Its cheap enough not to be noticed and there's lots more
 > > fat in
 > >  > the Squeak VM one can cut to more than regain performance.
 > >  >
 > >  > So unlike, say, named primitives for the core primitives, this is
 > > something
 > >  > I am in favour of.  It is a cost well worth paying for the added
 > >  > functionality.
 > >
 > > And when we're twice as fast as VisualWorks is now it'll be a 10%
 > > overhead. Twice as fast as VisualWorks is the original goal for
 > > Exupery.
 > >
 >
 > Where are you on that?

Progress is good though will be a little slow over the summer.

I'm working towards the 1.0 release. That's going well. The last
release looks reasonably reliable and the current release compiles
much quicker than previously. I've fixed the performance of the
register allocator so that it doesn't blow out like it used to. Now it
always takes about 50% of the compile time. Cascade support has also
been added so all major language features are now supported.  There's
a bug in the current development version that'll need fixing before
the next minor release.

The work towards 1.0 now involves adding primitives which the
interpreter inlines and tuning. The current engine should be able to
provide a nice performance improvement for Squeak. 1.0 will be worse
than VisualWorks for overall performance as send performance is worse
though still twice as good as Squeak's interpreter. 1.0 should be a
little faster than VisualWorks for bytecode performance though I'd
guess it's a bit slower now because I haven't done any bytecode tuning
in the last few years.

The current releases are good enough to play with. The next one will
be much nicer to play with than the current released version due to
faster compilation.

Compilation is still much slower than it needs to be, so far I've
favoured simplicity, debuggability, and testability over compile time
performance. For instance every compiler stage copies it's input to
create the output even for stages that only do a few
optimisations. Besides the register allocator all optimisations are
simple linear time tree traversals.

After 1.0, the plan is to add full dynamic message inlining in 2.0,
then an SSA optimiser in 3.0. Exupery's goals are similar to AoSTa's,
the major differences are the code generator is in the image, and
Exupery doesn't stop execution to optimise. It compiles in the
background then registers the compiled method which will be used by
later calls. Exupery relies on the interpreter to execute code that
isn't used frequently enough to be worth compiling or that isn't
currently compiled.
 
Bryce

P.S. Being able to control precisely what's in the code cache makes
debugging crashes much easier. A common trick when debugging Exupery
bugs is to recompile everything that was compiled when it crashed then
try to reproduce the crash. Once it's reproduced, it's possible to do
binary chop of the compiled methods to get down to the few that are
required to reproduce the problem.

That would be much more difficult to do with a HPS style system which
compiles the method before execution. Of course HPS's style has it's
own advantages.