Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust is now overall faster than C in benchmarks

benchmarksgame-team.pages.debian.net

Post reply on HN
Print view View original

31–40 of 445 posts

Re: Rust is now overall faster than C in benchmarks

#31

Post by steveklabnik »

skohan wrote: post #24
zarkov99 wrote: post #14

Earlier quoted context omitted.

Why is that? There are cases where c++ is faster than C, a typical example is qsort vs std::sort.

How does c++ manage to win here? I'm not doubting, just curious

The classic example is quicksort. qsort takes a function pointer, but std::sort is a template. This means that the machinery can be inlined more often in C++ than C.

https://stackoverflow.com/questions/18002087/qsort-vs-stdsor...

Re: Rust is now overall faster than C in benchmarks

#32

Post by steveklabnik »

nynx wrote: post #29
steveklabnik wrote: post #25

Earlier quoted context omitted.

Rust does not take full advantage of it; that is, &T will still get noalias, it's &mut T that's currently disabled. The tracking bug is https://github.com/rust-lang/rust/issues/54878

Ah, my mistake. Thank you for the correction.

It's all good; most people don't draw the distinction. I myself didn't know that &T was also noalias for years.

Re: Rust is now overall faster than C in benchmarks

#33

Post by zarkov99 »

skohan wrote: post #24
zarkov99 wrote: post #14

Earlier quoted context omitted.

Why is that? There are cases where c++ is faster than C, a typical example is qsort vs std::sort.

How does c++ manage to win here? I'm not doubting, just curious

In he case of std::sort the C++ compiler can inline the comparison function when it generates the actual sort implementation from the std::sort template. In C the qsort implementation is fixed and must call the comparison via an indirect reference.

Re: Rust is now overall faster than C in benchmarks

#34

Post by tlb »

skohan wrote: post #24
zarkov99 wrote: post #14

Earlier quoted context omitted.

Why is that? There are cases where c++ is faster than C, a typical example is qsort vs std::sort.

How does c++ manage to win here? I'm not doubting, just curious

C++ can inline the comparison function (which is often just a few instructions) at compile time. It can also statically optimize for the stride, using shifts or addressing modes instead of multiplies. C can't do either with qsort, which takes the stride and comparison function pointer as arguments.

Re: Rust is now overall faster than C in benchmarks

#35

Post by pixel_fcker »

jolux wrote: post #11

I think benchmarking C vs C++ vs Rust must only really be useful for researchers. They’re all making a similar tradeoff for performance: forcing you to consider how you use memory. Does anyone work in a field where the performance difference between these specific three platforms matters? I’m genuinely curious. Edit: also, if you could explain briefly why and what makes particular choices out of the three unsuitable,…

Graphics software.

Re: Rust is now overall faster than C in benchmarks

#37

Post by coldtea »

yudlejoza wrote: post #8

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.

C++ makes certain intentions clear to the compiler in ways that C doesn't, which makes certain optimizations possible.

Re: Rust is now overall faster than C in benchmarks

#38

Post by 1vuio0pswjnm7 »

The reasons I use C versus comparable alternatives are not limited to speed. For example, the size of the compiler toolchain, the speed of compilation and the size of the resulting executables are all factors I have to consider. I do lots of work on systems with limited resources. How does Rust compare on those points versus, say, GCC.

https://dev.to/aakatev/executable-size-rust-go-c-and-c-1bna

Re: Rust is now overall faster than C in benchmarks

#39

Post by gpderetta »

zarkov99 wrote: post #33
skohan wrote: post #24

Earlier quoted context omitted.

How does c++ manage to win here? I'm not doubting, just curious

In he case of std::sort the C++ compiler can inline the comparison function when it generates the actual sort implementation from the std::sort template. In C the qsort implementation is fixed and must call the comparison via an indirect reference.

Technically libc couldhave an inline version of qsort in the header or the linker (even the dynamic linker) could do LTO, but bechmarks are done on actual implementations not the mythical sufficiently good compiler.

Re: Rust is now overall faster than C in benchmarks

#40

Post by steveklabnik »

1vuio0pswjnm7 wrote: post #38

The reasons I use C versus comparable alternatives are not limited to speed. For example, the size of the compiler toolchain, the speed of compilation and the size of the resulting executables are all factors I have to consider. I do lots of work on systems with limited resources. How does Rust compare on those points versus, say, GCC. https://dev.to/aakatev/executable-size-rust-go-c-and-c-1bna

I mean, you'll get drastically different numbers with all of those examples if you actually ask for options that produce small binaries. That the default flags don't try to make things small (across any of these toolchains) means this isn't really a fair comparison.

The smallest "hello world" binary rustc has ever produced was 137 bytes. https://github.com/tormol/tiny-rust-executable

Post reply on HN