Ok, fair enough; thanks. That's a pretty good reason to not chop it any time
soon (and it's not like there's any pressure to do/not do something
immediately).
Can you keep us informed -- e.g., if your requirement ever does disappear and
it would be safe to delete this functionality from OMPI?
Hi, OMPI Community
On the call yesterday, Ralph and Jeff posed the question to the Community
at large and to NVIDIA in particular if they/we/us have a vested interest
in heterogeneous support. Mellanox and NVIDIA are partnering on systems
that, on today's roadmap, could require heterogeneous
On Mon, Apr 28, 2014 at 01:58:13PM -0400, George Bosilca wrote:
> My concern was more about the “what" factor: what do you write on remote
> memory in a heterogeneous case. I imagine you can either write the converted
> data or you can convert remotely after writing. Anyway, on both cases you
>
My concern was more about the “what" factor: what do you write on remote memory
in a heterogeneous case. I imagine you can either write the converted data or
you can convert remotely after writing. Anyway, on both cases you need
intermediary buffers to do the conversion (especially if we are
On Mon, Apr 28, 2014 at 01:44:28PM -0400, George Bosilca wrote:
>
> On Apr 28, 2014, at 13:39 , Nathan Hjelm wrote:
>
> > This part of the heterogeneous support being broken was my fault. I
> > fixed it in r31535. I will try to spend some time over the next month or
> > so
On Apr 28, 2014, at 13:39 , Nathan Hjelm wrote:
> This part of the heterogeneous support being broken was my fault. I
> fixed it in r31535. I will try to spend some time over the next month or
> so fixing heterogeneous support in the one-sided code. Right now the
> packed
This part of the heterogeneous support being broken was my fault. I
fixed it in r31535. I will try to spend some time over the next month or
so fixing heterogeneous support in the one-sided code. Right now the
packed datatype representation will not work if sizeof (int) is not
consistent. Not sure
I'm afraid I honestly don't remember the last time I tested with enable-hetero
- at least 2-3 weeks ago. I'd suggest starting ~6 months ago and see if that
still worked.
On Apr 28, 2014, at 7:04 AM, George Bosilca wrote:
> When did you tested last? I have no idea what is
Not sure about the details either, but ppc64le support was only included
in libtool recently (will be in the next release). I guess ppcle support
is only becoming a reality now, and it wasn't widely usable in the past.
Brice
Le 28/04/2014 17:17, George Bosilca a écrit :
> I’m not sure how to
I’m not sure how to interpret their claim. They say it has native support for
little endian, fact that was true for quite some time
(http://en.wikipedia.org/wiki/PowerPC#Endian_modes). Unfortunately, I could not
find any indication about the possible overhead of running little-endian
Hi George,
The Power8 can run in little-endian mode without penalty:
http://www.hpcwire.com/2014/04/23/power8-openpower-might-mean-hpc/
Not saying hetero support is unneeded, but this case may not be it.
Scott
On Apr 24, 2014, at 12:54 PM, George Bosilca wrote:
> There
When did you tested last? I have no idea what is broken so it is difficult to
assess the complexity of the fix. Let’s try to find the last working “version”
and then run a dihcotomic test to find the culprit (with s hopefully).
George.
On Apr 28, 2014, at 09:05 , Ralph Castain
I might have misunderstood Jeff's comment :
> The broken part(s) is(are) likely somewhere in the datatype and/or PML code
> (my guess). Keep in mind that my only testing of this feature is in
> *homogeneous* mode -- i.e., I compile with --enable-heterogeneous and then
> run tests on
According to Jeff's comment, OpenMPI compiled with
--enable-heterogeneous is broken even in an homogeneous cluster.
as a first step, MTT could be ran with OpenMPI compiled with
--enable-heterogenous and running on an homogeneous cluster
(ideally on both little and big endian) in order to identify
So it sounds like we may have a test platform, which leaves the question of
repair
George: can you give us some idea of what was broken and/or pointers on what
needs to be done to repair it?
On Apr 25, 2014, at 4:34 AM, Adrian Reber wrote:
> On Fri, Apr 25, 2014 at
On Fri, Apr 25, 2014 at 10:29:36AM +, Jeff Squyres (jsquyres) wrote:
> On Apr 25, 2014, at 6:13 AM, Gilles Gouaillardet
> wrote:
>
> > it is possible to use qemu in order to emulate unavailable hardware.
> > for what it's worth, i am now running a ppc64 qemu
On Apr 25, 2014, at 6:13 AM, Gilles Gouaillardet
wrote:
> it is possible to use qemu in order to emulate unavailable hardware.
> for what it's worth, i am now running a ppc64 qemu emulated virtual
> machine on an x86_64 workstation.
> this is pretty slow (2 hours
On Apr 24, 2014, at 12:05 PM, Andreas Schäfer wrote:
> Hey,
>
> On 14:49 Thu 24 Apr , George Bosilca wrote:
>> On Thu, Apr 24, 2014 at 1:06 PM, Jeff Squyres (jsquyres)
>> wrote:
>>> The code is unused. It has been unused for a long time. It is
>>
Hey,
On 14:49 Thu 24 Apr , George Bosilca wrote:
> On Thu, Apr 24, 2014 at 1:06 PM, Jeff Squyres (jsquyres)
> wrote:
> > The code is unused. It has been unused for a long time. It is
> unlikely to be fixed.
We'd be using it, probably not in production, but in research
On Thu, Apr 24, 2014 at 1:06 PM, Jeff Squyres (jsquyres)
wrote:
> On Apr 24, 2014, at 12:54 PM, George Bosilca wrote:
>
>> There seems to be an opportunity to still have heterogeneous environment in
>> the future.
>>
There seems to be an opportunity to still have heterogeneous environment in the
future.
http://www.enterprisetech.com/2014/04/23/ibm-google-show-power8-systems-openpower-efforts/
I don’t think it is fair to shift the burden on the original developer instead
of the committer who broke a feature.
21 matches
Mail list logo