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
