Re: JIT compiling with LLVM v12

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: JIT compiling with LLVM v12
Дата
Msg-id 20180905185539.k5rbfghfbtfilvm7@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: JIT compiling with LLVM v12  (Noah Misch <noah@leadboat.com>)
Ответы Re: JIT compiling with LLVM v12  (Noah Misch <noah@leadboat.com>)
Список pgsql-hackers
Hi,

On 2018-08-22 06:20:21 +0000, Noah Misch wrote:
> I see jit slows the regression tests considerably:

Is this with LLVM assertions enabled or not?  The differences seem
bigger than what I'm observing, especially on the mips animal - which I
observe uses a separately installed LLVM build.

On my machine, with master, on a postgres assert build w/ non-debug llvm build:
PGOPTIONS='-c jit=0' time make -Otarget -j10 -s check-world  && echo success || echo f
240.37user 55.55system 2:08.17elapsed 230%CPU (0avgtext+0avgdata 66264maxresident)k

PGOPTIONS='-c jit=1' time make -Otarget -j10 -s check-world  && echo success || echo f
253.02user 55.77system 2:16.22elapsed 226%CPU (0avgtext+0avgdata 54756maxresident)k


Using your command, on a postgres optimized build w/ non-debug llvm build:

> # x86_64, non-assert, w/o llvm
> $ for n in 1 2 3; do env time make -C src/bin/pg_upgrade check; done 2>&1 | grep elapsed
> 7.64user 4.24system 0:36.40elapsed 32%CPU (0avgtext+0avgdata 36712maxresident)k
> 8.09user 4.50system 0:37.71elapsed 33%CPU (0avgtext+0avgdata 36712maxresident)k
> 7.53user 4.18system 0:36.54elapsed 32%CPU (0avgtext+0avgdata 36712maxresident)k
>
> # x86_64, non-assert, w/  llvm trunk
> $ for n in 1 2 3; do env time make -C src/bin/pg_upgrade check; done 2>&1 | grep elapsed
> 9.58user 5.79system 0:49.61elapsed 30%CPU (0avgtext+0avgdata 36712maxresident)k
> 9.47user 5.92system 0:47.84elapsed 32%CPU (0avgtext+0avgdata 36712maxresident)k
> 9.09user 5.51system 0:47.94elapsed 30%CPU (0avgtext+0avgdata 36712maxresident)k
>

andres@alap4:~/build/postgres/master-optimize/vpath$ for n in 1 2 3; do PGOPTIONS='-cjit=0' env time make -C
src/bin/pg_upgradecheck; done 2>&1 | grep elapsed
 
8.01user 3.63system 0:39.88elapsed 29%CPU (0avgtext+0avgdata 50196maxresident)k
7.96user 3.86system 0:39.70elapsed 29%CPU (0avgtext+0avgdata 50064maxresident)k
7.96user 3.80system 0:37.17elapsed 31%CPU (0avgtext+0avgdata 50148maxresident)k
andres@alap4:~/build/postgres/master-optimize/vpath$ for n in 1 2 3; do PGOPTIONS='-cjit=1' env time make -C
src/bin/pg_upgradecheck; done 2>&1 | grep elapsed
 
7.88user 3.76system 0:44.98elapsed 25%CPU (0avgtext+0avgdata 50092maxresident)k
7.99user 3.72system 0:46.53elapsed 25%CPU (0avgtext+0avgdata 50036maxresident)k
7.88user 3.87system 0:45.26elapsed 25%CPU (0avgtext+0avgdata 50132maxresident)k

So here the difference is smaller, but not hugely so.


> # mips32el, assert, w/o llvm (buildfarm member topminnow) [1]
> 28min install-check-*
> 35min check-pg_upgrade
>
> # mips32el, assert, w/  llvm 6.0.1 [1]
>  63min install-check-*
> 166min check-pg_upgrade

But this seems so absurdly large of a difference that I kinda think LLVM
assertions (wich are really expensive and add O(N) operations in a bunch
of places) might be to blame.

Greetings,

Andres Freund


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jesper Pedersen
Дата:
Сообщение: Re: pread() and pwrite()
Следующее
От: Andrew Gierth
Дата:
Сообщение: Re: Bug fix for glibc broke freebsd build in REL_11_STABLE