Zoltán Borók-Nagy created IMPALA-15522:
------------------------------------------

             Summary: Random choice of broadcast runtime filter producers makes 
codegen nondeterministic and defeats the codegen cache
                 Key: IMPALA-15522
                 URL: https://issues.apache.org/jira/browse/IMPALA-15522
             Project: IMPALA
          Issue Type: Improvement
          Components: Backend
            Reporter: Zoltán Borók-Nagy


For a broadcast join with only non-local filter targets, the coordinator picks 
MAX_BROADCAST_FILTER_PRODUCERS (3) random instances to produce each filter 
(coordinator.cc:479, random_shuffle() then resize()).

On each backend, PhjBuilderConfig drops the filters this backend does not 
produce before codegen (partitioned-hash-join-builder.cc:120), and the 
codegen'd build loop emits one insert per kept filter. So the generated IR of 
the build differs between producer and non-producer backends. Which backends 
are producers changes on every run.

The codegen cache key is the module bitcode, so these fragments miss the cache 
on warm runs.

*Evidence* (TPC-DS SF100, 5 executors, master 1f34ea915e):
* 57 of 1887 fragments had host- and run-dependent IR, and they accounted for 
every warm cache miss: 144 of 144 in the second iteration and 71 of 71 in the 
third.
* Example: for q1 F02, hosts {1,3,5} got the larger IR in one run and hosts 
{2,4,5} in the next.
* Each miss means a full LLVM optimization and compile. About 40% of that 
compile time shows up in wall time overall, and 60-100% for sub-second queries.

*Proposed fix:* codegen inserts for all filters of the join on every backend, 
and skip the filters this backend does not produce at runtime.
* Keep a FilterContext with filter == nullptr for them, and don't allocate or 
publish them.
* The codegen'd insert already returns early when the local filter is null.
* The IR then depends only on the plan.

The alternative, choosing producers deterministically (for example a stable 
backend order rotated by filter id), still leaves producer and non-producer IR 
different. It also breaks whenever the set of backends changes.

A prototype of the proposed fix took warm codegen-cache misses over the 
workload from 128 to 0. The geomean of per-query times was 0.87 (-2.9% total); 
most of the gain is on sub-second queries.

Side note: std::random_shuffle is deprecated in C++14 and removed in C++17.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to