[prev in list] [next in list] [prev in thread] [next in thread] 

List:       e-lang
Subject:    [E-Lang] Announcing E 0.8.10gamma2: Integrating Dean's Transformer
From:       "Mark S. Miller" <markm () caplet ! com>
Date:       2001-11-17 4:11:32
[Download RAW message or body]

One small step for actual performance.  Two giant leaps for possible 
performance.

With the 0.8.10gamma2 release of E, Dean's Transformer is now integrated 
into our main development path.  This transformer 
1) Does scope analysis over an E program,
2) transforms name-based variable access into access based on indexing into 
    arrays, and 
3) causes an object to only retain its actual instance variable (those 
    lexically enclosing variable that it actually uses freely), instead of 
    holding on to its entire creation time scope.

Although few methodical timing tests have yet been performed, measurements 
to date indicate that this version should perform between 2x and 5x of 
previous releases.  This is the small step for actual time performance. 
(This release also gives us the giant leap on space performance, in that E's 
garbage collection should now be as accurate as Java's, due to #3 above.)

The first giant leap for possible performance is that any actual compiler 
must perform such a transformation.  Hopefully, this will accelerate Darius' 
efforts to build an actual E compiler.

The second leap is that the new (transformer-based) E language interpreter 
per se is now a much smaller fraction of total execution (although we have 
yet to carefully quantify this).  The remaining reason for poor performance 
is poor performance engineering (by me) in various places in ELib, and these 
places should now be more visible to those (such as Dean) with access to 
good Java profiling tools.  At least no one can accuse me of premature 
optimization! ;)

Using these profiling tools, Dean already identified E's sameness comparison 
("==" in the E language) as a bottleneck, and this release also incorporates 
a speedup contributed by Dean.  (Our current collection classes also seem to 
be a problem, but we'll avoid investing too much effort into speeding them 
up until we figure out what their life expectancy is, and how Hydro's 
classes compare.)

Once we do have a true compiler, there will probably continue to be a role 
for the current transformation-based interpreter.  Compilers are great for 
code that's run over and over, like code in a *.e, *.emaker, or *.caplet 
file.  (MarcS will be explaining *.caplet files soon.)  However, because of 
the up-front latency of a compiler (especially in the JVM context, where 
compiled code must be class-loaded), it will probably be unsuitable for a 
command line.  We expect to continue to use the current scheme -- 
interpreting the output of Dean's transformer -- where low latency is more 
important than marginal performance, as on the command line.



With this step, the E implementation is starting to feel less like an 
executable specification and more like a conventional language 
implementation.  Thank you Dean!


        Cheers,
        --MarkM

_______________________________________________
e-lang mailing list
e-lang@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/e-lang

[prev in list] [next in list] [prev in thread] [next in thread]