A Thought about Multiple Cores

> 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
>

> tim Rowledge wrote:
>> I guess we could claim that using things like the Rome/Cairo  
>> plugin is doing a modern equivalent since it is supposed to pass  
>> off most rendering chores to the GPU. If Squeak made effective use  
>> of such
>
> The main bottleneck is that in most cases we still have at least  
> one extra bitblt as Squeak doesn't support a native surface as  
> Display yet. (at least to my knowledge and what I got from  
> discussions with Bert, he can explain that in more detail than I can).