Adaptive Execution of Compiled Queries

Kohn, Andre; Leis, Viktor; Neumann, Thomas

doi:10.1109/icde.2018.00027

“…Before we look at the reasons for this, we note that these are not large differences, especially when compared to the performance gap to other systems. For example the difference between HyPer and PostgresSQL is between one and two orders of magnitude [17]. In other words, the performance of both query processing paradigms is quite closedespite the fact that the two models appear different from the point of someone implementing these systems.…”

Section: Micro-architectural Analysismentioning

confidence: 99%

Everything you always wanted to know about compiled and vectorized queries but were afraid to ask

Kersten

¹

,

Leis

²

,

Kemper

³

et al. 2018

Self Cite

View full text Add to dashboard Cite

The query engines of most modern database systems are either based on vectorization or data-centric code generation. These two state-of-the-art query processing paradigms are fundamentally different in terms of system structure and query execution code. Both paradigms were used to build fast systems. However, until today it is not clear which paradigm yields faster query execution, as many implementation-specific choices obstruct a direct comparison of architectures. In this paper, we experimentally compare the two models by implementing both within the same test system. This allows us to use for both models the same query processing algorithms, the same data structures, and the same parallelization framework to ultimately create an apples-to-apples comparison. We find that both are efficient, but have different strengths and weaknesses. Vectorization is better at hiding cache miss latency, whereas data-centric compilation requires fewer CPU instructions, which benefits cacheresident workloads. Besides raw, single-threaded performance, we also investigate SIMD as well as multi-core parallelization and different hardware architectures. Finally, we analyze qualitative differences as a guide for system architects.

show abstract

“…Subsequent sections show the basic translator design and introduce the proposed optimizations step by step. Kohn et al [18] created the adaptive execution method which incorporates multiple execution backends into the HyPer database system. Adaptive execution switches dynamically between execution backends at runtime-even halfway through a query-in order to profit from fast compilation for short-running queries and from fast execution for longrunning queries.…”

Section: Flying Start Backendmentioning

confidence: 99%

“…Flying Start can reuse a stack slot once it knows that the value occupying the slot is never used again. To obtain this information, we arrange the program's basic blocks in reverse post-order and calculate the live spans of all values with the linear time algorithm described by Kohn et al [18,26]. The live span of a value is the interval from first to last point in the program where the value is live (similar to live intervals of Poletto and Sarkar [38]).…”

Section: Stack Space Reusementioning

confidence: 99%

“…Further, it reduces the time spent for execution as the speed of the created machine-code is close to that of thoroughly optimized code. The Flying Start backend is integrated into Umbra through the adaptive execution technique [18]. This allows Umbra to switch dynamically between low-latency compilation with Flying Start and highest-speed query execution by optimizing compilation with the LLVM compiler framework.…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Tidy Tuples and Flying Start: fast compilation and fast execution of relational queries in Umbra

Kersten¹,

Leis

²

,

Neumann³

2021

Self Cite

View full text Add to dashboard Cite

Although compiling queries to efficient machine code has become a common approach for query execution, a number of newly created database system projects still refrain from using compilation. It is sometimes claimed that the intricacies of code generation make compilation-based engines too complex. Also, a major barrier for adoption, especially for interactive ad hoc queries, is long compilation time. In this paper, we examine all stages of compiling query execution engines and show how to reduce compilation overhead. We incorporate the lessons learned from a decade of generating code in HyPer into a design that manages complexity and yields high speed. First, we introduce a code generation framework that establishes abstractions to manage complexity, yet generates code in a single fast pass. Second, we present a program representation whose data structures are tuned to support fast code generation and compilation. Third, we introduce a new compiler backend that is optimized for minimal compile time, and simultaneously, yields superior execution performance to competing approaches, e.g., Volcano-style or bytecode interpretation. We implemented these optimizations in our database system Umbra to show that it is possible to unite fast compilation and fast execution. Indeed, Umbra achieves unprecedentedly low query latencies. On small data sets, it is even faster than interpreter engines like DuckDB and PostgreSQL. At the same time, on large data sets, its throughput is on par with the state-of-the-art compiling system HyPer.

show abstract

“…Real-world data-centric compilation systems take mitigating measures against this. HyPer switches off certain LLVM optimization passes such as register allocation and replaces them by its own more scalable register allocation algorithm, and even contains a LLVM IR interpreter that is used to execute the first morsels of data; if that is enough to answer the query, full LLVM compilation is omitted [17]. This largely obviates this downside of compilation-but comes at the cost of additional system complexity.…”

Section: Compilation Timementioning

confidence: 99%

Everything you always wanted to know about compiled and vectorized queries but were afraid to ask

KerstenTimo¹,

LeisViktor²,

et al. 2018

Self Cite

View full text Add to dashboard Cite

The query engines of most modern database systems are either based on vectorization or data-centric code generation. These two state-of-the-art query processing paradigms are fundamentally different in terms of system structure and query execution code. Both paradigms were used to build fast systems. However, until today it is not clear which paradigm yields faster query execution, as many implementation-specific choices obstruct a direct comparison of architectures. In this paper, we experimentally compare the two models by implementing both within the same test system. This allows us to use for both models the same query processing algorithms, the same data structures, and the same parallelization framework to ultimately create an apples-to-apples comparison. We find that both are efficient, but have different strengths and weaknesses. Vectorization is better at hiding cache miss latency, whereas data-centric compilation requires fewer CPU instructions, which benefits cacheresident workloads. Besides raw, single-threaded performance, we also investigate SIMD as well as multi-core parallelization and different hardware architectures. Finally, we analyze qualitative differences as a guide for system architects.

show abstract

Adaptive Execution of Compiled Queries

Cited by 43 publications

References 23 publications

Everything you always wanted to know about compiled and vectorized queries but were afraid to ask

Everything you always wanted to know about compiled and vectorized queries but were afraid to ask

Tidy Tuples and Flying Start: fast compilation and fast execution of relational queries in Umbra

Everything you always wanted to know about compiled and vectorized queries but were afraid to ask

Contact Info

Product

Resources

About