Domain: Software Engineering / Systems Architecture / Game Engine Development
Expert Persona: Senior Systems Architect and Performance Engineer
PROCESS PROTOCOL 2 & 3: SUMMARIZE (STRICT OBJECTIVITY)
Target Audience for Review:The Systems Architecture & Performance Optimization Group. This specialized cohort of low-level engineers, compiler researchers, and engine architects is dedicated to maximizing hardware utilization and minimizing latency in large-scale distributed systems and real-time simulations.
Abstract:
In this technical keynote, Mike Acton, Principal Engineer at Unity, advocates for a fundamental shift from Object-Oriented Programming (OOP) to Data-Oriented Design (DOD). Acton argues that modern software engineering is hindered by "clowns in the car"—layers of unnecessary abstraction and "insidious lies" that ignore hardware realities. He introduces Unity’s Data-Oriented Tech Stack (DOTS), which comprises the C# Job System, the Burst Compiler, and the Entity Component System (ECS).
The presentation identifies memory latency and cache misses as the primary bottlenecks in modern computing, demonstrating that traditional heap-allocated, pointer-heavy objects result in up to 90% hardware waste. Acton details the implementation of "HPC#" (High-Performance C#), a memory-safe subset of the language that eliminates garbage collection to enable aggressive ahead-of-time (AOT) compilation and SIMD optimization. The session concludes with a rigorous definition of engineering principles centered on data transformation, hardware awareness, and the rejection of generic, "future-proofed" frameworks in favor of performance-driven utility.
Systematic Summary of "Building a Data-Oriented Future"
0:00–2:29 - Professional Context: Mike Acton (formerly Technical Director at Insomniac Games) describes his background in AAA console development (PlayStation 1–4, Xbox 360/One) and his transition to Unity. The goal is to address performance issues at a massive scale, impacting over 3 billion devices and 50% of the mobile market.
2:30–4:23 - The Core Mission: Acton defines his mission as maximizing user value by eliminating "clowns in the car"—the fundamental inefficiencies inherent in common software development practices that drain batteries and waste data.
4:24–6:12 - The Three Big Lies: The speaker identifies three misconceptions in the software industry: (1) Software is not a platform (it is merely a set of instructions for hardware); (2) Code should not be designed around world-models or "stories"; (3) Code is not more important than data.
6:13–9:32 - Performance by Default: Acton defines a set of goals for the next generation of engineering: Performance by default, optimizability by default, and scalability by default. He argues for an iterative development path that removes the "wall" between pre-production (prototyping) and production (final code).
9:33–11:04 - Core Technology Stack (DOTS): The speaker introduces Unity's Data-Oriented Tech Stack (DOTS), consisting of a Job Scheduler, the Burst Compiler (LLVM-based), native memory containers, and the Entity Component System (ECS).
11:05–13:02 - Job Scheduler and Verification: The Job System requires developers to fully declare data usage and read/write permissions. This allows the system to perform automated verification of correctness, identifying race conditions and enabling junior developers to write safe, high-performance multi-threaded code.
13:03–15:59 - The Burst Compiler and HPC#: Unity utilizes "High-Performance C#" (HPC#), a subset of the language that excludes class types, boxing, exceptions for control flow, and garbage collection. This allows for ahead-of-time (AOT) compilation into native, highly optimized code for specific targets (ARM, x64).
16:00–18:49 - Editor Inspector and Static Analysis: Acton demonstrates the in-editor inspector, which allows developers to view the IR (Intermediate Representation) and assembly output for different target platforms, with iteration times targeting under 500 milliseconds.
18:50–20:05 - Memory Containers and Aliasing: The system uses custom allocators (Temp, TempJob) and strict aliasing rules. Because the compiler knows the source and lifetime of memory via these containers, it can perform aggressive LLVM optimizations impossible in standard C++.
20:06–22:30 - ECS Architecture: Acton contrasts Object-Oriented game objects (randomly heap-allocated) with ECS (homogeneous data storage). ECS organizes data into "archetypes" and 16 KB "chunks," allowing systems to process data sequentially and maximize cache hits.
22:31–25:51 - Global Energy and Data Transformation: Principles of DOD: (1) The energy used should be proportional to "surprise" (how much a frame differs from the previous one); (2) The purpose of every program is solely to transform data from one form to another.
25:52–28:11 - Utility vs. Storytelling Abstraction: The speaker distinguishes between utility abstraction (helpful scaffolding) and storytelling abstraction (hiding what is actually happening to the data). He argues that the latter leads to poor engineering results.
28:12–30:01 - Rejection of Generic Frameworks: Acton argues against platform independence, generic frameworks, and "future-proofing." He contends that these practices hide specific problem knowledge and that the only future-proof systems are those that are easy to delete.
30:02–31:30 - Understanding the Cost: To solve a problem, an engineer must understand its constraints across four categories: Performance, Determinism, Scalability, and Workflow/UX.
31:31–33:33 - Hardware and the L2 Cache Reality: Acton illustrates the "memory wall." On modern x86/64 hardware, an L1 cache hit takes ~3 cycles, while an L2 miss (fetching from RAM) can exceed 200 cycles. Cache misses are the most significant component of software performance.
33:34–35:23 - The Cost of OOP: Using a code example, Acton demonstrates that traditional OOP objects waste approximately 90% of a 64-byte cache line per read. This results in software being inherently 10 times slower than required by the hardware.
35:24–36:50 - Engineering vs. Magic: Acton concludes that Data-Oriented Design is not magic, but engineering. It focuses on providing tools that help build experts who can measure, understand, and optimize data transformations.