FWIW, here's the v1.3.x bug report we review every week:
https://svn.open-mpi.org/trac/ompi/report/14
I still have one "blocker" bug (coll sm) that seems to creep
asymptotically close to completion but never seems to get all the way
there. :-(
On Sep 28, 2009, at 8:50 AM, Terry
On Sep 16, 2009, at 9:53 PM, Ralph Castain wrote:
WHAT: change the IPv6 configuration option to enable IPv6 if and
only if specifically requested
WHY: IPv6 support is only marginally maintained, and is currently
broken yet again. The current default setting is causing user
systems to
On Mon, Sep/28/2009 03:11:46PM, Ethan Mallove wrote:
> On Mon, Sep/28/2009 02:05:14PM, Jeff Squyres wrote:
> > Try a newer compiler than gcc 3.4 -- it's pretty ancient.
>
> I don't get the warning with 4.1.2 either.
To get the warning I needed to enable some developer configure options (e.g.,
I don't think we need to DECLSPEC it, do we? We don't need (or want)
this symbol to be visible at the link level when user apps link
against libmpi. You might want to put in a comment about why it's not
static so that we don't repeat this conversation again next year. ;-)
I think not
The issue isn't why or why not static, Jeff - the issue is that we get
a compiler warning whenever we do a developer build.
On Sep 29, 2009, at 2:32 PM, Jeff Squyres wrote:
I don't think we need to DECLSPEC it, do we? We don't need (or
want) this symbol to be visible at the link level when
On Sep 29, 2009, at 5:30 PM, Ralph Castain wrote:
The issue isn't why or why not static, Jeff - the issue is that we get
a compiler warning whenever we do a developer build.
Right. The initial issue was the static-ness, though -- Ethan removed
the static because some compilers were
I see a bunch of new features being added to the hwloc trunk.
Is the intent to stabilize the trunk and release, or is the intent to
add a bunch of PCI features before releasing? I kinda thought we were
trying to stabilize and release ASAP...?
--
Jeff Squyres
jsquy...@cisco.com
I have began to use hwloc, and I found it quite nice to use, but I do
have some comments and questions:
1) redundancy: for several operations, looping there are several ways
to to the same thing.
it is nice support several paradigms, but these occupy space and will
be very difficult to
Thanks for the quick answers!
On 29-set-09, at 16:59, Samuel Thibault wrote:
Fawzi Mohamed, le Tue 29 Sep 2009 16:39:47 +0200, a écrit :
Maybe I worry too much, but with machines with 1'000 of processor
coming, and maybe wanting local restricted copies to know the
topology
of the whole
Fawzi Mohamed, le Tue 29 Sep 2009 17:39:17 +0200, a écrit :
> so that in the future one could avoid storing it at least in the
> deepest levels where it is easy and relatively cheap to generate (and
> where one would have the largest savings).
Even the deepest levels would have a L1 cache level
Hi Samuel,
On 29-set-09, at 18:14, Samuel Thibault wrote:
Fawzi Mohamed, le Tue 29 Sep 2009 17:39:17 +0200, a écrit :
so that in the future one could avoid storing it at least in the
deepest levels where it is easy and relatively cheap to generate (and
where one would have the largest
Fawzi Mohamed, le Tue 29 Sep 2009 20:39:02 +0200, a écrit :
> It comes down to what you want to have, if you think you might want to
> go the sparse full granularity way then indeed alloc/copy/free should
> be added
Yes, that's my point: do we really want it?
Samuel
On 29-set-09, at 20:43, Samuel Thibault wrote:
Fawzi Mohamed, le Tue 29 Sep 2009 20:39:02 +0200, a écrit :
It comes down to what you want to have, if you think you might want
to
go the sparse full granularity way then indeed alloc/copy/free should
be added
Yes, that's my point: do we
13 matches
Mail list logo
