From Candidate Lists to Tensorized Computation Graphs

In evolutionary computation,diversityis a prerequisite for the algorithm to work: only by maintaining enough candidate solutions will selection pressure avoid prematurely squeezing the population into a local optimum. But diversity also means a huge computational load—a single run often requires evaluating tens of thousands, even millions, of candidate solutions. When candidates are written as ordinary arrays of objects and fed one by one into evaluation through item-by-item loops, most of the computation time is spent on item-by-item scheduling and host-language control flow rather than on actual numerical operations. This is preciselythe root cause of why traditional serial CPU loops are inefficient when handling tens of thousands of candidate evaluations.

A Leap in Representation: From Candidate Lists to Tensorized Computation Graphs

What EvoX brings is not a local speedup of some operator, buta change in how the evolutionary process is represented: a shift from list-style processing of candidates one by one to batch computation with tensors as first-class citizens. The set of candidates is no longer scattered across arrays of objects; instead, together with evaluation results and algorithm state, it is uniformly organized into tensors so that everything can participate in computation as a whole.

Candidate tensor: The entire generation of candidates is written as a tensor of shape [population size, solution dimension]. A "candidate" is now just a row in the tensor rather than a separate host-language object.
Batch operators: Operations such as mutation act directly on the entire population; a single call updates all candidates instead of looping N times.
Batch evaluation: Using evaluate(candidate tensor) to obtain the evaluation results for the whole generation in one go, the unit of evaluation changes from "one" to "a batch".
Computation graph: Selection and state updates are no longer merely serial control logic but nodes in the graph, thus gaining compiler optimization opportunities such as operator fusion and parallel scheduling.

Comparing the Two Styles

The list-style approach is roughly: take out candidates one by one, evaluate one by one, compare one by one, and update state—every step relies on host-language loops and is hard to optimize as a whole. The tensorized approach is: candidate tensor → mutation → evaluation → selection → state update, with the entire chain composed of tensor operations and expressed as a single computation graph that the compiler can fuse and schedule across devices. Note that the algorithm's logic (mutation distribution, selection pressure) is not rewritten; what is rewritten isthe representation.

Key term

Tensorized computation—using tensors as the smallest unit of processing, so that mutation, evaluation, selection, and state update all act on the entire population in batch form, and allowing these batch operations to enter a computation graph for compiler optimization. The key transition on this page can be captured in one sentence: from "candidate lists" to "tensorized computation graphs."

Structural Conversion from Candidate Lists to Tensors

List-style processing treats each candidate as a separate object evaluated one by one in a loop, whereas tensorization writes the entire generation of candidates as a tensor of shape [population size, solution dimension], where a candidate is merely one row; mutation, evaluation, and selection are then invoked in batches and organized into a compilable, optimizable computation graph—without changing the algorithm's logic itself.

Question 1

In evolutionary tasks with tens of thousands of candidates, what is the main reason traditional serial CPU loops are inefficient?

The fitness function cannot be written as a program

A large amount of time is spent on item-by-item scheduling and host-language control flow rather than on actual numerical operations

Too many candidates cause insufficient population diversity

CPU hardware itself does not support floating-point operations

Question 2

In a tensorized representation, what does "one candidate solution" in the population correspond to?

A separate host-language object that needs to be processed in its own loop

A separate compilation task

A separate node in the computation graph

A slice of the candidate tensor (for example, one row)

Question 3

What is the main benefit of putting selection and state updates into the computation graph?

It guarantees convergence to the global optimum

It gains compiler optimization opportunities such as operator fusion and parallel scheduling

It eliminates the need for a fitness function or evaluation process

It automatically increases the population size to improve diversity

Question 4

If the candidate tensor has shape [population size, solution dimension], what shape is the output most likely to be after evaluating the entire generation of candidates in one call?

[population size] or [population size, number of objectives]

A scalar unrelated to the population size

A single row of [solution dimension]

[population size, solution dimension], exactly the same as the candidate tensor

Question 5

Which of the following best describes the change EvoX makes at the representation level?

Replacing real evaluation entirely with surrogate models to avoid computation

Replacing the evolutionary algorithm itself with a deep learning model

Keeping the original list-style workflow but swapping a few operators for faster hardware implementations

Changing the evolutionary process from list-style, candidate-by-candidate processing to a batch computation graph with tensors as first-class citizens

Case Study: Tensorizing a 50,000-Candidate Airfoil Search

Read the scenario, then answer the two questions, providing your reasoning and design trade-offs.

A team uses an evolutionary algorithm to search parameters for a supercritical airfoil, with a population size of 50,000 and a solution dimension of 48; a single real-time evaluation requires a costly high-fidelity simulation. The early implementation wrote each candidate as a separate object, evaluating, comparing, and updating the best solution one by one in a loop; a single generation took hours and slowed down almost linearly as the population grew. After the overhaul, the team organized candidates into a tensor of shape [50000, 48], obtained the evaluation results for the entire generation in one call, and wrote selection and state updates as nodes in a computation graph.

1. Analyze where the efficiency bottleneck of the original implementation came from, and explain which overheads the tensorization eliminated without changing the algorithm's logic.

Answer:
The bottleneck lies mainly in the data organization and scheduling layer, not in the numerical operations themselves: (a) per-candidate object access and per-item function calls introduce substantial fixed overhead; (b) host-language loops break numerical operations that could be parallelized into serial scheduling steps; (c) per-item comparisons and manual state updates make the control flow bear work that batch operators could handle; (d) processing only one candidate at a time fails to saturate the hardware's parallel width. Tensorization organizes the candidate set, evaluation results, and algorithm state uniformly into tensors; mutation and evaluation act on the entire population in one call, eliminating per-item scheduling overhead and delegating parallelizable numerical operations to batched kernels. It's important to note that the algorithm's logic—such as selection pressure and mutation distribution—is unchanged; only the representation is changed. This is exactly what "from candidate lists to tensorized computation graphs" means. Scoring points: identifying that the bottleneck lies in scheduling and control flow rather than compute power, noting that batching acts on the whole population, and confirming that the algorithm's logic is not rewritten.

2. If selection and state updates are also to benefit from compiler optimization, what design adjustments should be made? Provide the shape of the candidate tensor and how the operators are organized.

Answer:
The idea is to rewrite the imperative step-by-step control logic as tensor operation nodes in a computation graph, so that the entire chain of "mutation → evaluation → selection → state update" can be described and compiled as a whole. Concrete organization: the candidate tensor has shape [population size, solution dimension], i.e. [50000, 48] in this case; the evaluation output has shape [population size] (single-objective) or [population size, number of objectives] (multi-objective); the mutation operator acts on the candidate tensor as a whole, updating all candidates in one call; selection is based on evaluation results, performing tensor indexing or masking operations on the population rather than comparing one by one; state updates (best solution, convergence statistics, etc.) are written as reduction nodes along the population dimension (such as min or mean) rather than manual loop writes. This way the compiler can perform operator fusion and device scheduling on the entire graph, reducing intermediate tensors and synchronization overhead. Scoring points: correct shapes, all four stages expressed as tensor operations, and explicitly noting that selection and state updates change from control logic to graph nodes.