Let the tasking layer say how much parallelism is available.

We're moving toward having the tasking layer tell the rest of Chapel
(notably the module code) how much parallelism it thinks it can provide,
instead of the module code (et al.) deciding that on its own based on
how much hardware it sees.  This is the first step along that path.  It
augments the processor-counting support in the runtime so that we can
get an accurate count of the number of cores and processor units (PUs,
basically anything that can issue instructions, including hyperthreads).
And, it adds a chpl_getMaxPar() call to the tasking layer interface, to
say how much true parallelism the tasking layer implementation thinks it
can provide.  Only the fifo and massivethreads layers are done so far,
and the module code hasn't been updated to use this information.  It's
still looking directly at how much hardware is configured.

The specific file changes are as follows.

runtime/include/chplsys.h
runtime/src/chplsys.c
  Rename chpl_numCoresOnThisLocale() as chpl_getNumPUsOnThisNode()
  (since #PUs is what it actually returned) and re-implement it for
  Linux to reflect kernel scheduling affinity, not just what hardware is
  present.  Add a new chpl_getNumCoresOnThisNode(), which returns the
  number of cores available to the process.  This new function is a copy
  of ...getNumPUs..., adjusted to return the number of actual cores (no
  hyperthreads or equivalent).  Make both of these return a regular int;
  chpl_numCoresOnThisLocale() returned an int64_t, but I can't think of
  a good reason to retain that.

runtime/include/chpl-tasks.h
runtime/src/tasks/fifo/tasks-fifo.c
runtime/src/tasks/massivethreads/tasks-massivethreads.c
  Add the new tasking interface function chpl_task_getMaxPar().
  Implement it in terms of chpl_getNumCoresOnThisNode() (added above).
  Also, in fifo tasking, call chpl_getNumPUsOnThisNode() instead of
  chpl_numCoresOnThisLocale() (which actually returned #PUs) when
  deciding whether to spin or use a pthread cond var while waiting for a
  sync var to be in the desired state.  And, while here, clarify the
  associated comment.

modules/internal/ChapelLocale.chpl
modules/internal/localeModels/flat/LocaleModel.chpl
  Add a new maxTaskPar member to the LocaleModel module, and initialize
  it by calling chpl_task_getMaxPar().

test/localeModels/gbt/maxTaskPar.chpl
test/localeModels/gbt/maxTaskPar.cleanfiles
test/localeModels/gbt/maxTaskPar.prediff
  Add a new test to ensure that here.maxTaskPar has the expected value.
Clean up in a few spots.

In chplsys, for Linux and Cygwin define chpl_getNumCoresOnThisNode() in
terms of the number of PUs returned by chpl_getNumPUsOnThisNode().

In flat/LocaleModel.chpl initialize numCores with the value returned by
chpl_getNumPUsOnThisNode(), which returns what used to be returned by
chpl_numCoresOnThisLocale().  Thus the value of numCores will be the
same as it was before all this work.
Add maxTaskPar support in qthreads tasking and numa locale model.

This adds chpl_task_getMaxPar() in qthreads tasking, and updates the
numa locale model to include a maxTaskPar member and initialization of
that.

While here, I also corrected the return types of the runtime functions
that return #PUs and maxTaskPar, in the extern decls in the flat locale
model.
Fix a function call I missed.

I neglected to change a call to chpl_numCoresOnThisLocale() into a call
to chpl_getNumPUsOnThisNode().  (It's a call that really is looking for
the number of PUs on the node.)
Merge branch 'master' of github.com:chapel-lang/chapel into taskrt-concurrency
Finalize support for numa and add darwin.

This fixes problems in maxTaskPar support with CHPL_LOCALE_MODEL=numa,
and adds support for the darwin (Mac) platform.  I've tested on linux
with tasks=(fifo,massivethreads,qthreads) and locale model=(flat,numa)
in all combinations, and on darwin with tasks=fifo and both locale
models.  Note: I've tested only the one new test, not anything else
(well, maybe a hello here and there).  That should be sufficient, since
I'm not yet changing behavior, just adding the new locale model member.

The specific file changes are as follows.

runtime/src/chplsys.c
  Take the #warnings out of the '#ifdef __APPLE__' code, so that it can
  build.  While here, also remove the #warnings for #ifdef __CYGWIN__,
  though I haven't been able to test that yet.

modules/internal/localeModels/numa/LocaleModel.chpl
  If there are no sublocales (as with CHPL_TASKS=fifo), set maxTaskPar
  to chpl_task_getMaxPar(), on the assumption that the tasking layer
  will behave like CHPL_LOCALE_MODEL=flat in this case.

test/localeModels/gbt/maxTaskPar.chpl
  Make this new test recursively print maxTaskPar for any sublocales.

test/localeModels/gbt/maxTaskPar.prediff
  Add a bunch of elaboration to compute what we think the program ought
  to print, and make a .good file containing that.
Fix updateBuildVersion bug so we don't always rebuild version.cpp

The updateBuildVersion script had a bug that caused it to always think there
was a new version. It was testing ("versionNum" eq versionNum), including
quotes as characters for one of the strings, so they are always different.
This just removes the quotes.
changing .bad files to match the new parameters to open()
Merge pull request #160 from tzakian/open_sig_change

Changing .bad files to match the new parameters to open().
Merge pull request #158 from daviditen/updateBuildVersion

Fix updateBuildVersion bug so we don't always rebuild version.cpp

The updateBuildVersion script had a bug that caused it to always think there
was a new version. It was testing ("versionNum" eq versionNum), including
quotes as characters for one of the strings, so they are always different.
This just removes the quotes.

[reviewed by hildeth]
Update to reflect review feedback.

There are just three changes here:
- In chplsys.c, only define getPUsPerCore() for Linux targets, not for
  all non-Apple targets.  It's only called on Linux targets.
- Also in chplsys.c, collapse the multi-space runs into single spaces in
  the sscanf() format strings used to read values from /proc/cpuinfo.  A
  single space in the format is sufficient to match any amount of white
  space in the input, and using multi-space runs implies more input
  matching precision than is actually happening.
- Explicitly cast return values where they don't match the function
  return type, in both chplsys.c and the tasking layers.
Merge pull request #156 from gbtitus/taskrt-concurrency

Add the runtime tasking layer's notion of max parallelism to locale models.

[Reviewed by Sung.]

We're moving toward having the tasking layer tell the rest of Chapel
(notably the module code) how much parallelism it thinks it can provide,
instead of the module code (et al.) deciding that on its own based on
how much hardware it sees. This is the first step along that path. It
augments the processor-counting support in the runtime so that we can
get an accurate count of the number of cores and processor units (PUs,
basically anything that can issue instructions, including hyperthreads).
And, it adds a chpl_getMaxPar() call to the tasking layer interface, to
say how much true parallelism the tasking layer implementation thinks it
can provide. Only the runtime tasking layer work is done so far. The
module code hasn't been updated to use this information. It's still looking
directly at how much hardware is configured, when deciding for example
how much parallelism to create for a forall-stmt.

The specific file changes are as follows.

runtime/include/chplsys.h
runtime/src/chplsys.c
Rename chpl_numCoresOnThisLocale() as chpl_getNumPUsOnThisNode()
(since #PUs is what it actually returned) and re-implement it for
Linux to reflect kernel scheduling affinity, not just what hardware is
present. Add a new chpl_getNumCoresOnThisNode(), which returns the
number of cores available to the process. This new function is a copy
of ...getNumPUs..., adjusted to return the number of actual cores (no
hyperthreads or equivalent). Make both of these return a regular int;
chpl_numCoresOnThisLocale() returned an int64_t, but I can't think of
a good reason to retain that.

runtime/include/chpl-tasks.h
runtime/src/tasks/fifo/tasks-fifo.c
runtime/src/tasks/massivethreads/tasks-massivethreads.c
third-party/qthread/qthread-1.10/src/interfaces/chapel/tasks-qthreads.c
Add the new tasking interface function chpl_task_getMaxPar().
Implement it in terms of chpl_getNumCoresOnThisNode() (added above)
for fifo and massivethreads, and in terms of qthread_num_workers() for
qthreads.
Also, in fifo tasking, call chpl_getNumPUsOnThisNode() instead of
chpl_numCoresOnThisLocale() (which actually returned #PUs) when
deciding whether to spin or use a pthread cond var while waiting for a
sync var to be in the desired state. And, while here, clarify the
associated comment.

modules/internal/ChapelLocale.chpl
modules/internal/localeModels/flat/LocaleModel.chpl
modules/internal/localeModels/numa/LocaleModel.chpl
Add a new maxTaskPar member to the LocaleModel module. For the flat
locale model and for numa with no sublocales (which happens for example
with tasks=fifo), initialize maxTaskPar by calling chpl_task_getMaxPar(). For
numa with sublocales, for now set the maxTaskPar value for the locale to the
number of sublocales, and for the sublocales to chpl_task_getMaxPar()
divided by the number of sublocales. We may want to get fancier later, but
this should do for now.

test/localeModels/gbt/maxTaskPar.chpl
test/localeModels/gbt/maxTaskPar.cleanfiles
test/localeModels/gbt/maxTaskPar.prediff
Add a new test to ensure that here.maxTaskPar has the expected value on
all the locales and sublocales in the locale model the program finds itself
running on.
Remove TAB characters.
Merge pull request #161 from gbtitus/fix-tabs

Remove TAB characters.

[Not reviewed; seems not to need it.]

Remove some TAB characters I inserted with my last pull merge.
Change iterators before yield back to 4096.

Had some performance regressions on chap03/04
Fixed .bad mismatches due to strengthened const checking
Merge pull request #162 from vasslitvinov/fixed-.bad-mismatches-for-const-checking

Fixed .bad mismatches due to strengthened const checking.

[autoCopyWithBegin discussed with Sung;
 initCopyWithBegin to be reviewed post-commit, for expediency]

In both tests a field of a record formal passed by blank intent
was modified. Since #157 this is flagged as an error,
shadowing the issues that the tests expose.

In autoCopyWithBegin, I simply changed the formal to have 'in' intent.

In initCopyWithBegin, neither 'in' nor 'ref' intent worked.
I.e. the compiler issued unrelated errors, due to the way
chpl__initCopy is handled and utilized by the compiler.

So instead I made the test modify another variable.
IMO this preserves the spirit of the test, which is that
a 'begin' block results in an extra formal of chpl__initCopy,
and that causes issues. I.e. it does not matter what happens
in the begin block.

While there, I added autoCopyWithBegin.compopts with "--verify".
This way an issue is caught earlier in the compiler.
FYI without --verify the symptom is the same as for initCopyWithBegin.

I did not add --verify for initCopyWithBegin, because it does not affect
the symptom.
Merge pull request #163 from ronawho/qthreads-syncvar-deadlock

Change iterators before yield back to 4096 for qthreads sync unlock



Had some performance regressions on chap03/04, lets try waiting more before we yield. On the plus side my comments are right again.