# EvoX Intelligent Evolution System and AI Native Research Practice — Course Lecture Notes

Class hours: 1 · Slide pages: 16

## Reading Navigation

- [Lesson 4 | Topic: Modern Computing Foundation and Tensorized Parallel Evolution](#lecture-lesson-1)

---

<a id="lecture-lesson-1"></a>

## Lesson 4 | Topic: Modern Computing Foundation and Tensorized Parallel Evolution

<a id="lecture-page-1"></a>

### Modern Computing Foundation and Tensorized Parallel Evolution

*Page 1*

> **Page Objective:** Learn how EvoX organizes populations, evaluations, and states into tensors that can be computed as a whole, breaking through traditional serial bottlenecks to achieve large-scale acceleration.

> **Page Objective**
>
> As the opening of Lesson 4, this page highlights the core problem this lesson aims to solve — when the population size, number of evaluations, and iteration steps of evolutionary algorithms continue to grow, the traditional individual-by-individual, step-by-step serial processing approach becomes an obvious bottleneck. The main thread of this lesson is to see how EvoX reorganizes populations, evaluations, and states into tensors that can participate in computation as a whole, thereby achieving substantial acceleration in large-scale scenarios.

> **Explanation Sequence**
>
> You can start by posing an intuitive question — "If there are one hundred thousand individuals in the population, and we still need to process them one by one in a loop, what would happen?" This guides students to realize the dual waste of serial loops in terms of time and hardware utilization. Then present the answer direction of this lesson: treat the entire population as a batch of data, treat one generation's update as a single batch operation, and let computation land on parallel hardware as a whole. Finally, introduce the role of the Runtime layer, explaining that it is responsible for scheduling heterogeneous computing power while maintaining algorithm composability.

**Teaching Points**

- 1. Tensorized expression — populations, fitness evaluations, and internal algorithm states are no longer scattered objects, but are organized into tensors with unified shapes, enabling one generation of evolution to be expressed as several batch operations. The benefit is that computation patterns become regular and easy to vectorize, and the same algorithm description can adapt to populations of different scales. 2. Breaking through serial bottlenecks — in traditional implementations, evaluation and state updates are often performed individual by individual; as scale grows, loop overhead and synchronization waits dominate runtime
- After batching, these overheads are amortized, and throughput increases significantly. 3. The scheduling role of Runtime — Runtime sits between algorithm descriptions and underlying hardware, responsible for dispatching batch operations to heterogeneous computing power such as CPU and GPU, so that algorithm authors do not need to rewrite logic for each device. At the same time, it maintains the composability of algorithm components, allowing different operators and strategies to be freely assembled without breaking parallel capability.

**Keyword Coverage**

- Tensorization, batch computation, serial bottleneck, large-scale acceleration, heterogeneous computing power scheduling, algorithm composability.

**Comprehension Check**

Ask students to explain in their own words what "turning the population into a tensor" actually changes — the expected answer should land on "changing from individual-by-individual loops to whole-batch operations, so that parallel hardware is truly utilized"; if they only recite terminology without explaining causality, prompt them to reorganize their statement from the two perspectives of computation count and hardware utilization.

> **Transition Hint**
>
> After confirming that students have established the basic causal chain of "tensorization → batch computation → parallel acceleration," proceed to subsequent pages to specifically see how populations and states are organized into tensors and how Runtime completes scheduling.

<a id="lecture-page-2"></a>

### Modern Computing Foundation and Tensorized Parallel Evolution

*Page 2*

> **Page Objective:** Learners should understand the contradiction between the large-scale computing power demands faced by modern evolutionary computation and traditional architectures.

> **Page Objective**
>
> Understand the contradiction between the large-scale computing power demands faced by modern evolutionary computation and traditional serial architectures; grasp the approach of organizing populations, evaluations, and states into tensors to advance evolution through batch parallelism; recognize how large models expand candidate generation and the system-level architectural trade-offs this brings.

> **Explanation Sequence**
>
> First point out the core contradiction "diversity → number of evaluations → state management and scheduling costs," then explain why serial loops hit the ceiling first; next unfold the three levels of tensorization — population tensor, evaluation tensor, and state tensor — and summarize the core term "batch parallelism"; then explain how large models push candidate generation to new boundaries; finally land on EvoX scenario examples and system-level trade-offs, and handle exercises and cases.

**Teaching Points**

- Evolution depends on population diversity, and diversity directly translates into evaluation counts, state management, and scheduling costs. In traditional CPU individual-by-individual loops, each individual must separately call the objective function, separately update state, and separately record logs
- When the population grows from dozens to thousands, evaluation counts and wall-clock time grow almost linearly. Once a single simulation is costly, overall throughput is locked to a "single-core rhythm." The higher the diversity and the more expensive the evaluation, the more obvious the serial bottleneck. The tensorization approach reorganizes populations, evaluations, and states into tensors that can be computed as a whole. The population tensor stacks all candidate parameters into a two-dimensional tensor of "number of individuals × dimensions," and one operator call completes mutation and updates for the entire population
- The evaluation tensor packages batch evaluation requests and dispatches them, executed in parallel by GPU or batch processing services, then merges return values
- The state tensor maintains intermediate states such as fitness, constraint violations, and rankings in tensor form, enabling selection, sorting, and updates to all be computed as a whole. Together, the three constitute "batch parallelism," which turns the computational load brought by diversity from a burden into a scale that throughput can absorb — therefore it is not an optimization detail but an infrastructure issue for modern evolutionary computation. Once the computation scale is opened up, the key question shifts from "can we compute it" to "where do candidates come from." Large models can understand natural language, code, domain knowledge, and project context, and based on this construct structurally complex candidates, expanding the evolutionary object from numerical parameters to programs, algorithms, and even complete system states
- Encoding and mutation methods that previously relied on manual design can now involve model-generated approaches. Two forces thus meet: GPUs allow a large number of possibilities to be explored simultaneously, large models allow the system to produce richer possibilities, and the evolutionary mechanism is responsible for sending candidates into real tasks, determining through execution and evaluation which changes are worth preserving. For algorithm engineers and system developers, this is not local optimization but architectural trade-offs: one must make system-level trade-offs among the richness of candidate generation, the throughput of batch computation, and engineering complexity. Diversity is the prerequisite for evolutionary effectiveness, but it must be digested by throughput. In the EvoX scenario, if serial CPU loops are still used to evaluate individual by individual, population size will be limited by throughput
- After switching to tensorized batch parallelism, the parameters, evaluation states, and updates of a large number of candidates can be organized simultaneously in the same round, making "maintaining diversity" and "large-scale exploration" simultaneously feasible in engineering terms.

**Keyword Coverage**

- Batch parallelism, tensorization, population tensor, evaluation tensor, state tensor, serial bottleneck, candidate generation, system-level trade-offs.

**Exercise Handling**

This page has 5 multiple-choice questions and 1 case question, with 2 sub-questions in total. The multiple-choice questions respectively check the core contradiction, the implementation method of batch parallelism, the role of large models, the system-level trade-offs after migration, and the direct changes in the EvoX scenario. When answering, grasp two main threads: first, the causal chain of "diversity → computation load → serial bottleneck → batch parallelism"; second, the division of labor in which "large models are responsible for generating richer candidates, and the evaluation mechanism is responsible for determining which candidates are worth preserving." The first sub-question of the case question requires diagnosing the serial bottleneck and explaining how tensorization changes the organizational approach in three places: population, evaluation, and state; the second sub-question requires giving trade-off judgments from dimensions such as candidate richness vs. batch throughput, exploration benefit vs. engineering complexity, and batch throughput vs. evaluation fidelity.

Correct answers should connect to the concepts on this page and explain the basis; if the judgment is wrong, return to the causal chain "diversity → number of evaluations → state management and scheduling costs," and distinguish between "accelerating the same serial loop" and "changing the organization of computation."

**Comprehension Check**

Randomly ask one student to summarize the key points of this page in their own words, especially explaining how diversity translates into computation load, why serial execution hits the ceiling, and how tensorized batch parallelism organizes population, evaluation, and state. If students can only recite terminology without explaining causality, guide them back to the slope comparison in the chart and the "serial bottleneck: throughput ceiling" marker.

> **Transition Hint**
>
> After confirming that students can articulate the core relationships on this page — diversity brings computation load, serial execution hits the ceiling, and tensorized batch parallelism digests scale through whole-batch computation — proceed to the next page's examples, applications, or summary.

<a id="lecture-page-3"></a>

### Evolutionary Diversity and Computational Scale Challenges

*Page 3*

> **Page Objective:** Learners should understand the computational pressure brought by multi-objective trade-offs and candidate diversity in real problems.

> **Page Objective**
>
> Understand the computational pressure brought by multi-objective trade-offs and candidate diversity, and grasp the Pareto front, dominance relations, and the tension between maintaining diversity and evaluation cost.

**Teaching Points**

- Only when a problem has a single objective does a unique optimal solution exist. Real engineering problems usually have multiple mutually constraining objectives (lift and drag, precision and latency, performance and cost), in which case the "good answer" is a set of mutually non-dominated trade-off solutions, i.e., the Pareto front. Compare item by item whether A is no worse than B on all objectives → whether A is strictly better on at least one objective → only when both hold does A dominate B. As long as A is worse on one item, the two are mutually non-dominated and both may remain on the front. The horizontal axis f1 and vertical axis f2 are both better when smaller
- Cluster A favors low f1, cluster B compromises, cluster C favors low f2
- Gray points are dominated solutions. Decision-makers need the trade-off space represented by the entire front, not a single point chosen by the algorithm. Refers to structured differences distributed along different trade-off directions on the Pareto front. Direction coverage — filling the upper-left end, middle section, and lower-right end of the front
- Difference preservation — nearly identical candidates are equivalent to one
- Decision value — preferences are often clarified afterward; preserving differentiated candidates allows zero-cost re-selection. The stronger the diversity, the broader the search space, the larger the population size, and the more evaluations. When evaluation depends on high-fidelity simulation (such as supercritical airfoil aerodynamic computation taking hours), the cost of a single evaluation is amplified into the main bottleneck. Common responses: surrogate models replace most high-fidelity evaluations
- Allocate the limited high-fidelity budget preferentially to candidates that can best expand front coverage
- Reallocate the budget between population size and number of generations. Equating diversity with random noise or simply running more times. True diversity is structured directional difference
- Pure random perturbation will not expand front coverage, nor will it reduce decision difficulty. Exercise clues (5 multiple-choice questions + 1 case analysis): The Pareto front is a set of mutually non-dominated trade-off solutions; any two solutions each have advantages and disadvantages on different objectives. A is better on f1, B is better on f2; the two are mutually non-dominated and both may remain on the front. Diversity is the structured difference distributed along different trade-off directions on the Pareto front, directly serving decision-making. Broader trade-off direction coverage requires a larger search range, population size, and number of objective evaluations, so the stronger the diversity, the greater the computational scale challenge. Using surrogate models to handle most evaluations and concentrating the limited high-fidelity budget on expanding front coverage can alleviate the tension between scale and diversity. Supercritical airfoil design. The deliverable should be a set of candidate solutions located on the Pareto front and covering different trade-off directions, rather than a single scheme
- Measures to alleviate the tension include surrogate models, priority allocation of budget, adjusting the ratio of population to generations, and multi-fidelity staged screening.

**Comprehension Check**

Ask students to explain dominance relations and the Pareto front in their own words, and give examples of why diversity brings computational pressure. If students confuse diversity with random perturbation, return to the "self-check mnemonic" — no matter how many candidates there are, if they crowd into the same corner of the front, there is still no diversity.

> **Transition Hint**
>
> After confirming that students can distinguish single-point optimality from trade-off solution sets and understand the cost of diversity, proceed to the next page on tensorized parallel evolution.

<a id="lecture-page-4"></a>

### Efficiency Bottleneck of Traditional Serial CPU Loops

*Page 4*

> **Page Objective:** Learners should recognize the performance limitations of traditional serial CPU loops when handling tens of thousands of candidate evaluations.

**Teaching Points**

- Total evaluations ≈ population size × number of generations; serial evaluation time ≈ total evaluations × time per evaluation. Calculate these two quantities first, then judge whether the bottleneck is worth modifying.
- Interpreter-level loops, individual-by-individual boundary checks and type dispatch, non-contiguous memory access, and frequent synchronization and data movement add up to serial constant overhead. Tuning only the operator itself can only shave off a small portion.
- Plot wall-clock time under different population sizes: approximately straight lines indicate execution is still serial, while step-like patterns indicate it has been organized by batches. The shape of the curve explains bottleneck attribution better than single-point numbers.

> **Page Objective**
>
> This page is intended to make students realize that when candidate evaluations reach the order of tens of thousands, traditional serial CPU loops become the narrowest segment in the entire evolutionary pipeline; this bottleneck belongs to the execution model level, not to a single operator implementation or code defect. Subsequent batching, tensorization, and parallel scheduling are precisely the directions for transforming this structural bottleneck.
>
> Explanation sequence and teaching points:
>
> Evolution depends on diversity, and diversity brings multiplied growth in population size and evaluation count. Total evaluations ≈ population size × number of generations; serial evaluation time ≈ total evaluations × time per evaluation. When evaluations reach the order of 10⁵, serial wall-clock time grows approximately linearly.
>
> The figure compares serial individual-by-individual processing with batch parallel processing. The horizontal axis is candidate evaluation counts 10³, 10⁴, 10⁵, and the vertical axis is normalized wall-clock time. The serial curve grows approximately linearly; the parallel curve grows in steps. Darker segments represent scheduling and data movement overhead. The key conclusion is: for the same workload, the growth of parallel time is mainly determined by the number of batches rather than the number of individuals. Using the curve shape explains bottleneck attribution better than looking only at single-point numbers.
>
> The most naive implementation treats the entire population as a list, looping to take individuals one by one → decode into concrete parameters → call the evaluation function → write fitness back. Adjacent iterations can hardly overlap: if evaluation results do not return, write-back cannot proceed; if write-back is not complete, there is nowhere to place the next individual's result. Thus parallel units such as multi-core, SIMD, and GPU remain idle most of the time.
>
> Linearly expanding evaluation counts; interpreter-level individual-by-individual execution, including per-individual loops, boundary checks, and type dispatch, brings fixed but high constant overhead; non-contiguous memory access and data movement, where individuals taken one by one are often non-contiguous in memory, resulting in low cache hit rates; synchronization and scheduling, where the execution flow repeatedly pauses and resumes in order to fetch the next individual. Tuning only the inside of the operator can shave off only a small portion.
>
> Taking a population of 1000 and 100 generations as an example, the total number of evaluations is about 1000 × 100 = 10⁵. If a single evaluation averages 1 ms, the evaluation stage alone takes about 100 seconds serially, not yet counting operator computation and scheduling overhead; if restart count increases from 1 to 5 to maintain diversity, the cost rises approximately linearly to about 500 seconds. If the same workload is organized by batches and handled by parallel hardware, wall-clock time is mainly determined by the number of batches and time per batch.
>
> When a single evaluation is extremely cheap (microsecond level) or the population is extremely small (below the hundred level), scheduling and memory overhead may surpass computation overhead, the gap between serial and parallel narrows significantly, the marginal benefit of tensorization diminishes, and the bottleneck shifts to scheduling granularity and memory bandwidth. Therefore, whether it is worth transforming the execution model must be evaluated jointly with evaluation cost and scale.
>
> The efficiency bottleneck of serial CPU loops is structural. To truly solve it, one must restructure from individual-by-individual to batch-by-batch, that is, batching, tensorization, and parallel scheduling, which constitutes the direct motivation for the subsequent tensorized computation graph design.

**Keyword Coverage**

- Serial CPU loop, batch parallelism, wall-clock time, candidate evaluation count, number of batches, interpreter-level overhead, non-contiguous memory access, synchronization and scheduling, structural bottleneck, tensorization.

**Exercise Handling**

This page has 5 multiple-choice questions. It is recommended to have students state their reasoning before giving feedback for each question.

Question 1 asks about the main execution model limitation of serial loops. The answer is "adjacent iterations can hardly overlap, and parallel units such as multi-core, SIMD, and GPU remain idle most of the time." Feedback points: the individual-by-individual process of fetching individual → decoding → evaluation → write-back makes each individual an independent serial step, and hardware lacks independent work that can be executed simultaneously; the bottleneck is not that fitness cannot be computed, but that only one individual is being processed at any moment.

Question 2 asks for the serial wall-clock time of the evaluation stage alone when the population is 1000, generations are 100, and a single evaluation is 1 ms. The answer is about 100 seconds. Guidance for calculation: total evaluations are about 1000 × 100 = 10⁵, then multiply by 1 ms.

Question 3 asks which item is not a factor that amplifies the constant overhead of serial loops. The answer is "tensorized batch scheduling." Feedback points: tensorized batching is a transformation direction to alleviate the bottleneck, not a source of overhead amplification in serial loops themselves; serial overhead comes from non-contiguous memory access, per-individual boundary checks and type dispatch, interpreter-level loops, and so on.

Question 4 asks what mainly determines wall-clock time when completing the same total workload under batch parallelism. The answer is "the number of batches and time per batch." Feedback points: batching turns individual-by-individual into batch-by-batch, and wall-clock time grows in steps with the number of batches, no longer approximately linearly with the number of individuals.

Question 5 asks in which situation judging a serial loop as a structural bottleneck is most likely invalid. The answer is "a single evaluation drops to the microsecond level, and the population size is only at the hundred level." Feedback points: at this time scheduling and memory overhead may surpass computation overhead, and the gap between serial and parallel narrows; judging the bottleneck requires joint evaluation of evaluation cost and scale.

**Classroom Activity**

The case on this page, "Execution Model Choice under One Hundred Thousand Evaluations," can be used. First have students estimate, then discuss the boundaries of transformation.

Estimate the wall-clock time of the current serial implementation for the evaluation stage alone, and explain the change after the restart count increases from 1 to 5, using this to judge the optimization focus. Reference answer: 1000 × 100 = 10⁵ evaluations, multiplied by 1 ms gives about 100 seconds; with 5 restarts, about 5 × 10⁵ evaluations, that is, about 500 seconds, and wall-clock time expands approximately linearly. This shows that constant-level micro-tuning inside the operator yields limited benefit, and the optimization focus should be placed at the execution model level, namely batching, tensorization, and parallel scheduling, so that wall-clock time is determined by the number of batches rather than the number of individuals.

If switching to a batch parallel execution model, what boundary conditions still need to be considered to judge whether the transformation is worthwhile? Reference answer: First, evaluation cost and scale. If a single evaluation drops to the microsecond level, or the population shrinks below the hundred level, scheduling and memory movement overhead may surpass computation overhead, and parallel benefit diminishes. Second, constraints on the number of batches and batch size. Batch size is limited by GPU memory, memory bandwidth, and single-batch computation time; too large a batch increases single-batch time and synchronization cost. Third, data layout and memory access. If candidate individuals cannot be organized into contiguous, vectorizable tensors, batching will still be discounted due to non-contiguous memory access. Overall, only when both the number of evaluations and the cost per evaluation are sufficiently large is the benefit of transforming the execution model significant.

**Comprehension Check**

Randomly ask one student to summarize the key points of this page in their own words, for example, "why serial loops are a structural bottleneck" and "what determines wall-clock time after parallelization." If students only say "slow," ask them to follow up on the two dimensions of order of magnitude and number of batches. A quick-calculation mnemonic can be added: total evaluations ≈ population size × number of generations; serial evaluation time ≈ total evaluations × time per evaluation. Remind them not to focus only inside the operator, and use the curve shape for self-check: approximately straight lines indicate execution is still serial, while step-like patterns indicate it has been organized by batches.

> **Transition Hint**
>
> After confirming that students can state "serial is an execution model bottleneck, and after parallel organization by batches, wall-clock time is determined by the number of batches," proceed to the subsequent design content on tensorized computation graphs and parallel scheduling.

**Reference Basis**

Evolution depends on diversity, and diversity means enormous computation. Traditional serial CPU loops are inefficient when handling tens of thousands of candidate evaluations.

<a id="lecture-page-5"></a>

### From Candidate Lists to Tensorized Computation Graphs

*Page 5*

> **Page Objective:** Learners should master the core transformation of converting the evolutionary process from list representation to tensorized computation graphs.

> **Page Objective**
>
> Learners should master the core transformation of converting the evolutionary process from list representation to tensorized computation graphs, and be able to explain why evolution requires batch tensor computation and how tensorization changes the expression of the evolutionary process.

**Teaching Points**

- Evolution depends on diversity and requires evaluating tens of thousands or even millions of candidate solutions. If candidates are written as ordinary object arrays and evaluated item by item in loops, most time is consumed by item-by-item scheduling and host-language control flow rather than actual numerical operations. This is the root cause of the inefficiency of traditional serial CPU loops. Candidate sets, evaluation results, and algorithm states are uniformly organized as tensors. An entire generation of candidates is written as a candidate tensor of shape [population size, solution dimension]
- A candidate is no longer an independent object, but a slice or row in the tensor. The page diagram also unfolds in this order: the candidate list on the left is processed item by item, the candidate tensor is in the middle, and the computation graph on the right is mutation, evaluation, selection, and state update in sequence. Operations such as mutation act directly on the entire population, and one call completes updates for all candidates
- Evaluation is written as evaluate(candidate tensor), obtaining an entire generation of results in one call, and the unit of evaluation changes from "individual" to "batch." Selection and state updates are no longer merely serial control logic, but nodes in the graph, thus gaining opportunities for compiler optimizations such as operator fusion and parallel scheduling. The logic of the algorithm, such as mutation distribution and selection pressure, has not been rewritten
- What has been rewritten is the mode of expression. This is not simply moving loops onto faster devices, but organizing data and operators with tensors as the minimal unit of processing. If one still insists that "one candidate equals one independent object," then no matter how wide the parallel hardware is, it can only be fed data serially. The key transition on this page can be recorded as "from candidate lists to tensorized computation graphs"
- When you see batch operators, think "compute the whole population together."

**Keyword Coverage**

- Tensorized computation, candidate tensor, batch operators, batch evaluation, computation graph, compiler optimization, population size, solution dimension.

**Exercise Handling**

The answer to multiple-choice question 1 should point to the fixed overhead of item-by-item scheduling and host-language control flow, rather than insufficient computing power or insufficient diversity. In feedback, emphasize that the more candidates there are, the higher the proportion of this overhead.

One candidate solution corresponds to one slice in the candidate tensor, for example one row; it is no longer bound as an independent host-language object.

After selection and state updates enter the computation graph, they can gain compiler optimization opportunities such as operator fusion and parallel scheduling, reducing intermediate tensors and synchronization overhead.

The evaluation output is most likely [population size] or [population size, number of objectives]; evaluation produces one or a set of metrics for each candidate along the population dimension.

At the expression level, EvoX changes item-by-item candidate list-style processing into a batch computation graph with tensors as first-class citizens.

50000 candidate airfoil search. The original implementation bottleneck is mainly at the data organization and scheduling layer: per-candidate object access, item-by-item function calls, item-by-item comparisons and manual state updates, and processing only one candidate at a time, unable to fill the hardware's parallel width. Tensorization transformation does not change selection pressure and mutation distribution, but unifies candidates, evaluation results, and algorithm states into tensors, allowing mutation and evaluation to act on the entire population at once. If one hopes selection and state updates also gain compiler optimization, the candidate tensor should be set to [50000, 48]; the evaluation output is [50000] or [50000, number of objectives]; mutation takes effect on the entire candidate tensor; selection uses tensor indexing or masks;

State updates are written as reduction nodes along the population dimension, such as taking the minimum or computing the mean.

**Comprehension Check**

What is the shape of the candidate tensor? What is the output shape of one evaluation? Which two stages have changed from serial control logic into computation graph nodes? If all three can be answered, it indicates mastery of the core transition on this page.

> **Transition Hint**
>
> After confirming that students can explain in their own words the change "from candidate lists to tensorized computation graphs," proceed to the next page's applications, examples, or summary.

<a id="lecture-page-6"></a>

### Tensorized Organization of Population, Evaluation, and State

*Page 6*

> **Page Objective:** Learners should understand how to uniformly map population data, fitness evaluation, and state variables into tensor structures.

> **Page Objective**
>
> Understand how to uniformly map population data, fitness evaluation, and algorithm runtime states into tensor structures, forming a unified data contract that is batch-computable, device-resident, and reproducible.

> **Explanation Sequence**
>
> Start with three questions — what is the population, how is evaluation done, and at which step is the run; then correspond to three types of containers — population tensor [N, D], evaluation and constraint matrices [N, M] and [N, K], and a unified state container; finally explain how batch evaluation and state residency turn individual-by-individual loops into whole-batch operations.

**Teaching Points**

- Organize N candidate solutions into an encoding tensor of [N, D]. N is the batch dimension, D is the feature dimension. Usually N is placed outermost so that the same operator can act on the entire batch at once. If an individual consists of multiple parameter segments, it can be split into field blocks such as [N, D1] + [N, D2] + …
- Variable-length individuals use padding plus masks or bucketing to avoid heterogeneous structures breaking whole-batch computation. One batch evaluation produces an [N, M] fitness matrix
- Multiple objectives, multiple constraints, and additional metrics can be placed side by side as [N, M+K] or stored in separate tables; the key is to avoid individual-by-individual loop calls to the evaluation function. Generation, random number state, strategy hyperparameters, best solution, historical cache, ranking or sampling state, etc. also enter tensors or structured state containers, ensuring reproducibility, traceability, and batch updates. Unified tensors can reduce host-device round trips, lower loop overhead, and provide a data foundation for subsequent operator parallelism
- But attention must be paid to mask validity, padding waste, widening of the evaluation matrix due to growth in the number of objectives, and state synchronization cost.

> **Material Clues**
>
> - The memory layout diagram places the population tensor, evaluation matrix, constraint matrix, and unified state container under the same device memory semantics. Learners can be reminded to note that the "batch evaluation" arrow indicates one call handles the entire batch, rather than calling individual by individual. When N=1024, D=50, M=2, the population is [1024, 50], evaluation values are [1024, 2], and constraints are [1024, K]. generation can be stored as a scalar, best_x can be stored as a one-dimensional tensor [D], and rng_state can be represented by an integer tensor of appropriate length. Each generation's update can be completed as a whole along the same batch dimension.

**Exercise Handling**

The core understanding is "population, evaluation, and state are uniformly mapped into tensor structures." If selected correctly, it indicates that this understanding is consistent with the main line of this page; if selected incorrectly, return to the beginning of the page to review the unified data contract.

A reasonable statement should emphasize that batch evaluation generates [N, M] and [N, K], rather than individual-by-individual loops. Being able to connect matrix shapes and the basis for batch evaluation is sufficient.

A reasonable statement should explain that generation, random number state, best solution, etc. are also incorporated into a unified state container, facilitating checkpoints and reproducibility. If the answer only stays at "put data into tensors," remind them to also focus on state management and reproducibility.

For the scenario N=2048, D=100, M=3, K=5, it is recommended that the population be [2048, 100], evaluation [2048, 3], constraints [2048, 5]; state variables such as generation use scalar tensors, best_x uses [100], rng_state uses an integer tensor, and historical cache can use [T, 2048, 100] or compressed storage. During batch evaluation, vectorize the evaluation function so that it accepts [N, D] and returns [N, M] and [N, K]; variable-length individuals use padding plus masks or bucketing, and after computation ignore invalid parts according to the mask.

**Comprehension Check**

Ask one learner to explain in one sentence why N should be the outermost batch dimension, and state at least one reason why a state variable should be tensorized. If the answer stays at "put data into tensors," add: the key is the unified data contract and whole-batch operator execution.

> **Transition Hint**
>
> After confirming that learners can distinguish the four types of containers — population, evaluation, constraints, and state — proceed to the next page's examples, applications, or summary.

<a id="lecture-page-7"></a>

### Operator Parallelism and Compiler Optimization

*Page 7*

> **Page Objective:** Learners should understand the underlying compiler optimization mechanisms when operations such as mutation and crossover act on the entire population.

> **Page Objective**
>
> Understand that in EvoX's modern computing foundation, the minimal execution unit of evolutionary operators changes from "individual" to "population tensor"; master how tensorized operators and computation graph compilation improve batch evolution throughput while keeping algorithm semantics unchanged.

> **Explanation Sequence**
>
> First establish the judgment of "who the operator acts on," then compare the execution differences between individual-by-individual loops and tensor-level operators, then explain how computation graph compilation optimizes from operator sequences to execution plans, and finally use cases and exercises to reinforce the principle "efficiency changed, semantics did not."

**Teaching Points**

- 1. The population tensor has shape [N, D], where N is population size and D is decision variable dimension. Operators such as mutation, crossover, and selection can act directly on the entire population tensor, with one call covering all N individuals
- The individual dimension serves as the batch dimension, allowing the device to execute massively in parallel, with throughput scaling with population size. 2. Individual-by-individual writing such as for ind in population: ind = mutate(ind) splits each operator into N small calls, bringing frequent framework scheduling and kernel launches
- Each batch is only 1, making it hard to fill the device's parallel units; repeatedly creating and releasing intermediate results also increases GPU memory allocation and data movement overhead. The key to transformation is population = mutate(population_tensor), letting operators execute with the population tensor as the unit. 3. Computation graph compilation organizes "mutation → crossover → selection" into a computation graph and performs global optimization on the whole graph: operator fusion can merge multiple elementwise operations into fewer kernels, reducing intermediate tensors and reads/writes
- Kernel generation and scheduling use fewer kernel launches to complete an entire generation of evolution
- Memory reuse pre-plans buffers for intermediate results, reducing allocation and movement costs. Optimization only changes "how to compute," not "what to compute." The number of kernels, the scale of intermediate tensors, and memory and scheduling strategies can change, but the logical meaning of mutation, crossover, and selection, the order of operator composition, and the way random numbers are used should remain consistent
- Under the same random seed, the generation-by-generation trajectory and results before and after optimization should be consistent. Mistaking tensorization for switching to a different evolutionary algorithm, or believing compiler optimization makes the algorithm "smarter." Tensorization only applies the same operator to the entire population tensor
- Compiler optimization also only lands at the execution layer. If regression validation is not done after optimization, implementation differences can easily be mistaken for algorithm improvements.

> **Material Clues**
>
> - In the figure, the left side shows the population tensor [N, D] and all individuals; the middle shows the evolutionary operator computation graph of "mutation → crossover → selection"; the right side compares before compilation "individual-by-individual loops, many kernel launches, batch dimension of 1" with after compilation "fused computation graph, a small number of efficient GPU kernels, one batch forward pass completing an entire generation of evolution." This flow can be used to help students connect tensorization with compiler optimization.

**Exercise Handling**

The exercises on this page revolve around execution granularity and semantic preservation.

A mutation operator call usually acts on the entire population tensor [N, D]; it is not the objective function value vector, nor a single individual's decision vector.

Individual-by-individual Python/CPU loops are slow because a large number of small-scale calls bring scheduling and framework overhead, and the batch dimension is 1, resulting in low device utilization.

The main benefit of operator fusion is merging multiple elementwise operations into fewer kernels, reducing intermediate tensors and kernel launch counts; it does not change probability distributions or operator meanings.

Only the execution method is changed; the logical meaning and composition order of mutation, crossover, and selection are not changed.

The transformation of population[i] = mutate(ind) should be changed to population = mutate(population_tensor), and the operator sequence should be handed to computation graph compiler optimization; reducing N, changing loop syntax, or merely using CPU multithreading does not solve the execution granularity problem.

Taking an evolution strategy with population size N = 4096 and dimension D = 128 as an example, the initial implementation has device utilization below 30%, single-generation time grows approximately linearly with N, and GPU memory usage is relatively high. Diagnosis should land on execution granularity: individual-by-individual loops amplify fixed overhead by N times, the batch dimension degenerates to 1, parallel units cannot be filled, and intermediate results are repeatedly created and released. The transformation has three steps: first, tensorize operators so that mutation, crossover, and selection act directly on the [N, D] tensor; second, enable computation graph compilation to perform operator fusion, kernel generation, memory reuse, and scheduling optimization; third, fix the random seed for regression validation, comparing the per-generation best fitness curve and population statistics before and after optimization.

If the curves basically overlap, it indicates only the execution method changed; if they diverge, first check whether operator order, the number of random number uses, or selection rules were changed.

**Comprehension Check**

Should an evolutionary operator act on a single individual or on the entire population tensor? What is the equivalence chain from operator fusion to device utilization? How do you verify that optimization has not changed algorithm semantics? Expected answer: it acts on the [N, D] population tensor; the more fusion, the fewer kernel launches, the fewer intermediate tensor reads/writes, and the higher device utilization; use the same random seed to compare the per-generation best fitness curve and population statistics before and after optimization.

> **Transition Hint**
>
> After confirming that students can distinguish tensorization from computation graph compilation and can use same-seed regression to verify unchanged semantics, proceed to the next page's examples, applications, or summary.

<a id="lecture-page-8"></a>

### Open and Decoupled Foundation Architecture Design

*Page 8*

> **Page Objective:** Learners should understand the decoupled design principles and core component division of the EvoX foundation architecture.

> **Page Objective**
>
> Understand the design principles of EvoX's open decoupled foundation and the responsibility division of its five core modules, and be able to use "module boundaries" to determine where requirements should land.

> **Explanation Sequence**
>
> First give the core judgment — researchers should not spend time on parallel communication, device allocation, and distributed fault tolerance; then introduce the five first-level modules; finally use the architecture diagram to explain the layered relationship between upper-level evolutionary logic and lower-level unified scheduling.

**Teaching Points**

- The algorithm module defines "how to evolve"
- The problem module provides a unified evaluation interface
- The workflow organizes evolution by stages
- The monitor module observes the evolutionary process
- The Runtime scheduler serves as the unified execution layer, answering "where to compute and how to make computation run." A mnemonic can be used: "evolution logic on top, computing power scheduling below," with the order being algorithm → problem module → workflow → monitor module → Runtime scheduler. The algorithm module only describes search logic such as selection, crossover, mutation, and update, not bound to a specific problem, nor aware of which card the tensor is on
- The problem module encapsulates simulation, objective functions, or environments into a unified evaluation interface
- The workflow determines the stage order of initialization, iterative evolution, convergence determination, and so on
- The monitor module collects metrics, records population states and convergence curves
- The Runtime scheduler shields differences among GPUs, accelerators, and distributed clusters, taking over the details of batch computation, parallelism, and communication. Algorithms and problems are independent of each other, and problems and computing power are independent of each other. When adding a new mutation operator, only the algorithm module needs to be changed
- The problem module continues to provide the unified evaluation interface, the workflow and monitor modules maintain their original organization, and the Runtime scheduler automatically completes batch tensor computation and device allocation, with no need to modify low-level execution code. Therefore, the same foundation can support scenarios such as reinforcement learning, genetic programming, and combinatorial optimization, avoiding repeated construction of parallel, scheduling, and distributed engineering infrastructure. Decoupling does not necessarily mean performance becomes slower. What truly affects performance is how the Runtime scheduler handles batch computation and device utilization, not the number of modules. To judge whether layering is efficient, compare end-to-end time, device utilization, and communication proportion
- If scheduling overhead rises, optimize the Runtime scheduler's batch computation and device utilization strategy, rather than writing parallel code back into the algorithm module. Use "what needs to be changed" to test decoupling. Changing hardware or cluster scale should only require changing the Runtime scheduler
- Changing the problem should only require changing the problem module
- Changing operators should only require changing the algorithm module. If a small change affects more than three layers, it indicates the implementation has become over-coupled. What decoupling saves is repeated engineering, not computation time; benchmark experiments are still needed to verify whether scheduling overhead is acceptable.

**Exercise Handling**

The excluded item among the five core modules (the answer is "hyperparameter searcher," which belongs to experimental configuration or algorithm strategy, not a first-level module of the foundation); the accurate manifestation of high cohesion and low coupling (the answer is that the algorithm module's internal logic is self-consistent and not bound to a specific problem, and the problem module is not aware of underlying computing power); the core responsibility of the Runtime scheduler (the answer is shielding differences among GPUs, accelerators, and distributed clusters and uniformly scheduling execution); the scope of changes when adding a new mutation operator (the answer is that only new logic needs to be implemented in the algorithm module, while the problem, workflow, monitor, and Runtime scheduling remain unchanged); the most direct significance of unified open access (the answer is that various domains reuse the same set of engineering infrastructure).

During feedback, first have students return to the "responsibility boundaries of the five modules" to find evidence, then explain why other options break boundaries or confuse responsibilities.

In scaling to a multi-node GPU cluster, the algorithm module, problem module, workflow, and monitor module should remain unchanged because their responsibilities are unrelated to the form of computing power; what needs to be changed or reconfigured is the Runtime scheduler. If there is debate over "hand-writing device allocation and communication inside operators" versus "fully relying on the Runtime scheduler," the key evaluation point is which layer the change lands in: device allocation and communication belong to the execution layer, and writing them into operators couples computing power details into the algorithm module. The validation plan is to compare pure Runtime scheduling and hand-written scheduling on the same combinatorial optimization problem in terms of end-to-end time, device utilization, and communication overhead proportion, and record the cost when migrating to another type of hardware or reinforcement learning task;

Only when reproducible significant benefits can compensate for coupling and migration costs should partial sinking be considered.

**Comprehension Check**

Ask students to restate the five modules and the questions each answers in their own words, and choose any requirement to judge which layer should be changed. Transition hint: after confirming that students can distinguish "evolution logic" from "computing power scheduling," proceed to the subsequent implementation details of tensorized parallel evolution.

<a id="lecture-page-9"></a>

### Division of Algorithm and Problem Modules

*Page 9*

> **Page Objective:** Learners should understand the responsibilities and interaction methods of the algorithm module and problem module in the foundation architecture.

> **Page Objective**
>
> Understand the responsibility boundaries and interface contract of the algorithm module and problem module in EvoX's open decoupled foundation, and the significance of this division for multi-objective, constrained, and expensive-feedback problems.

> **Explanation Sequence**
>
> First anchor the division of labor in one sentence — the algorithm module answers "how to search," and the problem module answers "what to evaluate and how the environment feeds back." Then unfold their inputs and outputs, and finally land on the independent extensibility, composability, and transferability brought by a stable interface contract.

**Teaching Points**

- 1. The algorithm module encapsulates search strategies and evolutionary mechanisms. It is responsible for candidate solution generation, population initialization, mutation, crossover, selection, elitism preservation, as well as search control such as iteration rounds, population size, restarts and convergence criteria, and operator parameter scheduling. The key point is that it depends only on the abstract premise that "candidate solutions will be evaluated," and does not care about the physical meaning and specific form of the objective function. 2. The problem module defines evaluation standards and environmental feedback. It transforms candidate solutions into comparable feedback, such as objective values, fitness, constraint violations, or the result of one environment interaction
- At the same time, it declares variable dimensions, value ranges, and feasible region rules, letting the algorithm know where to generate candidate solutions. The problem module gives consistent evaluations for the same batch of candidate solutions, allowing horizontal comparison among different individuals, different generations, and even different algorithms. The algorithm module submits a batch of candidate solutions, and the problem module returns structured evaluation results (objective vectors, constraint violations, and optional diagnostic information), based on which the algorithm module updates the population and advances to the next generation. One "submit-return" round is one generation of evolution. The correctness of direction is important: the algorithm side submits candidate solutions to be evaluated, and the problem side returns evaluation results. Independent extension — adding or replacing algorithms does not affect problem definitions, and modifying or adding problems does not require rewriting the algorithm module
- Composability — the same problem module can connect to different evolutionary algorithms, and the same algorithm module can switch to different problem modules
- Transferability — as long as the contract is stable, both sides can be reused, replaced, and transferred across tasks. Real engineering problems such as supercritical airfoil design often simultaneously have multiple mutually constraining objectives, nested constraints, and expensive and sparse feedback. The problem module uniformly converts multiple objectives and constraints into comparable evaluation results, using surrogate models when necessary to reduce cost
- The algorithm module maintains a set of diversified candidate schemes, supporting experts in making preference trade-offs among lift, drag, and safety margin. Therefore, the contract cannot carry only a single scalar fitness; it must also carry objective vectors and constraint violations, otherwise multi-objective and constraint information will be permanently lost at the interface.

**Keyword Coverage**

- Algorithm module, problem module, candidate solution batch, evaluation results, objective vector, constraint violation, interface contract, independent extension, composability, transferability, surrogate model. Writing objective functions, constraint handling, or problem-specific heuristic rules into the algorithm module, or implementing selection and population updates in the problem module, will recouple the two sides. The self-check question is: "If I only change the physical model, do I only need to replace the problem module?" The answer must be yes. The interface should be "narrow and complete": narrow means few and stable fields, transmitting only two types of information, the candidate solution batch and evaluation results
- Complete means key information cannot be missing; objective vectors, constraint violations, variable dimensions, and boundaries must all be preserved. Returning only a single scalar fitness is the design defect that is hardest to remedy afterward.

> **Exercise Clues**
>
> - The five multiple-choice questions respectively verify — who is responsible for search, the core responsibility of the problem module, the direction of contract data flow, independent extension after decoupling, and the consequences of single scalar fitness. The correct answers point in order to: the algorithm module generates candidate solutions and updates the population
> - the problem module transforms candidate solutions into objective values, constraint violations, or environment interaction results
> - the algorithm module produces candidate solution batches, and the problem module returns evaluation results
> - as long as the contract remains unchanged, replacing either side requires no rewrite of the other side
> - discarding constraint information prevents the algorithm from obtaining constraint feedback, making constrained problems difficult to handle correctly. During feedback, if students answer correctly, ask them to explain the basis
> - if they answer incorrectly, guide them back to "who searches, who evaluates" and "whether the contract is complete" to judge again. When migrating airfoil aerodynamic optimization to wing structural weight reduction, replacing the evolutionary algorithm does not require rewriting the problem module, because the problem module only promises externally "input candidate solution batch, output evaluation results," unrelated to the algorithm's internal selection, update, or sorting mechanisms. When reusing the same algorithm for structural weight minimization, the problem module must return at least three types of information: objective values (structural weight, or an objective vector if stiffness metrics are included), constraint violations (the degree to which stiffness and geometric feasibility constraints are exceeded), and the variable dimensions and value ranges of the search space. None can be missing, because the algorithm is only responsible for search and needs objective values to judge优劣, constraint violations to distinguish feasible from infeasible, and consistent boundaries to generate legal candidate solutions.

**Classroom Activity**

Have students restate using memory anchors — algorithm module = how to search (generation, mutation, crossover, selection, iteration control); problem module = what to evaluate (objective values, constraint violations, environment feedback). Then ask one student to answer: "If only the physical model is changed, which side should be replaced?"

**Comprehension Check**

Randomly ask one student to state in their own words the data flow of "candidate solution batch ⇄ evaluation results," and explain why returning only a single scalar fitness would break the handling of constrained problems.

> **Transition Hint**
>
> After confirming that students can distinguish search from evaluation and can clearly state that the contract must be "narrow and complete," proceed to the next page's examples, applications, or summary.

<a id="lecture-page-10"></a>

### Workflow and Monitor Module Management

*Page 10*

> **Page Objective:** Learners should understand the role of workflow control and the monitor module in managing the evolutionary process.

> **Page Objective**
>
> After this page, learners should be able to distinguish the responsibilities of the workflow module and the monitor module, and explain how the two turn the evolutionary loop from an "unknown black box" into an observable, determinable, intervenable, and reproducible controlled process.

> **Explanation Sequence**
>
> First establish the division of labor in one sentence — the workflow answers "in what order to run," and monitoring answers "where are we now, is it good, should we act." Then unfold the workflow's order, back edges, and stage boundaries, then explain how monitoring collects state, exposes metrics, and drives decisions. Finally close with the three responsibility boundaries and the cost of observability, and use a GPU tensorized evolution example to connect the whole logic.

**Teaching Points**

- 1. The workflow module orchestrates steps and dependencies, not the algorithm logic itself. It defines the order, back edges, and stage boundaries of "initialization → evaluation (batch) → selection → mutation/crossover → state update → termination determination," and connects the algorithm module and problem module through a unified interface. The key to orchestration lies in granularity and boundaries: treat "one batch evaluation" as a stage that can be scheduled as a whole, rather than advancing individual by individual
- Stage boundaries are simultaneously monitoring sampling points and scheduling switch points. 2. The monitor module is the collection and exposure layer for runtime state, continuously tracking metrics such as population size, evaluation count, fitness distribution, convergence and diversity, per-generation time, GPU memory, and throughput. But the purpose of observation is not recording, but decision-making: metrics are used to trigger termination, early stopping, restart, parameter or strategy switching, thus forming a closed loop of "monitor → judge → intervene." 3. Controllability also requires that state be serializable. Checkpoint saving and restoration allow long-running evolution to be interrupted and resumed, failures to be located, and experiments to be reproduced. At the same time, decoupling requires monitoring to be attached via callbacks or hooks, without intruding into the algorithm and problem modules, so different monitoring backends such as consoles, logs, and curve panels can be swapped while the core algorithm remains unchanged. The workflow manages "order and stages," monitoring manages "state and metrics," and the runtime scheduler manages "resources and parallel mapping." A common mistake is stuffing resource mapping or algorithm logic into the workflow, or stuffing order control into monitoring, leading to coupling and non-reproducibility. Observability also has a cost: high-frequency sampling and synchronous return transmission may interrupt the parallel pipeline, so sampling frequency, metric aggregation methods, and asynchronous disk-writing strategies need to be traded off according to experimental goals. The workflow schedules "batch evaluation" as a whole stage
- The monitor module records the best and average fitness, population diversity, and per-generation time by generation within the same stage
- When metrics stagnate for N consecutive generations, trigger termination determination or switch to a strategy with larger perturbation, and synchronously write checkpoints to disk, so that this evolution is both reproducible and can resume from the interruption point.

**Keyword Coverage**

- Workflow module, monitor module, steps and dependencies, stage boundaries, back edges, batch evaluation, observability, monitor → judge → intervene, checkpoint, callback/hook, responsibility boundaries, sampling cost.

> **Exercise Clues**
>
> - The exercises on this page revolve around five judgments. The direct orchestration object of the workflow is steps and dependencies, not operator formulas, GPU memory mapping, or objective function encoding
> - Treating batch evaluation as a whole stage for scheduling is because granularity and boundaries are more appropriate; stage boundaries simultaneously bear monitoring sampling and scheduling switching
> - The fundamental purpose of monitoring is decision-making, not post-hoc archiving
> - Callback or hook attachment is for decoupling, making monitoring backends interchangeable
> - Observability requires trade-offs among sampling frequency, metric aggregation, and disk-writing strategy, because high-frequency sampling may interfere with the parallel pipeline. When correct, emphasize that the basis comes from the two lines of "order and stages" and "monitor → judge → intervene"
> - When incorrect, return to responsibility boundaries and distinguish the four types of responsibilities: algorithm logic, resource mapping, order control, and state collection.

**Comprehension Check**

The case "Suspicious Stagnation in Long-Running Tensorized Evolution" can be used to test mastery. First use stage boundaries to separate the time consumption of batch evaluation, selection, mutation, and state update, and determine which stage the rise in per-generation time comes from; then overlay the two curves of average fitness stagnation and diversity decline to judge whether it is convergence stabilizing or falling into a local optimum. The handling plan is organized as "monitor → judge → intervene": the monitoring layer collects fitness stagnation generations, diversity, and per-generation time; the judgment layer sets "improvement below threshold for N consecutive generations and diversity below the lower bound" as stagnation, and "per-generation time exceeding threshold" as resource anomaly; the intervention layer triggers strategy switching, early stopping, or restart, and adjusts batch size or parallel mapping for time anomalies.

Before handling, write checkpoints to disk first to ensure experiments are reproducible, failures are locatable, and long-running evolution can be interrupted and resumed.

> **Transition Hint**
>
> After confirming that learners can state "the workflow manages order and stages, monitoring manages state and metrics, and the scheduler manages resources and parallel mapping," proceed to the next page.

<a id="lecture-page-11"></a>

### Runtime Scheduler and Heterogeneous Computing Power Management

*Page 11*

> **Page Objective:** Learners should master the core role of the Runtime scheduler in heterogeneous hardware allocation and algorithm composability.

> **Page Objective**
>
> Master the positioning of the Runtime scheduler in EvoX — it is the execution hub connecting algorithm logic and physical hardware, responsible for mapping upper-level evolutionary algorithms, problem definitions, and workflows to heterogeneous computing resources such as GPUs, accelerators (TPU/NPU), and distributed clusters, while shielding hardware differences and maintaining efficient composability of algorithm modules.

> **Explanation Sequence**
>
> 1. First distinguish the algorithm layer from the execution layer. The algorithm layer focuses on "what to do," and Runtime focuses on "where to do it and how to do it." This separation is key to understanding the EvoX architecture.
>
> Heterogeneous computing power scheduling, uniformly managing GPUs, accelerators, and distributed clusters, assigning tasks, operators, and tensor computation graphs to appropriate backends; dependency and state coordination, ensuring task dependencies and execution states are correctly synchronized; unified scheduling interface, so that the algorithm layer does not need to bind to a specific device or cluster form when submitting tasks; module composability, supporting modular combination, replacement, and reuse of algorithms, problems, operators, and execution backends.
>
> When the same set of evolutionary algorithms switches from a single-machine GPU to a multi-machine cluster, the algorithm layer code remains unchanged, and Runtime remaps computation tasks and execution backends. Researchers can therefore focus on algorithm innovation without rewriting code for each type of hardware.
>
> The upper layer is the algorithm and workflow layer (algorithm module, problem definition, workflow), the middle is the Runtime scheduler and unified scheduling interface, and the lower layer is the heterogeneous computing power layer (GPU, TPU/NPU, distributed cluster); tasks, operators, and computation graphs are passed downward, and states and results are returned upward.

**Teaching Points**

- Runtime does not implement evolutionary algorithm logic, nor does it define problem objective functions
- Its responsibility is scheduling and mapping. The execution resources it manages are hardware resources, such as GPUs, accelerators, and distributed clusters
- Algorithm module source code belongs to the algorithm layer and is not an object scheduled by Runtime. The algorithm layer only needs to describe what to do, without caring on what hardware to do it, so the same set of algorithms can migrate to single-machine, multi-GPU, or cross-cluster environments. Composability means algorithms, problems, operators, and execution backends can be freely combined, replaced, and reused, rather than being locked to a single hardware backend.

**Keyword Coverage**

- Runtime scheduler, heterogeneous computing power scheduling, dependency and state coordination, unified scheduling interface, module composability, GPU, accelerator, TPU/NPU, distributed cluster, algorithm layer, execution layer.

> **Material Clues**
>
> - This page is accompanied by an architecture diagram of the Runtime scheduler connecting hardware devices and upper-level algorithms. In the diagram, the upper layer is the algorithm and workflow layer, the middle is the Runtime scheduler and unified scheduling interface, and the lower layer is the heterogeneous computing power layer
> - Arrows indicate tasks/operators/computation graphs are distributed downward, and states/results are returned upward. When explaining the diagram, students can be asked to restate along the arrows "what the upper layer submits, what Runtime does, and what the lower layer returns."

**Exercise Handling**

The correct answer to multiple-choice question 1 is mapping algorithms and workflows to heterogeneous computing resources and shielding hardware differences. Feedback points: Runtime is the execution hub; it does not implement algorithm logic, nor define problems.

Runtime manages hardware execution resources; source code belongs to the algorithm layer.

The correct answer to multiple-choice question 3 is that through the unified scheduling interface, the algorithm layer does not need to bind to a specific device or cluster form. Feedback points: reducing coupling means the algorithm layer does not need to write different code for each type of hardware.

The correct answer to multiple-choice question 4 is modular combination, replacement, and reuse of algorithms, problems, operators, and execution backends. Feedback points: composability is reflected in the free combination and replacement of components.

The correct answer to multiple-choice question 5 is remapping computation tasks and execution backends, with algorithm layer code remaining unchanged. Feedback points: Runtime dynamically adjusts task mapping, and the algorithm layer requires no modification.

In the multi-objective airfoil design scenario, the team simultaneously optimizes lift coefficient and cruise lift-to-drag ratio, and migrates the same set of algorithm code between a single-machine GPU and a distributed cluster. When answering, grasp two points: First, Runtime maps tasks, operators, and computation graphs to specific hardware backends through the unified scheduling interface; when hardware changes, algorithm layer code remains unchanged, and Runtime remaps and splits the computation graph and coordinates task dependencies and state synchronization. Second, scheduling must consider task computation characteristics and dependencies, hardware capabilities (such as GPU parallelism and cluster communication overhead), parallel execution of multi-objective evaluation and synchronization under sparse feedback, and state return transmission, ensuring efficient cross-hardware implementation without breaking composability.

**Comprehension Check**

Ask students to explain in their own words "the algorithm layer focuses on what to do, and Runtime focuses on where to do it and how to do it," and give an example of which layer changes and which layer remains unchanged when switching from GPU to cluster. If students only remember hardware names without explaining the scheduling and mapping relationship, guide them back to the arrow relationships in the architecture diagram.

> **Transition Hint**
>
> After confirming that students can state Runtime's scheduling and mapping role and can explain cross-hardware migration using the unified interface and composability, proceed to the next page's examples, applications, or summary.

<a id="lecture-page-12"></a>

### Multi-Domain Applications Supported by the Unified Foundation

*Page 12*

> **Page Objective:** Learners should understand how this unified foundation supports a wide range of tasks such as reinforcement learning, genetic programming, and combinatorial optimization.

> **Explanation Sequence**
>
> Start with one sentence to clarify "unified foundation = open access + tensorized execution + Runtime scheduling. When you see 'multi-domain applications,' self-check with these three questions: How does the task connect? How are candidate solutions batch-evaluated? Who uniformly manages computing power and state?" Then combine it with the examples, diagrams, or keywords on the page to explain why it matters.

**Teaching Points**

- Unified foundation = open access + tensorized execution + Runtime scheduling. When you see "multi-domain applications," self-check with these three questions: How does the task connect? How are candidate solutions batch-evaluated? Who uniformly manages computing power and state?
- Parallel environment stepping, program tree structure evolution, and discrete tensor mapping belong to the adaptation layer
- Evaluation flow, state management, operator organization, and scheduling belong to the shared layer. If a domain-specific structure is written directly into shared scheduling logic, it indicates the wrong level of abstraction was chosen.
- This page only answers "what the unified foundation can support." When encountering questions such as throughput, scheduling overhead, and batch tensor implementation details, place them first in the subsequent scope of learning on computational efficiency and batch tensor methods, and do not dwell on them here.

Multi-Domain Applications Supported by the Unified Foundation

11

AI999

Modern Computing Foundation and Tensorized Parallel Evolution

Control and decision tasks require continuous interaction with a changing environment; structural design tasks require searching in variable-length program and expression spaces; resource allocation and path planning tasks must be solved in discrete permutations and constraints. If a separate system is rebuilt for each type of problem, evaluation interfaces, state storage, operator libraries, and computing power scheduling all need to be repeatedly implemented, resulting in extremely high engineering migration costs. The core idea of the unified foundation is to use the same set of evolutionary infrastructure to carry these heterogeneous tasks, allowing multi-domain applications to share evaluation, state, operators, and computing power management.

Open access (connecting tasks with unified registration and interface specifications), tensorized execution (organizing candidate solutions into batches and performing batch parallel evaluation), runtime scheduling (allocating tasks on heterogeneous computing power and maintaining state). Together, the three ensure cross-domain reuse, and also explain why the capability "provides a unified open access foundation for reinforcement learning, genetic programming, and combinatorial optimization" deserves separate discussion.

Multi-Domain Applications Supported by the Unified Foundation Same open access foundation · Shared evaluation flow, state management, operator organization, and computing power scheduling Foundation capabilities / Task domains Reinforcement learning Genetic programming Combinatorial optimization Open access Environment access interface Program structure access Solution and constraint access Parallel environment interaction Multi-environment batch sampling — — Program tree structure evolution — Mutation / crossover — Tensorized solving Policy batch evaluation Structural tensorization Candidate and constraint batches Runtime scheduling and state management Shared scheduling and state Shared scheduling and state Shared scheduling and state Adaptation layer: absorbing domain differences — Parallel environment stepping · Program tree structure evolution · Discrete tensor mapping Unified foundation: open access · tensorized execution · Runtime scheduling and state management How three typical tasks land on the same foundation Reinforcement learning: the foundation provides parallel environment interaction capability, supporting batch sampling of multiple environment instances, batch parallel evaluation of a batch of candidate policies, and forming a closed loop with evolutionary optimization.

The foundation supports the evolution of variable-length, hierarchical structures such as program trees, and can handle structural representations and their mutation and crossover within a unified population and evaluation flow. Combinatorial optimization: adapt discrete decisions, selections, permutations, and constrained objectives into tensorized solving, improving search throughput through batch candidates and parallel evaluation. What is shared, what is adapted Domain differences are absorbed by the adaptation layer: reinforcement learning emphasizes parallelism of environment stepping, genetic programming emphasizes evolution of program tree structures, and combinatorial optimization emphasizes mapping discrete decisions to tensors. The three share the underlying Runtime scheduling and state management — sharing evaluation flow, state carriers, operator organization, and computing power management, rather than rebuilding the system for each type of problem.

If a domain-specific structure is written directly into shared scheduling logic, it indicates the wrong level of abstraction was chosen. Scope of this page This page focuses on "what the unified foundation can support," and does not expand on specific performance comparisons and scheduler implementation details; the latter are left for subsequent discussion in the computational efficiency and batch tensor methods section.

What is the primary value of the unified open access foundation?

Allowing different domains to reuse evaluation, state, operators, and computing power management, significantly reducing engineering migration costs

Replacing reinforcement learning, genetic programming, and combinatorial optimization with one unified algorithm

Compressing all tasks into the same fixed-length vector representation

Rebuilding an independent system and toolchain for each new type of problem

Task forms differ, but access specifications, batch evaluation, state management, and computing power scheduling can be shared; new problems only need to describe their differences in the adaptation layer.

"Rebuilding the system for each type of problem" is precisely the problem the foundation aims to solve; at the same time, the foundation does not require all tasks to share the same algorithm or the same representation, as differences are absorbed by the adaptation layer.

Correct. This answer connects to the concepts on this page and explains the basis.

Please return to the explanation on this page, find key evidence or examples, and then judge.

In reinforcement learning scenarios, which key capability does the unified foundation mainly provide?

Mutation and crossover operators for program trees

Serial stepping supporting only a single environment instance

Batch sampling of multiple environment instances and trajectory collection, with batch parallel evaluation of a batch of candidate policies

Modeling interface for discrete permutations and constraints

Multiple environment instances advance simultaneously, trajectories are collected in batches, and candidate policies are evaluated in parallel, thereby forming a closed loop with evolutionary optimization.

Program tree structure evolution belongs to the adaptation point of genetic programming, and discrete constraint modeling belongs to the adaptation point of combinatorial optimization; the key to reinforcement learning is batch parallelism of environment interaction, not single-instance serial execution.

When genetic programming tasks connect to the unified foundation, what key feature must the foundation support?

Processing only fixed-length real vectors

Representation and evolution of variable-length, hierarchical structures such as program trees, including structural mutation and crossover

Forcing program trees to be encoded into fixed-length binary strings before evolution

Handling only unconstrained continuous objective functions

Genetic programming candidate solutions are variable-length, hierarchical program structures; the foundation needs to accommodate this representation within a unified population and evaluation flow, and support corresponding mutation and crossover.

Fixed-length vectors are a typical representation for continuous optimization; the core feature of genetic programming is precisely variable-length, hierarchical program tree structures and evolutionary operations on structures.

For combinatorial optimization tasks to connect to the unified foundation, what is the most critical adaptation work?

Removing all constraints and keeping only a single objective

Rewriting the problem as a continuous differentiable neural network training task

Compiling a dedicated solver separately for each problem instance

Adapting discrete decisions, selections, permutations, and constrained objectives into tensorized solving

Candidate solutions and constraints are organized into batches, thereby reusing the foundation's batch candidate and parallel evaluation capabilities.

Compiling a dedicated solver per instance is equivalent to returning to the old path of "rebuilding the system"; abandoning constraints also changes the problem itself, and neither is the adaptation required by the foundation.

Regarding the division of labor between the shared layer and the adaptation layer, which of the following understandings is correct?

Scheduling logic must be written separately for reinforcement learning, genetic programming, and combinatorial optimization

The adaptation layer only performs interface display and does not participate in any task semantic conversion

The shared layer handles program tree structure evolution, and the adaptation layer handles environment stepping

Domain differences are absorbed by the adaptation layer, and the three types of tasks share the underlying Runtime scheduling and state management

Parallel environment stepping, program tree structure evolution, and discrete tensor mapping belong to the adaptation layer; evaluation flow, state management, operator organization, and scheduling belong to the shared layer.

Writing domain-specific structures into shared scheduling logic, or having the shared layer handle structure evolution specific to a certain domain, are both errors in layer division.

Same runtime carrying three heterogeneous tasks

Read the scenario and answer the questions.

An algorithm team is building an evolutionary computation platform. Previously, they maintained three independent systems for reinforcement learning control, symbolic regression (program structure search), and logistics path planning: each had its own evaluation interface, state storage, and computing power scheduling, code duplication was severe, and switching to a new task required rewriting the process. The new plan uses one unified foundation to carry these three types of tasks: reinforcement learning tasks advance multiple environment instances in parallel and collect trajectories; genetic programming tasks evaluate program tree populations in parallel; combinatorial optimization tasks organize candidate solutions and constraints into tensor batches, with unified scheduling allocating heterogeneous computing power.

1. Why did the team abandon maintaining separate systems for each type of problem? Please explain from the perspective of reuse and migration cost.

Task access, batch evaluation of candidate solutions, state management of candidates and populations, operator organization, and computing power scheduling. Maintaining them separately means these capabilities are repeatedly implemented three times, and any new task requires rebuilding the process once, resulting in high engineering migration cost. The unified foundation lets the three types of tasks reuse the same set of evaluation flow, state carriers, operator organization, and computing power management; new tasks only need to describe their own differences in the adaptation layer to connect.

2. Please indicate the differences that the three types of tasks absorb in the adaptation layer, and explain what they reuse in the shared layer.

Reinforcement learning emphasizes parallelism of environment stepping (batch sampling of multiple environment instances, trajectory collection, and batch evaluation of policies); genetic programming emphasizes representation and evolution of variable-length, hierarchical structures such as program trees (structural mutation and crossover); combinatorial optimization emphasizes mapping discrete decisions, selections, permutations, and constrained objectives into tensorized solving. Shared layer reuse: open access specifications, tensorized batch execution, Runtime scheduling and state management, and unified heterogeneous computing power allocation. Precisely because differences are gathered in the adaptation layer and commonalities sink into the shared layer, there is no need to rebuild the system for each type of problem.

First remember the three pillars

Unified foundation = open access + tensorized execution + Runtime scheduling. When you see "multi-domain applications," self-check with these three questions: How does the task connect? How are candidate solutions batch-evaluated? Who uniformly manages computing power and state?

Distinguish the shared layer from the adaptation layer

Parallel environment stepping, program tree structure evolution, and discrete tensor mapping belong to the adaptation layer; evaluation flow, state management, operator organization, and scheduling belong to the shared layer. If a domain-specific structure is written directly into shared scheduling logic, it indicates the wrong level of abstraction was chosen.

Boundary of this page

This page only answers "what the unified foundation can support." When encountering questions such as throughput, scheduling overhead, and batch tensor implementation details, place them first in the subsequent scope of learning on computational efficiency and batch tensor methods, and do not dwell on them here.

step-1

Learners should understand how this unified foundation supports a wide range of tasks such as reinforcement learning, genetic programming, and combinatorial optimization.

lesson_4

lesson_4_slide_11

From EvoClass draft

Provides a unified open access foundation for reinforcement learning, genetic programming, and combinatorial optimization

lesson_id_distribution

67ee25ab22558e4ae0e13f24b7c34c2da1218107cceb1cd331b38fc3521a9743

**Reference Basis**

From EvoClass draft (pages 4-4)

> **Material Clues**
>
> - Provides a unified open access foundation for reinforcement learning, genetic programming, and combinatorial optimization

**Classroom Activity**

Please retell the content of this page using an example close to students' experience, and have students explain the relationship between this example and "unified foundation = open access + tensorized execution + Runtime scheduling. When you see 'multi-domain applications,' self-check with these three questions: How does the task connect? How are candidate solutions batch-evaluated? Who uniformly manages computing power and state?"

> **Corresponding Objectives**
>
> - Master the method of expressing the evolutionary process as batch tensor computation
> - Understand Runtime's role in scheduling heterogeneous computing power and maintaining algorithm composability

**Comprehension Check**

Randomly ask one student to summarize the key points of this page in their own words, and the instructor supplements missing keywords based on the answer.

> **Transition Hint**
>
> After confirming that students can state the core relationships on this page, proceed to the next page's examples, applications, or summary.

<a id="lecture-page-13"></a>

### Practical Analysis of Computational Efficiency Comparison

*Page 13*

> **Page Objective:** Learners should understand the efficiency difference between CPU serial traversal and GPU tensor batch processing through practical comparison.

> **Page Objective**
>
> Land the computational efficiency comparison on a reproducible practice, understand the end-to-end efficiency difference between CPU serial individual traversal and GPU tensor batch processing, and clarify where acceleration comes from, what the cost is, and where the boundary lies.

> **Explanation Sequence**
>
> First give the two baselines on the same evolutionary task, then look at the efficiency comparison bar chart, then explain the reproducible measurement protocol, and finally summarize the sources of benefit, constraints, and practical conclusions.

**Teaching Points**

- Use loops to call the evaluation function individual by individual; each generation requires N independent scheduling, state update, and result aggregation steps. Loop control, interpreter overhead, and scattered memory access dilute effective computing power
- The more individuals there are, the higher the proportion of these non-computational costs. Organize the population, evaluation inputs, and runtime state as tensors, and execute evaluation and operators in batches on the GPU, with one call covering the entire candidate set, thereby greatly reducing serial loops and scheduling counts. Under the same problem, same population, same random seed, and timing after warm-up and device synchronization, the CPU serial loop is baseline 1.0×, GPU batch processing b=64 is about 2.2×, b=256 is about 4.5×, and b=1024 is about 7.1×. The figure shows relative per-generation time; the larger the batch size, the easier it is to amortize fixed overhead. Fixed problem, population size, number of generations, and random seed
- Record actual per-generation time, total time, throughput (evaluations/second), speedup, GPU utilization, and GPU memory usage. Warm up before timing to exclude the effects of first compilation and GPU memory allocation
- Timing points must perform device synchronization
- Computation time and host-device data transfer time should be counted separately. If any link is missing, the speedup may be distorted. Benefits come from batch parallelism, tensorized operators, and intra-device parallelism, allowing one call to process the entire candidate set
- Constraints include batch size, problem dimension, degree to which the evaluation function can be vectorized, host-device copy overhead, and kernel launch overhead. If the batch is too small, launch overhead will eat the benefit
- If the evaluation function cannot be vectorized, batch processing has almost no room to function. The correct order is to first verify whether the evaluation function can be batched, then compare CPU and GPU implementations. The efficiency advantage should ultimately land on "obtaining more generations or more candidate schemes under the same computation budget," and deployment methods and experimental design should be decided accordingly, rather than simply pursuing speedup numbers.

**Exercise Handling**

The correct answer to question 1 is "the scheduling, interpreter, and scattered memory access overhead caused by independently calling the evaluation function for each individual." The serial baseline produces N independent scheduling and state updates per generation; loop control, interpreter overhead, and scattered memory access dilute effective computing power; at this point there is not yet GPU kernel launch and copying.

The correct answer to question 2 is organizing the population, evaluation inputs, and runtime state into tensors, with one call covering the entire candidate set. The core of acceleration is batch parallelism and tensorization, not changing precision, population size, or the number of seeds.

The standard protocol for question 3 is to fix the problem, population size, generations, and seed, warm up and perform device synchronization before timing, and distinguish computation time from data transfer time.

GPUs often execute asynchronously; without synchronization, timing may miss computation that has not yet completed, causing time to be underestimated and speedup to be inflated; synchronization itself does not improve computing power, nor does it eliminate data transfer.

When the evaluation function has a low degree of vectorizability, the advantage of GPU batch processing is significantly weakened, and benefits may even be limited due to copy and kernel launch overhead; acceleration is not constant, nor does it increase without上限 as batch size grows.

Case practice:

1. The approximately 9× speedup obtained without device synchronization is very likely unreliable. After the host issues a kernel, it continues execution without waiting for completion; if timing points are not synchronized, the measured time may only cover the kernel issuance stage and miss the actual computation still executing, causing GPU time to be severely underestimated and speedup to be inflated. The correction method is: call device synchronization at each timing point to ensure all issued work has truly completed before reading the timestamp; perform warm-up iterations first, and count host-device data transfer time separately from pure computation time. Only per-generation time and total time measured under fixed seed, warm-up, and synchronization conditions can serve as a credible basis.

2. A speedup of only about 1.2× at small batch b=8 is not contradictory. Batch processing benefit is jointly constrained by batch size, kernel launch overhead, and data transfer overhead; when the batch is too small, the amount of parallel work available on the device is insufficient, fixed overhead accounts for a large proportion of per-generation time, and effective parallelism cannot amortize these costs, so the speedup naturally approaches 1. It is recommended to increase batch size within the allowable GPU memory range, vectorize the evaluation function and post-processing logic as much as possible, and re-measure according to the standard protocol, reporting per-generation time, total time, throughput, and speedup separately, thereby judging whether the benefit truly lands on the goal of obtaining more generations or more candidates under the same budget.

**Comprehension Check**

Randomly ask students to explain in their own words why the evaluation function should first be verified as vectorizable before comparing CPU and GPU; and state what warm-up and device synchronization each solve.

> **Transition Hint**
>
> After confirming that students can distinguish sources of benefit from constraints and can convert acceleration into budget benefit, proceed to the next page's examples, applications, or summary.

<a id="lecture-page-14"></a>

### Core Methods of Batch Tensor Computation

*Page 14*

> **Page Objective:** Learners should consolidate the core methods of expressing the evolutionary process as batch tensor computation.

> **Page Objective**
>
> Consolidate the core methods of expressing the evolutionary process as batch tensor computation, understand the relationships among batch dimension, batch operators, computation graph optimization, and throughput metrics, and be able to identify pseudo-batch processing.

> **Explanation Sequence**
>
> Candidate tensor X is [N × D], objectives and constraints F are [N × M], evaluation output Y is [N × M]; batch dimension N is always outermost, and D and M describe the number of variables and number of objective terms of a single candidate.
>
> Uniformly map the population, objectives/constraints, evaluation output, and evolutionary state into tensors with a batch dimension; state quantities are maintained with scalars or small tensor buffers, rather than recorded individual by individual in Python objects.
>
> Mutation X′ = X + σ·randn(X), crossover pairs and recombines along the N dimension, selection idx = topk(F, k), evaluation Y = fθ(X). The focus is not a single expression, but that all candidates share the same tensor computation graph, with one batch call replacing N single-candidate calls; constraints and out-of-bounds can be handled within the same batch operation using mask tensors.
>
> Operator fusion reduces kernel launches, intra-batch parallelism lets all candidates execute simultaneously, asynchronous execution overlaps computation and transfer, and memory reuse reduces intermediate tensor allocation.
>
> Shift from single-step latency to candidates/second or generations/second, because one batch call carries the entire batch of candidates, and overall throughput reflects search efficiency.
>
> Embedding batch operators inside individual-by-individual Python loops reintroduces interpreter overhead and kernel launch overhead, making the batch dimension nominal. Self-check method: in one evolutionary step, the scheduling level should contain only "batch," not "individual."

**Teaching Points**

- Batch dimension N is the number of candidates; when shapes match, mutation, crossover, selection, and evaluation can all execute directly in batches along the N dimension. The direct benefit of tensorization comes from reducing call counts and scheduling overhead, not from changing the number of candidates or improving single-point precision. randn(X) generates a random perturbation tensor with the same shape as X; the perturbation is elementwise, and σ controls intensity. topk(F, k) selects the indices of the top k candidates along batch dimension N; the selection object is candidates, not variables or objective terms. Batch execution changes the location of the performance bottleneck; latency is still measurable, but measuring scale efficiency depends on how many candidates or generations are completed per unit time.

**Keyword Coverage**

- Batch tensor computation, batch dimension N, shape contract, batch operators, computation graph optimization, throughput, candidates/second, generations/second, pseudo-batch processing.

> **Material Clues**
>
> - The schematic on this page has the theme "Evolutionary Process → Batch Tensor Computation Graph," with three columns in order: ① tensorized organization, ② batch operators, ③ compiler optimization and throughput. Board writing or a mind map can unfold along these three columns, and highlight the throughput metrics "candidates/second · generations/second" in the third column.

> **Exercise Clues**
>
> - The 5 multiple-choice questions respectively check the shape contract, the performance benefit of tensorization, the meaning of the mutation expression, the semantics of topk selection, and the reason for the metric shift. Answer feedback can emphasize: when correct, connect to the shape contract or call pattern to explain the basis
> - when incorrect, return to the explanation on this page and find key evidence before judging. The case question "Migrating Individual-by-Individual Evolution Loops to Batch Tensor Execution" requires explaining how to organize candidates, objectives, and state into tensors and process them along the N batch, as well as the trade-offs between computation graph optimization and insufficient GPU memory. Key points of the answer include X:[N×D], F:[N×M], Y=fθ(X), state using scalar or small tensor buffers
> - mutation, crossover, selection, and evaluation all execute in batches along the N dimension
> - optimization can include operator fusion, intra-batch parallelism, asynchronous execution, and memory reuse
> - when GPU memory is insufficient, chunking or small-batch execution, lower numerical precision, and shortening intermediate tensor lifetimes can be used, but all candidates within the same generation should maintain a consistent comparison standard.

**Classroom Activity**

Have students explain in their own words "why batch dimension N should be outermost," and give a simple example, such as N=4, D=3, M=2, write out the shapes of X, F, and Y, and explain how one batch call replaces multiple single-candidate calls.

**Comprehension Check**

Ask students to summarize the shape contract, point out one pseudo-batch writing pattern, and explain why the metric shifts from single-step latency to throughput. If students can only recite terms but cannot explain changes in call counts and scheduling levels, return to the batch operators and common misconceptions section for supplementary explanation.

> **Transition Hint**
>
> After confirming that students can state the relationship between the shape contract and batch execution, proceed to the next page's applications, summary, or more complex computation graph optimization discussion.

<a id="lecture-page-15"></a>

### Runtime Scheduling and Algorithm Composability

*Page 15*

> **Page Objective:** Learners should consolidate the core understanding of Runtime in heterogeneous computing power scheduling and algorithm composability.

> **Page Objective**
>
> Establish Runtime's positioning as a middle layer — it is not a specific algorithm, but a scheduling and abstraction layer that connects the above and below: upward, it supports flexible combination of algorithms, problems, and workflows; downward, it manages heterogeneous computing power such as CPU and GPU, thereby maintaining algorithm composability and hardware independence.

> **Explanation Sequence**
>
> First give the "middle layer" judgment; then break down scheduling objects, heterogeneous resources, and decoupling mechanisms; next explain the benefits and costs of composability; finally use an algorithm replacement example and exercises to check understanding.

**Teaching Points**

- According to the workflow and monitor module state, schedule tasks such as population, evaluation, and operators to appropriate devices, and uniformly manage parallel execution and resource usage. It connects algorithm, problem, and workflow modules and calls CPU, GPU, and accelerators downward. Algorithms, problems, and operators are combined through modular interfaces, not directly bound to underlying hardware, parallel strategies, or compilation details. Therefore, when replacing algorithms such as DE or PSO or changing optimization problems, there is no need to rewrite underlying GPU/CPU parallel code. Device differences, tensorized execution, and compiler optimization are absorbed by Runtime, and the algorithm layer remains device-independent, facilitating replacement and reuse. Abstraction brings scheduling and data movement overhead, requiring a balance among flexibility, performance, and engineering complexity, for example using batching, asynchronous execution, or caching to reduce data movement. The same Runtime can support multi-domain applications and also provides a stable execution environment for method evolution and algorithm replacement.

> **Material Clues**
>
> - The schematic on this page can be read in three layers. The upper layer is the algorithm layer, including the algorithm module, problem definition, and workflow, all connected through a unified interface
> - The middle layer is the Runtime scheduling layer, responsible for task scheduling, parallel execution, resource management, and interface isolation
> - The lower layer is heterogeneous computing power, including CPU, GPU, and accelerators. The two side prompts respectively emphasize "algorithms replaceable, hardware independent" and "trade-off: flexibility · performance · complexity," and the bottom prompt says "the same Runtime supports multi-domain applications." When explaining, follow the arrows from top to bottom: the algorithm layer does not directly touch hardware, but is scheduled and executed by Runtime according to the workflow.

**Keyword Coverage**

- Heterogeneous computing power scheduling, algorithm composability, unified interface, workflow scheduling, hardware-independent abstraction, interface isolation, scheduling overhead, data movement overhead.

**Exercise Handling**

Five multiple-choice questions can be used for quick checking. The correct direction for question 1 is "provide a scheduling and abstraction layer, manage heterogeneous computing power, and maintain algorithm composability." If students mistakenly choose "directly implement optimization algorithms," emphasize that Runtime does not implement specific algorithms. The correct direction for question 2 is "combine through modular interfaces, not bound to underlying hardware and parallel strategies." If they mistakenly choose CUDA APIs or hand-written parallel code, explain that this breaks decoupling. The correct direction for question 3 is "absorb device differences, tensorized execution, and compiler optimization, making the algorithm layer device-independent." The correct direction for question 4 is "abstraction brings scheduling and data movement overhead, requiring trade-offs among flexibility, performance, and engineering complexity."

The correct direction for question 5 is "the same Runtime can support multi-domain applications and provide a stable execution environment for method evolution." In feedback, consistently tie back to three pieces of evidence: it is a middle layer rather than an algorithm implementation, composability requires hardware decoupling, and abstraction is not zero-cost.

As a middle layer, Runtime combines algorithm, problem, and workflow modules through a unified interface, scheduling tasks such as population, evaluation, and operators to CPU or GPU for execution; the algorithm layer is not directly bound to hardware, parallel strategy, or compilation details, so when the team replaces DE, PSO, or adjusts population size, there is no need to rewrite underlying parallel code. The second question can be answered: abstraction brings additional scheduling and data movement overhead, which may affect end-to-end performance; at the same time, Runtime's own maintenance and debugging increase engineering complexity. The team can reduce data movement through batching, asynchronous execution, or caching, achieving a balance among flexibility, performance, and engineering complexity.

**Comprehension Check**

Ask students to explain in one sentence why Runtime allows algorithm replacement without touching hardware code; then give one scheduling object and one heterogeneous resource each, confirming they will not confuse "population, evaluation, operators" with "CPU, GPU, accelerators."

> **Transition Hint**
>
> After confirming that students can distinguish scheduling objects from heterogeneous resources and can state the benefits and costs of composability, proceed to the next page's examples, applications, or summary.

<a id="lecture-page-16"></a>

### The Cornerstone of High-Intensity Parallel Evolutionary Exploration

*Page 16*

> **Page Objective:** Learners should comprehensively summarize the overall value and practical significance of EvoX's computing foundation and tensorized parallel evolution.

> **Page Objective**
>
> Comprehensively summarize the overall value and practical significance of EvoX's computing foundation and tensorized parallel evolution. Learners should be able to explain the transformation from candidate lists to tensorized computation graphs, master the three types of tensorized objects — population, evaluation, and state — and understand how the unified Runtime and decoupled architecture support high-intensity parallel evolutionary exploration.

> **Explanation Sequence**
>
> First point out the bottleneck of traditional serial processes, then introduce the tensorized computation graph as the cornerstone, then unfold the three major tensorized objects, then discuss graph-based computation and unified architecture, and finally land on benefits, practical significance, and the supercritical airfoil case.

**Teaching Points**

- 1. Traditional evolutionary experiments treat each individual as an independent Python object, modeling and evaluating one by one. When candidate scale expands to thousands or tens of thousands, the real bottleneck is often no longer the algorithm itself, but the scheduling, synchronization, and I/O overhead of candidate-by-candidate processing. EvoX's cornerstone can be summarized as: from candidate lists to tensorized computation graphs. It reorganizes populations, evaluations, and runtime states into tensors that can be computed as a whole, then schedules them through a unified Runtime to GPUs and heterogeneous computing power for batch execution, thereby supporting large-scale, multi-objective, multi-solution parallel evolutionary search. 2. Three major tensorized objects: individual parameters, genes, or policies are no longer looped through Python objects one by one, but organized into tensors along the batch dimension, with differences among individuals carried by one dimension of the tensor. Fitness, constraints, multi-objective metrics, and simulation or model evaluation results can be computed in batches; candidates within the same batch share one device call, significantly reducing candidate-by-candidate scheduling and I/O overhead. Runtime states such as evolutionary generation, random seed, cache, and monitoring metrics are uniformly managed, so that experiments remain reproducible and traceable after parallel acceleration. Tensorization is not local optimization of one place, but runs through the three levels of the evolutionary loop. If any layer falls back to object-by-object loops, parallelism will be stuck at that layer. After elevating candidate lists to tensorized computation graphs, operator parallelism and compiler optimization have room to operate, and population size and evaluation parallelism can scale with computing power, rather than being locked by interpreter loops. Accompanying this is a unified architecture — algorithm, problem, workflow and monitoring, and the Runtime scheduler are decoupled from one another, making algorithms composable, problems pluggable, and heterogeneous computing power uniformly managed. Users writing algorithms do not need to simultaneously worry about underlying scheduling. Replacing traditional CPU serial loops, achieving large-scale acceleration on GPUs and heterogeneous computing power, and providing a stable throughput foundation for high-intensity exploration
- Within the same wall-clock time, more candidates, more objective combinations, or more random repetitions can be explored. When underlying loop and scheduling engineering are absorbed by the foundation, researchers can turn their energy to problem modeling, objective trade-offs, and the design of experimental hypotheses, rather than first falling into underlying loop and scheduling engineering. This division of labor is both the prerequisite for high-intensity parallel evolutionary exploration and provides an engineering foundation for subsequent method evolution and AI Native research. In supercritical airfoil multi-objective optimization, cruise lift-to-drag ratio and critical buffet lift coefficient constrain each other, requiring preservation of a set of differentiated candidate schemes for experts to trade off. A single high-precision simulation is expensive, and candidate scale reaches thousands; early CPU serial loops required several days for one experiment, and random seeds and intermediate results were scattered and difficult to verify. Transformation approach: first perform population tensorization, organizing candidate airfoil parameters into tensors along the batch dimension
- then perform evaluation tensorization, batch-evaluating objectives and constraints such as lift-to-drag ratio and buffet lift coefficient; surrogate models can first perform batch prediction, then high-precision simulation can be called for a small number of candidates
- at the same time perform state tensorization, uniformly recording generation, random seed, cache, and monitoring metrics
- finally perform graph-based computation and schedule batch execution to GPUs and heterogeneous computing power through a unified Runtime. The links where throughput improves include batch evaluation parallelism, operator parallelism and compiler optimization, removal of candidate-by-candidate Python scheduling and synchronization overhead, and exploration of more candidates, more objective combinations, and more random repetitions within the same wall-clock time. Regarding reproducibility: it is not advisable to output a unique optimal scheme too early, because objectives constrain each other, and early single-point convergence loses trade-off information
- preserving differentiated candidates allows experts to choose according to benefit, cost, and applicable conditions. In terms of reproducibility, generation, random seed, cache, and monitoring metrics should be uniformly recorded as runtime state and managed with the computation graph, so that the results of batch parallel execution can be fully reproduced and traced; evaluation records of candidate batches should also be traceable to specific parameters and evaluation configurations.

**Exercise Handling**

This page is accompanied by five multiple-choice questions and one case question, which can be used to check conceptual understanding and transfer application.

The cornerstone is from candidate lists to tensorized computation graphs, scheduled for batch execution by a unified Runtime. Answer hint: the bottleneck is in candidate-by-candidate Python loops, scheduling, and I/O, not in the algorithm itself, nor in compressing the population or increasing single-core frequency.

Population tensorization is organizing tensors along the batch dimension, with individual differences carried by tensor dimensions. Answer hint: object-by-object loops are precisely what must be escaped; tensorization has nothing to do with the number of objectives, nor does it come at the cost of sacrificing reproducibility.

The main benefit of evaluation tensorization is batch computation of fitness, constraints, and multi-objective metrics, reducing candidate-by-candidate scheduling and I/O overhead. Answer hint: it does not improve the numerical precision of a single evaluation, cannot replace simulation models, and does not mean abandoning records.

Unified management of runtime state is to enhance the reproducibility and traceability of experiments. Answer hint: state tensorization manages generation, seed, cache, and monitoring metrics together; it is unrelated to reducing GPU memory, and does not cancel random seeds or restrict parallelism.

The significance of decoupling is that algorithms are composable, problems are pluggable, and heterogeneous computing power is uniformly managed. Answer hint: decoupling releases reuse and parallel capability, rather than limiting algorithms to serial implementation, and certainly does not cancel the need for experimental hypotheses and objective trade-offs.

First explain the transformation in four steps: population, evaluation, state, computation graph, and Runtime, then point out the links where throughput improves; the second question should explain why diversified candidates are preserved and how state tensorization and unified recording ensure reproducibility.

When students answer correctly, affirm that they can connect to the concepts on this page and explain the basis; when they answer incorrectly, guide them back to the explanation on this page, find key evidence or examples, and then judge.

**Classroom Activity**

Students can find an evolutionary computation or batch evaluation scenario they are familiar with and determine whether there is an explicit Python loop in it; if so, discuss whether tensorization should be prioritized at the population, evaluation, or state layer, and explain why.

**Comprehension Check**

Randomly ask one student to summarize the key points of this page in their own words; the teacher supplements keywords such as the three tensorizations, unified Runtime, breaking serial bottlenecks, reproducibility, and decoupled architecture according to the answer. A follow-up question can be asked: Why is reproducibility not an add-on? If random seeds, generations, cache, and monitoring metrics are not uniformly recorded with the computation graph, the acceleration benefit will be offset by the lack of traceability.

> **Transition Hint**
>
> After confirming that students can state the core relationship from candidate lists to tensorized computation graphs and can distinguish the three types of tensorized objects — population, evaluation, and state — proceed to the next page's examples, applications, or summary.