GFQL Performance: Vectorization and GPU Acceleration

GFQL Performance: Vectorization and GPU Acceleration#

Engine speedups at a glance#

GFQL runs the same query on four interchangeable engines — pandas (default), polars (CPU, columnar), cudf (NVIDIA GPU), and polars-gpu (GPU) — and returns identical results on each (differential parity is a release gate). Unsupported engine/query combinations are declined before execution during validation, compilation, or planning rather than silently falling back. The biggest, easiest win is one keyword, no GPU required:

g.gfql(query)                    # engine='pandas' (default)
g.gfql(query, engine='polars')   # up to ~38x faster on real graphs, same results

Warm-median latency, same query, identical result rows (Orkut, 117M edges, SNAP):

Workload (117M edges)

pandas

polars

cudf

polars-gpu

1-hop from 10K seeds

2613 ms

68 ms

1005 ms

63 ms

Full out-degree aggregation

799 ms

205 ms

314 ms

167 ms

There is no universal winner: polars typically takes over from ~10K edges up (pandas still wins trivial sub-millisecond operations), and the right GPU engine depends on the workload. See Choosing a GFQL Engine: pandas, Polars, cuDF, Polars-GPU for the full decision matrix, the honest “when not to use Polars”, the cuDF-vs-Polars-GPU comparison, and the methodology + reproducer scripts behind these numbers. The end-to-end CPU/GPU-vs-Neo4j benchmark is in GFQL Cypher Benchmark: CPU/GPU DataFrames vs Neo4j.

How GFQL is fast#

Three design choices explain the numbers above:

Collection-oriented execution. GFQL evaluates whole collections of nodes and edges at once (set-at-a-time), rather than walking one path at a time like traditional Cypher/Gremlin engines. A traversal advances by joining edge tables, so the work vectorizes.

Vectorized columnar processing. Data is processed in columnar batches on top of Apache Arrow, which keeps the CPU path fast and makes moving data between systems cheap. The polars engine additionally builds one fused lazy plan and collects once, which is why it outruns both pandas and eager cuDF on bulk work.

Massive parallelism on GPUs. On an NVIDIA GPU (cudf / polars-gpu), the same vectorized work saturates tens of thousands of threads — paying off when there is enough work to amortize kernel-launch cost (large frontiers, dense joins, full-graph aggregation).

Start on CPU with no special hardware, and move to a GPU engine by changing one keyword when your workload grows into GPU territory. See Choosing a GFQL Engine: pandas, Polars, cuDF, Polars-GPU for exactly when each engine wins.

Note

Same-path constraints (where) can be more expensive on dense graphs. Prefer selective per-step predicates and see GFQL WHERE (Same-Path Constraints) for details.

Next Steps#