[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
yet more on processes
While I completely agree with Urs and Peter, I also wanted
to stick in my own 2 cent's worth.
Here's the way I look at it:
Self does even less scheduling than Smalltalk in the VM. This costs you in
more process switches, but may make it easier to play with the scheduler.
Like Smalltalk, our standard libraries do not allow for concurrency.
Unlike Smalltalk, you can easily change the fundamental system objects
and just file them in, since our compiler/parser is "below the line".
(Of course this makes it harder to change Self's parser.)
I am very pleased by the minimalism in the Self VM's treatment of
processes. I hope it works out.
By the way, on non-LIFO blocks:
The whole issue of how far to reify activations and how much upward
functionality to give blocks is a REAL toughie. The advantages are
well known, but I think the costs are frequently underestimated.
Specifically: performance. We would love Self to compete head-to-head
with optimized C in runtime performance. I suspect that either
reified activations or upward blocks would make this MUCH harder if
not impossible. I do not believe that the work that the LISP community
has done so far contradicts my view. For example, one LISP system
that is considered pretty efficient (the subject of Kent Dybvig's
SIGPLAN 90 paper on high-performance continuations) does not even
use register windows on the SPARC--a MUST to compete with C on that
machine. For regrettable, but good reasons, there is a dearth of
head-to-head performance comparisons between C and LISP, and the ones
we are aware of have used "shortcuts" like declarations or unsafe
arithmetic functions. They do not give me any hope that, in the 1990's,
we can approach optimized C performance AND do upward blocks in a
language like Self. Sorry for the long answer, I hope to be proven wrong.