Comparative Empirical Analysis of Programming Language Runtime Dynamics: The Prime Sieve Benchmark Evaluation

Architectural Context and Historical Provenance

The digital artifact identified by video index tQtFdsEcK_s, titled E01: What is the FASTEST Computer Language? 45 Languages Tested!, represents the first formal competitive installment of the Computer Language Drag Racing Series created by former Microsoft systems engineer Dave Plummer on the technical engineering channel Dave’s Garage1. This project originated as an empirical exploration into single-threaded execution efficiency across programming languages, transitioning from an initial prototype comparison of C++, C#, and Python into a broader community-driven benchmarking initiative2. Following the publication of the baseline sieve algorithm, community contributors ported the reference implementation to dozens of distinct execution environments, establishing the open-source repository PlummersSoftwareLLC/Primes on GitHub, where it rose to the top ranks of global developer trending charts2.
While the overarching benchmark series eventually expanded to encompass more than 60 programming languages—spanning native compilers, managed execution environments, functional paradigms, and dynamic scripting runtimes—Episode 01 focuses on a historically significant group of structured, statically typed, and safety-oriented compiled languages: Pascal, Delphi, and Ada2. Pitting these languages against one another under an identical algorithmic workload isolates the direct micro-architectural consequences of compiler code generation, runtime boundary enforcement, and data structure memory packing, eliminating peripheral distortions introduced by complex runtime garbage collectors or high-level operating system APIs5.

Algorithmic Framework and Execution Criteria

The computational core chosen for the benchmark is the classical Sieve of Eratosthenes configured to discover all prime numbers up to an upper limit of one million (), an algorithm exhibiting asymptotic theoretical time complexity of 1. Rather than testing multi-threaded scaling, vectorization through specialized assembly libraries, or raw floating-point floating-unit throughput, the sieve exposes how language runtimes traverse contiguous memory buffers, manage register-level arithmetic, and interact with CPU cache hierarchies6.
To maintain scientific integrity across radically disparate language paradigms, the project enforces a standardized execution harness governing memory allocation, algorithmic compliance, and time normalization5. The candidate prime memory buffer must be allocated dynamically at runtime rather than instantiated as a static compile-time global array, preventing optimizing compilers from precomputing the sieve at build time or relying on fixed, baked address offsets5. Implementations must also adhere to strict algorithmic fidelity, requiring the sequential elimination of composite multiples step-by-step without resorting to mathematical bypasses, prime tables, or irregular wheel factorizations5.
Each benchmark pass allocates the buffer, executes the clearing loop across all odd factors up to , verifies the final prime count against a known mathematical ground truth, and repeats this entire pipeline continuously over a calibrated duration window of approximately five seconds2. The resulting performance metric is expressed as the total count of completed valid passes normalized to passes per second, establishing a high-resolution, single-threaded throughput index that evaluates the efficiency of each language’s tight inner loop execution2.

Comparative Systems Analysis: Ada, Pascal, and Delphi Implementations

The central comparative focus of Episode 01 is the architectural head-to-head evaluation between Ada, standard Pascal, and its object-oriented descendant Delphi2. These systems languages share common intellectual lineage rooted in the structured programming movement, yet their real-world compilers and runtime safety profiles introduce divergence in machine-code generation4.

Language / Dialect	Compiler Backend & Infrastructure	Type System & Safety Architecture	Memory Representation Strategy	Primary Optimization & Code-Generation Vectors
Ada	GNAT (GCC optimization backend)	Strong, static typing with explicit subtype ranges and invariant validation7	Dynamically allocated boolean buffers or packed bit arrays5	Scalar evolution, dead-code elimination, aggressive interprocedural inlining7
Pascal	Free Pascal Compiler (FPC)	Strongly typed procedural paradigm with modular units10	Dynamic continuous byte-boolean arrays or bitmapped primitives6	Register variable allocation, loop invariant hoisting, suppressible range checking6
Delphi	Embarcadero Delphi / Native Compiler	Object Pascal with component model and object encapsulation10	Heap-allocated object wrapper containing raw memory buffers6	Whole-program link-time code generation, fastcall register convention1

Compiler Code Generation and Safety Mechanics in Ada

Ada was commissioned by the United States Department of Defense specifically to mitigate systemic failures in embedded and real-time defense applications through static verification and deterministic runtime execution7. When processing the prime sieve benchmark through the GNU Ada Translator (GNAT) built upon the GCC optimization backend, the language demonstrates how formal safety checks interface with low-level machine execution7.
By default, an Ada compiler inserts pervasive runtime assertions into the compiled binary, checking array bounds, integer range overflows, and pointer validity on every iteration of the inner marking loop7. While essential for mission-critical reliability, this defensive instruction emission introduces branch instructions that disrupt instruction pipelining and degrade throughput relative to raw C7. However, when compiled under full release optimization flags (such as -O3 combined with pragma assertions that suppress checks where correctness has been proven statically), GNAT generates machine instructions that closely rival optimized C and C++7. The GCC optimizer identifies loop invariants, performs dead-code elimination, and vectorizes contiguous memory updates, demonstrating that Ada’s perceived performance ceiling is largely governed by compiler safety configurations rather than structural language overhead7.

The Pascal and Delphi Memory Management Models

Pascal, architected by Niklaus Wirth, prioritizes pedagogical simplicity and structural transparency, while Delphi expands this foundation into a commercial, component-oriented development environment10. Within the benchmark harness, both the Free Pascal Compiler (FPC) and the proprietary Delphi compiler highlight distinct mechanics regarding how structured languages handle continuous memory and bit manipulation6.
The comparative implementations illustrate a fundamental architectural dilemma between bit-level storage density and CPU cycle expenditure6. When developers implement the sieve using a packed bit array, memory consumption drops by an order of magnitude, ensuring the entire candidate buffer resides within the processor’s highest-speed L1 data cache6. Nevertheless, updating an individual candidate bit requires multiple arithmetic and logical instructions, specifically bitwise shifts (SHR, SHL) to locate the target byte and bitwise masks (AND, OR, NOT) to toggle the specific bit6.
Conversely, configuring the sieve with an array of individual 8-bit booleans eliminates bit-shifting overhead, allowing the CPU to mark a composite number using a single direct byte-write instruction6. However, this strategy expands the memory working set eightfold, increasing the probability of cache line evictions and memory bus stalls6. The benchmark reveals that when compiler directives are utilized to disable redundant runtime range checking ({$R-}) and overflow detection ({$Q-}), Free Pascal and Delphi generate lean native code capable of competing within a narrow margin of both Ada and C++, demonstrating the enduring performance viability of Wirthian structured architectures6.

Cross-Paradigm Performance Dynamics Across the Systems Spectrum

Episode 01 situates Pascal and Ada within a broader taxonomic framework across 45 tested languages, illustrating how distinct execution strategies alter performance profiles across several orders of magnitude1.

Architectural Category	Representative Languages	Primary Execution Engine	Memory Abstraction Model	Relative Throughput Magnitude
Native Systems Ahead-of-Time (AOT)	C, C++, Rust, Zig, Ada, Fortran, Pascal1	Direct compilation to native machine architecture via GCC, LLVM, or native backends7	Explicit manual memory layout, unboxed bit arrays, unmediated pointer access6	Baseline Maximum (1.0x – 0.7x throughput): Minimal abstraction cost, zero garbage collection, optimal cache utilization8.
Managed Runtime / Just-In-Time (JIT)	C#, Java, Dart, Scala, F#1	Bytecode / Intermediate Language (IL) execution via dynamic JIT compilers2	Garbage-collected managed heap, runtime boundary checks, object header overhead2	Moderate (0.6x – 0.3x throughput): JIT compilation overhead, persistent array bounds checks, GC metadata overhead2.
Interpreted / Dynamic Bytecode	Python, Ruby, PHP, Perl, Bash, PowerShell1	Dynamic Abstract Syntax Tree (AST) interpretation or dynamic bytecode dispatch3	Fully boxed object structures, dynamic typing metadata, reference counting3	Sub-System (0.05x – 0.001x throughput): Interpretive evaluation loops, dynamic type resolution, lack of native bit primitives3.

The quantitative gulf separating these categories stems from how abstract language semantics map down to modern microprocessor micro-architectures3. In an implementation that tracks only odd candidate integers up to one million, a packed bitmask occupies precisely:

This footprint fits comfortably inside the Level 2 cache—and in many architectures, the Level 1 data cache—of modern desktop and server central processing units, virtually eliminating external DRAM latency penalties during inner loop traversal6.
In contrast, naive implementations in managed or dynamically typed scripting languages frequently allocate arrays of boxed integers or full 32-bit boolean primitives, expanding the active memory footprint to several megabytes3. This ballooning spills past the CPU cache boundaries, forcing memory controllers to continuously fetch cache lines from main system memory and stalling the CPU pipeline3.
Furthermore, optimizing ahead-of-time compilers leverage scalar evolution and mathematical loop bounds proofs to prove that an array index variable never exceeds buffer boundaries, entirely excising branch instructions from the compiled binary7. Managed virtual machines and dynamic interpreters frequently fail to establish these proofs due to complex stepping increments (), leaving redundant bounds-checking branches inside the innermost loop and imposing recurring branch misprediction penalties on modern speculative execution engines2.

Systematic Implications for Modern Software Engineering

The comparative data generated throughout Dave Plummer’s benchmark series yields critical engineering principles regarding software systems architecture, computational efficiency, and language selection criteria1.
A primary insight is the fundamental fallacy of labeling a programming language as intrinsically fast or slow based strictly on lexical syntax7. A programming language is merely an abstract formal specification; execution performance is determined by the synergy between the runtime model, the optimization maturity of the compiler backend, and the developer’s chosen data representation6. While systems languages such as C, C++, Ada, and Pascal consistently dominate the leaderboard, their dominance is not due to superior syntactical constructs, but rather their capacity to express unboxed memory layouts and compile down to direct machine instructions without mandated runtime overhead6.
A secondary architectural implication involves the operational cost of language safety mechanisms7. Developers often discard safety-oriented languages like Ada and Pascal under the mistaken assumption that rigorous type bounds and runtime verifications inevitably throttle execution throughput7. The results of Episode 01 illustrate that modern optimizing compilers can verify safety invariants ahead of time during compilation5. When configured for production deployment, languages engineered for mission-critical reliability achieve execution speeds comparable to unrestricted languages, debunking the premise that safety and raw throughput are mutually exclusive7.
Finally, the benchmark highlights the distinction between micro-benchmark performance and macro-scale software engineering7. An in-memory prime sieve isolates a narrow operational envelope: tight, branch-heavy loops interacting with low-level CPU caches6. In production distributed systems, enterprise workloads, or cloud infrastructure, total throughput is rarely bounded by bit-manipulation loop speed; instead, applications are predominantly bottlenecked by asynchronous network input/output, disk access times, and cross-thread synchronization2. Consequently, while a language like Python, Ruby, or C# may trail native Ada or Pascal by one or two orders of magnitude in an isolated algorithmic drag race, it may remain economically superior for enterprise deployment due to developer iteration speed, extensive ecosystem libraries, and lower maintenance costs3.

Conclusions

Dave Plummer’s E01: What is the FASTEST Computer Language? 45 Languages Tested! provides a rigorous engineering baseline for analyzing compiler optimizations and memory access patterns across programming languages1. By benchmarking Ada, Pascal, and Delphi using the Sieve of Eratosthenes, the study shows that execution speed is governed by compiler code-generation quality, cache-conscious data layouts, and the elimination of redundant runtime safety checks rather than language syntax5. The results demonstrate that classic structured and safety-focused compiled languages remain highly competitive with modern systems programming environments when configured for optimal machine-code generation1.

Works cited

E01: What is the FASTEST Computer Language? 45 … - YouTube, https://www.youtube.com/watch?v=tQtFdsEcK_s

C# vs Java: Which is Faster? Computer Language Drag Racing Series, https://podwise.ai/episodes/2837554

E00: Software Drag Racing: C++ vs C# vs Python - Which Will Win?, https://www.youtube.com/watch?v=D3h62rgewZM

What’s the Fastest Computer Language? We benchmark 45 … - Reddit, https://www.reddit.com/r/programming/comments/ok993q/whats_the_fastest_computer_language_we_benchmark/

Prime sieve language race - D Programming Language Forum, https://forum.dlang.org/thread/fpfujysoyeydnxtciwkw@forum.dlang.org

(off-topic?) inter-language ‘drag race’ competition · Issue #600 - GitHub, https://github.com/dotnet/vblang/issues/600

The results of the Dave Plummer’s Programming Languages Drag, https://www.reddit.com/r/programming/comments/og72q3/the_results_of_the_dave_plummers_programming/

Language Drag Race : r/rust - Reddit, https://www.reddit.com/r/rust/comments/ofbk0p/language_drag_race/

r/ada on Reddit: 45種類のコンピュータ言語の比較：どれが最も速い, https://www.reddit.com/r/ada/comments/og597h/45_computer_languages_compared_which_is_fastest/?tl=ja

“Object Pascal everywhere” by Bruno Fierens - YouTube, https://www.youtube.com/watch?v=WdpNx_LZOMc

Is c++ worth learning in 2023 people seem to forget that its … - Reddit, https://www.reddit.com/r/dotnet/comments/16e6vrx/is_c_worth_learning_in_2023_people_seem_to_forget/

aStrA : Aligned Strings format with attributes - Hackaday.io, https://hackaday.io/project/171641-astra-aligned-strings-format-with-attributes