# Nice talk about Go PGO. What is the state in Julia?

**URL:** <https://discourse.julialang.org/t/nice-talk-about-go-pgo-what-is-the-state-in-julia/115715>\
**Category:** Internals & Design\
**Tags:** profiling, developer-tools, compiler\
**Created:** [June 16, 2024, 3:16pm UTC](https://discourse.julialang.org/t/nice-talk-about-go-pgo-what-is-the-state-in-julia/115715 "2024-06-16T15:16:04Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![Dan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dan/32/42581_2.png) [@Dan](https://discourse.julialang.org/u/Dan)\
**Post date:** [June 16, 2024, 3:16pm UTC](https://discourse.julialang.org/t/nice-talk-about-go-pgo-what-is-the-state-in-julia/115715/1 "2024-06-16T15:16:05Z")

</div>

**These devs get it!**  
The first 10 minutes are about the Go ecosystem and are worth it for any language devs.  
The rest are a great introduction to optimization issues and PGO. P.S. What is the state of PGO in Julia?  
I would love to see a similar demo in Julia if the tools are available.

[![](https://global.discourse-cdn.com/julialang/original/3X/8/e/8e350e4cfb74e2658e61ebe50180c8a835b9aa5a.jpeg "Boost performance of Go applications with profile guided optimization") ](https://www.youtube.com/watch?v=FwzE5Sdhhdw)

---

<div class="post-metadata">

**Author:** ![Zentrik](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/zentrik/32/35409_2.png) [@Zentrik](https://discourse.julialang.org/u/Zentrik)\
**Post date:** [June 16, 2024, 4:06pm UTC](https://discourse.julialang.org/t/nice-talk-about-go-pgo-what-is-the-state-in-julia/115715/2 "2024-06-16T16:06:26Z")

</div>

I’m not aware of any way or any plans for using PGO on Julia code. If you want to pgo the parts of Julia written in C/C++ you can use [Add PGO+LTO Makefile by haampie · Pull Request #45641 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/pull/45641).

---

<div class="post-metadata">

**Author:** ![nsajko](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nsajko/32/221187_2.png) [@nsajko](https://discourse.julialang.org/u/nsajko)\
**Post date:** [June 16, 2024, 5:58pm UTC](https://discourse.julialang.org/t/nice-talk-about-go-pgo-what-is-the-state-in-julia/115715/3 "2024-06-16T17:58:35Z")

</div>

> [@Dan](#):
>
> What is the state of PGO in Julia?

Related thread:

> [@Has PGO for (re)compiling methods been considered?](https://discourse.julialang.org/t/has-pgo-for-re-compiling-methods-been-considered/97426):
>
> It just crossed my mind that it would be very nice if Julia provided some kind of profile-guided optimization (PGO) API. Something like: The user gathers a performance profile for some of their Julia code The user is now able to request a recompilation of their Julia code, feeding the profile to the Julia compiler to enable better optimizations, like, for example, [control height reduction](https://reviews.llvm.org/D50591) or [hot-cold splitting](https://groups.google.com/g/llvm-dev/c/RUegaMg-iqc/m/wFAVxa6fCgAJ). Step 2 could look like this: pgo\_anonymous\_function = recompile\_with\_pgo(m…

So there’s not much activity in this space, but see Tim Holy’s comment about profile-guided despecialization for a limited example.

---

<div class="post-metadata">

**Author:** ![MilesCranmer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/milescranmer/32/21070_2.png) [@MilesCranmer](https://discourse.julialang.org/u/MilesCranmer)\
**Post date:** [June 23, 2024, 1:06pm UTC](https://discourse.julialang.org/t/nice-talk-about-go-pgo-what-is-the-state-in-julia/115715/4 "2024-06-23T13:06:52Z")

</div>

Very interesting. What kind of performance gains could we get out of PGO? In the talk they say they get about 10% across the board for one example but I’m assuming it depends on the optimisations that are by default turned off, and also the particular example.

The statistic about “15% of functions use 99% of CPU time” from the talk is interesting. So basically the idea would be to be more aggressive about inlining, loop unrolling, and constant propagation for those 15% of functions?

Also I guess this sort of thing might just eventually be handled at the LLVM level?

I like the general idea about simply providing the compiler with runtime information rather than just source code so it can make better choices.

---

<div class="post-metadata">

**Author:** ![MilesCranmer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/milescranmer/32/21070_2.png) [@MilesCranmer](https://discourse.julialang.org/u/MilesCranmer)\
**Post date:** [June 23, 2024, 4:01pm UTC](https://discourse.julialang.org/t/nice-talk-about-go-pgo-what-is-the-state-in-julia/115715/5 "2024-06-23T16:01:41Z")

</div>

I feel like this also gives Julia a unique advantage over statically compiled languages, because the compilation is already happening during runtime. So in principle all of the information is already there, and you wouldn’t have this somewhat manual procedure of doing (1) compile, (2) profile, (3) re-compile with profiling information – like they talked about in Go. Julia could technically already do this during the normal runtime.

Maybe the Julia compiler could eventually have an option where it does an on-the-fly “recompilation” sometime after the initial compilation based on profiling results thus far.

Perhaps the first compilation would enable profiling; the second time would turn it off and pass the results to LLVM for PGO-enabled recompilation.

---

<div class="post-metadata">

**Author:** ![Elrod](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/elrod/32/22461_2.png) [@Elrod](https://discourse.julialang.org/u/Elrod)\
**Post date:** [June 23, 2024, 5:07pm UTC](https://discourse.julialang.org/t/nice-talk-about-go-pgo-what-is-the-state-in-julia/115715/6 "2024-06-23T17:07:11Z")

</div>

> [@MilesCranmer](#):
>
> I feel like this also gives Julia a unique advantage over statically compiled languages, because the compilation is already happening during runtime.

It would work especially well with a tiered JIT, like JavaScript has.  
To use PGO, you need to recompile the function. You also don’t want any instrumentation in a function optimized for speed.  
So your lower tiers, which are optimized for compile time rather than runtime, do the instrumentation. They already need to record at least call counts.  
Then, by the time they’re called often enough to be considered hot and trigger recompilation, they can use that profile data.

On the other hand, some whole program optimizations like function reordering based on profile data won’t work as well in a JIT. You’d need to recompile many functions at a time to get much benefit of that.

---

<div class="post-metadata">

**Author:** ![Zentrik](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/zentrik/32/35409_2.png) [@Zentrik](https://discourse.julialang.org/u/Zentrik)\
**Post date:** [June 23, 2024, 5:59pm UTC](https://discourse.julialang.org/t/nice-talk-about-go-pgo-what-is-the-state-in-julia/115715/7 "2024-06-23T17:59:24Z")

</div>

Some examples of the speedup from PGO:  
Julia Compiler - about 10% per [Add PGO+LTO Makefile by haampie · Pull Request #45641 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/pull/45641)  
Rust Compiler - about 15% per [Utilize PGO for windows x64 rustc dist builds by lqd · Pull Request #96978 · rust-lang/rust (github.com)](https://github.com/rust-lang/rust/pull/96978)  
Chrome - about 10% per [Chromium Blog: Chrome just got faster with Profile Guided Optimization](https://blog.chromium.org/2020/08/chrome-just-got-faster-with-profile.html)

Also, looks like [Tiered JIT Experiments by pchintalapudi · Pull Request #47484 · JuliaLang/julia (github.com)](https://github.com/JuliaLang/julia/pull/47484) does some compiling code quickly, then pgo + optimizing if called a lot.

---

<div class="post-metadata">

**Author:** ![StefanKarpinski](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stefankarpinski/32/24_2.png) [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)\
**Post date:** [June 24, 2024, 2:36pm UTC](https://discourse.julialang.org/t/nice-talk-about-go-pgo-what-is-the-state-in-julia/115715/8 "2024-06-24T14:36:31Z")

</div>

> [@MilesCranmer](#):
>
> Maybe the Julia compiler could eventually have an option where it does an on-the-fly “recompilation” sometime after the initial compilation based on profiling results thus far.

There is danger here of causing “performance flapping” where the system never reaches a steady state, let alone the optimal state. Check out this (imo modern classic) paper:

[https://arxiv.org/pdf/1602.00602v3](https://arxiv.org/pdf/1602.00602v3)

Also found this video on the same subject for those who prefer a video format:

[![](https://global.discourse-cdn.com/julialang/original/3X/c/6/c6130d12e91fbd67490c9d20735f86dfbfeb2482.jpeg "Virtual machine warmup blows hot and cold - Laurence Tratt") ](https://www.youtube.com/watch?v=lIyU2OQdEZE)

Not an insurmountable problem but one does have to be careful. One of this nice things that Julia has going for it is that since it is a Just Ahead of Time compiler that compiles like an AoT compile but just in time, it has very predictable performance characteristics, whereas VM “JITs” which are actually not in time but after time, have pretty complicated performance behavior that depends on the data they encounter and the environment in which they execute—for better and worse. The key point of that paper is that it is not all upside, there is a real downside.

---

<div class="post-metadata">

**Author:** ![nsajko](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nsajko/32/221187_2.png) [@nsajko](https://discourse.julialang.org/u/nsajko)\
**Post date:** [June 24, 2024, 4:40pm UTC](https://discourse.julialang.org/t/nice-talk-about-go-pgo-what-is-the-state-in-julia/115715/9 "2024-06-24T16:40:48Z")

</div>

> [@StefanKarpinski](#):
>
> “performance flapping” where the system never reaches a steady state, let alone the optimal state

Interesting. This is a strong argument in favor of my PGO API proposal from the linked Discourse thread, where the profiling, and thus PGO, is only done when the user requests it.