[lld] r287042 - Use one task per iteration in parallel_for_loop.

Rui Ueyama via llvm-commits llvm-commits at lists.llvm.org
Tue Nov 15 17:38:54 PST 2016


On Tue, Nov 15, 2016 at 3:22 PM, Rafael Avila de Espindola <
rafael.espindola at gmail.com> wrote:

> But reducing the chunk size would reduce non thread performance.
>
> Do revert this for now if you want , please wait to change the chunk size.
>
> I will try tomorrow to find which loop got slower.
>

If you don't want to revert it, how about this.

The problem in the original code is the task size is fixed to 1024. We can
make it adaptive to the size of the input, so that we will always have
reasonable number of tasks.

Cheers,
> Rafael
>
>
> On November 15, 2016 6:01:43 PM EST, Rui Ueyama <ruiu at google.com> wrote:
>>
>> I'm not really focusing on multi-thread performance now, but because the
>> degradation is too large, I'd like to revert it, and instead make the
>> build-id chunk size much smaller (1 KB, maybe?) to parallelize the task.
>>
>> I believe this should be that slow. We need to improve our threading
>> library.
>>
>> On Tue, Nov 15, 2016 at 2:57 PM, Rafael EspĂ­ndola <
>> rafael.espindola at gmail.com> wrote:
>>
>>> On 15 November 2016 at 17:24, Rui Ueyama <ruiu at google.com> wrote:
>>> > Can you try to run your benchmark again without --build-id? For me,
>>> this
>>> > patch slows down the linker by about 30% with --threads and without
>>> > --build-id.
>>>
>>> Sigh, yes, it goes from 6.316669764 to 7.173495002. No threads is
>>> 6.962417327.
>>>
>>> Do you want to revert or we track which parallel for loop needs a
>>> bigger granularity?
>>>
>>> Cheers,
>>> Rafael
>>>
>>
>>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161115/252ace1f/attachment.html>


More information about the llvm-commits mailing list