We've been doing this with X since 1984....

It always confounded some people that apps would work faster across the
network than locally.

So yes, MP's help performance this way, with a suitable implementation
with queuing.
                                     - Jim


On Fri, 2007-01-26 at 22:41 -0800, Dan Ingalls wrote:
> In 1978 we built a Smalltalk to run on the NoteTaker, an experimental 
> somewhat portable (we called it *trans* portable ;-) computer with an 
> 8-MHz (this was considered fast ;-) 8086 processor.  In addition to 
> the ST processor board, there was an I/O board with a 4-MHz 8086, and 
> also an Ethernet board with an 8-MHz 8086.  We got ST going on it, 
> and it actually ran pretty well.
> 
> But you know how it is -- faster is always better.  We weren't doing 
> anything with the Ethernet board, and I started to get ideas...
> 
> This was the first Smalltalk that did all graphics with BitBlt and 
> Smalltalk so, eg, while displaying text, there was as much work 
> running the bytecodes to pick characters and set up BitBlt as there 
> was to actually do the BitBlt operations.  So it occurred to me to 
> have the BitBlt primitive simply put BitBlt requests on a queue, and 
> then use the Etherenet processor to read the queue and do the actual 
> Blt.  I can't believe that I actually did this, but the truth is that 
> it worked beautifully.  We only used it a few times because there was 
> only one working Ethernet board (for that matter there was usually 
> only one working NoteTaker ;-) but the result was nearly a full 
> factor of two improvement in how the UI behaved.  Obviously care had 
> to be taken to wait for completion when the destination was not the 
> Display, but it's easy to check and occurs relatively infrequently. 
> [I can't remember, but I think I simply ran these in the ST processor 
> rather than queuing them for the Ether processor, so in some cases 
> BitBlt could actually be running in *both* processors]
> 
> So this is just a suggestion that, when multiple cores are available, 
> Squeak might well run such things as screen updates almost twice as 
> fast if we put the BitBlt engine (ie everything after the tests for 
> failures) in a separate thread from the rest of Squeak.  What's nice 
> is that it's a very local change with *no* impact to the rest of 
> Squeak except to make things run faster.
> 
> If someone has suggested this already I apologize -- I get behind on 
> my email sometimes.
> 
> 	- Dan
> 
-- 
Jim Gettys
One Laptop Per Child