🚀 go-pugleaf

In article <benoitDI5x81.I26@netcom.com> benoit@netcom.com (schillings benoit) writes:
>Actually with 2 CPU you can hope to reach better values than with a single
>one... the reason is that you can have some balanced processed on both
>sides which will not have to context switch at all... the message works
>then like a mailbox between the two tasks... just difficult to achieve.

Right, assuming that the one task isn't waiting for the reponse of the other.
Good asynchronous design is hard to come by.  There are relatively
straight-forward server/client transactions -- but in "real" life, defering
state transition usually means passing a significant amount of your state
to the other side.  That can be a performance drag.

On the Amiga, solutions to such problems were easy -- package your state
into a good object design and build a message subsystem that deals with your
object's usecount.  When you start crossing the process boundary with all the
attendent pointer-to-pointer issue, it becomes problematic again.

Tough choices.

>Kernel messages are very critical to our performance... we keep looking
>for ways to improve it.

Well, if the 100microsecond context-switch number was accurate, and you're
getting 10,000 messages per second -- sounds like the next thing you'll want
to look at is context switch :)

-- 
David Navas  jazz@netcom.com  dnavas@us.oracle.com     P11 -- your "friend"
Minbari: "bonehead" will never mean the same thing again. (season 1)
Minbari: Things are getting hairy on Babylon 5.           (season 2)