Re: Why JIT speed improvement is so modest?

From: Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Why JIT speed improvement is so modest?
Date: 2019-12-06 16:52:15
Message-ID: 3ea180b0-4a82-c98c-42d0-12e8e42c0b36@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 06.12.2019 18:53, Robert Haas wrote:
> On Thu, Nov 28, 2019 at 2:08 AM Konstantin Knizhnik
> <k(dot)knizhnik(at)postgrespro(dot)ru> wrote:
>> calls float4_accum for each row of T, the same query in VOPS will call
>> vops_float4_avg_accumulate for each tile which contains 64 elements.
>> So vops_float4_avg_accumulate is called 64 times less than float4_accum.
>> And inside it contains straightforward loop:
>>
>> for (i = 0; i < TILE_SIZE; i++) {
>> sum += opd->payload[i];
>> }
>>
>> which can be optimized by compiler (loop unrolling, use of SIMD
>> instructions,...).
> Part of the reason why the compiler can optimize that so well is
> probably related to the fact that it includes no overflow checks.

May it makes sense to use in aggregate transformation function which is
not checking for overflow and perform this check only in final function?
NaN and Inf values will be preserved in any case...

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2019-12-06 17:17:32 Re: global / super barriers (for checksums)
Previous Message Justin Pryzby 2019-12-06 16:23:25 Re: error context for vacuum to include block number