From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <9895aa081bff6e53edfa01c398576e7c@quanstro.net>
From: erik quanstrom <quanstro@quanstro.net>
Date: Tue,  3 Feb 2009 11:07:40 -0500
To: 9fans@9fans.net
In-Reply-To: <13426df10902030803q33a25285k135ee01d33f50f53@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] Pegasus 2.6 is released
Topicbox-Message-UUID: 942ecb9e-ead4-11e9-9d60-3106f5b1d025

> > Not obvious to me.  In today's (well, tomorrow's) massively multicore
> > world, I would expect a remote call to a process in another core, with
> > its own instruction cache, could easily be more efficient than a local
> > procedure call.
> >
>
> well, there's remote calls and remote calls. Remote calls that go
> through some shared memory queue are one thing. But a remote call that
> goes through the kernel? You'd better have lots of work to amortize
> that cost. The packages I've seen do not.

ignorant question.

is the cost in latency or cycles?  if the cost is latency
and your application is parallel, could the simple trick
of having multple outstanding help?

- erik