Live data from Hacker News

Rust is now overall faster than C in benchmarks

benchmarksgame-team.pages.debian.net

441–445 of 445 posts

Re: Rust is now overall faster than C in benchmarks

#441

Is it just me or has that 'benchmarks game' site been growing less navigable over time? It use to be easy to compare benchmarks across several languages. If that capability still exists somewhere it's buried and I'm not interested in puzzling it out. There are no side bars or menus or anything helpful.

1) The parent post linked to charts which "compare benchmarks across several languages".

2) The home page (click the banner) has links which compare benchmarks across two language implementations.

3) Each of those comparison pages has links which compare all the programs, for all the language implementations, for each benchmark.

Re: Rust is now overall faster than C in benchmarks

#443

Earlier quoted context omitted.

> I have no idea whether that matters or even easy to measure... It is reasonably easy to measure, and the GP is about right. I've measured a crossover point of around a few hundred items too. (Though I'm sure it'll vary depending on use case and whatnot.) I made a rope data structure a few years ago in C. Its a fancy string data structure which supports inserts and deletes of characters at arbitrary offsets. (Design…

Thank you, I tried the rope, and I ran a benchmark that creates a rope of length 1G by repeatedly inserting 1023 bytes at random positions. Some notes: When I changed the hardcoded node size from 136 to 1024 bytes, time went down from 3.6 secs to 2.6 secs on my laptop. It kind of plateaued at 1024 bytes. I didn't do more extensive testing. What's the rationale for the choice of 136? A cache line is usually 64, so the…

Oh interesting! What CPU was that on? 136 the optimal number I found benchmarking on an old intel based laptop I was using a few years ago. I wonder if modern CPUs (with much larger caches) have changed the ideal array size.

Re: Rust is now overall faster than C in benchmarks

#444

Earlier quoted context omitted.

Thank you, I tried the rope, and I ran a benchmark that creates a rope of length 1G by repeatedly inserting 1023 bytes at random positions. Some notes: When I changed the hardcoded node size from 136 to 1024 bytes, time went down from 3.6 secs to 2.6 secs on my laptop. It kind of plateaued at 1024 bytes. I didn't do more extensive testing. What's the rationale for the choice of 136? A cache line is usually 64, so the…

Oh interesting! What CPU was that on? 136 the optimal number I found benchmarking on an old intel based laptop I was using a few years ago. I wonder if modern CPUs (with much larger caches) have changed the ideal array size.

This was on a Sandybridge Laptop from 2011: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz. If I read right, it has 256KB and 3MB L1 and L2 caches

Re: Rust is now overall faster than C in benchmarks

#445
post #130

When Rust is faster than C in a benchmark in which C++ is also faster than C, I know I can safely ignore such benchmark.

> I know I can safely ignore such benchmark And yet, rather than ignoring it, you are commenting on it, with a pithy retort which dismisses the entire benchmark without actually providing any additional insight. Programming languages, compilers, library ecosystems, the groups of people who decide to sit down and try to produce a better result for a given language, and the benchmark maintainers who decide what submiss…

> … C, C++, and Rust; languages which allow for performance without compromise…

> … designed with an eye towards performance, but still have some amount of overhead…

Here's a rough count of the programs contributed to the benchmarks game since April 2018.

Does this information moderate your opinion?

Julia 48

Rust 35

F# 23

C# 22

Go 22

Node 19

C++ 16

Haskell 15

Pascal 14

Chapel 11

Swift 10

Lisp 9

Python 9

Dart 7

OCaml 6

C 5

Fortran 5

Erlang 4

Java 4

TypeScript 4

Lua 2

Perl 2

Racket 2

Ruby 2

Ada 1

PHP 1

Post reply on HN