Live data from Hacker News

Rust is now overall faster than C in benchmarks

benchmarksgame-team.pages.debian.net

361–370 of 445 posts

Re: Rust is now overall faster than C in benchmarks

#361

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…

> 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.

Do not tie computational operations on string operations in C.

Pick one of many string manipulation libraries to do any serious work with them.

Re: Rust is now overall faster than C in benchmarks

#362
post #353

Earlier quoted context omitted.

And even MISRA C isn't enough to assure the absence of undefined behaviour. C is a tricky beast to tame.

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 `.

Re: Rust is now overall faster than C in benchmarks

#363
post #337

Earlier quoted context omitted.

Lots of people argue that Rust improves correctness by way of sum types (including no implicit nil/null), affine types (addressing data races and so on), and (compared to Go) generics. I completely buy this argument.

Those data races are only addressed for in-memory accesses across threads. If you are accessing data via some mechanism of IPC across processes, e.g. database access to same data rows without proper transactions, accessing shared files without locks, GPU memory data,.., affine types won't save you.

Yes, that is correct.

Re: Rust is now overall faster than C in benchmarks

#364
post #301

Earlier quoted context omitted.

> All high level languages are portable, including some older than C. Theoretically portable, maybe. But C is actually portable in practice - you can compile C code for the vast majority of CPUs and OSs.

Yeah, but isn't due to the language, rather to the amount of people that have spent money and resources to implement compilers for all those CPUs and OSs. 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.

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.

Re: Rust is now overall faster than C in benchmarks

#365

Earlier quoted context omitted.

> null terminated strings feel like idiomatic C to most people Doesn't that mean that null terminated strings is idiomatic C? That is, my understanding of the term idiomatic is that it is defined by whatever is most natural to users of a language regardless of whether it is the most performant.

One of my long standing complaints about modern programming is how rarely people read code. We don't encourage it in school, and in the workplace most people only read code written by their coworkers. It would be the equivalent of teaching people to write books without encouraging them to read anything. To break myself of the habit I started reading some well regarded programs for fun. And oh boy, have I learned a lo…

They're somewhat old now, but I'd recommend checking out The Architecture of Open Source Applications series of books.

https://aosabook.org/en/index.html

Re: Rust is now overall faster than C in benchmarks

#366
post #300

Earlier quoted context omitted.

When a Rust program is faster than the matching C program, it is utterly nonsensical to attribute its speed to C. It is gratifying to see C++ identified, here, as the hands-down fastest implementation language, but odd to see Rust performance still compared, in the headline, to C, as if that were the goal. The headline should say that Rust speed is approaching C++ speed. In principle, Rust speed should someday exceed…

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.

Re: Rust is now overall faster than C in benchmarks

#367

Wondering around the site I found this particular benchmark interesting https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Why is julia using 250x the memory? (and it`s still fast)

It's including compilation time and memory too, which I would consider a major flaw in the benchmarks game. If I wrap things in a function and run it a second time in the repl, this is what I get: $ JULIA_LLVM_ARGS="-unroll-threshold=500" ~/julia-b00e9f0bac/bin/julia -O3 --check-bounds=no julia> include("nbody.jl") run (generic function with 1 method) julia> @time run(50000000) -0.169075164 -0.169059907 2.044478 seco…

Julia is not allowed to use its compiler (PackageCompiler.jl) but Rust and C are. It's really silly and imposed by the author of the benchmarks for no clear reason.

Re: Rust is now overall faster than C in benchmarks

#369
post #301

Earlier quoted context omitted.

Yeah, but isn't due to the language, rather to the amount of people that have spent money and resources to implement compilers for all those CPUs and OSs. 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.

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 program on the PDP-7 itself, but instead used a set of macros for the GEMAP assembler on a GE-635 machine. A postprocessor generated a paper tape readable by the PDP-7.

> Although we entertained occasional thoughts about implementing one of the major languages of the time like Fortran, PL/I, or Algol 68, such a project seemed hopelessly large for our resources: much simpler and smaller tools were called for. All these languages influenced our work, but it was more fun to do things on our own.

> By 1970, the Unix project had shown enough promise that we were able to acquire the new DEC PDP-11. The processor was among the first of its line delivered by DEC, and three months passed before its disk arrived. Making B programs run on it using the threaded technique required only writing the code fragments for the operators, and a simple assembler which I coded in B; soon, dc became the first interesting program to be tested, before any operating system, on our PDP-11. Almost as rapidly, still waiting for the disk, Thompson recoded the Unix kernel and some basic commands in PDP-11 assembly language. Of the 24K bytes of memory on the machine, the earliest PDP-11 Unix system used 12K bytes for the operating system, a tiny space for user programs, and the remainder as a RAM disk. This version was only for testing, not for real work; the machine marked time by enumerating closed knight's tours on chess boards of various sizes. Once its disk appeared, we quickly migrated to it after transliterating assembly-language commands to the PDP-11 dialect, and porting those already in B.

> By 1971, our miniature computer center was beginning to have users. We all wanted to create interesting software more easily. Using assembler was dreary enough that B, despite its performance problems, had been supplemented by a small library of useful service routines and was being used for more and more new programs. Among the more notable results of this period was Steve Johnson's first version of the yacc parser-generator [Johnson 79a].

> By early 1973, the essentials of modern C were complete. The language and compiler were strong enough to permit us to rewrite the Unix kernel for the PDP-11 in C during the summer of that year. (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.)

What failed was the initial port attempt to C, not UNIX running on PDP-7.

While I am quite critic of C, I take the effort to learn and criticise properly, because regardless of my opinion it isn't going away on my lifetime and bills need to be paid.

Re: Rust is now overall faster than C in benchmarks

#370

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…

> real world C is a lot less performant than people think it might be What is meant here? Fast? Reliable? Secure? Memory efficient? Power efficient? Easy to write? Easy to maintain? Quick to compile? Easy to debug? I have no illusions about the reliability/security/correctness of real-world C code, especially since it's usually not compiled with a memory-safe compiler or run with memory-safe libraries and runtime env…

I assume, since the submissions says is talking about something "faster in benchmarks", that he means "fast".
Post reply on HN