Zoltán Borók-Nagy created IMPALA-15650:
------------------------------------------
Summary: Inline bloom filter probes and inserts into codegen'd code
Key: IMPALA-15650
URL: https://issues.apache.org/jira/browse/IMPALA-15650
Project: IMPALA
Issue Type: Improvement
Components: Backend
Reporter: Zoltán Borók-Nagy
The codegen'd runtime filter evaluation (FilterContext::CodegenEval(), calling
the cross-compiled RuntimeFilter::Eval()) probes a bloom filter with
kudu::BlockBloomFilter::Find(), which calls BucketFindAVX2() through a member
function pointer (block_bloom_filter.cc, master 9c8bcc9585). Neither call can
be inlined into the generated code, so every probed row pays an out-of-line
call and an indirect call. The codegen'd filter insert of join builds
(BloomFilter::IrInsert()) makes the same calls into Kudu's Insert().
*Proposal:* implement Kudu's probe and insert in bloom-filter-ir.cc on the
public state of the Kudu filter, with the same hash, bucket index and bit
layout, using generic 256-bit vectors that the AVX2 IR module lowers to the
same instructions as Kudu's AVX2 code. Use them from the codegen'd filter
evaluation and insert; interpreted code keeps calling Kudu. Add a unit test
that checks that answers and filter bytes match Kudu's Find() and Insert().
*Measured* with a prototype: a tight probe loop on a 1 MB filter took 1.8 ns
instead of 2.2 ns per probe, but TPC-DS SF100 with 5 executors (MT_DOP=0)
showed no measurable end-to-end gain (total -0.5%, +0.4% without q72 and q78).
Low priority on its own.
Prototype: https://gerrit.cloudera.org/#/c/25204/
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
