Skip to Content.
Sympa Menu

charm - Re: [charm] Reduction on std::vector

charm AT lists.cs.illinois.edu

Subject: Charm++ parallel programming system

List archive

Re: [charm] Reduction on std::vector


Chronological Thread 
  • From: Sam White <white67 AT illinois.edu>
  • To: Jozsef Bakosi <jbakosi AT lanl.gov>
  • Cc: "charm AT lists.cs.illinois.edu" <charm AT lists.cs.illinois.edu>
  • Subject: Re: [charm] Reduction on std::vector
  • Date: Thu, 3 May 2018 16:15:41 -0500
  • Authentication-results: illinois.edu; spf=pass smtp.mailfrom=samt.white AT gmail.com; dkim=pass header.d=gmail.com header.s=20161025; dkim=pass header.d=illinois-edu.20150623.gappssmtp.com header.s=20150623; dmarc=none header.from=illinois.edu

I don't think we've ever encountered that issue. Our per-commit and nightly tests all run charm/examples/charm++/reductions/typed_reduction, which has [reductiontarget] entry methods with the following signatures:

entry [reductiontarget] void typed_array_ints_done(int results[n], int n);

entry [reductiontarget] void typed_indiv_ints_done(int x, int y, int z);

entry [reductiontarget] void typed_array_doubles_done(int n, double results[n]);

Each reduction target method contains assertions that the results are correct, and I don't remember ever seeing a failure in those tests.

-Sam


On Thu, May 3, 2018 at 3:58 PM, Jozsef Bakosi <jbakosi AT lanl.gov> wrote:
Another question: Have you guys ever encountered a problem with a reduction that
used the target in the form of

      entry [reductiontarget] void minstat(double min[n], int n);

that was contributed to with the absolutely certainly correct size array as

std::array< double, 2 > sum{{ 0.0, 0.0 }};
contribute( sum.size()*sizeof(double), sum.data(), CkReduction::sum_double, cb );

yet it had the wrong value n in the reduction target? Very occasionally (e.g., 1
of 50K builds), this is triggered for me (by an assert), and I have no clue how
to even begin thinking about this.

For now, I'm replacing my reduction target to take a list of doubles, as in

     entry [reductiontarget] void minstat(double min1, double min2);

instead of the 1st version because n is not large, but I wonder if I am just
sweeping this problem under the rug by not even being able to test for the
number doubles received. (I.e., if I still have this problem, now min2 might
just not be valid at all - which will just be the wrong result and error later.)

This is very curious...any clue is appreciated.

J

On 05.03.2018 14:41, Jozsef Bakosi wrote:
> Thanks, that makes sense. Thanks for the help.
> J
>
> On 05.03.2018 15:35, Sam White wrote:
> > [reductiontarget] entry methods are not type-safe, and you can't overload
> > them currently. We have a related issue to this open right now:
> > https://charm.cs.illinois.edu/redmine/issues/1700
> >
> > There is no difference between the following:
> >     1. entry [reductiontarget] void minstat(double min[n], int n);
> >     2. entry [reductiontarget] void minstat(int n, double min[n]);
> >
> > -Sam
> >
> > On Thu, May 3, 2018 at 3:16 PM, Jozsef Bakosi <jbakosi AT lanl.gov> wrote:
> >
> > > Cool, thanks, Sam. Both versions work.
> > >
> > > However, I am now curious about the 2nd one: If I can contribute a
> > > std::vector
> > > with a size determined at runtime to a reduction, how can you guys find the
> > > right overload at compile-time for the target using the 2nd version? That
> > > seem
> > > fishy to me, or at least not type-safe.
> > >
> > > In particular, it also appears to work with
> > >
> > >      entry [reductiontarget] void minstat(double min1, double min2, double
> > > min3);
> > >
> > > And if I use min3 I risk formatting the internet? ;-)
> > >
> > > Another question: I have so far been using
> > >
> > >      entry [reductiontarget] void minstat(double min[n], int n);
> > >
> > > but
> > >
> > >      entry [reductiontarget] void minstat(int n, double min[n]);
> > >
> > > also works. Is there a reason to prefer one over the other? Are they just
> > > overloads of the same?
> > >
> > > J
> > >
> > > On 05.03.2018 14:45, Sam White wrote:
> > > > The [reductiontarget] entry method still needs to take a C-style array
> > > of N
> > > > doubles as its argument or separate doubles, despite now being able to
> > > > contribute a std::vector directly to the reduction. So it should like
> > > this:
> > > >
> > > >     entry [reductiontarget] void minstat(int n, double min[n]);
> > > >
> > > > or this:
> > > >
> > > >     entry [reductiontarget] void minstat(double min1, double min2);
> > > >
> > > >
> > > > We'll update our documentation to make this clear.
> > > >
> > > > -Sam
> > > >
> > > > On Thu, May 3, 2018 at 2:31 PM, Jozsef Bakosi <jbakosi AT lanl.gov> wrote:
> > > >
> > > > > Hi folks,
> > > > >
> > > > > I'm trying do a reduction on a std::vector:
> > > > >
> > > > > std::vector< double > min{ 1.0, 1.0 };
> > > > >
> > > > > contribute( min, CkReduction::min_double,
> > > > >   CkCallback(CkReductionTarget(Target,minstat), target) );
> > > > >
> > > > > with
> > > > >
> > > > > chare Target {
> > > > >   entry [reductiontarget] void minstat( std::vector< double > d );
> > > > > }
> > > > >
> > > > > class Target : public CBase_Target {
> > > > >   public:
> > > > >     void minstat( std::vector< double > d ) {
> > > > >        ...
> > > > >     }
> > > > > }
> > > > >
> > > > > However, I get:
> > > > >
> > > > > 161: ------------- Processor 0 Exiting: Called CmiAbort ------------
> > > > > 161: Reason: Unhandled C++ exception in user code.
> > > > > 161:
> > > > > 161: [0] Stack Traceback:
> > > > > 161:   [0:0] CmiAbortHelper+0xc1  [0x7fffe75ccfc1]
> > > > > 161:   [0:1] +0x7148  [0x7fffe75ca148]
> > > > > 161:   [0:2] +0x17cb88  [0x7fffe7d59b88]
> > > > > 161:   [0:3] +0x17cb69  [0x7fffe7d59b69]
> > > > > 161:   [0:4] +0x22763  [0x7fffe5536763]
> > > > > 161:   [0:5] +0x25516  [0x7fffe5539516]
> > > > > 161:   [0:6] +0x254af  [0x7fffe55394af]
> > > > > 161:   [0:7] std::__1::__vector_base_common<true>::__throw_length_
> > > error()
> > > > > const+0x44  [0x7fffe57e00a4]
> > > > > 161:   [0:8] std::__1::vector<double, std::__1::allocator<double>
> > > > > >::__append(unsigned long)+0x139  [0x5aaf59]
> > > > > 161:   [0:9] std::__1::vector<double, std::__1::allocator<double>
> > > > > >::resize(unsigned long)+0x7b  [0x5aa9db]
> > > > > 161:   [0:10] void PUP::operator|<double>(PUP::er&,
> > > > > std::__1::vector<double, std::__1::allocator<double> >&)+0x44
> > > [0x5aa884]
> > > > > 161:   [0:11] _ZN3PUP6detailorINSt3__16vectorIdNS2_
> > > 9allocatorIdEEEEEEvRNS_
> > > > > 2erERNS0_21TemporaryObjectHolderIT_Xsr3std16is_constructibleINS_
> > > > > 11reconstructESA_EE5valueEEE+0x1d  [0x5b204d]
> > > > > 161:   [0:12] inciter::CkIndex_Transporter::
> > > _call_redn_wrapper_minstat_marshall11(void*,
> > > > > void*)+0x80  [0x7ffff649d6f0]
> > > > > 161:   [0:13] CkDeliverMessageFree+0x41  [0x7fffe7d73b21]
> > > > > 161:   [0:14] +0x19763b  [0x7fffe7d7463b]
> > > > > 161:   [0:15] +0x19ecfb  [0x7fffe7d7bcfb]
> > > > > 161:   [0:16] +0x199496  [0x7fffe7d76496]
> > > > > 161:   [0:17] _processHandler(void*, CkCoreState*)+0x245
> > > [0x7fffe7d75a85]
> > > > > 161:   [0:18] CmiHandleMessage+0x97  [0x7fffe735faa7]
> > > > > 161:   [0:19] CsdScheduleForever+0xc4  [0x7fffe735fdd4]
> > > > > 161:   [0:20] CsdScheduler+0x1a  [0x7fffe735fafa]
> > > > > 161:   [0:21] +0x9c91  [0x7fffe75ccc91]
> > > > > 161:   [0:22] ConverseInit+0x6c3  [0x7fffe75cc543]
> > > > > 161:   [0:23] main+0x45  [0x7fffe825e755]
> > > > > 161:   [0:24] __libc_start_main+0xe7  [0x7fffe4d45a87]
> > > > > 161:   [0:25]   [0x4bd00a]
> > > > >
> > > > > I also tried with
> > > > >   entry [reductiontarget] void minstat( const std::vector< double >& d
> > > );
> > > > > and
> > > > >     void minstat( const std::vector< double >& d ) {
> > > > >
> > > > > yielding the same problem. Can someone enlighten me on how to reduce a
> > > > > std::vector?
> > > > >
> > > > > Thanks,
> > > > > Jozsef




Archive powered by MHonArc 2.6.19.

Top of Page