Rust is now overall faster than C in benchmarks • Hacker News Board

Re: Rust is now overall faster than C in benchmarks

#371

Post by MaxBarraclough » Mon, Jan 04, 2021, 4:03 PM UTC

enedil wrote: post #362

tormeh wrote: post #353

Earlier quoted context omitted.

Not such a big deal in embedded, where the compiler and hardware is always the same, which means that the behavior is still predictable even if undefined

This is not true. Undefined behaviour can mean that ``` bool b; if (b) printf("1 "); if (!b) printf("2 "); ``` might print `1 2 `.

Right on. Unless the compiler documentation promises a consistent handling of the various triggers of undefined behaviour, it is under no obligation to always generate code that handles UB consistently.

To my knowledge there is no C compiler that promises to always handle all forms of UB consistently. The closest you could get would probably be something like Valgrind.

Re: Rust is now overall faster than C in benchmarks

#372

Post by Can_Not » Mon, Jan 04, 2021, 4:12 PM UTC

tutfbhuf wrote: post #196

Nodejs is incredible fast for a interpreted language. It is only ~4 times slower than Rust and only a bit slower than Go or Java (compiled GC languages) in the benchmarks. Compare that with Python 3, also interpreted but ~30 times slower than Rust. I know that Python 3 can do some runtime stuff that Nodejs can't, but I wonder whether that's worth so much performance. Maybe if the answer is that you would include C mo…

> I know that Python 3 can do some runtime stuff that Nodejs can't

Examples? This is too interesting to just throw in then hand wave away.

Re: Rust is now overall faster than C in benchmarks

#373

Post by BruceEel » Mon, Jan 04, 2021, 4:28 PM UTC

WalterBright wrote: post #261

Matthias247 wrote: post #93

Apart from those benchmark games a lot of real world C is a lot less performant than people think it might be. I spent a fair amount of time reviewing C code in the last 5 years - and things that pop up in nearly every review are costly string operations. Linear counts due to the use of null terminated strings and extra allocations for substrings to attach null terminators, or just deep copies because ownership can’t…

D uses slices for strings, which also gives D a big performance boost over C whenever strings are in play.

Walter, can you elaborate on this, are D's slices functionally equivalent to C++'s string_view? I.e. no copying as long no 'ASCIIZ-dependent' code is involved?

Re: Rust is now overall faster than C in benchmarks

#374

Post by bluecalm » Mon, Jan 04, 2021, 4:31 PM UTC

jacquesm wrote: post #366

bluecalm wrote: post #358

Earlier quoted context omitted.

Your claims contradict my experience. One example: C re-write of a popular chess engine Stockfish (written in C++) is significantly faster (10%-30% depending on who measures it at which time and on what hardware). This is a piece of code which was already heavily optimized for many years as speed is critical for the engine's performance. One guy (although very talented one) re-wrote it in C and got the speed gains. A…

Typically any rewrite of a piece of code will result in speed gains because you can take all of the knowledge that resulted in the previous version and use that in writing the next one. To properly discount for this you'd have to do two rewrites: one in the original language and one in the new one.

Well, that would be true if it was the same team doing the re-write and/or the original code was set in stone. Instead it was one guy. Stockfish is still heavily worked on and the developers have access to CFish code. The reason they are not porting performance improvements is exactly that it wouldn't be idiomatic C++ (even though the whole project uses only minimal set of C++ features). One of his explicitly stated goals was to explore possible optimization issues of C versus C++ compilers. That is to see how much typical even light C++ abstractions cost in comparison to more close to the metal style.

Re: Rust is now overall faster than C in benchmarks

#375

Post by aidenn0 » Mon, Jan 04, 2021, 4:52 PM UTC

moonchild wrote: post #118

spiffytech wrote: post #94

Earlier quoted context omitted.

That kind of tit-for-tat in benchmarks seems like it's counter to the goal of benchmarks: what kind of performance could I expect to see using technology $FOO? Crucially, that question depends on how someone will realistically implement $FOO. I like PyPy as an example: on the surface, implementing a Python runtime in Python and expecting performance gains seems crazy. PyPy manages to outperform CPython because althou…

> PyPy manages to outperform CPython because although a C implementation should theoretically be faster, realistically the increased expressiveness of Python lets the PyPy devs opt into optimizations the CPython devs find out of reach. Pypy outperforms cpython for the simple reason that pypy is a jit where cpython is a basic bytecode interpreter. Anything else is icing on the cake. The only reason python seems slow a…

Common Lisp (hereafter Lisp for concision) is differently dynamic, not strictly more dynamic.

One quick example: standard-class objects in Lisp are mostly more dynamic than python objects[1] but structure-class objects are quite static, and compilers will use this to their advantage.

On top of this, functions in python are in fact objects; in python you can do this just fine:

  def foo():
    foo.bar = 3

  def bar():
    print(foo.bar)

There are obviously other ways to accomplish this in lisp, but the fact that someone might do something like this can inhibit optimizations.

If you read the Lisp specification you will see dozens of places where they allow for opting out of dynamism in ways that help the compiler optimize. Type declarations are one and the fact that a function defined in a single file is considered to have a fixed definition for the scope of the file is another.

1: It's not quite as easy to add new slots to Lisp standard-class instances on the fly as it is to python class instances, but it's doable, and Lisp, of course, supports class redefinition in a way that few other languages (including Python) do.

Re: Rust is now overall faster than C in benchmarks

#376

Post by jacquesm » Mon, Jan 04, 2021, 4:56 PM UTC

pjmlp wrote: post #369

jacquesm wrote: post #364

Earlier quoted context omitted.

That's not the history as I'm familiar with it. What I read - and remember, which may be faulty - is that the first attempt to write Unix failed because what they wanted to achieve was too complex to implement easily. Adding structs to C allowed them to overcome this bottleneck and led to the first production versions of C.

Here is a refresher, with some key quotes. http://cm.bell-labs.co/who/dmr/chist.html > Thompson was faced with a hardware environment cramped and spartan even for the time: the DEC PDP-7 on which he started in 1968 was a machine with 8K 18-bit words of memory and no software useful to him. While wanting to use a higher-level language, he wrote the original Unix system in PDP-7 assembler. At the start, he did not even…

> " (Thompson had made a brief attempt to produce a system coded in an early version of C—before structures—in 1972, but gave up the effort.)"

Yes, but that is the key bit right, the fact that C didn't have structures yet is what caused the effort to be aborted, and once those were added they succeeded.

Re: Rust is now overall faster than C in benchmarks

#377

Post by Leherenn » Mon, Jan 04, 2021, 4:56 PM UTC

Skunkleton wrote: post #285

blackrock wrote: post #228

Earlier quoted context omitted.

Fascinating. I would’ve thought most commercial C programs would have heavily used linked lists, hashes (dictionary), and binary search trees all over the place. I assume most C++ programs heavily use more of these advanced data structures, correct?

> I would’ve thought most commercial C programs would have heavily used linked lists, hashes (dictionary), and binary search trees all over the place. Every large scale C code base I have worked on has had these things, and they were used as you say all over the place. If I were to encounter a code base that didn't have these things I would wonder why it was written in C in the first place.

Conversely, I have only seen arrays being used, and never linked lists/hash maps in the few embedded code bases I have worked on.

Re: Rust is now overall faster than C in benchmarks

#378

Post by scottlamb » Mon, Jan 04, 2021, 5:11 PM UTC

pbadenski wrote: post #329

scottlamb wrote: post #220

Earlier quoted context omitted.

Conversely, more sophisticated algorithms, and particularly monomorphization, may bloat the code size, causing icache, L2/L3 cache, and TLB misses. (Also slows compilation.) I think this is under-appreciated because it doesn't show in microbenchmarks. (I wish I knew of an easy way to measure how much cache pressure you're causing from a microbenchmark.) I suspect for this reason it'd be better in Rust to use a Go-lik…

Thank you for mentioning monomorphization - I wasn't aware of this concept. Would you maybe if there's any source discussing how this is solved in different languages and performance consequences of it?

I'm not aware of a high-quality source discussing this. I'd be interested in seeing one. Off the top of my head:

* In many languages, monomorphization is impractical. Eg, in C it requires macros or external code generators. Java and Go don't even have macros. So it's rarely done. Instead, stuff uses type erasure, dynamic dispatch, more heap allocations, and tables like the ones described in that dave.cheney.net link. Maybe some JITs or even some ahead-of-time compilers do monomorphization internally in some cases, but I'm speculating rather than speaking from knowledge.

* In C++ and Rust, monomorphization is easy. You don't have to do it, but it's easy, so many people do. The containers in the standard library are monomorphized. This code can perform very well in any particular case, but in aggregate it's large enough that I have doubts about whether it's always worth it for the whole program.

Re: Rust is now overall faster than C in benchmarks

#379

Post by tutfbhuf » Mon, Jan 04, 2021, 5:12 PM UTC

Can_Not wrote: post #372

tutfbhuf wrote: post #196

Nodejs is incredible fast for a interpreted language. It is only ~4 times slower than Rust and only a bit slower than Go or Java (compiled GC languages) in the benchmarks. Compare that with Python 3, also interpreted but ~30 times slower than Rust. I know that Python 3 can do some runtime stuff that Nodejs can't, but I wonder whether that's worth so much performance. Maybe if the answer is that you would include C mo…

> I know that Python 3 can do some runtime stuff that Nodejs can't Examples? This is too interesting to just throw in then hand wave away.

Honestly, I don't know. I think I read it somewhere, as explanation for why python is so slow. It made sense to me, that it must be language features. I hope there's someone on HN who can explain it.

Re: Rust is now overall faster than C in benchmarks

#380

Post by pjmlp » Mon, Jan 04, 2021, 5:42 PM UTC

jacquesm wrote: post #376

pjmlp wrote: post #369

Earlier quoted context omitted.

Here is a refresher, with some key quotes. http://cm.bell-labs.co/who/dmr/chist.html > Thompson was faced with a hardware environment cramped and spartan even for the time: the DEC PDP-7 on which he started in 1968 was a machine with 8K 18-bit words of memory and no software useful to him. While wanting to use a higher-level language, he wrote the original Unix system in PDP-7 assembler. At the start, he did not even…

> " (Thompson had made a brief attempt to produce a system coded in an early version of C—before structures—in 1972, but gave up the effort.)" Yes, but that is the key bit right, the fact that C didn't have structures yet is what caused the effort to be aborted, and once those were added they succeeded.

Except my point was

> Original C was created after UNIX already existed, used for UNIX's first rewrite and until UNIX source code left Bell Labs, it only worked on PDP-11 computers.

Regardless of failed porting effort, the original UNIX, implemented in Assembly and running on the PDP-7, was already being used by a small community.