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

Re: Rust is now overall faster than C in benchmarks

#181

Post by roca » Sun, Jan 03, 2021, 10:49 PM UTC

jerf wrote: post #125

nindalf wrote: post #110

Earlier quoted context omitted.

How often does benchmark code have a function that takes two pointers that could potentially alias each other? If it's as rare as I think it is, it might not have that much of an impact on Rust's position in the benchmarks game. Still, real world performance will probably benefit from this fix so it's a positive change regardless.

I've been fairly convinced for a while that once Rust matures (which is probably fairly close to "now", but I've held this opinion for years) that it's going to have a performance advantage in real code that's going to be hard to capture in benchmarks, because it's easy in a small benchmark to be very careful and ensure that you don't have aliasing, avoid extra copies, etc. Where I expect Rust to really shine perform…

I agree that the aliasing control and other features of Rust enable all kinds of interesting optimizations that currently aren't being done, and 'restrict' is only part of it. For example we also know that the data behind a shared reference is really immutable (apart from UnsafeCell etc).

Unfortunately we may need an entirely new generation of compiler infrastructure to exploit these opportunities because LLVM is really a C/C++ compiler at heart and may not be happy about taking big changes that can't benefit C/C++.

Re: Rust is now overall faster than C in benchmarks

#182

Post by cygx » Sun, Jan 03, 2021, 10:50 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…

realistically the increased expressiveness of Python lets the PyPy devs opt into optimizations the CPython devs find out of reach

Not really: It's the compilation strategy (that whole meta-tracing JIT compiler thing, compared to a simple bytecode interpreter) that makes the difference, not the surface syntax of the implementation language - which is actually not 'real' Python, but a restricted, less dynamic subset known as RPython.

Also note that the CPython is deliberately kept 'dumb'.

Re: Rust is now overall faster than C in benchmarks

#183

Post by gameswithgo » Sun, Jan 03, 2021, 10:51 PM UTC

zeroimpl wrote: post #156

sli wrote: post #115

Earlier quoted context omitted.

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.

That's the whole point of the metaphor - comparing apples to apples is good, apples to oranges is bad.

and its a bad metaphor. there are many reasonable comparisons to be made between any two things even when both are not fruits

Re: Rust is now overall faster than C in benchmarks

#184

Post by gameswithgo » Sun, Jan 03, 2021, 10:52 PM UTC

vitus wrote: post #122

gameswithgo wrote: post #107

Earlier quoted context omitted.

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…

> Nobody really thinks Rust is faster than C now. The submission title would beg to differ. (I know, it explicitly calls out "benchmarks" as the context.) I think languages like Rust or Swift have significant advantages around safety over C/C++, while not sacrificing much in terms of performance. But if one language's benchmark contributors are willing to put in more effort than another's to eke out additional perfor…

go fix the c implementation then.

no single person can maintain optimally implemented solutions over dozens of languages. its up to we the people to help out. you want perfectly equivalent comparisons, make it happen

Re: Rust is now overall faster than C in benchmarks

#185

Post by Hello71 » Sun, Jan 03, 2021, 10:53 PM UTC

bsder wrote: post #157

jart wrote: post #123

Earlier quoted context omitted.

Not for char. Compiler always assumes non-restrict for char pointers and arrays, which is important to remember if you're ever operating on a RGB or YCbCr matrix or something.

Huh. Does that also hold for a "uint8_t"--which is often just a renamed unsigned char rather than being a genuine type of its own?

not according to the standard, but in practice yes, currently. there are arguments that it should be considered not for optimization reasons, but there is likely too much existing code relying on it to change behavior. (see related llvm, gcc bugs)

Re: Rust is now overall faster than C in benchmarks

#186

Post by mkl » Sun, Jan 03, 2021, 10:56 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…

> That kind of tit-for-tat in benchmarks seems like it's counter to the goal of benchmarks

Yep. There are good reasons why this set of benchmarks is called The Computer Language Benchmarks Game.

Re: Rust is now overall faster than C in benchmarks

#187

Post by gameswithgo » Sun, Jan 03, 2021, 10:57 PM UTC

FartyMcFarter wrote: post #142

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.

> I wouldn't be surprised if there's something similar happening here. In this case it seems like benchmark code is allowed to use intrinsics, which can degenerate into a situation where a benchmark in language X is more "glorified x86 Assembly code" than actual code in language X. This is not very useful for comparing languages IMO. Especially since all of Rust, C, C++ can use this strategy and become almost identic…

So three languages with identical performance ceilings end up with essentially identical performance results. sounds like a job well done.

if you want to know something more than that, like how performance tends to end up after inputs of identical effort and talent you will need to recruit a lot of people and money to run really large scale experiments and when you are done people on HN will just endlessly find nits to pick with your results whenever they don’t agree with their preconceived notions

Re: Rust is now overall faster than C in benchmarks

#188

Post by slaymaker1907 » Sun, Jan 03, 2021, 10:57 PM UTC

cma wrote: post #121

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.

When people use the unsafe keyword are they always taking into account aliasing? At least you can audit only those places though.

Rust takes const with pointers very seriously. It is undefined behavior to mutate anything non-mut (pointer or reference) unless it is through an UnsafeCell. While you can break compiler guarantees through pointers in Rust, dereferencing this pointers must still obey the above guarantee (basically think of it as you need to go back to references to actually use the aliased pointers which would be undefined due to the aliasing).

Therefore, the optimizer can always assume mutations don't alias. Even UnsafeCell isn't allowed to break the alias rules, it just provides flexibility going from immutable to mutable.

Re: Rust is now overall faster than C in benchmarks

#189

Post by loeg » Sun, Jan 03, 2021, 10:58 PM UTC

nindalf wrote: post #110

Svetlitski wrote: post #49

Once LLVM fixes some bugs with `noalias`, at which point Rust will begin using it again in more circumstances [1], I'd expect to see Rust get even faster in these benchmarks, given that the Rust compiler knows much more about which pointers do/do-not alias than most other programming languages [2] and the myriad optimizations this knowledge allows. [1] https://github.com/rust-lang/rust/issues/54878#issuecomment-... […

How often does benchmark code have a function that takes two pointers that could potentially alias each other? If it's as rare as I think it is, it might not have that much of an impact on Rust's position in the benchmarks game. Still, real world performance will probably benefit from this fix so it's a positive change regardless.

Benchmark hackers can just sprinkle `restrict` all over the place, too. Real world C code doesn't get restrict by default and often isn't fully annotated, so the benchmarks may artificially hide the real-world difference.

Re: Rust is now overall faster than C in benchmarks

#190

Post by michaelmior » Sun, Jan 03, 2021, 11:00 PM UTC

akkartik wrote: post #177

michaelmior wrote: post #162

Earlier quoted context omitted.

True. I was skipping over that, but the fact that functions manipulating null terminated strings are part of the standard library is certainly a reason in itself to consider them idiomatic.

They're agreeing with you.

Yes, I understand :)