frankmcsherry/dynamic-datalog

Engines, queries, and data for dynamic Datalog computation

Rust

137

9 commits

updated Aug 4, 2021

See the code

README

dynamic-datalog

Engines, queries, and data for dynamic Datalog computation


This repository maintains a list of dynamic Datalog engines, those that update query outputs in response to changes in the input fact sets.

The repository also maintains several paired Datalog queries and input data, meant to exercise dynamic Datalog execution engines in non-trivial ways. These can be found in the ./problems/ subdirectory. These problems may also be independently interesting for evaluating non-dynamic Datalog engines.

Engines

We also use the excellent Soufflé as a non-dynamic baseline.

Problems

Evaulations

For each problem we record reported times for various systems in various configurations, both to perform any query-specific compilation and then execution. These measurements are meant to be representative rather than definitive. All of the systems support multiple worker threads, and could be run in a variety of configurations on a variety of hardware platforms.

Soufflé can often benefit from join planning help; without this help it can take orders of magnitude longer than it could. Such help is currently provided for the CRDT and Doop benchmarks, and measurements for other queries could improve in the future (especially for those runs in which it did not finish in 1,000 seconds). The Soufflé measurements are all directly using the query.dl file from the decompressed input directory, either with the -c flag (for compilation) or without (for interpretation).

Unlike other measurements, the Differential Dataflow measurements are for hand-written code in a larger language, and can reflect implementation and optimizations not easily available within Datalog. The code for each problem is in the differential/ directory.

The CRDT benchmark

EngineCompilationEvaluationCoresNotes
Soufflé (interpreted)0s1000s+ (DNF)1Laptop
Soufflé (compiled)10.15s294.73s1Laptop
Differential Dataflow166.26s3.44s1Laptop
Declarative Dataflow0s
Differential Datalog
IncA

The CRDT benchmark contains stratified negation, as well as several "maximization" idioms represented in Datalog using a quadratic number of facts, which can be more efficiently implemented as data-parallel reduce operations.

The DOOP benchmark

EngineCompilationEvaluationCoresNotes
Soufflé (interpreted)0s762.14s1Laptop
Soufflé (compiled)93.43s111.76s1Laptop
Differential Dataflow237.43s161.58s1Laptop
Declarative Dataflow0s
Differential Datalog
IncA

The DOOP benchmark is just really quite large.

The GALEN benchmark

EngineCompilationEvaluationCoresNotes
Soufflé (interpreted)0s1000s+ (DNF)1Laptop
Soufflé (compiled)9.31s198.19s1Laptop
Differential Dataflow111.59s123.54s1Laptop
Declarative Dataflow0s
Differential Datalog
IncA

The GALEN benchmark contains joins on highly skewed keys, for which correct or adaptive join orders are important. The most problematic rule (IR4) is presented in the least problematic order for binary joins.

Contributors

frankmcsherry

9 commits

frankmcsherry/dynamic-datalog

Engines, queries, and data for dynamic Datalog computation

Rust

137

9 commits

updated Aug 4, 2021

See the code

README

dynamic-datalog

Engines, queries, and data for dynamic Datalog computation


This repository maintains a list of dynamic Datalog engines, those that update query outputs in response to changes in the input fact sets.

The repository also maintains several paired Datalog queries and input data, meant to exercise dynamic Datalog execution engines in non-trivial ways. These can be found in the ./problems/ subdirectory. These problems may also be independently interesting for evaluating non-dynamic Datalog engines.

Engines

We also use the excellent Soufflé as a non-dynamic baseline.

Problems

Evaulations

For each problem we record reported times for various systems in various configurations, both to perform any query-specific compilation and then execution. These measurements are meant to be representative rather than definitive. All of the systems support multiple worker threads, and could be run in a variety of configurations on a variety of hardware platforms.

Soufflé can often benefit from join planning help; without this help it can take orders of magnitude longer than it could. Such help is currently provided for the CRDT and Doop benchmarks, and measurements for other queries could improve in the future (especially for those runs in which it did not finish in 1,000 seconds). The Soufflé measurements are all directly using the query.dl file from the decompressed input directory, either with the -c flag (for compilation) or without (for interpretation).

Unlike other measurements, the Differential Dataflow measurements are for hand-written code in a larger language, and can reflect implementation and optimizations not easily available within Datalog. The code for each problem is in the differential/ directory.

The CRDT benchmark

EngineCompilationEvaluationCoresNotes
Soufflé (interpreted)0s1000s+ (DNF)1Laptop
Soufflé (compiled)10.15s294.73s1Laptop
Differential Dataflow166.26s3.44s1Laptop
Declarative Dataflow0s
Differential Datalog
IncA

The CRDT benchmark contains stratified negation, as well as several "maximization" idioms represented in Datalog using a quadratic number of facts, which can be more efficiently implemented as data-parallel reduce operations.

The DOOP benchmark

EngineCompilationEvaluationCoresNotes
Soufflé (interpreted)0s762.14s1Laptop
Soufflé (compiled)93.43s111.76s1Laptop
Differential Dataflow237.43s161.58s1Laptop
Declarative Dataflow0s
Differential Datalog
IncA

The DOOP benchmark is just really quite large.

The GALEN benchmark

EngineCompilationEvaluationCoresNotes
Soufflé (interpreted)0s1000s+ (DNF)1Laptop
Soufflé (compiled)9.31s198.19s1Laptop
Differential Dataflow111.59s123.54s1Laptop
Declarative Dataflow0s
Differential Datalog
IncA

The GALEN benchmark contains joins on highly skewed keys, for which correct or adaptive join orders are important. The most problematic rule (IR4) is presented in the least problematic order for binary joins.

Contributors

frankmcsherry

9 commits

Languages

Rust

100.0%