6 ms·

> Its hard to beat C++ when it comes to performance (while still having high level abstractions). Re: performance, Rust's doing pretty well (on a bunch of arbi

> Its hard to beat C++ when it comes to performance (while still having high level abstractions). Re: performance, Rust's doing pretty well (on a bunch of arbitrary microbenchmarks): https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=rust&lang2=gpp https://benchmarksgame.alioth.debian.org/u64q/compare.php?la... Re: high level abstractions, Rust doesn't have many of the template shenanigans C++ does (but that's a good thing, IMHO). However Rust does have a phenomenal type system for a language with such predictable and solid performance. And it has many wonderful high-level abstractions (exhaustive pattern matching on algebraic data types, iterator syntax for collections, many functional idioms, an AST-based macro system, etc.). > If something is going to kill C++, its probably a language that scales very well to multicore. Rust has fantastic concurrency, and the libraries for it are still in relative infancy. The type system keeps un-synchronized shared mutable state from happening (unless you intentionally turn off certain checks using unsafe code, IIRC). There are freely available libraries for lock-free data structures and stack-scoped threads. As an aside, it's also really easy to use those libraries without having to vendor some random header files that may or may not conform to your coding style. > Maybe a functional language. I be happy if that happened as that would be a revolutionary breakthrough. Rust also has some pretty cool functional syntax, although I'm not an expert on functional programming, I've been enjoying it quite a bit. > About the aliasing problem. I'm not sure how it could detect that either. Not sure how C++ intends to do it, but Rust does it with a strict ownership system that is fully enforced at compile time.

petke 11y ago
Yeah lets see how it plays out. I might have a look at rust at some point. On the benchmark though, its doesn't seem quite fair. At least that first one is comparing a single threaded c++ program, to a multi threaded rust program. And for the regex example the author doesn't use C++ std::regex and std::futures (std::async) like he does for Rust. It makes me think a proper C++ implementation would do much better. (Personally I use the Parallel Patterns Library. I like it a lot. We will get something similar in C++ in a few years) I don't know much about rust. It worries me though the examples are still using threads and mutexes. I think we need much higher level abstraction (like ppl::task, coroutines, etc) to get better scaling. Also lock free data structures dont scale that well either. As they still require synchronization and that hurts scaling). I think we need some kind of revolution in how we code to scale our programs to hundreds of cores.
- steveklabnik 11y ago
  Rust's ownership system makes shared memory much more safe than you'd expect. And you can also use shared-nothing approaches if you prefer those.
- dikaiosune 11y ago
  It is worth noting that the implementations for those benchmarks are contributed by a community, not all written by the same person (IIRC), so if someone is interested in using a language to the best of its hypothetical performance ceiling, they can definitely submit a solution. I'm not sure about the details for the "fasta" benchmark, but I know it's at least partly I/O bound, and many implementations for the benchmark are single-threaded: https://benchmarksgame.alioth.debian.org/u64q/performance.php?test=fasta https://benchmarksgame.alioth.debian.org/u64q/performance.ph... Notably, Rust also edges out a multi-threaded C implementation for that one. I'm sure they've done some very hairy optimizations to get to the top on that board, but it's cool to see that it's possible. On the subject of regexes, I am not familiar with the C++ std::regex implementation, but it does look like (some rather slow) C++ implementations are using a boost regex library. Those are generally fairly "standard" in C++, right?
  - petke 11y ago
    I cant be sure about Rust, but C++ should at least be as fast as C for any fair benchmark. About the regex example. https://benchmarksgame.alioth.debian.org/u64q/program.php?test=regexdna&lang=gpp&id=2 https://benchmarksgame.alioth.debian.org/u64q/program.php?te... The boost regex library is fast and widely used. It doesnt look like the example is using it though, but a library called "re2". Never heard of it before. Googling turned up this https://github.com/google/re2 https://github.com/google/re2
    - dikaiosune 11y ago
      Re: regex, I was referring to some of the other C++ implementations: https://benchmarksgame.alioth.debian.org/u64q/program.php?test=regexdna&lang=gpp&id=4 https://benchmarksgame.alioth.debian.org/u64q/program.php?te... https://benchmarksgame.alioth.debian.org/u64q/program.php?test=regexdna&lang=gpp&id=3 https://benchmarksgame.alioth.debian.org/u64q/program.php?te... I have no idea whether it's the regex implementations that are causing the comparative slowness, to be honest. Just seemed interesting that some C++ implementations using what I would think are common techniques fall behind many other languages' implementations. Of course, benchmarks are always arbitrary, and some of them will just disadvantage approaches that would be perfectly realistic ways to solve "real-world" problems, so it's always a grain-of-salt situation. However I'm not sure it's necessarily fair to say that "C++ should be at least as fast as C for any fair benchmark." Doesn't that expose you to the danger of redefining fair benchmarks as "those benchmarks which reinforce my preconceived notions of which tools have what performance characteristics"?

petke 11y ago

Yeah lets see how it plays out. I might have a look at rust at some point. On the benchmark though, its doesn't seem quite fair. At least that first one is comparing a single threaded c++ program, to a multi threaded rust program. And for the regex example the author doesn't use C++ std::regex and std::futures (std::async) like he does for Rust. It makes me think a proper C++ implementation would do much better. (Personally I use the Parallel Patterns Library. I like it a lot. We will get something similar in C++ in a few years) I don't know much about rust. It worries me though the examples are still using threads and mutexes. I think we need much higher level abstraction (like ppl::task, coroutines, etc) to get better scaling. Also lock free data structures dont scale that well either. As they still require synchronization and that hurts scaling). I think we need some kind of revolution in how we code to scale our programs to hundreds of cores.

steveklabnik 11y ago
Rust's ownership system makes shared memory much more safe than you'd expect. And you can also use shared-nothing approaches if you prefer those.
dikaiosune 11y ago
It is worth noting that the implementations for those benchmarks are contributed by a community, not all written by the same person (IIRC), so if someone is interested in using a language to the best of its hypothetical performance ceiling, they can definitely submit a solution. I'm not sure about the details for the "fasta" benchmark, but I know it's at least partly I/O bound, and many implementations for the benchmark are single-threaded: https://benchmarksgame.alioth.debian.org/u64q/performance.php?test=fasta https://benchmarksgame.alioth.debian.org/u64q/performance.ph... Notably, Rust also edges out a multi-threaded C implementation for that one. I'm sure they've done some very hairy optimizations to get to the top on that board, but it's cool to see that it's possible. On the subject of regexes, I am not familiar with the C++ std::regex implementation, but it does look like (some rather slow) C++ implementations are using a boost regex library. Those are generally fairly "standard" in C++, right?
- petke 11y ago
  I cant be sure about Rust, but C++ should at least be as fast as C for any fair benchmark. About the regex example. https://benchmarksgame.alioth.debian.org/u64q/program.php?test=regexdna&lang=gpp&id=2 https://benchmarksgame.alioth.debian.org/u64q/program.php?te... The boost regex library is fast and widely used. It doesnt look like the example is using it though, but a library called "re2". Never heard of it before. Googling turned up this https://github.com/google/re2 https://github.com/google/re2
  - dikaiosune 11y ago
    Re: regex, I was referring to some of the other C++ implementations: https://benchmarksgame.alioth.debian.org/u64q/program.php?test=regexdna&lang=gpp&id=4 https://benchmarksgame.alioth.debian.org/u64q/program.php?te... https://benchmarksgame.alioth.debian.org/u64q/program.php?test=regexdna&lang=gpp&id=3 https://benchmarksgame.alioth.debian.org/u64q/program.php?te... I have no idea whether it's the regex implementations that are causing the comparative slowness, to be honest. Just seemed interesting that some C++ implementations using what I would think are common techniques fall behind many other languages' implementations. Of course, benchmarks are always arbitrary, and some of them will just disadvantage approaches that would be perfectly realistic ways to solve "real-world" problems, so it's always a grain-of-salt situation. However I'm not sure it's necessarily fair to say that "C++ should be at least as fast as C for any fair benchmark." Doesn't that expose you to the danger of redefining fair benchmarks as "those benchmarks which reinforce my preconceived notions of which tools have what performance characteristics"?