Re: JIT compiling with LLVM v10.1

On 14.02.2018 21:17, Andres Freund wrote:
> Hi,
>
> On 2018-02-07 06:54:05 -0800, Andres Freund wrote:
>> I've pushed v10.0. The big (and pretty painful to make) change is that
>> now all the LLVM specific code lives in src/backend/jit/llvm, which is
>> built as a shared library which is loaded on demand.
>>
>> The layout is now as follows:
>>
>> src/backend/jit/jit.c:
>> Part of JITing always linked into the server. Supports loading the
>> LLVM using JIT library.
>>
>> src/backend/jit/llvm/
>> Infrastructure:
>> llvmjit.c:
>> General code generation and optimization infrastructure
>> llvmjit_error.cpp, llvmjit_wrap.cpp:
>> Error / backward compat wrappers
>> llvmjit_inline.cpp:
>> Cross module inlining support
>> Code-Gen:
>> llvmjit_expr.c
>> Expression compilation
>> llvmjit_deform.c
>> Deform compilation
> I've pushed a revised version that hopefully should address Jeff's
> wish/need of being able to experiment with this out of core. There's now
> a "jit_provider" PGC_POSTMASTER GUC that's by default set to
> "llvmjit". llvmjit.so is the .so implementing JIT using LLVM. It fills a
> set of callbacks via
> extern void _PG_jit_provider_init(JitProviderCallbacks *cb);
> which can also be implemented by any other potential provider.
>
> The other two biggest changes are that I've added a README
> https://git.postgresql.org/gitweb/?p=users/andresfreund/postgres.git;a=blob;f=src/backend/jit/README;hb=jit
> and that I've revised the configure support so it does more error
> checks, and moved it into config/llvm.m4.
>
> There's a larger smattering of small changes too.
>
> I'm pretty happy with how the separation of core / shlib looks now. I'm
> planning to work on cleaning and then pushing some of the preliminary
> patches (fixed tupledesc, grouping) over the next few days.
>
> Greetings,
>
> Andres Freund
>

I have made  some more experiments with efficiency of JIT-ing of deform
tuple and I want to share this results (I hope that them will be
interesting).
It is well known fact that Postgres spends most of the time in sequence
scan queries for warm data in deforming tuples (17% in case of TPC-H Q1).
Postgres  tries to optimize access to the tuple by caching fixed size
offsets to the fields whenever possible and loading attributes on demand.
It is also well know recommendation to put fixed size, non-null,
frequently used attributes at the beginning of table's attribute list to
make this optimization work more efficiently.
You can see in the code of heap_deform_tuple shows that first NULL value
will switch it to "slow" mode:

for (attnum = 0; attnum < natts; attnum++)
    {
        Form_pg_attribute thisatt = TupleDescAttr(tupleDesc, attnum);

        if (hasnulls && att_isnull(attnum, bp))
        {
            values[attnum] = (Datum) 0;
            isnull[attnum] = true;
            slow = true;        /* can't use attcacheoff anymore */
            continue;
        }

I tried to investigate importance of this optimization and what is
actual penalty of "slow" mode.
At the same time I want to understand how JIT help to speed-up tuple
deforming.

I have populated with data three tables:

create table t1(id integer primary key,c1 integer,c2 integer,c3
integer,c4 integer,c5 integer,c6 integer,c7 integer,c8 integer,c9 integer);
create table t2(id integer primary key,c1 integer,c2 integer,c3
integer,c4 integer,c5 integer,c6 integer,c7 integer,c8 integer,c9 integer);
create table t3(id integer primary key,c1 integer not null,c2 integer
not null,c3 integer not null,c4 integer not null,c5 integer not null,c6
integer not null,c7 integer not null,c8 integer not null,c9 integer not
null);
insert into t1 (id,c1,c2,c3,c4,c5,c6,c7,c8) values
(generate_series(1,10000000),0,0,0,0,0,0,0,0);
insert into t2 (id,c2,c3,c4,c5,c6,c7,c8,c9) values
(generate_series(1,10000000),0,0,0,0,0,0,0,0);
insert into t3 (id,c1,c2,c3,c4,c5,c6,c7,c8,c9) values
(generate_series(1,10000000),0,0,0,0,0,0,0,0,0);
vacuum analyze t1;
vacuum analyze t2;
vacuum analyze t3;

t1 contains null in last c9 column, t2 - in first c1 columns and t3 has
all attributes declared as not-null (and JIT can use this knowledge to
generate more efficient deforming code).
All data set is hold in memory (shared buffer size is greater than
database size) and I intentionally switch off parallel execution to make
results more deterministic.
I run two queries calculating aggregates on one/all not-null fields:

select sum(c8) from t*;
select sum(c2), sum(c3), sum(c4), sum(c5), sum(c6), sum(c7), sum(c8)
from t*;

As expected 35% time was spent in heap_deform_tuple.
But results (msec) were slightly confusing and unexected:

select sum(c8) from t*;

w/o JIT
with JIT
t1 763
563
t2 772
570
t3
776
592

select sum(c2), sum(c3), sum(c4), sum(c5), sum(c6), sum(c7), sum(c8)
from t*;

w/o JIT
with JIT
t1 1239 742
t2 1233 747
t3
1255 803

I repeat each query 10 times and take the minimal time ( I think that it
is more meaningful than average time which depends on some other
activity on the system).
So there is no big difference between "slow" and "fast" ways of
deforming tuple.
Moreover, for sometimes "slow" case is faster. Although I have to say
thatvariance of results is quite large: about 10%.
But in any case, I can made two conclusions from this results:

1. Modern platforms are mostly limited by memory access time, number of
performed instructions is less critical.
This is why extra processing needed for nullable attributes can not
significantly affect performance.
2. For large number of attributes JIT-ing of deform tuple can improve
speed up to two time. Which is quite good result from my point of view.

--

Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company