> Standard block dist, with no flags. Average time: 0.84 sec
>
> ...
>
> My custom dist, with no flags. Average time: 1.46 sec
>
> ...
FWIW, I wouldn't waste too much time doing performance comparisons/comm
counts of non--fast compiles. The runtime checks that we do are only
going to add noise, and you wouldn't want to run in this mode in any
serious study. So I'd suggest using it for debugging new code, but saving
yourself that axis in any analysis.
> Standard block dist, with --no-local --fast. Average time: 0.68 sec
>
> (get = 4236, get_nb = 0, put = 0, put_nb = 0, test_nb = 0, wait_nb = 0,
> try_nb = 0, fork = 0, fork_fast = 0, fork_nb = 1602) (get = 823, get_nb
> = 0, put = 0, put_nb = 0, test_nb = 0, wait_nb = 0, try_nb = 0, fork =
> 1608, fork_fast = 0, fork_nb = 0)
>
>
> My custom dist, with --no-local --fast. Average time: 0.95 sec
>
> (get = 4236, get_nb = 0, put = 0, put_nb = 0, test_nb = 0, wait_nb = 0,
> try_nb = 0, fork = 0, fork_fast = 0, fork_nb = 1602) (get = 5633, get_nb
> = 0, put = 0, put_nb = 0, test_nb = 0, wait_nb = 0, try_nb = 0, fork =
> 1608, fork_fast = 0, fork_nb = 0)
>
>
>
> I was a bit surprised about how much faster standard block dist was,
> because in my previous tests the overhead was significantly smaller. Is
> it possible that there have been some changes in chapel git (during last
> month) which could be causing this?
I'm not sure offhand. Our nightly performance graphs are available here,
with annotations added when there are significant changes that we can
explain:
http://chapel.sourceforge.net/perf/
These are all single-locale configurations, though sometimes tests
that are run in a --no-local mode can show changes that would also
indicate similar changes for multi-locale tests.
We've recently started working on adding multi-locale nightly performance
graphs as well, but they're not publicly part of this page just yet.
> I guess it would be simplest to go back to block dist and start building
> my own dist from it step by step while monitoring performance and comm
> stats. After all, modifications I made were by no means extensive, most
> of the time was spent investigating the existing code.
Perhaps. The technique of asserting that things are where you'd expect it
to be might also bear some fruit. As I say, it continues to look to me as
though something that you think should be on locale 1 is actually on
locale 0 for some reason. E.g., if the entire local array or domain class
were on the wrong locale, it seems like it could result in communication
patterns like this.
(I'll mention in passing that a professor from WWU is currently working on
the design and implementation of a Chapel visual debugging tool with the
goal of rendering how a program is executing in a way that would hopefully
help catch locality errors like this which can be difficult to detect
visually in the source code.
> Another question, is it possible to use config param to determine which
> modules to use? I tried normal conditionals, but that gives me invalid
> use of module -error.
If I'm understanding properly, I don't think there is at present using
config params. The challenge is that conditionals on config params
introduce new lexical scopes, so I find myself often wanting to do things
like:
if myParamTest then
var x: int;
else
var x: real;
...x...
but this doesn't work because the scope of 'x' is the branch of the
conditional, so it's out of scope by the time the conditional ends. In
many cases, you can switch to a conditional expression:
var x: if myParamtest then int else real;
or a function:
var x: myTypeFunction(myParamTest);
but for module uses, I don't think this is an option.
Note that if the goal of your question is to switch between two
distributions, this could be done by use-ing both modules and then using a
conditional like the above to specify which dmap to use. We do this sort
of thing in [test/release/]examples/benchmarks/lulesh and .../miniMD for
example.
For switching between different modules, I think the way we typically deal
with it at present is to name two modules the same thing, put them in
different directories, and use different -M options to choose between them
(or name the files diferent things, have them declare their modules
explicitly, and name them on the command-line).
Note that I/we have had a long-standing desire to have a simplified
version of param conditionals that could be evaluated early (near parse
time) and not introduce lexical scopes in order to get a cpp-style
#if/#ifdef-like capability in the language for cases like this, but
nobody's pushed on it hard enough to propose a design that has stuck.
We're definitely open to inspiration here.
> Also, I have a constructor defined as
>
> proc MyPolicy(boundingBox: domain, param rank=boundingBox.rank, type
> idxType=boundingBox.idxType, targetLocs: [] locale = Locales,
> relCutTable: [] real)
>
> How could I have relCutTable's default value to be an array filled with
> 1.0s, with same domain as targetLocs?
Do either of these work?
relCutTable: [targetLocs.domain] real = 1.0
or:
targetLocs: [?tld] locale = Locales,
relCutTable: [tld] real = 1.0
If not, let me know. (in which case, a lame workaround would be to create
two constructors, one of which takes relCutTable, the other of which
doesn't. If you could forward constructors (something we're currently
planning for), this wouldn't be so bad, but without that, it'd result in
lame code duplication (though maybe that could be moved into a helper
routine).
-Brad
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
_______________________________________________
Chapel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-users
