[e-lang] Re: A game developer presents needs for future language
marcs at skyhunter.com
Thu Feb 16 15:20:17 EST 2006
> So their concern is maintaining consistency in the face of multiple
> concurrent threads performing object updates over the same
> pool. There are no disconnection scenarios, no deliberate
> scenarios. And there are hundreds of thousands of updates
> per second, soon
> approaching millions. So any mechanism that slows the
> fast-path of method
> invocation -- especially creating an object in order to
> execute a message
> send, as is necessary in E -- is likely to be too slow.
Actually, not all message passing in E is that slow. I am thinking in
particular about the message passing across vats using the "boot comm"
protocol, which is one of the ways vats can talk to each other when they
share space on the same computer. To pass a pure Data object in boot comm, E
simply hands over a reference which can then be used for immediate calls,
there is no serialization. Any object that is not pure data is passed by
reference as well, but only eventual sends are allowed. In the brief
experience I had with boot comm for DonutLab, I found it easy and intuitive
to use (which is amusing because it is a little complicated to explain).
Anyway, if we compare bootcomm implementations of promise pipelining with
locks and threads, I do not think it is self-evident that locks and threads
will be faster -- after all, sometimes you'll wait on the locks (if there
were no risk of needing to wait on the locks, you wouldn't need to lock :-)
One would have to benchmark a high performance locks and threads language
against a high performance boot comm promise pipelining language. Alas,
today there is no high performance promise pipelining language to benchmark.
Well, the silver lining is, I can claim it would work just as well and no
one can prove me wrong :-)
More information about the e-lang