Understand and explore the power of scientific programming

Julia Code Outperformed Native C (But what it actually informed about speed)

"This post tells about surprising benchmark where Julia outperformed C in a loop test. Learn how I/O buffering and unoptimized GCC compilers can completely flip execution speeds."

PROGRAMMING

Rahul Mahajan

5/26/20262 min read

Introduction 

In performance bench-marking, you know C is the undisputed, champion as far as raw speed is considered. So, you can imagine my sheer disbelief when I wrote a quick loop to calculate and print the square roots of numbers from 1 to 100,000, and Julia crossed the finish line in 48 seconds while C dragged behind at 1 minute and 52 seconds. How a high-level language can beat C by over a minute? The answer exposes a massive, but hidden truth about how modern programming languages actually operate.

1. The Screen Is big issue: Printing vs. Math

When performing, my CPU wasn't sweating over the mathematics; it was choking on the terminal window. Sending text to a monitor is one of the slowest performance tasks for a computer. And the two languages handle it completely differently:

  • C (printf): By default, C flushes its output buffer constantly. It continuously pauses the entire program to wait for operating system for allowing it to update the screen line-by-line.

  • Julia (println): Julia features a brilliantly optimized, asynchronous I/O buffering system. It bundles massive chunks of text quietly in memory and dumps them onto the screen all at once, which makes printing blazing fast.

2. The Trap of the Un-optimized Compiler

Julia uses a Just-In-Time (JIT) compiler that automatically optimizes code on the fly. C relies on an Ahead-Of-Time compiler (e.g. GCC) which, by default, turns all optimizations completely off to save compilation time. Running a standard gcc main.c command usually produces sluggish machine code.

The Rematch: 10 billion Iterations, No Distractions

To find out which language fires aggressively, I eliminated terminal printing bottleneck, cranked the workload up to a massive 10 billion iterations, and unleashed C's full power using the maximum optimization flag (-O3).

With a high-resolution timer ticking, the rematch was a breathtaking, neck-and-neck drag race:

  • C: 23.91 seconds

  • Julia: 26.08 seconds

Here are my codes:

# -----------------------------------------Julia Code -----------------------------------

function compute_sqrt()

total = 0.0

for i in 1:10000000000

total += sqrt(i)

end

println("Sum: ", total) # Print only at the very end

end

@time compute_sqrt()

/* -----------------------------------------C Code ----------------------------------- */

#include <stdio.h>

#include <math.h>

#include <time.h> // Required for timing functions

int main() {

struct timespec start, end;

double sum = 0.0;

// Get the starting wall-clock time

clock_gettime(CLOCK_MONOTONIC, &start);

// Main loop starts here

for (long long i = 1; i <= 10000000000; i++) {

sum += sqrt(i);

}

// Get the ending wall-clock time

clock_gettime(CLOCK_MONOTONIC, &end);

// Calculate total time taken in seconds

double time_taken = (end.tv_sec - start.tv_sec) + (end.tv_nsec - start.tv_nsec) / 1e9;

// Print the results

printf("Sum: %lf\n", sum);

printf("Time taken: %lf seconds\n", time_taken);

printf("\nPress Enter to exit...");

getchar();

return 0;

}

An entry level machine was deployed to run my test i.e. CPU with AMD Ryzen 3 3200U with Radeon Vega Mobile Gfx (2.60 GHz) equipped with 8.00 GB RAM

What exactly happened here?
  1. Once the bottleneck of screen-printing was gone, both languages were cruising at the absolute physical limits of Hardware, executing an astonishing 400 million calculations per second.

  2. That about 2-second lead C maintained isn't because its math engine is superior. It’s simply the "JIT compilation tax"—the brief fraction of a time Julia takes to spin up its environment and compile the function when you first hit run. Once Julia warmed up, it runs at the almost exact same hardware-level speed as C.

Leave a reply

scientificprogramming.in

Explore scientific programming

Contact author

© 2025. All rights reserved.