Skip to Content.
Sympa Menu

charm - Re: [charm] [ppl] charm Digest, Vol 58, Issue 10

charm AT lists.cs.illinois.edu

Subject: Charm++ parallel programming system

List archive

Re: [charm] [ppl] charm Digest, Vol 58, Issue 10


Chronological Thread 
  • From: Jim Phillips <jim AT ks.uiuc.edu>
  • To: Gengbin Zheng <gzheng AT illinois.edu>
  • Cc: "charm AT cs.uiuc.edu" <charm AT cs.uiuc.edu>, Evghenii Gaburov <egaburov AT dds.nl>
  • Subject: Re: [charm] [ppl] charm Digest, Vol 58, Issue 10
  • Date: Fri, 17 Aug 2012 13:07:44 -0500 (CDT)
  • List-archive: <http://lists.cs.uiuc.edu/pipermail/charm>
  • List-id: CHARM parallel programming system <charm.cs.uiuc.edu>


He wants to split a single module across multiple files.

-Jim

On Fri, 17 Aug 2012, Gengbin Zheng wrote:

Hi Evghenii,

You can write multiple ci files. One of them needs to be a
mainmodule, and then you use "extern module M" to link them together.

Gengbin

On Fri, Aug 17, 2012 at 6:36 AM, Evghenii Gaburov
<egaburov AT dds.nl>
wrote:
Dear Phil,

On a similar topic:

One thing that is really missing is the ability to use multiple .ci files for a single
module or an array. Especially, with a heavy use of a structured dagger, the single .ci
file because too cumbersome and big to maintain. I was not also able to use "include
"another_file.ci" inside a .ci file, was getting a syntax error. Ideally, it will
be great to split a module or an array, especially structured dagger implementation, among
multiple .ci files.

Is there a plan to support multiple .ci files in the near future, and if so,
when do you think it will be implemented.

Perhaps it is already in place, but I am just using it incorrectly.. Either
way, this makes me keep bouncing between AMPI and Charm, while I would
certainly prefer to use charm all the way..

Thanks!

Cheers,
Evghenii

On Aug 15, 2012, at 7:00 PM,
charm-request AT cs.uiuc.edu
wrote:

Send charm mailing list submissions to

charm AT cs.uiuc.edu

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.cs.uiuc.edu/mailman/listinfo/charm
or, via email, send a message with subject or body 'help' to

charm-request AT cs.uiuc.edu

You can reach the person managing the list at

charm-owner AT cs.uiuc.edu

When replying, please edit your Subject line so it is more specific
than "Re: Contents of charm digest..."


Today's Topics:

1. Re: [ppl] Questions about developing in Charm++ (Phil Miller)
2. Re: [ppl] Questions about developing in Charm++
(McCandless, Brian C.)


----------------------------------------------------------------------

Message: 1
Date: Tue, 14 Aug 2012 12:00:59 -0500
From: Phil Miller
<mille121 AT illinois.edu>
Subject: Re: [charm] [ppl] Questions about developing in Charm++
To: "McCandless, Brian C."
<mccandless3 AT llnl.gov>
Cc:
"charm AT cs.illinois.edu"

<charm AT cs.illinois.edu>
Message-ID:

<CAMDbWJGofKsKCqTump0bXUy0-8+2BLG=fcmgLoE6eAZOFH__6Q AT mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

On Tue, Jul 31, 2012 at 11:16 AM, McCandless, Brian C.
<mccandless3 AT llnl.gov>
wrote:
1. The error message when there is a syntax error in the .ci file is not
very helpful. I get a line number and a message that says "syntax error",
and that's it. For example, I recently had the bug of typing
"[reductionTarget]" instead of "[reductiontarget]" and the line number was
no where near my mistake. Is there a better way to find bugs like these?

This is something that we are well aware of (we write a lot of Charm++
code), and intend to fix. When there's dedicated effort toward it, we
plan to catalog various erroneous inputs and see what we can do to the
translator's grammar to get them reported cleanly. This is somewhat
difficult because we're just using yacc, but should be doable over the
next several months.

2. The other sort of error is a C++ error in the SDAG coding. Here I get
the C++ error message, but the line number is at the <chareName>_SDAG_CODE
macro. Sometimes it's easy to figure these out from the context, but
sometimes it's not. What is normally an automatic process of jumping to the
next compiler warning/error in my editor, now requires a bit more mental
energy to figure out.

This is partially addressed in the current development version, and
may be fully addressed in the development version fairly soon.

Basically, I've already implemented code to emit SDAG-generated
function definitions one-by-one in the foo.def.h file, with only their
declaration remaining inside that macro. Early reports on it so far
say that it makes this debugging much easier, including bugs
encountered at runtime and tackled with gdb, because you can actually
see the source listed there, too.

A new student in the lab, Ralf, is working on teaching the translator
to emit line number information from the original .ci file in those
function declarations. After this week, I'll have some spare cycles to
review what he's done and hopefully help wrap that up and integrate
it.

What do Charm++ developers typically do to speed up the development cycle in
these cases?

As you can hopefully get from the above: we fix it :-).

Thanks for writing, and I hope your explorations with Charm++ take you far.

Phil


------------------------------

Message: 2
Date: Tue, 14 Aug 2012 10:23:41 -0700
From: "McCandless, Brian C."
<mccandless3 AT llnl.gov>
Subject: Re: [charm] [ppl] Questions about developing in Charm++
To: Phil Miller
<mille121 AT illinois.edu>
Cc:
"charm AT cs.illinois.edu"

<charm AT cs.illinois.edu>
Message-ID:
<CC4FD6A3.8F9A%mccandless3 AT llnl.gov>
Content-Type: text/plain; charset="us-ascii"


Thanks for the replies.
The debugger issue was also a problem, so I'm glad that is being fixed as
well.

Brian


On 8/14/12 10:00 AM, "Phil Miller"
<mille121 AT illinois.edu>
wrote:

On Tue, Jul 31, 2012 at 11:16 AM, McCandless, Brian C.
<mccandless3 AT llnl.gov>
wrote:
1. The error message when there is a syntax error in the .ci file is
not
very helpful. I get a line number and a message that says "syntax
error",
and that's it. For example, I recently had the bug of typing
"[reductionTarget]" instead of "[reductiontarget]" and the line number
was
no where near my mistake. Is there a better way to find bugs like
these?

This is something that we are well aware of (we write a lot of Charm++
code), and intend to fix. When there's dedicated effort toward it, we
plan to catalog various erroneous inputs and see what we can do to the
translator's grammar to get them reported cleanly. This is somewhat
difficult because we're just using yacc, but should be doable over the
next several months.

2. The other sort of error is a C++ error in the SDAG coding. Here I
get
the C++ error message, but the line number is at the
<chareName>_SDAG_CODE
macro. Sometimes it's easy to figure these out from the context, but
sometimes it's not. What is normally an automatic process of jumping
to the
next compiler warning/error in my editor, now requires a bit more
mental
energy to figure out.

This is partially addressed in the current development version, and
may be fully addressed in the development version fairly soon.

Basically, I've already implemented code to emit SDAG-generated
function definitions one-by-one in the foo.def.h file, with only their
declaration remaining inside that macro. Early reports on it so far
say that it makes this debugging much easier, including bugs
encountered at runtime and tackled with gdb, because you can actually
see the source listed there, too.

A new student in the lab, Ralf, is working on teaching the translator
to emit line number information from the original .ci file in those
function declarations. After this week, I'll have some spare cycles to
review what he's done and hopefully help wrap that up and integrate
it.

What do Charm++ developers typically do to speed up the development
cycle in
these cases?

As you can hopefully get from the above: we fix it :-).

Thanks for writing, and I hope your explorations with Charm++ take you
far.

Phil




------------------------------

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


End of charm Digest, Vol 58, Issue 10
*************************************


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

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





Archive powered by MHonArc 2.6.16.

Top of Page