HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
kostya
benchmarks
Makefile2014–2025
kostya / benchmarks

benchmarks

Some benchmarks of different languages

Testing & Quality
Explore on GitHubRead Hacker News discussions
62Distinct people
74Mentions
1Explicit recommenders
2.9KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Some benchmarks of different languages

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

I'm surprised you're able to get Turing to run faster, to be honest. I looked at Turing and was impressed by it, but in general my experience with MCMC libraries in Julia is…

wululiyu used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 9:02:44 AM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year74 dated mentions

Observed mentions: 2014-11-25 20:25:21 UTC to 2025-08-11 11:33:32 UTC.

0510152014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20142015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 15 mentions; 1 submissions, 14 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 8 mentions; 3 submissions, 5 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 13 mentions; 0 submissions, 13 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 8 mentions; 0 submissions, 8 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 9 mentions; 1 submissions, 8 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 7 mentions; 0 submissions, 7 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 3 mentions; 2 submissions, 1 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2025

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC101
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC15114
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC835
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC13013
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC404
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC808
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC918
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC707
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC303
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC202
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC321
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC101

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
Table of Content Overview Measurements Test Cases Brainfuck bench.b mandel.b Base64 Json Matmul Primes Tests Execution Environment Using Docker Manual Execution Prerequisites Contribution Makefile guide Binary executables Compiled artifacts Scripting language README update Docker image update Overview The benchmarks follow the criteria: They are written as the average software developer would write them, i.e. The algorithms are implemented as cited in public sources; The libraries are used as described in the tutorials, documentation and examples; The used data structures are idiomatic. The used algorithms are similar between the languages (as the reference implementations), variants are acceptable if the reference implementation exists. All final binaries are releases (optimized for performance if possible) as debug performance may vary too much depending on the compiler. My other benchmarks: jit-benchmarks, crystal-benchmarks-game, LangArena Measurements The measured values are: time spent for the benchmark execution (loading required data and code self-testing are not measured); memory consumption of the benchmark process, reported as base + increase, where base is the RSS before the benchmark and increase is the peak increase of the RSS during the benchmark; energy consumption of the CPU package during the benchmark: PP0 (cores) + PP1 (uncores like GPU) + DRAM. Currently, only Intel CPU are supported via the powercap interface. All values are presented as: median±median absolute deviation. UPDATE: 2026-07-19 Test Cases Brainfuck Testing brainfuck implementations using two code samples (bench.b and mandel.b). Supports two mode: Verbose (default). Prints the output immediately. Quiet (if QUIET environment variable is set). Accumulates the output using Fletcher-16 checksum, and prints it out after the benchmark. Brainfuck bench.b Language Time, s Memory, MiB Energy, J C# (Staged)/.NET Core 0.373±0.009 36.62±00.12 + 0.25±00.00 14.33±00.26 Scala (Staged) 0.409±0.011 229.62±03.27 + 7.00±01.44 26.31±00.71 Racket (Staged) 0.885±0.000 101.37±01.65 + 0.06±00.06 34.39±00.17 V/gcc 0.985±0.001 2.12±00.00 + 0.00±00.00 41.65±00.28 Rust 1.008±0.000 1.88±00.00 + 0.00±00.00 42.93±00.33 D/ldc2 1.078±0.001 3.12±00.00 + 0.00±00.00 45.78±00.24 C++/g++ 1.097±0.002 3.38±00.00 + 0.00±00.00 46.21±00.59 C/gcc 1.112±0.001 1.38±00.12 + 0.00±00.00 47.10±00.09 D/gdc 1.116±0.001 6.75±00.00 + 0.00±00.00 48.89±00.28 C/clang 1.136±0.000 1.44±00.06 + 0.00±00.00 48.52±00.33 C++/clang++ 1.167±0.002 2.88±00.00 + 0.00±00.00 48.87±00.76 Nim/gcc 1.171±0.001 2.00±00.00 + 0.00±00.00 48.80±00.70 Java 1.191±0.000 41.74±00.09 + 1.00±00.00 49.32±00.60 Vala/gcc 1.202±0.001 5.25±00.12 + 0.00±00.00 50.70±00.44 Kotlin/JVM 1.224±0.002 44.48±00.07 + 1.31±00.25 51.60±00.64 Vala/clang 1.235±0.000 5.19±00.06 + 0.00±00.00 52.40±00.39 Go 1.256±0.000 3.75±00.00 + 0.00±00.00 52.69±00.80 C#/.NET Core 1.280±0.001 36.88±00.06 + 0.00±00.00 54.29±00.22 Go/gccgo 1.287±0.000 23.50±00.38 + 0.00±00.00 54.23±00.16 Zig 1.327±0.000 1.38±00.12 + 0.00±00.00 55.13±00.40 Crystal 1.545±0.001 3.25±00.00 + 0.00±00.00 65.69±00.40 Julia 1.564±0.003 244.00±00.12 + 0.38±00.00 67.80±00.43 F#/.NET Core 1.566±0.002 41.88±00.07 + 0.12±00.00 65.15±00.12 Nim/clang 1.579±0.000 2.25±00.00 + 0.00±00.00 65.59±00.57 OCaml 1.607±0.002 3.25±00.00 + 2.62±00.00 75.45±00.78 MLton 1.737±0.006 1.62±00.00 + 0.38±00.00 74.87±00.28 Chez Scheme 1.758±0.005 25.88±00.29 + 3.25±00.00 74.43±00.21 Racket 1.761±0.013 112.86±00.03 + 0.50±00.38 72.49±02.28 V/clang 1.846±0.009 2.06±00.06 + 0.00±00.00 80.00±00.53 Scala 2.379±0.003 66.03±00.14 + 196.44±00.12 108.88±00.92 Node.js 2.954±0.060 49.57±00.06 + 5.78±00.12 126.35±03.17 D/dmd 3.010±0.001 3.50±00.00 + 0.00±00.00 113.43±01.11 Haskell (MArray) 3.497±0.001 4.00±00.00 + 4.00±00.00 144.74±00.32 Haskell (FP) 3.819±0.008 4.12±00.06 + 4.06±00.06 163.47±01.56 Ruby/truffleruby (JVM) 4.645±0.070 354.81±05.59 + 478.37±54.20 221.41±05.66 Ruby/truffleruby 5.169±0.461 197.19±00.69 + 693.00±117.12 252.03±23.51 Swift 5.497±0.001 17.00±00.12 + 0.00±00.00 205.09±04.14 Lua/luajit 5.686±0.024 2.50±00.00 + 0.00±00.00 235.32±01.30 Python/pypy 9.398±0.038 60.19±00.19 + 30.10±00.05 419.65±03.72 Idris 15.088±0.032 21.55±00.26 + 8.00±00.00 677.49±01.79 Elixir 20.456±0.025 90.88±00.30 + 0.00±00.00 814.83±07.69 Ruby (--jit) 30.807±0.033 21.88±00.13 + 4.62±00.00 1275.90±04.28 PHP 34.055±0.041 17.61±00.06 + 0.00±00.00 1447.00±15.80 Lua 37.051±0.168 2.62±00.00 + 0.00±00.00 1528.23±05.85 Ruby/jruby 38.543±0.745 255.48±00.77 + 70.31±00.25 1732.28±34.61 Python 61.009±0.870 11.38±00.00 + 0.00±00.00 2601.10±34.54 Ruby 74.107±0.332 12.12±00.06 + 0.00±00.00 3209.85±28.74 Tcl (FP) 189.615±0.465 4.62±00.00 + 0.00±00.00 8409.77±69.18 Perl 225.517±1.873 7.06±00.06 + 0.12±00.00 9777.03±135.29 Tcl (OOP) 373.095±1.341 4.62±00.00 + 0.00±00.00 16604.13±190.89 mandel.b Mandel in Brainfuck Language Time, s Memory, MiB Energy, J C# (Staged)/.NET Core 2.917±0.001 36.75±00.00 + 3.25±00.00 109.82±00.22 Scala (Staged) 7.118±0.079 228.10±04.74 + 71.23±06.06 356.09±07.48 C++/g++ 10.143±0.051 3.50±00.00 + 0.62±00.00 434.41±04.03 C/gcc 12.544±0.019 1.62±00.00 + 0.25±00.00 509.37±03.30 Vala/gcc 12.718±0.010 5.25±00.06 + 0.50±00.00 511.94±00.90 C++/clang++ 12.803±0.022 3.00±00.00 + 0.62±00.00 545.25±01.09 Zig 13.030±0.017 1.50±00.00 + 1.00±00.00 556.10±03.71 Java 13.041±0.020 41.77±00.15 + 1.94±00.06 537.41±01.88 C/clang 13.120±0.021 1.50±00.06 + 0.25±00.00 579.20±04.21 Kotlin/JVM 13.463±0.052 44.46±00.06 + 2.56±00.06 571.73±03.08 D/ldc2 14.340±0.012 3.06±00.06 + 0.75±00.00 591.01±03.53 Rust 14.460±0.021 1.94±00.06 + 0.25±00.00 577.37±02.52 Go 14.540±0.007 3.75±00.00 + 0.00±00.00 584.48±01.83 Vala/clang 14.802±0.012 5.12±00.00 + 0.50±00.00 595.99±01.53 Crystal 14.891±0.054 3.38±00.06 + 0.38±00.00 631.17±02.60 D/gdc 15.17
Read the full README on GitHub

What Hacker News says

15 sources
erickt·Oct 22, 2015
I wrote serde_json, and wrote the rust benchmark here a few months ago. Interestingly when I wrote this benchmark, I had my implementation as equivalent to RapidJSON on my Mac, but for some reason Kostya couldn't replicate it: Ohttps://github.com/kostya/benchmarks/pull/44 I'm guessing gcc just has some optimizations llvm doesn't. Rust does have some experimental SIMD, but I'm not using it yet because I want the serde libraries to be safe to use on byte streams, and reading 16 bytes ahead could block if at the end of a socket stream. Hopefully we will get specialization soon, which would let me use SIMD when I know I have at least X bytes in a buffer.
In Fastest JSON parser in the world is a D project?
grayrest·Oct 22, 2015
The JSON looks like this: {"coordinates": [ {"x": 0.65, "y": 0.23, "z": 0.91, "name": "fwgzd", "opts": {'1': [1, true]}, {"x": 0.45, "y": 0.78, "z": 0.22, "name": "alfsj", "opts": {'1': [1, true]}, ... ], "info": "some info"} The benchmark code [1] (very readable) is reading an array of structs containing x,y,z from 'coordinates'. [1] https://github.com/kostya/benchmarks/blob/master/json/test_f... I haven't read the code but the algorithm would look at this roughly like: See `{` process? yes See `"coordinates"` process? yes See `[` process? yes See `{` process? yes See `"x"` process? yes => new Coord, Coord.x = 0.65 See `"y"` process? yes => Coord.y = 0.23 See `"z"` process? yes => Coord.z = 0.91 See `"name"` process? no, next token is `"`, skip to `"` See `"opts"` process? no,
Read the rest
next token is `{`, skip to `}` The tradeoff is that he's completely ignoring the contents of `name` or `opts` or `info` and those values could potentially be invalid JSON but this processor doesn't care. The code is also picking up efficiencies from being a static C-like language. The "new Coord" isn't actually doing anything, the alloc happened for the array as a whole so the assignments just write a known size value to a known offset from the start of the array. He's also using SIMD instructions to process multiple bytes at a time and some other tricks but the skipping is the main difference. I think it's also interesting that the Rust code implemented value skipping in the benchmark file itself. The relative slowness there is likely that the library used (serde_json) is the JSON plugin for a generic serialization/deserialization lib and that Rust doesn't have a way to do SIMD yet.
In Fastest JSON parser in the world is a D project?
srean·Aug 14, 2015
If ML and C++ excites you, don't miss out on Felix. http://felix-Lang.org You will get more out of it if ML excites you more than C++, rather it is the possibility of talking to C++ with minimal or no glue that excites you. It wont be totally wrong to say that it is to C++ what F# is to C#, or perhaps little more accurately Scala to Java. It is plenty fast too. A toy brainfuck interpreter written in it turned out to be speedier than C++, D, Go, but got beaten by an interpreter written in nim. Can post the link once I get off the phone. EDIT: Here it is https://github.com/kostya/benchmarks/blob/master/README.md#b... Something I find interesting is that it has had fibres and coroutines long before go was a thing. The author(not me) used it in his projects on telco switches.
In Evil ML: ML to C++ template language
espadrine·Jun 6, 2015
In that case, what he missed was AOT optimization :) Many Lisps have had compilation to binaries. But having a binary doesn't imply being faster than an interpreted language. Theoretically, a JIT optimization can end up with faster code than an AOT optimizer can produce, thanks to runtime profiling. In fact, I'd be interested in seeing benchmarks, which Crystal is probably not ready to share, but may have conducted: https://github.com/manastech/crystal/blob/master/samples/fan... Edit: this[0] seems to indicate that the optimizations are in the same ballpark as Go and D, which is really impressive. [0]: https://github.com/kostya/benchmarks
In Crystal Language

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.