Re: Optimizing PostgreSQL with LLVM's PGO+LTO

2023-02-01 Thread João Paulo Labegalini de Carvalho
On Mon, Jan 30, 2023 at 10:47 AM Andres Freund wrote: > For some reason my notes for using LTO include changing RANLIB to point to > gcc/llvm-ranlib of the appropriate version. Won't even be used on HEAD, but > before that it can make a difference. > I will try that. > Depending on how you

Re: Optimizing PostgreSQL with LLVM's PGO+LTO

2023-01-30 Thread Andres Freund
Hi, On 2023-01-30 10:24:02 -0700, João Paulo Labegalini de Carvalho wrote: > > What compiler / version / flags / OS did you try? > > > > I am running experiment on a machine with: > >- Intel(R) Xeon(R) Platinum 8268 CPU @ 2.90GHz >- Ubuntu 18.04.6 LTS >- LLVM/Clang 15.0.6 (build

Re: Optimizing PostgreSQL with LLVM's PGO+LTO

2023-01-30 Thread João Paulo Labegalini de Carvalho
> What compiler / version / flags / OS did you try? > I am running experiment on a machine with: - Intel(R) Xeon(R) Platinum 8268 CPU @ 2.90GHz - Ubuntu 18.04.6 LTS - LLVM/Clang 15.0.6 (build from source) These are the flags I am using: CFLAGS = -O3 -fuse-ld=lld -gline-tables-only

Re: Optimizing PostgreSQL with LLVM's PGO+LTO

2023-01-27 Thread Andres Freund
Hi, On 2023-01-27 18:28:16 -0500, Tom Lane wrote: > Andres Freund writes: > > I'm sure we have a few places that aren't that careful, but I would hope > > it's > > not a large number. Are you thinking of specific "patterns" we've repeated > > all > > over, or just a few cases you recall? > >

Re: Optimizing PostgreSQL with LLVM's PGO+LTO

2023-01-27 Thread Tom Lane
Andres Freund writes: > On 2023-01-27 15:06:37 -0500, Tom Lane wrote: >> There are a lot of places where we're implicitly relying on >> cross-compilation-unit optimizations NOT happening, because the code isn't >> adequately decorated with memory barriers and the like. > We have a fallback

Re: Optimizing PostgreSQL with LLVM's PGO+LTO

2023-01-27 Thread Andres Freund
Hi, On 2023-01-27 15:06:37 -0500, Tom Lane wrote: > There are a lot of places where we're implicitly relying on > cross-compilation-unit optimizations NOT happening, because the code isn't > adequately decorated with memory barriers and the like. We have a fallback compiler barrier

Re: Optimizing PostgreSQL with LLVM's PGO+LTO

2023-01-27 Thread Andres Freund
Hi, On 2023-01-27 10:05:09 -0700, João Paulo Labegalini de Carvalho wrote: > I am investigating the benefits of different profile-guided optimizations > (PGO) and link-time optimizations (LTO) versus binary optimizers (e.g. > BOLT) for applications such as PostgreSQL. > > I am facing issues when

Re: Optimizing PostgreSQL with LLVM's PGO+LTO

2023-01-27 Thread Tom Lane
=?UTF-8?Q?Jo=C3=A3o_Paulo_Labegalini_de_Carvalho?= writes: > I am facing issues when applying LTO to PostgreSQL as the produced binary > seems broken (the server dies quickly after it has started). This is > definitely a compiler bug, but I was wondering if anyone here have > experimented with

Re: Optimizing PostgreSQL with LLVM's PGO+LTO

2023-01-27 Thread Komяpa
Hi, We have implemented LTO in PostGIS's build system a couple releases ago. It definitely gives +10% on heavy maths. Unfortunately we did not manage to get it running under FreeBSD because of default system linker issues so we had to hide it under --with-lto switch which we recommend to

Optimizing PostgreSQL with LLVM's PGO+LTO

2023-01-27 Thread João Paulo Labegalini de Carvalho
Hi all, I am investigating the benefits of different profile-guided optimizations (PGO) and link-time optimizations (LTO) versus binary optimizers (e.g. BOLT) for applications such as PostgreSQL. I am facing issues when applying LTO to PostgreSQL as the produced binary seems broken (the server