llvm dev - Jun 2020 - Improve hot cold splitting to aggressively outline small blocks

Hello,
I am Ruijie Fang, a GSoC student working on "Improve hot cold
splitting to aggressively outline small blocks." Over the course of
last week, I met with my mentor and co-mentor, Aditya Kumar, and
Rodrigo Rocha, and we made a preliminary plan on improving the
existing hot/cold splitting pass in LLVM through identifying patterns
of cold blocks in real-world workloads via block frequency information
(We have settled to use the PostgreSQL codebase as a workload first,
although if time permits, we will also target other large codebases).

Our project will involve identifying new cold block patterns via
static analysis in our workload,  implementing detection of these
patterns into the existing hot/cold splitting pass, and then
benchmarking hot/cold splitting in our workload to see if there are
improvements. Our eventual goal is to improve the ability of hot/cold
analysis to detect cold blocks in these real-world workloads.

Our plan is attached at
https://docs.google.com/document/d/1rGLcFpfVXnF7aS31dWnowd2y_BjJnRA-hj3cUt6MqZ8/edit?usp=sharing.

Any feedback, input, or suggestion is welcome and highly appreciated!

Best regards,
Ruijie

Ruijie Fang
Email: ruijief at princeton.edu

On Sun, May 31, 2020 at 11:37 PM Ruijie Fang <ruijief at princeton.edu>
wrote:
> Hello,
> I am Ruijie Fang, a GSoC student working on "Improve hot cold
> splitting to aggressively outline small blocks." Over the course of
> last week, I met with my mentor and co-mentor, Aditya Kumar, and
> Rodrigo Rocha, and we made a preliminary plan on improving the
> existing hot/cold splitting pass in LLVM through identifying patterns
> of cold blocks in real-world workloads via block frequency information
> (We have settled to use the PostgreSQL codebase as a workload first,
> although if time permits, we will also target other large codebases).
>
> Our project will involve identifying new cold block patterns via
> static analysis in our workload,  implementing detection of these
> patterns into the existing hot/cold splitting pass, and then
> benchmarking hot/cold splitting in our workload to see if there are
> improvements. Our eventual goal is to improve the ability of hot/cold
> analysis to detect cold blocks in these real-world workloads.
>
Hi Ruijie,

Thanks for the info!

I skimmed the doc (suggest including it inline in the thread). It wasn't
clear to me if the main goal is to improve PGO based HCS or non-PGO based
HCS. It sounds like you are going to be focusing on non-PGO based HCS given
the comments about static analysis and detection of throws, asserts etc. A
couple of suggestions. I'd focus first on ensuring best performance
possible given PGO information (the last time I tried HCS with PGO it
wasn't improving performance for one of our large apps). Second, for the
non-PGO case, rather than building in the detection of likely cold blocks
into HCS itself, it would be better to drive static generation of some kind
of profile metadata for likely cold blocks (a la __builtin_expect). This
will be more general and allow passes other than HCS to benefit.

Teresa

> Our plan is attached at
>
>
https://docs.google.com/document/d/1rGLcFpfVXnF7aS31dWnowd2y_BjJnRA-hj3cUt6MqZ8/edit?usp=sharing
> .
>
> Any feedback, input, or suggestion is welcome and highly appreciated!
>
> Best regards,
> Ruijie
>
> Ruijie Fang
> Email: ruijief at princeton.edu
>

-- 
Teresa Johnson |  Software Engineer |  tejohnson at google.com |
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200601/1a4ecc40/attachment.html>

Hi Teresa,

Thank you for your reply! I discussed this with Aditya and Rodrigo today
about this. We will always have PGO turned on for our benchmark, (i.e. we
assume the profiling information is always available). In terms of the
workload we supply to PGO: For postgresql, I suggested we use the
"pgbench"
benchmark, a TPC-B-based SQL benchmark for postgres, to supply profiling
information for PGO. We can use other workloads/benchmarks should you have
any other suggestions about this.

Thank you,
Ruijie

Ruijie Fang
Email: ruijief at princeton.edu



On Mon, Jun 1, 2020 at 11:28 AM Teresa Johnson <tejohnson at google.com>
wrote:
>
>
> On Sun, May 31, 2020 at 11:37 PM Ruijie Fang <ruijief at
princeton.edu>
> wrote:
>
>> Hello,
>> I am Ruijie Fang, a GSoC student working on "Improve hot cold
>> splitting to aggressively outline small blocks." Over the course
of
>> last week, I met with my mentor and co-mentor, Aditya Kumar, and
>> Rodrigo Rocha, and we made a preliminary plan on improving the
>> existing hot/cold splitting pass in LLVM through identifying patterns
>> of cold blocks in real-world workloads via block frequency information
>> (We have settled to use the PostgreSQL codebase as a workload first,
>> although if time permits, we will also target other large codebases).
>>
>> Our project will involve identifying new cold block patterns via
>> static analysis in our workload,  implementing detection of these
>> patterns into the existing hot/cold splitting pass, and then
>> benchmarking hot/cold splitting in our workload to see if there are
>> improvements. Our eventual goal is to improve the ability of hot/cold
>> analysis to detect cold blocks in these real-world workloads.
>>
>
> Hi Ruijie,
>
> Thanks for the info!
>
> I skimmed the doc (suggest including it inline in the thread). It
wasn't
> clear to me if the main goal is to improve PGO based HCS or non-PGO based
> HCS. It sounds like you are going to be focusing on non-PGO based HCS given
> the comments about static analysis and detection of throws, asserts etc. A
> couple of suggestions. I'd focus first on ensuring best performance
> possible given PGO information (the last time I tried HCS with PGO it
> wasn't improving performance for one of our large apps). Second, for
the
> non-PGO case, rather than building in the detection of likely cold blocks
> into HCS itself, it would be better to drive static generation of some kind
> of profile metadata for likely cold blocks (a la __builtin_expect). This
> will be more general and allow passes other than HCS to benefit.
>
> Teresa
>
>
>> Our plan is attached at
>>
>>
https://docs.google.com/document/d/1rGLcFpfVXnF7aS31dWnowd2y_BjJnRA-hj3cUt6MqZ8/edit?usp=sharing
>> .
>>
>> Any feedback, input, or suggestion is welcome and highly appreciated!
>>
>> Best regards,
>> Ruijie
>>
>> Ruijie Fang
>> Email: ruijief at princeton.edu
>>
>
>
> --
> Teresa Johnson |  Software Engineer |  tejohnson at google.com |
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200602/bfc22206/attachment.html>