Skip to Content.
Sympa Menu

charm - Re: [charm] operator overloading possible?

charm AT lists.cs.illinois.edu

Subject: Charm++ parallel programming system

List archive

Re: [charm] operator overloading possible?


Chronological Thread 
  • From: Nicolas Bock <nicolasbock AT gmail.com>
  • To: "Kale, Laxmikant V" <kale AT illinois.edu>
  • Cc: "Bohm, Eric J" <ebohm AT illinois.edu>, "charm AT cs.uiuc.edu" <charm AT cs.uiuc.edu>
  • Subject: Re: [charm] operator overloading possible?
  • Date: Tue, 18 Jun 2013 11:51:07 -0600
  • List-archive: <http://lists.cs.uiuc.edu/pipermail/charm/>
  • List-id: CHARM parallel programming system <charm.cs.uiuc.edu>

Thanks for detailed replies. The use case I have in mind is a simple matrix multiplication, where the matrices are distributed among many chares. If I understand your replies correctly, then you are suggesting to write the multiply method as:

entry void multiply (CProxy_Matrix A, CProxy_Matrix B, CProxy_Matrix C);

where $C \leftarrrow A \times B$. Is that correct? The reason I was at first aiming at operator overloading was simply that it seemed to be a more C++'ish way of writing a matrix product.

Thanks again for your help,

nick



On Tue, Jun 18, 2013 at 11:42 AM, Kale, Laxmikant V <kale AT illinois.edu> wrote:
Eric has gone on a (useful) tangent with "futures" here. But I want to repeat the simple answer: no, a chare cannot be used in the manner you indicated. Further, chares cannot  be sent as parameters in method invocations. References to chares (proxies) can be so sent.  

It'd be useful to know what use case you are trying to address, so we can (a) suggest a more fitting solution and/or (b) figure out if we should extend Charm++ in some fashion.

-- 
-- 
Laxmikant (Sanjay) Kale         http://charm.cs.uiuc.edu
Professor, Computer Science     kale AT illinois.edu
201 N. Goodwin Avenue           Ph:  (217) 244-0094
Urbana, IL  61801-2302          FAX: (217) 265-6582


From: Eric Bohm <ebohm AT illinois.edu>
Date: Tuesday, June 18, 2013 12:07 PM
To: "charm AT cs.uiuc.edu" <charm AT cs.uiuc.edu>
Subject: Re: [charm] operator overloading possible?

That usage is not currently supported in that form.   The * operator would have to be able to take two chares as messages as input, and modify the chare b with the result.  In the general case, where b is on node 1 and a is on node 2, this would have to block in order to send a request to node 2 to get copies of a.  This reduces to the semantic of having a future for remote element a. 

This case further illuminates the difficulty of naively implementing such a function in a distributed system.  To consider the operands as remote futures and naively instantiate a local copy means that we would make two copies of a, send them to node 1, and then multiply them to update the contents of b.  It would have been half as network intensive to take the square of "a" on node 2 and pass that to node 1.  However, that network optimized implementation would shift the computation to node 2, which might be undesirable from a load balance perspective. 

In general, we do not send chares as operands in messages to avoid blurring the distinction (not to mention the type inheritance confusion entanglements) between persistent parallel computational entities with a globally unique identity, and ephemeral messages which carry data between them.

Charm++ supports futures (see section 12.3 of the manual), however it supports chares containing futures or using futures, not chares as futures. 


On 06/17/2013 04:41 PM, Nicolas Bock wrote:
Hi list,

is it possible to overload an operator in Charm++? Let's say I have a chare that represents a vector and I would like to be able to do something like this:

Vector a;
Vector b;

b = a*a;

Thanks already,

nick


_______________________________________________
charm mailing list
charm AT cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/charm


_______________________________________________
charm mailing list
charm AT cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/charm





Archive powered by MHonArc 2.6.16.

Top of Page