llvm dev - Nov 2016 - LLD: time to enable --threads by default

> Sounds like threading isn't beneficial much beyond the second CPU...
> Maybe blindly creating one thread per core isn't the best plan...
parallel.h is pretty simplistic at the moment. Currently it creates
one per SMT. One per core and being lazy about it would probably be a
good thing, but threading is already beneficial and improving
parallel.h an welcome improvement.

Cheers,
Rafael

On Thu, Nov 17, 2016 at 4:11 AM, Rafael Espíndola via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> > Sounds like threading isn't beneficial much beyond the second
CPU...
> > Maybe blindly creating one thread per core isn't the best plan...
>
> parallel.h is pretty simplistic at the moment. Currently it creates
> one per SMT. One per core and being lazy about it would probably be a
> good thing, but threading is already beneficial and improving
> parallel.h an welcome improvement.
>
Instead of using std::thread::hardware_concurrency (which is one per SMT),
you may be interested in using the facility I added for setting default
ThinLTO backend parallelism so that one per physical core is created,
llvm::heavyweight_hardware_concurrency() (see D25585  and r284390). The
name is meant to indicate that this is the concurrency that should be used
for heavier weight tasks (that may use a lot of memory e.g.).

Teresa

> Cheers,
> Rafael
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>


-- 
Teresa Johnson |  Software Engineer |  tejohnson at google.com |  408-460-2413
<(408)%20460-2413>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161117/d5a15cd5/attachment.html>

On Thu, Nov 17, 2016 at 6:12 AM, Teresa Johnson via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
>
>
> On Thu, Nov 17, 2016 at 4:11 AM, Rafael Espíndola via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> > Sounds like threading isn't beneficial much beyond the second
CPU...
>> > Maybe blindly creating one thread per core isn't the best
plan...
>>
>> parallel.h is pretty simplistic at the moment. Currently it creates
>> one per SMT. One per core and being lazy about it would probably be a
>> good thing, but threading is already beneficial and improving
>> parallel.h an welcome improvement.
>>
>
> Instead of using std::thread::hardware_concurrency (which is one per
> SMT), you may be interested in using the facility I added for setting
> default ThinLTO backend parallelism so that one per physical core is
> created, llvm::heavyweight_hardware_concurrency() (see D25585  and
> r284390). The name is meant to indicate that this is the concurrency that
> should be used for heavier weight tasks (that may use a lot of memory
e.g.).
>
Sorry for my ignorance, but what's the point of running the same number of
threads as the number of physical cores instead of HT virtual cores? If we
can get better throughput by not running more than one thread per a
physical core, it feels like HT is a useless technology.

Teresa
>
>
>> Cheers,
>> Rafael
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
>
>
> --
> Teresa Johnson |  Software Engineer |  tejohnson at google.com |
> 408-460-2413 <(408)%20460-2413>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161117/8afd6d8f/attachment.html>