Wow what a creative way to visualize the concept.

I think curves make it tricky to maintain objective perception, but the layout contributes significantly to the idea that internal latency is a different order from external.

Author here: Yeah, the mod was added to reduce risk of loop(s) getting optimized away.

It’s impressive but even more interesting, it could still be faster! Java is JIT at #3, so theoretically any of these languages could get there.

For the record - I can't imagine any tangible value in writing a graphics engine (and form library) for an environment that was literally designed as a graphics engine for forms. But, that disclaimer aside, I've considered WASM for graphics for a game engine and I have had some trial success with allocating a shared array buffer, writing to it in WASM and reading from it at a js-friendly rate of 30-60 fps (whatever requestAnimationFrame is serving). The idea being that you treat the shared array buffer as your "screen" and write to it from the WASM as if it were an image buffer, while on the JS side you read it as an image buffer onto the canvas. Gives you a nice, finite, bandwidth and an easy to scale maximum for how much data you can pass through, and neither JS nor WASM ever has to pass any time-critical data.

Of course, this setup leaves a very thin JS client - it's essentially just rendering the same image over and over. So if you've already got everything done in JS, it would mean porting all of your functional code over to something that can compile into WASM. Not a huge lift, but not fun either.

And then, on the other hand, if it's just rendering you're seeing as a bottleneck, JS works pretty well with webGL and webGPU for simple form rendering. A little loop unrolling might be a lot easier than porting the rest of the app.

Anyway, best of luck on it!

In Haskell the numerator and denominator of the Rational type are unbounded integers, so one of the (many equivalent) ways of writing it is:

    ghci> sum [i % (i+1) | i <- [0..9]]
    17819 % 2520
    ghci> 

I'll spare people the full result, but:

    ghci> sum [i % (i+1) | i <- [0..999]]
    70755...77483 % 71288...20000
    ghci>

PyPy uses just-in-time compilation, so for arithmetic-heavy computations not involving the GC, it should absolutely be faster.

This is the exact code you would expect pypy to run faster.

Go's int defaults to 64 bits on a 64 bit machine while C/Rust/Java are all defaulting to 32 bit on the author's machine.

Editing the code and running local to get a difference factor, it looks like the same Go code with int takes 1.5x the amount of time as the int32 code on my machine. That puts it ~right next to Java (assuming the perf change maps 1:1). Remove the GC and it comes in ~right next to C++.

Looking at the compiler assembly output on Godbolt it's fun to see all the extra panic info and checks Go adds before going to the loop whereas the C just segfaults from blasting forward anyways, sometimes with no detail.

Anyways, that's why I don't like these types of "benchmarks" (micro tests made into a media post). By the time someone actually looks into them to see what's up everyone has already seen the results and moved on.

Author here: Yeah, I was surprised that there doesn't seem to be many options for extra optimizations in the Go compiler. Would be curious if Go experts have more insight or other compiler recommendations.

Oh, the programs are supposed to take an integer from the command line? Then I wonder how many of them would fail when given an integer that's just a wee bit too large (like, say (2^129)-1).

> Seeing the visualization here really underscores how fast some languages are.

Yes and no.

It emphasizes that there are some scenarios where language choice can have an outsized effect on performance when running on modern architectures, which is a reminder some people could use or have never really witnessed.

But it's a very particular scenario that relatively few projects will encounter at a scale that meaningfully impacts them.

In particular, C and Rust are much better positioned to instruction pipelining and lack of cache busting because there are no conditionals and little-to-no out-of-loop code to execute. Even with a massive loop like this, that can be a real world scenario in things like data/signal processing and numerical computation. When you're doing those things, language choice can make a huge difference that may not be apparent without understanding how they work or at least seeing visualizations like this.

But even in C and Rust, most applications don't have to do this kind of thing. Most are dominated by smaller loops, with branching that breaks pipelining, complexity that busts cpu cache, calls and jumps that might interfere with both etc. In those much more common cases, the practical performance difference is going to be quite a lot less significant, and the fluency/ergonomics/safety/convenience of working in some other language can easily matter more.

Perhaps it's unrealistic in the sense that this is unrealistically-optimisable code.

Real-world code has closures, allocations, and pointer-dererencing. This code is just iterations, additions and modulus.

Nor does it pretend to be.

It's literally just "1 Billion nested loop iterations", methods and results.

You make of that whatever you want.

The other problem with it is that there are other variables involved besides pure speed, which is CONSISTENCY of speed.

Folks are always surprised to see just how fast Java is able to perform on benchmarks - it has a reputation as such a slow language then how come it's able to execute almost as fast as C++?

But Java's problem isn't execution performance. It's:

* Startup performance. It takes time to instantiate the JVM. That matters for some, not for others.

* Consistent performance. This is the nature of Garbage Collection. It can surprise you when it executes you and drop a performance blip when you least expect it.

Most developers who think they need the fastest performance actually need CONSISTENT performance more than the fastest.

Looks like they are just bouncing back and forth at relative speeds to each other; the speed of each ball is all that matters. I also found this diagram confusing at first.

If you are interested in looking into the details of microbenchmarks of this type, there is always https://benchmarksgame-team.pages.debian.net/benchmarksgame/... which has clearly defined methodology and allows to understand wall-clock time vs CPU cost too.

The benchmark code linked in the submission unfortunately suffers from the mistakes that happen whenever you write a benchmark for the first time. The visuals are pretty but might as well have been based on something more comprehensive.

(also, please stop measuring performance with loops that perform no work and fibonacci sequences, this was bad 30 years ago, this is bad today too)

Yeah, the random value prevents compile-time pre-calculation and the print makes sure the loops actually get run and values actually get calculated (as modern compilers are wont to simply omit code that clearly doesn't have consequence).

There are...a lot of PRs (and 4 as of this moment which add C#).

While it's not (necessarily) indicative of the languages as a whole, it looks pretty apples to apples to me.

These are very simple programs with no fancy tricks going on.

If you write the R code using vectorised operations it’s significant orders of magnitude faster (148 seconds to 1.5 milliseconds on posit.cloud).

The nested loop becomes: j <- sum((seq_len(100000) - 1) %% u) a <- a + j + r

I disagree w.r.t. python. You shouldn't need a numerical computing library to do a for loop generally.