On Dec 4, 2007 2:53 PM, Robert G. Brown <[EMAIL PROTECTED]> wrote:
> On Mon, 3 Dec 2007, [EMAIL PROTECTED] wrote:
>
> > impossibility. I am still waiting to get a straight flush in 5-card
> > draw.
>
> Are ye, now... interesting.
>
> Sometime we'll have to wait together. In the meantime, I find t
On Sun, Dec 02, 2007 at 03:51:53PM +0100, Toon Knapen wrote:
> Mark Hahn wrote:
> >>IMHO the hybris approach (MPI+threads) is interesting in case every
> >>MPI-process has lots of local data.
> >
> >yes. but does this happen a lot? the appealing case would be threads
> >that make lots of heavy u
On Mon, 3 Dec 2007, [EMAIL PROTECTED] wrote:
impossibility. I am still waiting to get a straight flush in 5-card
draw.
Are ye, now... interesting.
Sometime we'll have to wait together. In the meantime, I find that if
you play the game with a wild card or eight it alters the odds
magnificent
On Mon, Dec 03, 2007 at 10:29:56PM +, [EMAIL PROTECTED] wrote:
> True, enough ... one must consider both the kinetic and
> thermodynamic requirements for existence, but I was thinking that the
> system was perhaps at equilibrium by now.
No, people keep on producing hybrid codes and finding th
Greg Lindahl wrote:
On Mon, Dec 03, 2007 at 09:47:41PM +, [EMAIL PROTECTED] wrote:
I think that the number of real-world apps in this class is perhaps
not large, or there would be more hybrid code.
Ah, but you've missed the random element here: People start writing
hybrid code before they
-- Original message --
From: Greg Lindahl <[EMAIL PROTECTED]>
> On Mon, Dec 03, 2007 at 09:47:41PM +, [EMAIL PROTECTED] wrote:
>
> > I think that the number of real-world apps in this class is perhaps
> > not large, or there would be more hybrid code.
>
> Ah, bu
On Mon, Dec 03, 2007 at 09:47:41PM +, [EMAIL PROTECTED] wrote:
> I think that the number of real-world apps in this class is perhaps
> not large, or there would be more hybrid code.
Ah, but you've missed the random element here: People start writing
hybrid code before they have any proof that
-- Original message --
From: Håkon Bugge <[EMAIL PROTECTED]>
> I have a slightly different view. Hybrid
> programming is used for performance reasons, but
> only in cases where parallelization (to the same
> level) is impossible/impractical using the pure
> MPI mode,
On Mon, Dec 03, 2007 at 10:11:51AM +0100, H?kon Bugge wrote:
> But
> there are cases where you cannot; a) the
> "decomposition parallel efficiency" is not good
> enough or b) the processes need a huge (shared) table.
You can accomplish (b) using a mmaped file, which is much easier than
hybrid
At Sat, 1 Dec 2007 15:15:31,Greg Lindahl <[EMAIL PROTECTED]> wrote:
> The SPEC HPG (High Performance Group) is having discussions about using
> a hybrid of MPI and thread-level parallelism on the SPEC MPI2007
> benchmark suite.
I'd find it useful to debunk the notion that hybrid programming
actu
On Dec 2, 2007 1:15 AM, Greg Lindahl <[EMAIL PROTECTED]> wrote:
> On Thu, Nov 29, 2007 at 11:26:45AM -0800, Tom Elken wrote:
>
> > The SPEC HPG (High Performance Group) is having discussions about using
> > a hybrid of MPI and thread-level parallelism on the SPEC MPI2007
> > benchmark suite.
>
> I'
Mark Hahn wrote:
IMHO the hybris approach (MPI+threads) is interesting in case every
MPI-process has lots of local data.
yes. but does this happen a lot? the appealing case would be threads
that make lots of heavy use of some large data, _but_
without needing synchronization/locking. once
On Sun, Dec 02, 2007 at 12:05:50PM +0200, Eray Ozkural wrote:
> I wouldn't be so sure!
>
> Sounds like a great match for clusters of multi-core architectures.
People said the same thing when SMP became common on the low end.
> And obviously many papers have been written about programming cluste
On Thu, Nov 29, 2007 at 11:26:45AM -0800, Tom Elken wrote:
> The SPEC HPG (High Performance Group) is having discussions about using
> a hybrid of MPI and thread-level parallelism on the SPEC MPI2007
> benchmark suite.
I'd find it useful to debunk the notion that hybrid programming
actually gives
IMHO the hybris approach (MPI+threads) is interesting in case every
MPI-process has lots of local data.
yes. but does this happen a lot? the appealing case would be
threads that make lots of heavy use of some large data, _but_
without needing synchronization/locking. once you need locking
a
IMHO the hybris approach (MPI+threads) is interesting in case every
MPI-process has lots of local data.
If you have a cluster of quad-cores, you might either have one process per
node with each process using 4 threads or put one mpi-process per core. The
latter is simpler because it only requires
Many problems decompose well in large chunks that are well done
with MPI on different nodes, and tight loops that are best done
locally with shared memory processors.
I think the argument against this approach is more based on practice
than principles. hybrid parallelism certainly is possible,
Many problems decompose well in large chunks that are well done
with MPI on different nodes, and tight loops that are best done
locally with shared memory processors. In such problems one can
use both types of parallelisms well. My understanding of non-thread
safe MPI is that one should avoid ha
provide some thread-level parallelism on a cluster where you primarily
use MPI to achieve your parallel execution.*
either threads for low-investment newbie parallelism
or MPI for serious scalability.
Have you used compiler auto-parallel features mixed with MPI with
success on your clusters?
19 matches
Mail list logo
