A simple but less elegant solution would be to pack two contiguous arrays - one
of the string lengths in an integer vector and another of all the strings
concatenated into a vector and broadcast both. Of course you could hide
all this cruft inside a broadcast(vector) specialization, which does
On Tue, Oct 30, 2012 at 6:06 AM, Kirk, Benjamin (JSC-EG311) <
benjamin.kir...@nasa.gov> wrote:
> A simple but less elegant solution would be to pack two contiguous arrays
> - one of the string lengths in an integer vector and another of all the
> strings concatenated into a vector and broadcast bo
On Tue, 30 Oct 2012, Cody Permann wrote:
Actually now that I think about it, those strings come out of the
Exodus API as char arrays anyway. We convert them to strings after
the fact.
This solution really isn't that bad especially since we
can just leave them in their native formats long en
On Tuesday, October 30, 2012, Kirk, Benjamin (JSC-EG311) wrote:
> A simple but less elegant solution would be to pack two contiguous arrays
> - one of the string lengths in an integer vector and another of all the
> strings concatenated into a vector and broadcast both. Of course you
> could hide
> On Tuesday, October 30, 2012, Kirk, Benjamin (JSC-EG311) wrote:
>> A simple but less elegant solution would be to pack two contiguous arrays -
>> one of the string lengths in an integer vector and another of all the
>> strings concatenated into a vector and broadcast both. Of course you
>> co
On Tue, 30 Oct 2012, Kirk, Benjamin (JSC-EG311) wrote:
> The API convenience of Parallel::broadcast(std::vector &v) is
> probably still worth it though, even if this is the implementation of choice.
In cases where we have to repack a container's contents for MPI
anyway, there's really no reason
On Tue, Oct 30, 2012 at 9:55 AM, Roy Stogner wrote:
> The only downside I can see is that "broadcast(stuff)" is more terse
> than "broadcast(stuff.begin(), stuff.end())".
>
To me, this is a pretty big downside. I love the simplicity of
broadcast(stuff). If you want to make broadcast(stuff) turn
On Thu, Oct 25, 2012 at 1:43 PM, Lorenzo Botti wrote:
> http://epubs.siam.org/doi/abs/10.1137/110830125
> I guess you already know this work...
Wow, the matrix multiplication results (Fig. 2) in this paper are
pretty damning for "traditional" ETs (Blitz++ and UBLAS).
That's something I was not a
On Tue, 30 Oct 2012, Derek Gaston wrote:
On Tue, Oct 30, 2012 at 9:55 AM, Roy Stogner wrote:
The only downside I can see is that "broadcast(stuff)" is more terse
than "broadcast(stuff.begin(), stuff.end())".
To me, this is a pretty big downside. I love the simplicity of
broadcast
On Tue, Oct 30, 2012 at 10:16 AM, Roy Stogner wrote:
>
> Anyone know of an existing traits class where the equivalent of
> that_traits_class::is_container specializes to true for container
> types (i.e. any types returning iterators from begin() and end()) T?
> It would be easy to create one but I
On Tue, 30 Oct 2012, Roy Stogner wrote:
On Tue, 30 Oct 2012, Derek Gaston wrote:
On Tue, Oct 30, 2012 at 9:55 AM, Roy Stogner
wrote:
The only downside I can see is that "broadcast(stuff)" is more terse
than "broadcast(stuff.begin(), stuff.end())".
To me, this is a pretty big d
> As long as I'm asking about Parallel:: design decisions - what's the
> intended usage for the DataType argument to our methods which take
> containers-of-T? I understand that for non-built-in types we need to
> tell MPI how to send them, but that can be done by specializing
> StandardType. It
On Tue, 30 Oct 2012, Kirk, Benjamin (JSC-EG311) wrote:
>> As long as I'm asking about Parallel:: design decisions - what's the
>> intended usage for the DataType argument to our methods which take
>> containers-of-T? I understand that for non-built-in types we need to
>> tell MPI how to send the
On Tue, 30 Oct 2012, Roy Stogner wrote:
> I'm considering deprecating the input DataType method versions, but
> I'm very wary of taking something like that away if there's a use case
> I just didn't think of...
Ah, wait, here's a hypothetical case: the StandardType-based code
does a construction
On Tue, 30 Oct 2012, Roy Stogner wrote:
> As long as I'm asking about Parallel:: design decisions
Here's another one - since it's going to get much more important, do
we want to shorten the name of libMesh::Parallel::Communicator_World
and/or take it up a namespace?
Going from e.g. "Parallel::s
On Wed, 24 Oct 2012, Paul T. Bauman wrote:
On Wed, Oct 24, 2012 at 12:32 PM, Roy Stogner wrote:
This is such an aesthetic improvement over the mess of default
Communicator arguments in parallel.h that I'd be tempted to change to
something like your proposed API regardless of
On Tue, Oct 30, 2012 at 5:04 PM, Roy Stogner wrote:
>
> Extra testing would be appreciated.
>
Applying the patch and running one of the grins examples as is with all mpi
or mpi+threads worked fine for me.
--
Everyone hate
17 matches
Mail list logo
