I just wanted to add my last comment since this discussion seems to be
very hot! As Jeff
mentioned while a process is waiting to receive a message it doesn't
really matter if it uses
blocking or polling. What I really meant was that blocking can be useful
to use CPU cycles to
handle other
On Apr 24, 2008, at 9:09 AM, Adrian Knoth wrote:
On Thu, Apr 24, 2008 at 08:25:44AM -0400, Alberto Giannetti wrote:
I am using one of the nodes as a desktop computer. Therefore it is
most important for me that the mpi program is not so greedily
acquiring cpu time.
From a
Barry Rountree schrieb:
> On Thu, Apr 24, 2008 at 12:56:03PM +0200, Ingo Josopait wrote:
>> I am using one of the nodes as a desktop computer. Therefore it is most
>> important for me that the mpi program is not so greedily acquiring cpu
>> time.
>
> This is a kernel scheduling issue, not an
What George said is what I meant by "it's a non-trivial amount of
work." :-)
In addition to when George adds these patches (allowing components to
register for blocking progress), there's going to be some work to deal
with shared memory (we have some ideas here, but it's a bit more than
Well, blocking or not blocking this is the question !!! Unfortunately,
it's more complex than this thread seems to indicate. It's not that we
didn't want to implement it in Open MPI, it's that at one point we had
to make a choice ... and we decided to always go for performance first.
On Apr 24, 2008, at 6:56 AM, Ingo Josopait wrote:
I am using one of the nodes as a desktop computer. Therefore it is
most
important for me that the mpi program is not so greedily acquiring cpu
time.
From a performance/usability stand, you could set interactive
applications on higher
I am using one of the nodes as a desktop computer. Therefore it is most
important for me that the mpi program is not so greedily acquiring cpu
time. But I would imagine that the energy consumption is generally a big
issue, since energy is a major cost factor in a computer cluster. When a
cpu is
