GPU vs CPU vs TPU Simulator: An Interactive Web-Based Visualization of Heterogeneous Processor Performance for AI Workloads

1. Introduction

The rapid expansion of deep learning has driven the development of specialized hardware accelerators designed to handle the massive parallelism inherent in neural network computations. While CPUs remain the general-purpose backbone of computing, GPUs have become the de facto standard for training deep learning models, and TPUs represent Google's purpose-built approach to tensor operations. Understanding the architectural differences between these processors and their implications for AI workload performance is essential for practitioners making hardware selection decisions.

However, direct access to all three processor types for comparative benchmarking is impractical for most learners and practitioners. GPU clusters require significant investment, and TPU access is limited to Google Cloud Platform. Existing educational materials rely primarily on static benchmark tables, performance charts, and theoretical descriptions that fail to convey the dynamic nature of parallel processing.

GPU vs CPU vs TPU Simulator addresses this educational gap by providing a browser-based interactive tool that simulates the relative performance characteristics of all three processor types across representative AI workloads. Users observe a visual race between processors, examine animated core grids, and analyze real-time metrics—developing intuitive understanding of why certain architectures excel at specific workload patterns. The key contributions of this work are:

• A real-time processing race visualization with three competing processor lanes, progress bars, and global elapsed timer that makes performance differences immediately visible and engaging.
• Animated core visualization grids (16 cores for CPU, 256 for GPU, 64 for TPU) with pulsing effects during active processing, conveying the parallelism disparity between architectures.
• Four configurable AI workloads (matrix multiplication, CNN training, batch inference, NLP transformer) with adjustable batch sizes, enabling users to explore how workload characteristics affect relative processor performance.
• ASCII architecture diagrams illustrating internal processor structures (CPU cache hierarchy, GPU streaming multiprocessors with CUDA cores, TPU systolic array configuration).
• A zero-dependency, single-file implementation deployed on both GitHub Pages and Vercel without any build tooling.

2. Related Work

2.1 Heterogeneous Computing Architectures

The divergence between CPU, GPU, and TPU architectures reflects fundamentally different design philosophies. CPUs optimize for single-thread performance with deep pipelines, branch prediction, out-of-order execution, and large cache hierarchies. GPUs sacrifice single-thread performance for massive parallelism, organizing thousands of simpler cores into streaming multiprocessors that execute identical instructions across data elements (SIMT model). TPUs take specialization further, implementing a systolic array architecture where processing elements are arranged in a grid and data flows between them in a pipelined fashion, optimizing specifically for matrix multiply-accumulate operations.

Jouppi et al. (2017) described the TPU architecture in detail, reporting 15–30x performance improvements over contemporary CPUs and GPUs for inference workloads. Subsequent TPU generations (v2, v3, v4) extended this advantage to training, with TPU v4 pods delivering 1.1 exaflops of peak performance. Our simulator abstracts these architectural differences into configurable processor models that produce performance ratios consistent with published benchmarks.

2.2 Performance Benchmarking Tools

MLPerf (Mattson et al., 2020) established standardized benchmarks for comparing ML hardware across training and inference tasks. However, MLPerf results are static tables requiring specialized hardware to reproduce. Tools like AI Benchmark (Ignatov et al., 2019) focus on mobile processors. Our simulator complements these by providing an interactive, visual experience that runs in any web browser without specialized hardware.

2.3 Educational Visualizations

Interactive visualizations have proven effective for teaching computing concepts. TensorFlow Playground demonstrates neural network training, CNN Explainer visualizes convolutional operations, and Transformer Explainer (our prior work) visualizes attention mechanisms. However, no comparable interactive tool exists for comparing hardware architectures in the context of AI workloads. Our work fills this gap with a processor-centric visualization.

3. Processor Models

The simulator abstracts each processor type into a parameterized model that captures the essential performance characteristics without requiring cycle-accurate simulation. Each model is defined by its core count, clock frequency, parallelism factor, and workload-specific throughput scaling.

3.1 CPU Model

The CPU model excels at workloads with complex control flow and data-dependent branching but is constrained by its limited thread count for massively parallel tensor operations. In the simulation, CPU processing speed reflects this by applying a parallelism penalty proportional to the workload's inherent parallelism.

3.2 GPU Model

The GPU model achieves its performance advantage through massive parallelism—4096 CUDA cores executing the same instruction on different data elements simultaneously. The simulation models this by scaling GPU throughput proportionally to the data-parallel dimension of each workload, producing 10–50x speedups over CPU for suitable tasks.

3.3 TPU Model

The TPU model represents the most specialized architecture, achieving peak efficiency for matrix multiply-accumulate operations through its systolic array. The 128×128 array processes 16,384 multiply-accumulate operations per cycle in a pipelined fashion. The simulation reflects this by giving TPU the highest throughput for matrix-heavy workloads while applying efficiency penalties for operations that don't map well to the systolic array structure.

4. Workload Parameterization

The simulator supports four representative AI workloads, each characterized by distinct computational patterns that exercise the three architectures differently.

4.1 Batch Size Scaling

Users configure batch sizes from 32 to 256. Larger batch sizes increase the total computation and amplify the parallelism advantage of GPU and TPU architectures. The simulation models this relationship:

This formulation captures the reality that CPUs scale linearly with batch size (limited parallelism), GPUs scale sub-linearly (parallelism saturates at high batch sizes), and TPUs maintain near-linear throughput scaling due to the systolic array's efficient data flow.

4.2 Simulation Speed Control

A speed multiplier (adjustable via slider) scales the animation tick rate without affecting the relative performance ratios between processors. This allows users to observe the race dynamics at their preferred pace—slow for detailed analysis or fast for rapid comparison.

5. Simulation Engine

5.1 Tick-Based Architecture

The simulation runs on a setInterval-driven tick system. Each tick advances all three processors by their respective throughput amounts, calculated from the processor model parameters and current workload configuration. The tick interval is set to 50ms, providing smooth visual updates at 20 frames per second.

5.2 Stochastic Jitter Model

To prevent the simulation from appearing artificially deterministic, each processor's progress increment includes a random jitter component. The jitter is sampled from a uniform distribution scaled to ±15% of the base increment:

This produces realistic variation in finish times across simulation runs while preserving the expected performance ordering. The jitter also creates visual dynamism in the progress bars, making the race more engaging.

5.3 Completion Detection and Ranking

When a processor's cumulative progress reaches 100%, the simulation records its finish timestamp and assigns a rank (1st, 2nd, 3rd) with corresponding medal badges. The global elapsed timer continues until all processors complete. After all finish, the system calculates speedup ratios relative to the slowest processor and displays a comprehensive results summary.

6. Visualization Architecture

6.1 Processing Race Display

The centerpiece of the simulator is the processing race—three horizontal progress bars representing CPU, GPU, and TPU advancing toward 100% completion. Each lane is color-coded (cyan for CPU, green for GPU, orange for TPU) and displays the processor name, current progress percentage, and status badge (IDLE, RUNNING, or FINISHED). A global elapsed timer above the lanes shows cumulative time in seconds.

6.2 Core Visualization Grids

Each processor card displays an animated grid representing its processing elements:

The grid animations are designed to convey each architecture's parallelism model: CPU cores activate individually (limited parallelism), GPU cores activate in large waves (SIMT execution), and TPU units activate in diagonal sweeps (systolic data flow).

6.3 Architecture Diagrams

ASCII-style technical diagrams illustrate the internal structure of each processor, providing educational context for the performance differences:

CPU Architecture:
┌─────────────────────────────┐
│ Control Unit  │ Branch Predictor │
│──────────────┼──────────────┤
│ L1$ │ L2$ │    L3 Cache     │
│────┼────┼──────────────┤
│ Core0 │ Core1 │ Core2 │ Core3 │
└───────┴───────┴───────┴──────┘

GPU Architecture:
┌─────────────────────────────┐
│ GPC0: SM0 SM1 SM2 SM3     │
│ GPC1: SM4 SM5 SM6 SM7     │
│ Each SM: 128 CUDA Cores    │
│─────────────────────────────┤
│ HBM2e Memory Controller    │
└─────────────────────────────┘

TPU Architecture:
┌─────────────────────────────┐
│   128x128 Systolic Array   │
│   [PE][PE][PE]...[PE]      │
│   [PE][PE][PE]...[PE]      │
│   Matrix Multiply Unit     │
│─────────────────────────────┤
│   Unified HBM Controller   │
└─────────────────────────────┘

6.4 Real-Time Metrics Dashboard

Each processor card displays live metrics updated on every simulation tick:

6.5 Event Log Console

A scrollable console at the bottom of the interface displays timestamped log entries tracking simulation events. Events include processor initialization, workload assignment, milestone completions (25%, 50%, 75%), finish events with timing data, and final rankings with speedup calculations. The log provides a textual record complementing the visual race display.

7. Results and Analysis Display

Upon completion of all three processors, the simulator presents a comprehensive results panel:

• Ranked Finish Order: Processors ordered by completion time with medal badges (🥇 1st, 🥈 2nd, 🥉 3rd).
• Time Comparison: Absolute completion times for each processor with calculated speedup multipliers relative to the slowest (CPU).
• Performance Bars: Horizontal bars showing relative execution times, visually encoding the magnitude of performance differences.
• Timestamp Logs: Complete chronological record of all processor events from initialization to completion.

The results display reinforces the quantitative learning by presenting multiple representations of the same performance data—numerical, visual, and chronological.

8. User Interface Design

8.1 Visual Design System

The dark theme with processor-specific color coding creates immediate visual association between each lane and its processor type. The color scheme is consistent across progress bars, core grids, status badges, architecture diagrams, and results displays.

8.2 Interactive Controls

8.3 Responsive Layout

The interface uses CSS Grid and Flexbox to adapt across viewport sizes. On desktop, processor cards are displayed in a three-column layout for side-by-side comparison. On tablet, the layout transitions to a stacked arrangement with preserved race lanes. On mobile, all elements stack vertically with touch-optimized controls.

9. Deployment

9.1 Dual-Platform Deployment

The project is deployed on two platforms simultaneously, demonstrating the portability of the zero-dependency architecture:

Both deployments serve the identical index.html file with no build step, transpilation, or bundling required. The zero-dependency architecture ensures identical behavior across both CDN networks.

9.2 Local Development

git clone https://github.com/romizone/gpu-cpu-tpu-simulator.git
cd gpu-cpu-tpu-simulator
npx serve .
# Or: python3 -m http.server 3000
# Or: open index.html (direct file access)

10. Implementation Details

10.1 Technology Stack

10.2 Zero-Dependency Architecture

The entire application resides in a single index.html file containing HTML structure, CSS styles, and JavaScript logic. No npm packages, frameworks, build tools, or external CDN references are used. This architecture provides:

• Instant deployment: Serve from any static host or open directly from the file system.
• Zero maintenance burden: No dependency updates, security patches, or version conflicts.
• Maximum portability: Works identically across GitHub Pages, Vercel, Netlify, or local file access.
• Educational transparency: The complete codebase is inspectable in a single file.

10.3 Project Structure

gpu-cpu-tpu-simulator/
├── index.html              # Complete application (single-file, all-in-one)
│   ├── <style>             # CSS: dark theme, processor colors, animations, responsive
│   ├── <body>              # HTML: race lanes, processor cards, controls, results
│   └── <script>            # JS: simulation engine, tick loop, core animations, logging
├── LICENSE                 # MIT License
└── README.md               # Documentation and usage guide

11. Educational Value

The simulator serves as an educational bridge between theoretical hardware architecture knowledge and practical performance intuition. Key learning outcomes include:

12. Browser Compatibility

13. Future Work

• Custom Workload Builder: Allow users to define custom workloads by specifying operation mix (percentage matrix multiply, convolution, attention, sequential), enabling exploration of how workload composition affects relative processor performance.
• Multi-GPU/TPU Scaling: Simulate data-parallel and model-parallel scaling across 2, 4, and 8 accelerators, demonstrating Amdahl's law and communication overhead in distributed training.
• Power Efficiency Mode: Add performance-per-watt metrics alongside raw throughput, illustrating the energy efficiency advantages of specialized hardware.
• Historical Architecture Timeline: Allow users to select hardware generations (e.g., K80 vs V100 vs A100 vs H100) and observe how each generation improved AI workload performance.
• Memory Bandwidth Visualization: Add memory bandwidth utilization as a visible bottleneck, showing when workloads are compute-bound vs. memory-bound on each architecture.
• NPU/Neural Engine Support: Add Apple Neural Engine and Qualcomm Hexagon NPU models to cover edge AI processor comparisons.

14. Conclusion

GPU vs CPU vs TPU Simulator demonstrates that the fundamental performance characteristics of heterogeneous processor architectures can be made accessible through interactive browser-based visualization. By staging a visual race between three processors across representative AI workloads, users develop intuitive understanding of why GPUs and TPUs dramatically outperform CPUs for data-parallel tensor operations, and how workload characteristics influence the relative advantage of each architecture.

The animated core visualization grids convey the parallelism disparity between architectures more effectively than static diagrams or benchmark tables. The configurable workload selection and batch size controls enable users to explore the workload-architecture fit landscape, discovering that TPUs excel at matrix-heavy inference, GPUs dominate training workloads, and CPUs remain competitive only for sequential or control-flow-heavy operations.

Built as a single HTML file with zero external dependencies and deployed on both GitHub Pages and Vercel, the application is instantly accessible, fully transparent, and suitable for educational contexts ranging from computer architecture courses to AI practitioner workshops. The dual-platform deployment demonstrates the portability benefits of dependency-free web development.

The complete source code is available at https://github.com/romizone/gpu-cpu-tpu-simulator and live demos are accessible at GitHub Pages and Vercel.

References