Architecture Overview

The VectorAlpha stack is easier to understand if you stop thinking in terms of marketing layers and look at the actual boundary in the code. One side is indicator computation and data-parallel numeric work. The other side is research workflow: parameter search, validation, ranking, and the tooling around those runs. That split is the reason VectorTA and VectorGrid exist as separate products, which keeps the platform boundary clearer.

It also explains why the architecture keeps both CPU and GPU paths alive. A suitable CUDA device changes the throughput ceiling for the right workloads, but the CPU path is still the reference, the fallback, and in many cases the simpler answer. The design avoids an accelerator-by-default architecture. It keeps the hot loops explicit, the data movement legible, and the workflow honest about where time is actually spent.

The split that matters

VectorTA is the compute layer. It focuses on indicators, aligned buffers, scalar references, SIMD kernels, and where useful GPU execution. Its job is to turn market data into derived series efficiently without hiding the numeric contract. VectorGrid sits above that layer and asks a different question: once indicator work is tractable, how do you search strategy space, validate the survivors, and keep the full run manageable as a research workflow.

That boundary matters because it prevents the architecture from collapsing into a single monolith whose performance story is impossible to explain. Indicator code and optimization code fail in different ways. Indicators fail through incorrect warmup handling, unstable kernels, or poor memory layout. Optimization systems fail through state explosion, weak validation, and too much movement between storage, host memory, and device memory. Treating those as separate problems leads to cleaner code and more believable results.

What stays close to the metal

The low-level design choices are structural, not cosmetic. Rust is useful here because it lets the core libraries keep ownership and data layout explicit while still shipping safe public interfaces. Scalar implementations remain important even when SIMD and CUDA paths exist, because they give the system a readable reference implementation and a baseline for numerical checks. Fast code without a reference path turns debugging into archaeology.

The same logic applies to memory layout. Contiguous buffers, predictable traversal, and minimized copies matter more than slogans about low latency. If a calculation can stay in a compact layout and avoid needless marshaling, both the scalar and accelerated paths get easier to reason about. If data has to bounce through three representations before the real work begins, the architecture is already losing.

Why CPU and GPU both stay in the design

SIMD and CUDA serve the same architectural goal: keep the heavy numeric loops out of the vague middle ground where the compiler might help a little and the runtime moves a lot of memory for no good reason. On the CPU side that means explicit vectorization for the workloads that justify it and a scalar path for the rest. On the GPU side it means keeping enough of the pipeline on the device that the PCIe boundary stays smaller than the gain.

The stronger VectorGrid claim is about sustained device-side work. When the workload is large enough, price data, indicator generation, and backtest evaluation can be arranged into one continuous device-side flow. The same architectural discipline keeps the CPU path useful when the machine lacks a suitable GPU or when the workload is too small to amortize transfer overhead.

What the architecture is trying to avoid

The usual failure mode in this space is an unclear contract. A stack becomes hard to trust when indicator implementations disagree across execution modes, when the backtest layer quietly changes assumptions between runs, or when the performance story depends on benchmark fragments that barely resemble the real workflow. The architecture here is deliberately shaped to avoid that drift.

In practice that means keeping reference implementations, keeping execution boundaries visible, separating optimization from validation, and preferring a smaller number of defensible fast paths over a larger number of clever but weakly verified ones. The architecture keeps the hot paths narrow enough that they can be tested, benchmarked, and explained without hand-waving.

Where to read next

If the next question is indicator internals, continue with Technical Indicators Theory and SIMD Optimization Explained. If the next question is search and validation, move to Backtesting Fundamentals and the Backtesting Engine page. If you want the engineering argument behind the performance side, the relevant material lives in SIMD vectorization for technical indicators , GPU accelerated technical indicators , and VectorGrid: exact search at GPU speed .