[E-Lang] E FAQ

[Mark S. Miller]

At 12:21 PM Thursday 9/27/01, Zooko wrote:
>> What do you mean by "micro-parallelism"?  
>
>If you read my letter to e-lang, [1] [...] you'll see a proposal for computing separate
>E vat ticks in parallel (e.g. to take advantage of a newfangled SMT CPU), while
>still guaranteeing the same semantics.

Thanks for the reminder.  I think techniques like this are interesting.  In 
looking at it again in this context, I wonder in what sense any of this is 
specific to E.  During an individual turn of the vat (event), E is in all 
relevant regards a conventional sequential imperative memory-safe oo 
language.  By the time you could actually make work any of the techniques 
you describe, you could apply it to any other such language as well.

I do see one possible advantage for E (compared to other imperative 
languages that must accommodate concurrency), for this as well as various 
other optimizations.  Other imperative language are generally made to deal 
with concurrency by introducing multiple threads with shared state.  
Compiler optimizations that would have been correctness preserving on a 
truly sequential program are now dangerous.  Such languages have often been 
extended with concepts like "volatile", or forsaken some optimizations, or 
both.

E deals with concurrency without sacrificing true sequentiality.  For a 
hypothetical non-Java E implementation, there is an opportunity to safely 
apply optimizations that might otherwise be tricky -- especially those that 
transparently reorder side effects.  I suspect microparallelism optimization 
may likewise benefit.  (OTOH, many of the optimizations that would be 
newly enabled would also make debugging difficult.)

E avoids threads to help people reason about programs, but unsurprisingly, it 
should also help programs reason about programs.


        Cheers,
        --MarkM