I committed a fix to the trunk to use the fixed size datatypes.
I don't know offhand if the reduction type you need is defined on 64 bit
types...?
On Feb 20, 2013, at 5:41 PM, Steve Angelovich wrote:
> Sorry I lost track of all the comments in the thread. Does this mean it
> is fixed or wil
Sorry I lost track of all the comments in the thread. Does this mean it
is fixed or will be fixed?
Thanks,
Steve
On 02/20/2013 02:15 PM, Jeff Squyres (jsquyres) wrote:
> I didn't misspeak in my email. :-)
>
> That being said:
>
> 1. If the Java sizes are fixed, great. It should make writing c
Sounds like the problem comes down to just 32-bit systems that fault on
unaligned 8-byte loads.
That would be SPARC, IA64 and MIPS. For IB only SPARC is relevant.
So perhaps alignment>2 should be conditional on 32-bit SPARC target.
Additionally, an experiment to see if 4-byte alignment is "good e
I waffled on this issue a bit (and talked w/ Nathan about it in IM), but with
my RM hat on, I'm giving a final ruling: no.
This is too "last second", and it's for an incredibly small set of platforms
and configuration options.
I see that the risk is pretty small for this commit, but history i
I talked to Pasha about the change. He suggests fragments are 2-byte aligned to
save space. I suspect that on 64-bit platforms the fragment size is already a
multiple of 8 bytes so this change will likely only affect 32-bit systems
(which is where the bus error is occurring).
-Nathan
On Wed, F
I would hold off, if possible, until I can investigate the issue. I don't,
off-hand, know why the 2-byte alignment, although I would suspect it's for
performance reasons.
Josh
-Original Message-
From: devel-boun...@open-mpi.org [mailto:devel-boun...@open-mpi.org] On Behalf
Of Jeff
Arrgh. I think you're going to make me eat my words
(http://www.open-mpi.org/community/lists/devel/2013/02/12143.php).
I just recently lost my access to InfiniBand test gear, so I can't test this
myself. Hypothetically, it should be fine. But throwing in an untested change
literally right
If someone wants to submit a patch in the immediate future (i.e., within the
next hour), great.
Otherwise, I'm still going to release 1.6.4 as-is.
If someone wants to submit a patch after 1.6.4 is out, that's fine -- if we
ever do 1.6.5, it can go in there.
On Feb 20, 2013, at 4:09 PM, Nathan
I didn't misspeak in my email. :-)
That being said:
1. If the Java sizes are fixed, great. It should make writing configury to
find matching C types easier (because we know what the Java sizes are).
2. George raises a good point: we support the MPI_INTx_T datatypes now, which
probably obviat
On Wed, Feb 20, 2013 at 10:28:56AM -0800, Eugene Loh wrote:
> On 02/20/13 07:54, Jeff Squyres (jsquyres) wrote:
> >All MTT testing looks good for 1.6.4. There seems to be an MPI dynamics
> >problem when --enable-spare-groups is used, but this does not look like a
> >regression to me.
> >
> >I pu
Might be just fine - need to see how many of the types have issues, how best to
correct them
On Feb 20, 2013, at 12:32 PM, George Bosilca wrote:
> That is wrong with MPI_INT64_T ? (MPI 3.0 standard page 26.)
>
> George.
>
> On Feb 20, 2013, at 21:12 , Ralph Castain wrote:
>
>>
>> On Feb 2
That is wrong with MPI_INT64_T ? (MPI 3.0 standard page 26.)
George.
On Feb 20, 2013, at 21:12 , Ralph Castain wrote:
>
> On Feb 20, 2013, at 12:08 PM, Dmitri Gribenko wrote:
>
>> On Wed, Feb 20, 2013 at 10:05 PM, Ralph Castain wrote:
>>>
>>> On Feb 20, 2013, at 11:39 AM, Dmitri Gribenko
On Feb 20, 2013, at 12:08 PM, Dmitri Gribenko wrote:
> On Wed, Feb 20, 2013 at 10:05 PM, Ralph Castain wrote:
>>
>> On Feb 20, 2013, at 11:39 AM, Dmitri Gribenko wrote:
>>
>>> On Wed, Feb 20, 2013 at 9:34 PM, Jeff Squyres (jsquyres)
>>> wrote:
If someone could write some generic java c
On Wed, Feb 20, 2013 at 10:05 PM, Ralph Castain wrote:
>
> On Feb 20, 2013, at 11:39 AM, Dmitri Gribenko wrote:
>
>> On Wed, Feb 20, 2013 at 9:34 PM, Jeff Squyres (jsquyres)
>> wrote:
>>> If someone could write some generic java code to figure out the size of a
>>> java type (and either printf
On Feb 20, 2013, at 11:39 AM, Dmitri Gribenko wrote:
> On Wed, Feb 20, 2013 at 9:34 PM, Jeff Squyres (jsquyres)
> wrote:
>> If someone could write some generic java code to figure out the size of a
>> java type (and either printf it out, or write it to a file, or otherwise be
>> able to give
On Wed, Feb 20, 2013 at 9:34 PM, Jeff Squyres (jsquyres)
wrote:
> If someone could write some generic java code to figure out the size of a
> java type (and either printf it out, or write it to a file, or otherwise be
> able to give that value to a shell script), that would be a good start.
No
On Feb 20, 2013, at 12:37 PM, Ralph Castain wrote:
>> In Java, a long is always 64 bits. In C and Objective-C, a long might be 64
>> bits, or it might be 32 bits, or (in less common cases) it might be
>> something else entirely; the C standard doesn't specify an exact bit width.
>
> So we may
On 02/20/13 07:54, Jeff Squyres (jsquyres) wrote:
All MTT testing looks good for 1.6.4. There seems to be an MPI dynamics
problem when --enable-spare-groups is used, but this does not look like a
regression to me.
I put out a final rc, because there was one more minor change to accommodate an
Here's what I found:
> In Java, a long is always 64 bits. In C and Objective-C, a long might be 64
> bits, or it might be 32 bits, or (in less common cases) it might be something
> else entirely; the C standard doesn't specify an exact bit width.
So we may need a configure test to map the Jav
All MTT testing looks good for 1.6.4. There seems to be an MPI dynamics
problem when --enable-spare-groups is used, but this does not look like a
regression to me.
I put out a final rc, because there was one more minor change to accommodate an
MXM API change; it's in the usual place:
http
I guess the question is whether a java "long" is equivalent to a C "long",
"long long", or "long int"...
Do you know? (I'm not much of a Java guy)
On Feb 19, 2013, at 7:22 PM, Steve Angelovich wrote:
> All,
>
> We ran into a problem using openmpi from java with a Java data type of long
>
Definitely looks like a bug to me. We removed the Java bindings from the
upcoming 1.7.0 release because of receiving problem reports, and several
interested people are helping to review and revise the bindings now (interested
parties are welcome to help). We hope to include an updated and cleane
22 matches
Mail list logo
