LSEG announced a collaboration on 14 October using NVIDIA cuDF and Polars to accelerate Tick History analysis without duplicating the full licensed dataset. It reports benchmark processing falling from hours to seconds, a potentially useful improvement for execution analysis, strategy testing and market replay.[1]
Archive coverage sets the opportunity; the query determines the workload
The service spans 110 trillion rows, 100 million instruments, over 30 years and more than 580 venues and contributors. Archive coverage is not the same as the input size of an individual benchmark.[1]
For a research desk, the useful improvement is answering the same question faster or retaining more relevant historical detail within the available time. The release does not disclose enough benchmark configuration to infer a universal speed-up for every query.[1]
The processing path determines whether GPU acceleration is used
cuDF is a GPU-accelerated dataframe toolkit. It applies parallel processing to operations such as filtering, joins and aggregation on structured columns. Its relationship with Polars allows eligible analytical queries to use that processing without requiring every application to be redesigned around a different dataframe interface. Data transfer and interoperability remain part of the implementation, not costs eliminated by the word “GPU”.[2]
Three technical boundaries to test
| Boundary | Documented distinction | Implication for a user |
|---|---|---|
| Requested engine versus actual execution | Unsupported Polars operations may fall back to CPU | Measure the executed path, not only the configurationSource 3 |
| In-memory versus streaming workloads | Streaming processes partitioned work rather than relying only on the initial single-GPU in-memory design | Dataset size and operation choice affect the useful architectureSource 4 |
| Computation versus complete workflow | Data movement and dataframe operations are separate stages | A fast kernel is not an end-to-end service-level commitmentSource 2 |
NVIDIA’s version 26.10 developer documentation says POLARS_VERBOSE can expose CPU fallback with a PerformanceWarning. It also describes GPUEngine(raise_on_fail=True) as a debugging option that raises an error during unsupported translation instead of falling back. Those controls help distinguish a completed query from a query that actually followed the intended GPU path; they are not production performance promises.[3]
Polars’ August technical explanation describes the evolution from the original in-memory GPU engine to a streaming backend with partitioned execution. This expands the implementation choices for larger workloads. It does not identify which exact backend version, partition size or hardware configuration LSEG used; the product announcement and the general technology documentation answer different questions.[4]
Measure preparation and movement as well as calculation
A useful evaluation would compare the same input coverage and analytical result, record preparation and transfer time, and identify the hardware and software versions. Reducing the sampled history can make a task faster without improving processing efficiency. Conversely, retaining more detail at a similar turnaround can be valuable even when a headline speed multiple is modest. These are proposed evaluation criteria, not reported LSEG test results.
Existing data permissions remain in place. A research deployment therefore has two practical workstreams: a like-for-like performance evaluation of the complete analytical workflow, and confirmation that the users and intended outputs fit the licensed use.[1]
Sources & further reading
- LSEG significantly accelerates analysis of Tick History with NVIDIA cuDF LSEG · 14 Oct 2026 · Accessed 20 Oct 2026
- NVIDIA cuDF and the Polars GPU engine RAPIDS / NVIDIA · Accessed 20 Oct 2026
- GPU support for Polars: developer documentation NVIDIA · Accessed 20 Oct 2026
- The GPU streaming backend Polars / NVIDIA contributor · 28 Aug 2026 · Accessed 20 Oct 2026