Created a set of performance tests to demonstrate the behavior of different
task creation idioms, as observed in test/studies/shootout/thread-ring/.  Since
trivial cases (for example, if the task started merely spins for a while) do
not demonstrate this behavior as strongly until the number of tasks and number
of spins reaches rather high numbers, the code from thread ring is used.  To
ensure that the differences in performance is not a result of thread ring's
early termination of tasks, alternate versions have additionally been created
which allow each task to terminate on its own.

The six versions are as follows:
for-begin - utilizes a for loop, starting each new task within the for loop
   using a begin statement
coforall - utilizes a coforall loop to start tasks
coforall-begin - utilizes a coforall loop to start tasks, within which begin
   statements are used
for-begin-orderly-exit - same as for-begin, except when the algorithm is
   terminated, allows all threads to end themselves
coforall-orderly-exit - same as coforall, except when the algorithm is
   terminated, allows all threads to end themselves
coforall-begin-orderly-exit - same as coforall-begin, except when the algorithm
   is terminated, allows all threads to end themselves




git-svn-id: svn://svn.code.sf.net/p/chapel/code/trunk@21792 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Tweak output directory for weekend run.

git-svn-id: svn://svn.code.sf.net/p/chapel/code/trunk@21793 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Fix for test_dot_locale_error regression. [trivial]

The error detection code in functionResolution.cpp is matching against
PRIM_WIDE_GET_LOCALE, not PRIM_WIDE_GET_NODE.  So conversion of 
chpl_localeID_to_locale(_get_locale_id(x)).id to _get_node_id(x) causes
the error check to be skipped.  We really mean _get_locale_id(x) anyway, so
the regression was caused by what is essentially a type-o (pardon the pun).
The type of .locale.id is now chpl_localeID_t, not chpl_nodeID_t.

git-svn-id: svn://svn.code.sf.net/p/chapel/code/trunk@21794 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Chameneos clean-up (trivial and made by suggestion):

Removed an extra variable declaration that I had not seen when I copied the
code over from hannah/chameneos-redux-cas.chpl.

As suggested by Vass, moved part of the implementation of Chameneos.start into
a separate method for clarity.



git-svn-id: svn://svn.code.sf.net/p/chapel/code/trunk@21795 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Wrap-up of triage duty

All in all, it was a good week with lots of regressions getting
cleaned up -- thanks to everyone for their efforts.  The things
that snuck in at the last minute are:

- test_dot_locale_error starting to fail again, with the fix to
  the distributions/robust/arithmetic/performance failures

- SSCA2 comm counts improved, causing it to fail

+ memmaxExceedsLineno2 was resolved


Other changes are minor:

* updated paths to timing out nbody variations

* noted the reason that thread-ring tests are failing under GASNet is
  due to Sung limiting the number of threads for a valgrind run.
  Should probably be skipped or reduced to a smaller problem size for
  the correctness run.




git-svn-id: svn://svn.code.sf.net/p/chapel/code/trunk@21796 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
This test deadlocks; we'll solve that later; for now make it time out faster.

[Reviewed in discussions with bradcray.]

A recent change (r21725) added a forall in InitPrivateGlobals.chpl, with
the result that in programs running on more than one locale, we need a
minimum of two tasks running simultaneously in order to avoid deadlock.
These two tasks are (1) the one that originally encounters the forall
on locale 0 and (2) a remote task targeted at locale 0 and originating
on some other locale, which performs an atomic update on the endcount
associated with the forall.  With the tasks=fifo this means that we also
need two threads, to host the tasks.  If CHPL_RT_NUM_THREADS_PER_LOCALE
is set to 1 (one), we deadlock because we can't run the task to do the
atomic update on the endcount for the forall.

For now we are leaving this deadlock failure as a reminder to ourselves
to modify the module code so that it works properly with only a single
thread.  But to speed things up in the meantime, here I'm committing a
30-second timeout on this test.


git-svn-id: svn://svn.code.sf.net/p/chapel/code/trunk@21797 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
style improvements, more comments, updated EAM computation, distributed binCount

git-svn-id: svn://svn.code.sf.net/p/chapel/code/trunk@21798 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Updated the README to include information about runs with qthreads and under
the muxed tasking layer.



git-svn-id: svn://svn.code.sf.net/p/chapel/code/trunk@21799 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Removing -target=linux flag from Cray PrgEnv options

It seems that this -target=linux flag has been deprecated in
recent versions of the Cray PrgEnvs and hasn't been necessary
for some time.  While there are explicit things that the
target can be set to, it doesn't seem to be required any
longer (and may date from the days when Crays supported two
target OS environments?)



git-svn-id: svn://svn.code.sf.net/p/chapel/code/trunk@21800 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Reverting 21794.  Not a complete solution.

git-svn-id: svn://svn.code.sf.net/p/chapel/code/trunk@21801 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Switching to GASNet 1.20.2

Making GASNet 1.20.2 the default for a few nights of testing before
blowing away 1.20.0 to make sure there are no surprises.



git-svn-id: svn://svn.code.sf.net/p/chapel/code/trunk@21802 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Speed printchplenv and set Makefiles to use printchplenv generated obj dirs

[Reviewed by Greg,Tom,Brad]

After previous discussion (and a code review by Greg), an
earlier patch modified printchplenv to allow it to print
out the compiler,runtime,or launcher gen/obj/lib dir
name.

This patch continues that work in three ways:
  1) it modifies the chplenv/ and printchplenv scripts
     to run sub-tasks within the same Perl interpreter
     instead of fork/exec'ing all the time.
  2) it modifies printchplenv to support --make, which emits
     a Makefile snippet suitable for eval'ing in order to
     get all of the appropriate settings. That way, we can
     do all of our Make'ing with only *one* fork/exec of
     Perl (instead of zillions before).
  3) it modifies the Makefiles to actually use the output
     of printchplenv, including to get the the gen/etc subdirs.

Previous to this patch, a 'make' when there is nothing new
to do took about 3 seconds. On my machine, it takes about 1 second
with this patch. And, at the same time, it is adding new functionality
and consolidating configuration. (Note that if we didn't modify
chplenv scripts to run in the same Perl interpreter, the other
parts of this patch would slow us down to something like 18 seconds).

More details:

1) I've created a Run.pm Perl module to help abstract the details
    away. It provides run() and ret() functions. Under the hood,
    run() uses the usual `` approach if it's not a Perl program,
    and ret() returns the value in a shared variable. These scripts
    only print out if they are run from the command line - if they
    are run by run(), they return in a shared variable and do
    not print out. I did that by using the 'called' function. The Run.pm
    perl module assumes we are talking about a script in chplenv/.
    As part of these changes, I cleaned up and normalized the
    chplenv scripts a bit. They now have 'use strict'.
    Also, I switched these scripts to using FindBin instead of
    $0 to find the related files because FindBin works with lib
    to set the Perl include path (to work with Run.pm) - and $0
    does not (as far as I know).

2) printchplenv --make now prints out a makefile snippet.
    The snippet includes some slight variation on the usual
    printchplenv:
     -- CHPL_MAKE_HOST_MEM and CHPL_MAKE_TARGET_MEM are provided
        instead of CHPL_MAKE_MEM (since that is what the Makefiles
        were using)
     -- CHPL_MAKE_WIDE_POINTERS_DEFINES is set since the Makefiles
        will need it
     -- CHPL_MAKE_COMPILER_SUBDIR,CHPL_MAKE_RUNTIME_SUBDIR,CHPL_MAKE_LAUNCHER_SUBDIR
        are set to be our new gen-dir name (e.g. linux64.gnu.loc-flat.wide-struct.llvm-none)
        for the appropriate layer.
    In order to easily handle printing the short gen-dir names
    while printing the other variables under --make, I put all of
    the work in printchplenv into a 'go' routine, which is called
    recursively to print the short names under --make.

  3) Most of the action here is in Makefile.base, where I
     used some strange Makefile tricks to work around the fact
     that Make replaces newlines with spaces in a $(shell). An
     alternative would be to save the generated snippet to a file
     and include it, but we'd have to do that on every run, so
     there doesn't seem to me to be much point in saving it to
     a file.

     Since the printchplenv --make snippet now includes
     CHPL_MAKE_ATOMICS, etc, etc, it was no longer necessary
     to have make/Makefile.something for each configuration.
     
     Lastly, I observed that the g++ version was getting
     queried a zillion times so I tamped that down with the
     now usual ifdef/export trick in Makefile.gnu. At this
     point, on my configuration at least, the only thing
     that is getting exec'd over and over is pwd (and I don't
     see a simple way around that but it probably could be
     handled...).



git-svn-id: svn://svn.code.sf.net/p/chapel/code/trunk@21803 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Altered two directories in response to valgrind timing out on thread-ring.  The
timeout is a result of limiting the number of threads for valgrind and since the
number of threads is very important to the thread-ring program, I decided to
skip the thread-ring directory when running valgrind, rather than change the
run details.  I updated the README file appropriately.

However, I chose a different path for the comparison of our different task
creation models in test/parallel/taskCompare.  While the point of this directory
is to show the performance of different task creation models, it seems sensible
to at least assure ourselves that thread-ring does not leak memory.  Thus, I
changed the expected output and .good files used to use less threads than the
cap imposed on valgrind runs.  This test directory runs in a reasonable amount
of time (roughly twenty minutes for twelve tests) under valgrind.  I did not
feel the need to reflect this change over to test/studies/shootout/thread-ring,
as the settings there allow it to run in a few minutes under normal testing
settings and it is better to check the accuracy for a higher number of threads
since the shootout size is so large (503).



git-svn-id: svn://svn.code.sf.net/p/chapel/code/trunk@21804 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
updating future with more information

git-svn-id: svn://svn.code.sf.net/p/chapel/code/trunk@21805 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Fixed a cross-reference in a .future.


git-svn-id: svn://svn.code.sf.net/p/chapel/code/trunk@21806 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
trying out the dynamic iterator in the testing system

git-svn-id: svn://svn.code.sf.net/p/chapel/code/trunk@21807 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Improving handling of CHPL_COMPILER on Crays when no PrgEnv loaded

Prior to this commit, when running the compiler script on cray-x*
systems without a PrgEnv loaded, the compiler string would be set
to 'cray-prgenv' rather than 'cray-prgenv-foo' which is what we
expect when PrgEnv-foo was loaded.  This has confused me twice
this week because it doesn't seem inherently problematic until
you really look at it.  From what I can tell, this has been the
behavior since the beginning of time.

To try and improve this situation, this commit implements two
small changes:

1) emits a warning in this event.

2) makes the string 'cray-prgenv-none' just to make it stand out
   a bit more clearly if one were to miss the warnings.



git-svn-id: svn://svn.code.sf.net/p/chapel/code/trunk@21808 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Nearly remove the sublocale from the flat locale model's chpl_localeID_t.

[Reviewed by sungeun.]

This nearly removes the sublocale part of the chpl_localeID_t type as
defined by the flat locale model.  We retain a minimal sublocale just to
prevent initialization mismatches with the {0,0} initializers produced
by the compiler.  The file specific changes are as follows.

include/localeModels/flat/chpl-locale-model.h.
  Minimize the sublocale member of chpl_localeID_t down to just one
  bit.  We can't get rid of it entirely, yet, because the compiler
  generates initializers of the form {0,0} for the chpl_localeID_t
  locale members of wide pointers.

include/chpl-gen-includes.h.
  While here, remove the last remnant explicit references to the .node
  and .subloc members of chpl_localeID_t.  Use the (inlined) access
  functions provided by chpl-locale-model.h instead.


git-svn-id: svn://svn.code.sf.net/p/chapel/code/trunk@21810 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Fixes to some bugs exposed by NUMA work in Loop Invariant Code Motion 

[Original patch reviewed by Sung, slightly updated patch by David.]

- I missed setting an alias in one direction: If lhs aliases rhs I
  said lhs aliases rhs, rhs alises lhs, and lhs aliases rhsAlises, but
  I wasn't setting that the rhsAliases alias the lhs
 
- When a "class" is passed into a function, I wasn't assuming the
  fields were changed. I thought I was already doing this, but I guess
  not. I'm actually kinda surprised this didn't cause more issues in
  other places.  

- Corrected an assumption that the lhs of an alias was always the
  first expr in the callExpr (This isn't true for for
  PRIM_SET_MEMBER.) 

- If a field of a class is changed, the field and the class need to
  marked as having been changed. Note that this isn't really true for
  actual classes, but for records. For instance if you have a.b = 4,
  then c = a, you need to note that a has been changed. Currently this
  assumption is made for all "classes" but will be updated to only do
  this for records as for classes the pointer won't actually have
  changed. 

- A few minor updates/additions to the debug statements 

I'm using "class" to denote class, record, or union, and class to
denote a real chapel class. 


git-svn-id: svn://svn.code.sf.net/p/chapel/code/trunk@21811 3a8e244f-b0f2-452b-bcba-4c88e055c3ca
Filing some future for != and == of empty records

Empty record == and != always return true or false respectively,
regardless of the type of the second argument (int in these cases).

This happens because we build the functions with the second argument
as dtAny to handle sub-records, and then they later get instantiated
during resolution with the actual type.  The body of the function is
empty other than the return statement because the records have not
fields, so it compiles and runs.



git-svn-id: svn://svn.code.sf.net/p/chapel/code/trunk@21812 3a8e244f-b0f2-452b-bcba-4c88e055c3ca