Replace <locale>.numCores with <locale>.maxTaskPar where appropriate.
Remove an extraneous space character.
Update tests that reference numCores to reflect maxTaskPar change.

A number of tests refer to <locale>.numCores.  Many do so in order to
parameterize parallelism.  Others do so in order to print information
about the testing environment.  Adjust all these to parameterize or also
print using maxTaskPar.
Fix a mis-coding.

I added new output lines for maxTaskPar in these tests, to go with the
existing ones for numCores, but I didn't put them under control of the
if-stmt that prevents printing them unless desired.  As a result, the
tests didn't match their .good files any more.  Fix that.
Split out the graphs for EP and FT that are most important to us (largest that run)
Significant refactoring (mostly expansion) of graphs in the perf tracking suite

I added a bunch of graphs to the perf tracking suite that I think we should be
paying attention to (and removed one):

* EP Stream -- I took the version that has --local and --no-local results
  though I think all our stream graphs should be condensed down to 1-4
  and don't understand the relationship between this graph and the release
  version (TODO)

* Removed Global stream w/ promotion -- because the global stream graph we
  use subsumes this info

* added HPCC RA and HPL : the first because it's important to us; the
  second because it's fairly stable and interesting; FFT could also have
  been added, but it seems less stable (and is arguably less "the way
  we'd like to do it"

* added thread-ring and pidigits -- the former is now less noisy with
  qthreads; the latter is now interesting with GMP on in the nightly
  testing

* added NAS EP B, FT A, and IS S -- all of these need more eyes on them
  to make sure they're as we like them; but in the meantime they're
  fairly noise-free

* added many array performance tests -- I looked for ones that looked
  fairly noise-free; I think that maintaining/improving performance for
  these is key, so thought they were worth a look

* dynamic iterator -- of the various advanced iters, I chose this one
  because it's the one we use most commonly and because it had some
  interesting changes lately.

* various scalar idiom C vs. Chapel comparisons -- again, these will
  be key to performance and they're fairly noise-free

* compilation time -- grabbed this just so we have some sense of
  overall compiler performance from week-to-week without bringing
  up Elliot's full suite -- this can serve as a canary to look there.

* memory leaks for examples -- this is something else I'd like to keep
  an eye on.  I could imagine taking one graph from this suite, but
  didn't put in the time to split the one I liked off (probably memory
  leaks for examples)

* jacobi AST/generated code size -- something else worth tracking

* no-op -- maybe not worth tracking, but I wanted to err on including
  it.
Cleaned up the parsing of intent_expr

There was a small bug in how intent_expr was parsed. While here I
cleaned up the rest of it based off some feedback from Brad.
Update one last test to the new task intent syntax
Merge pull request #302 from bradcray/updatePerfSuite

Update to graphs in performance tracking suite

[effectively reviewed in the performance team meeting; OK'd by lydia by email]

It's been a long time since we considered which graphs are
in the performance graphing suite.  Here, I did a refresh
on them for my performance triage week as follows:

* EP Stream -- I took the version that has --local and --no-local results
  though I think all our stream graphs should be condensed down to 1-4
  and don't understand the relationship between this graph and the release
  version (TODO)

* Removed Global stream w/ promotion -- because the global stream graph we
  use subsumes this info

* added HPCC RA and HPL : the first because it's important to us; the
  second because it's fairly stable and interesting; FFT could also have
  been added, but it seems less stable (and is arguably less "the way
  we'd like to do it"

* added thread-ring and pidigits -- the former is now less noisy with
  qthreads; the latter is now interesting with GMP on in the nightly
  testing

* added NAS EP B, FT A, and IS S -- all of these need more eyes on them
  to make sure they're as we like them; but in the meantime they're
  fairly noise-free

* added many array performance tests -- I looked for ones that looked
  fairly noise-free; I think that maintaining/improving performance for
  these is key, so thought they were worth a look

* dynamic iterator -- of the various advanced iters, I chose this one
  because it's the one we use most commonly and because it had some
  interesting changes lately.

* various scalar idiom C vs. Chapel comparisons -- again, these will
  be key to performance and they're fairly noise-free

* compilation time -- grabbed this just so we have some sense of
  overall compiler performance from week-to-week without bringing
  up Elliot's full suite -- this can serve as a canary to look there.

* memory leaks for examples -- this is something else I'd like to keep
  an eye on.  I could imagine taking one graph from this suite, but
  didn't put in the time to split the one I liked off (probably memory
  leaks for examples)

* jacobi AST/generated code size -- something else worth tracking

* no-op -- maybe not worth tracking, but I wanted to err on including
  it.


In support of the NPB changes above, I split the sizes we care about
out from the .graph files that contained multiple sizes.
Merge pull request #303 from Kyle-B/task-intent-fixes

Clean up how intent_expr is parsed

There was a small bug in how intent_expr was parsed. While there I cleaned up the rest of it based off some feedback from Brad.

Updates one more test that slipped through with the old task intent syntax.
Merge pull request #288 from gbtitus/dataParTasksPerLocale-from-maxTaskPar

Replace <locale>.numCores with <locale>.maxTaskPar where appropriate.

Replace numCores with maxTaskPar everywhere in the module code. This will cause us to
compute parallelism based on what the tasking layer says it can achieve, rather than on
what we think we have available in terms of hardware.

While here, I also changed numCoreTasks to numSublocTasks in DefaultRectangular.chpl,
to reflect what I think we're actually computing there.

Finally, a number of tests refer to <locale>.numCores.  Many do so in order to parameterize
parallelism.  Others do so in order to print information about the testing environment.  I adjusted
all these to parameterize and/or print using maxTaskPar instead (or for printing, in addition).

Reviewed by @sungeunchoi.
Some additional comm count improvements from licm update
Merge pull request #304 from ronawho/licm-hoist-wide

Some additional comm count improvements from licm update

[trivial, not reviewed]
Test --dataParIgnoreRunningTasks=true in my playground

I've been curious if qthreads handles nested parallelism better, and am even
more curious with some of the results greg was seeing where we have better
performance for some tests when dataParTasksPerLocale > numCores

This will probably be my last experiment before retiring these scripts
Merge pull request #305 from ronawho/qthreads-timeouts

Test --dataParIgnoreRunningTasks=true in my playground

I've been curious if qthreads handles nested parallelism better, and am even
more curious with some of the results greg was seeing where we have better
performance for some tests when dataParTasksPerLocale > numCores

This will probably be my last experiment before retiring these scripts
Classify this future as a "bug".
Merge pull request #308 from sungeunchoi/test

Classify this future as a "bug".  The tag was missing prior to this commit.
Lower stack size for test/stress/deitz/test_10k_coforall.chpl

This test has the potential to create a lot tasks that exist simultaneously. On
some of our tests boxes with limited ram, we run out of memory. Qthreads places
no limit on the number of qthreads and thus stacks that can exist at once. For
tests like this I've been trying to limit the "max" memory usage to under 4GB.
4GB seems like a large enough value for correctness tests, and it is low enough
that our 32 bit machines shouldn't have trouble.
Merge pull request #309 from ronawho/qthreads-timeouts

Lower stack size for test/stress/deitz/test_10k_coforall.chpl

[trivial, not reviewed]

This test has the potential to create a lot tasks that exist simultaneously. On
some of our tests boxes with limited ram, we run out of memory. Qthreads places
no limit on the number of qthreads and thus stacks that can exist at once. For
tests like this I've been trying to limit the "max" memory usage to under 4GB.
4GB seems like a large enough value for correctness tests, and it is low enough
that our 32 bit machines shouldn't have trouble.
Lower the problem size for test_many_domain and test_many_array

Since switching to qthreads these tests take a lot longer to execute and
test_many_domain times out pretty often. test_many_domain has also been timing
out for numa+gasnet for months

This doesn't reflect a real problem with qthreads, so much as it does a
"problem" with the testing framework. Even with qthreads configured with
oversubscription and affinity off there is still interference from multiple
qthreads instances running on the same machine.

I tested these two programs out on an xc and on a cluster, and the qthreads
version was a few seconds quicker so I'm pretty confident in my claim that it's
just how we test gasnet+qthreads that's responsible for the slow down and not
some performance mystery that needs to be explored.

These new sizes lower the execution time to ~30 seconds.