[PATCH] D25585: Add interface for querying physical hardware concurrency

[Teresa Johnson via llvm-commits]

On Thu, Oct 13, 2016 at 5:14 PM, Mehdi Amini <mehdi.amini at apple.com> wrote:

>
> > On Oct 13, 2016, at 5:07 PM, Teresa Johnson <tejohnson at google.com>
> wrote:
> >
> > tejohnson added inline comments.
> >
> >
> > ================
> > Comment at: include/llvm/Support/Threading.h:121
> > +  /// host system, otherwise falls back to
> thread::hardware_concurrency().
> > +  unsigned hardware_physical_concurrency();
> > }
> > ----------------
> > mehdi_amini wrote:
> >> I think we may want to name it `hardware_coarse_concurrency`. Because:
> >>
> >> - This looks like expressing better what we're looking after.
> >> - Hyperthreading is in some sense "physical concurrency", but sharing
> some resources.
> >> - Other platforms may have something in between.
> >>
> > I thought about that name after you mentioned it on the prior review
> thread. But I felt that saying "physical concurrency" is a better
> expression for what it is actually trying to give you.  I think of the
> hyperthreading concurrency as "logical concurrency", vs physical
> concurrency due to physical cores.
>
> Hyperthreading is sharing some physical resources on the core, but have
> some other physical resources duplicated/dedicated, which is why I feel it
> is murky. But “good enough” as well...
> Also, I don’t know enough the PowerPC or Sparc equivalent of
> hyper-threading to know how much they share/duplicate and what we would
> pick on these for instance.
>

Right it is a bit murky. One reason I didn't like "coarse" is that
coarse-grained parallelism relates to how closely the tasks
communicate/synchronize, and I while ThinLTO backend tasks would qualify, I
don't think that's why they don't scale well beyond the # physical cores
(but rather the memory intensiveness as you pointed out in the other
thread). I'll go with this for now.



> —
> Mehdi
>
>
>
>


-- 
Teresa Johnson |  Software Engineer |  tejohnson at google.com |  408-460-2413
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161013/03c8eed5/attachment.html>