[llvm-dev] LLD: time to enable --threads by default

Rui Ueyama via llvm-dev llvm-dev at lists.llvm.org
Thu Nov 17 09:41:35 PST 2016


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>


More information about the llvm-dev mailing list