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

Re: Rust is now overall faster than C in benchmarks

#111

Post by hashingroll » Sun, Jan 03, 2021, 9:12 PM UTC

pjscott wrote: post #88

alerighi wrote: post #51

Earlier quoted context omitted.

Well you are saying that even in C you can use the restrict keyword to tell the compiler that 2 memory locations can overlap. Of course is in the hand of the programmer to tell the compiler to do so. I don't think there is a fair comparison between Rust and C: C is just an higher level assembler, if the programmer knows what he's doing he can use the hardware 100% of its potential. That is the reason why C is still u…

> Well you are saying that even in C you can use the restrict keyword to tell the compiler that 2 memory locations can overlap. Of course is in the hand of the programmer to tell the compiler to do so. It says that they can't overlap, but yes, you can get the compiler to optimize based on this if you provide the aliasing information and remember to keep it accurate. You probably won't do that, though, for anything ex…

> but most people probably won't bother.

Most people who don't bother with that probably also don't bother with the performance of their hashmap.

Re: Rust is now overall faster than C in benchmarks

#112

Post by jart » Sun, Jan 03, 2021, 9:13 PM UTC

Gibbon1 wrote: post #82

vvanders wrote: post #60

Earlier quoted context omitted.

Have you ever used restrict in anger? I've done it when we really needed that performance for an inner loop(particle system). It can be a real bastard to keep the non-alias constraint held constant in a large, multi-person codebase and the error cases are really gnarly to chase down. Compare that to Rust which has this knowledge built in since it naturally falls out of the ownership model.

I agree with that, no aliasing in C is an ugly kludge that bitches about perfectly fine code that benefit benefit from it. And it's hard insure that it actually works in code that does. Worse the failure is completely silent.

Is there something special about the noalias keyword that it really brings out the most unprofessional pig language in developers? https://www.lysator.liu.se/c/dmr-on-noalias.html

Re: Rust is now overall faster than C in benchmarks

#113

Post by zucker42 » Sun, Jan 03, 2021, 9:13 PM UTC

pornel wrote: post #75

stabbles wrote: post #53

Earlier quoted context omitted.

I doubt there's any performance to be gained that way, but if so, the C implementation can just use `restrict` to the same effect.

Rust's problem with aliasing in LLVM is caused exactly by limited usefulness of C's restrict. LLVM implements only coarse per-function aliasing information needed by C, and doesn't properly preserve fine-grained aliasing information that Rust can provide.

I thought the problem was there is simply a bug in the implementation because restrict isn't used frequently enough to have exposed the bug earlier.

Re: Rust is now overall faster than C in benchmarks

#114

Post by awestroke » Sun, Jan 03, 2021, 9:15 PM UTC

FartyMcFarter wrote: post #55

nynx wrote: post #9

The fastest n-body program is written in very idiomatic rust. https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

n-body in C compiled by clang runs just as fast as Rust apparently: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

The code for the C-Clang version is terrifying, compared to the Rust version. Which one would you rather maintain?

Re: Rust is now overall faster than C in benchmarks

#115

Post by sli » Sun, Jan 03, 2021, 9:15 PM UTC

gameswithgo wrote: post #107

vitus wrote: post #98

Earlier quoted context omitted.

You raise a good point. I've always been fascinating by PyPy's performance, personally -- anecdotally, I've achieved ~10x speedups from just running a script with `pypy` instead of `python`. I always attributed that to better performance of the JIT, but I could be wrong. I have nothing against Rust personally, but it's ultimately not an apples-to-apples comparison if they're not implementing the same algorithm, or ev…

comparing apples to apples is pointless, they are both apples. and you can always compare “equivalent” algorithms as some languages may not be able to efficiently express the same algorithm as another. i know what you are after, but trying to have some benchmark that is “fair” according to some spec that is important to your needs will just be seen as pointless to others. benchmark game at least lets us see what the…

I admit I'm destroying the metaphor here but there are a lot of useful comparisons to be made between different cultivars of apple and those comparisons have implications on their applications.

Re: Rust is now overall faster than C in benchmarks

#116

Post by ryanianian » Sun, Jan 03, 2021, 9:16 PM UTC

mh7 wrote: post #104

martincmartin wrote: post #96

Earlier quoted context omitted.

Also lack of generics can make it slow, e.g. qsort() requires a function call for each comparison. So C++'s std::sort() can be significantly faster on an array of integers.

It's more to do with the fact that std::sort's definition is visible to the compiler and qsort() is not. Put qsort() code in stdlib.h, make it static and write a static intcmp() and you'll see the compiler inline that no problem.

Sure you can hard-code intcmp into qsort but then it would only work for arrays of ints.

You could do some macro magic instead of templates e.g. `DEFINE_QSORT(int, intcmp)` which could stamp out `qsort_int` but that's not a part of the stdlib.

C++ arguably gets this right since sort and sort will be separate functions, although templates are of course a footgun. And of course duping the logic for std::sort for a bunch of different T impls increases the binary size.

Re: Rust is now overall faster than C in benchmarks

#117

Post by jcranmer » Sun, Jan 03, 2021, 9:16 PM UTC

pornel wrote: post #75

stabbles wrote: post #53

Earlier quoted context omitted.

I doubt there's any performance to be gained that way, but if so, the C implementation can just use `restrict` to the same effect.

Rust's problem with aliasing in LLVM is caused exactly by limited usefulness of C's restrict. LLVM implements only coarse per-function aliasing information needed by C, and doesn't properly preserve fine-grained aliasing information that Rust can provide.

Note that Rust's issue was that LLVM is buggy with restrict (because it isn't exercised frequently).

That said, there is a series of patches in-flight to get actual working full restrict support: https://reviews.llvm.org/D69542

Re: Rust is now overall faster than C in benchmarks

#118

Post by moonchild » Sun, Jan 03, 2021, 9:17 PM UTC

spiffytech wrote: post #94

vitus wrote: post #76

Earlier quoted context omitted.

I recall an anecdote about how Haskell actually outperformed C on various tree benchmarks because it was using a better implementation. At some point, the C programmers got fed up with the airs of superiority from Haskell programmers, ported the Haskell implementation, and reclaimed their position. I wouldn't be surprised if there's something similar happening here.

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 as an implementation language is because it was traditionally slow; the reason it was traditionally slow is that cpython, the only major implementation, is slow. Common lisp, for instance, is similarly dynamic (moreso, in fact), also is also generally natively compiled by itself, and is quite performant.

Re: Rust is now overall faster than C in benchmarks

#119

Post by nindalf » Sun, Jan 03, 2021, 9:18 PM UTC

Animats wrote: post #97

Two charts with different languages. Unclear what is being measured. Is this a humor article?

This site has a page where they explain what they're doing - https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Basically, it's toy programs written in each of these languages. They measure how fast each one is executed. This methodology does have it's limitations, which that page is upfront about.

Re: Rust is now overall faster than C in benchmarks

#120

Post by qart » Sun, Jan 03, 2021, 9:18 PM UTC

FartyMcFarter wrote: post #64

Looking at the reverse-complement code, it appears that the Rust and C implementations are using different algorithms: https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://benchmarksgame-team.pages.debian.net/benchmarksgame/... On a quick inspection: - The Rust code is about twice as long. - The Rust code has CPU feature detection and SSE intrinsics, while the C code is more idiomatic. - The lookup…

I have seen this happening so often: C/C++/Rust often end up using CPU-specific features, and the code starts looking more and more like assembly code, and less like idiomatic high-level language code. Basically, comparisons of programs written in all the other languages against these three become meaningless. And in turn, hurts benchmarksgame as a resource for comparing languages.

If I had to write a performant library at work, I too might rely on CPU-specific assembly wrappers in my code. But IMO, such code has no place in a general-purpose cross-language benchmark site.