Dave,
Tonight's trunk tarball built successfully on the effected system.
Thanks,
-Paul
On Tue, Feb 11, 2014 at 11:19 AM, Dave Goodell (dgoodell) <
dgood...@cisco.com> wrote:
> Should be fixed on trunk by r30674. It's been CMRed to v1.7.5 here:
> https://svn.open-mpi.org/trac/ompi/ticket/4254
Things are looking relatively good - I see two recurring failures:
1. idx_null - no idea what that test does, but it routinely fails
2. intercomm_create - this is the 3-way connect/accept/merge. Nathan - I
believe you had a fix for that?
Ralph
On Tue, Feb 11, 2014 at 08:09:35PM +, Jeff Squyres (jsquyres) wrote:
> On Feb 8, 2014, at 4:49 PM, Adrian Reber wrote:
>
> >> I note you have a stray $3 at the end of your configure.m4, too (it might
> >> supposed to be $2?).
> >
> > I think I do not really understand configure.m4 and was h
On Feb 8, 2014, at 4:49 PM, Adrian Reber wrote:
>> I note you have a stray $3 at the end of your configure.m4, too (it might
>> supposed to be $2?).
>
> I think I do not really understand configure.m4 and was happy to just
> copy it from blcr. Especially what $2 and $3 mean and how they are
> s
I've added better error messages in the trunk, scheduled to move over to 1.7.5.
I don't see anything in the code that would explain why we don't pickup and use
ib0 if it is present and specified in if_include - we should be doing it.
For now, can you run this with "-mca oob_base_verbose 100" on
Should be fixed on trunk by r30674. It's been CMRed to v1.7.5 here:
https://svn.open-mpi.org/trac/ompi/ticket/4254
-Dave
On Feb 11, 2014, at 11:00 AM, Jeff Squyres (jsquyres)
wrote:
> Excellent; thanks Paul. We're having a look.
>
> On Feb 8, 2014, at 6:50 PM, Paul Hargrove wrote:
>
>> W
Excellent; thanks Paul. We're having a look.
On Feb 8, 2014, at 6:50 PM, Paul Hargrove wrote:
> With Ralph's announcement that oshmem had been merged to v1.7 I started tests
> on lots of systems.
> When I found the problem described below, I tried the 1.7.4 release, I found
> the problem exis
+1
On Feb 11, 2014, at 9:25 AM, Andreas Schäfer
wrote:
> On 15:20 Tue 11 Feb , Christoph Niethammer wrote:
>> Ah and some restults for MPI_Dims_create(100, 3, {})
>>
>> original: 8.110628 sec
>> optimized-primes: 0.048702 sec
>> optimized-factorization: 0.13 sec
>
> Awesome! I did
On Feb 10, 2014, at 6:14 PM, Jeff Squyres (jsquyres) wrote:
> As a side effect, this means that -- for 32 bit builds -- we will not support
> large filesystems well (e.g., filesystems with 64 bit offsets). BlueGene is
> an example of such a system (not that OMPI supports BlueGene, but...).
To
On 15:20 Tue 11 Feb , Christoph Niethammer wrote:
> Ah and some restults for MPI_Dims_create(100, 3, {})
>
> original: 8.110628 sec
> optimized-primes: 0.048702 sec
> optimized-factorization: 0.13 sec
Awesome! I didn't expect that nested loop for checking whether a
factor would still
Hello,
Minor update as a little bug and an unused variable were left over in the patch.
I'll commit this + the parameter check change later.
Anybody volunteering for review of a cmr for 1.7.5. :)
Ah and some restults for MPI_Dims_create(100, 3, {})
original: 8.110628 sec
optimized-primes: 0
Hi,
ah, that's clever indeed!
Best
-Andreas
On 12:02 Tue 11 Feb , Christoph Niethammer wrote:
> Hello,
>
> After rethinking Jeff's comments about caching prime numbers I came to the
> conclusion that we can omit the prime numbers at all and go directly for the
> factorization. :D
> We th
Hello,
After rethinking Jeff's comments about caching prime numbers I came to the
conclusion that we can omit the prime numbers at all and go directly for the
factorization. :D
We then only need at most log_2(INT_MAX) * sizeof(int) = 32 * 4 byte = 128
byte of memory for the factors.
Comput
Dear Open MPI developer,
I.
we see peculiar behaviour in the new 1.7.4 version of Open MPI which is a change
to previous versions:
- when calling "mpiexec", it returns "1" and exits silently.
The behaviour is reproducible; well not that easy reproducible.
We have multiple InfiniBand islands i
OK, so we were thinking the same thing :-) The optimization you
mention below is the same I've used in my updated patch.
On 02:29 Tue 11 Feb , Christoph Niethammer wrote:
> As mentioned in my former mail I did not touch the factorization
> code.
> But to figure out if a number n is *not* a pr
Christoph-
Jeff is right, the largest prime p we need to precompute is p <
sqrt(2^31), so in total we'd get away with a dozen kB of RAM. The only
prime in the factorization we'd not catch this way can be retrieved
later on during the factorization.
But I agree with you that's it's not really wort
On 19:12 Mon 10 Feb , Jeff Squyres (jsquyres) wrote:
> 1. Should we cache generated prime numbers? (if so, it'll have to be done in
> a thread-safe way)
The code I've submitted in the other thread is much faster than the
original code (e.g. 100x faster for 1 nodes, the ratio increases
wi
17 matches
Mail list logo
