[PATCH] D140271: [NFCI][llvm-exegesis] Benchmark: parallelize codegen (5x ... 8x less wallclock)

[Roman Lebedev via Phabricator via llvm-commits]

lebedev.ri added a comment.

In D140271#4056530 <https://reviews.llvm.org/D140271#4056530>, @RKSimon wrote:

> In D140271#4056430 <https://reviews.llvm.org/D140271#4056430>, @lebedev.ri wrote:
>
>> In D140271#4056248 <https://reviews.llvm.org/D140271#4056248>, @RKSimon wrote:
>>
>>> Has anyone got a recent profile of llvm-exegesis upto --benchmark-phase=assemble-measured-code?
>>
>> for all-opcode pass,
>>
>> - `--benchmark-phase=prepare-snippet` is instantenious, takes less than a second
>> - `--benchmark-phase=prepare-and-assemble-snippet` takes maybe 2..5 seconds
>> - `--benchmark-phase=assemble-measured-code` takes minutes.
>
> I meant an actual profile - not just a timing - to see where the cycles are going - my hope is that there will be a series of minor changes we can make instead of going down the multi-threading path

The actual Codegen is known to be a compile time hog.
There is practically no way this result can be replicated otherwise.

In D140271#4056487 <https://reviews.llvm.org/D140271#4056487>, @courbet wrote:

> In D140271#4056430 <https://reviews.llvm.org/D140271#4056430>, @lebedev.ri wrote:
>
>> In D140271#4056202 <https://reviews.llvm.org/D140271#4056202>, @courbet wrote:
>>
>>>> Are you seriously saying that 10x wallclock improvement is negligible?
>>>
>>> 10x speed improvement is not negligible. I'm simply questioning whether speed matters in this case.
>>>
>>> If the speed improvement came at no cost, that would be a no-brainer. But there is a speed/readability tradeoff, which we need to evaluate.
>>
>> All the changes here are to a **single** function,
>> that isn't really going to change further anyway.
>> It's not like this requires changes to many places.
>
> I don't think number of touched functions is an agree-upon measure of complexity :) I would even argue that splitting in more functions might make the code less complex.
>
> But again, my point is more about usefulness to users, and right now it looks like the change leaves both reviewers (that happen to be users) asking about complexity/usefulness ratio. But both these users also might tend to have the same usage of the tool, so maybe we're not seeing the whole picture - maybe ask for more opinions ?

Right. Well, as a user, i do think the existing performance is not great.
More seriously, i think you would be in a better position to ask users, because i don't know any (other than the ones already here)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D140271/new/

https://reviews.llvm.org/D140271