A Thought about Multiple Cores
Jim Gettys
jg at laptop.org
Sat Jan 27 07:07:40 UTC 2007
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
More information about the Squeak-dev
mailing list
|