I may be repeating myself (I honestly can't remember), but I think we want
both "soft" tasking-layer notions of total and available resources for
tasking and "harder" system-oriented queries as well. The important
things might be that we probably want to use the former category in most
of the places that we use here.numCores() today so that things like
dataParTasksPerLocale are tasking-layer aware rather than
HW-specific(ish).
The first category makes good sense for the reasons that Greg outlines
(and I think there should be multiple queries rather than trying to boil
it down to a single entry: things like ideal/expected tasking capacity
when the system was quiescent, current capacity, and maybe others -- like
what resources are devoted to communication progress in a unified runtime
model like Dylan proposed at CHIUW).
For the latter, I think it's only natural for programmers to want to ask
questions about the hardware on which they're running -- even if they use
it to shoot themselves in the foot or to try and account for things that
we'd rather manage for them; and even if the queries themselves are
non-portable across architectures -- and I think the locale models provide
a nice mechanism for making such queries (compared to making your own
sysconf() calls or dredging /proc/cpuinfo for data).
-Brad
On Wed, 28 May 2014, Greg Titus wrote:
Hi --
I don't think we ought to be asking about the hardware at all, from the
Chapel level. In fact, I'd get rid of numCores itself. Even if the
code knows how many cores or hyperthreads or other hardware objects are
present, it can't know enough about how those are being used and/or
managed by the Chapel program itself or other things running alongside
to make useful decisions based on that information.
I'd call it something like here.availPar, implement it in terms of the
tasking layers providing information about how much concurrency they
could support, and base our decisions about how much parallelism to
create on that. So for example, I'd expect fifo tasking to return the
lesser of # hardware cores and CHPL_RT_NUM_THREADS_PER_LOCALE. I'd
expect qthreads tasking to return the number of worker threads. In both
cases I'd reduce this further if we were running in an overloaded state
and more than one Chapel top-level locale was on the same compute node.
(We could add a comm layer interface function to tell us that.)
In situations where we don't have an actual tasking layer, as we expect
to be the case for GPUs, I think we'll still have a thin translation
layer and here the "tasking layer" could just return the actual number
of cores. But the interface would be the same.
greg
On Fri, 9 May 2014, Ben Harshbarger wrote:
Hi all,
I ran into an issue with hyper threading on OSX this morning, and after a
discussion with Brad some questions were posed that seem better suited for
a group discussion.
Currently numCores (at least on linux) includes the count for
hyper-threading. This introduces some ambiguity in the meaning of
‘here.numCores’ (physical vs. logical), and raises some questions:
- What should numCores represent?
- Should we separate the notion of physical cores and the amount of
parallelism in hardware (new variable/name)?
- What does this mean for dataParTasksPerLocale?
Hopefully this gets the ball rolling.
-Ben
------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find
out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
------------------------------------------------------------------------------
Time is money. Stop wasting it! Get your web API in 5 minutes.
www.restlet.com/download
http://p.sf.net/sfu/restlet
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
