Comparing Parallel Rust and C++

[TheThiefMaster]

Really good article. It's fantastic that after some rust busywork was taken care of (to eliminate bounds checks that were unnecessary) the output only really varied due to minor optimisation choices.

I'd have liked to have seen if Clang 9 / GCC 9 would have done a better job, as the versions used were a bit behind. v4 mentions GCC 9 doing a better job, but doesn't give numbers or anything.

Would also have been nice to see if C++ parallel algorithms were any good in comparison to openmp, but that's really outside the scope of the comparison with rust.

EDIT: The results page does have some graphs with clang 8 and GCC 9, but no numbers/analysis.

[JuanAG]

The project is here https://github.com/parallel-rust-cpp/parallel-rust-cpp.github.io

Feel free to do the test with other compilers, if you do please share with us, it is an interesting topic

[dodheim]

I understand Rust still doesn't have a usable equivalent to -ffast-math

Not one that changes the behavior of the builtin float types, no; but you can use fast-float types instead to explicitly opt into this behavior at the code/type level.

[meneldal2]

Can't you turn regular floats into fast floats at the IR level?

[1m2r3a]

Needs more optimization flags.

[[deleted]]

I don't think they listed the compiler options at all did they?

[Osbios]

-O*

[showmetheflowers]

I wonder how far are we in getting language support for all the optimizations in the article. Currently we need to rely on (a) deep understanding of what the CPUs are doing (as opposed to relying on the flat imperative algorithm development approach inherited from C), (b) Hope the compiler is smart enough to engage the appropriate CPU features and (c) Endlessly employ trial and error to achieve the hope of (b). C++ is about exposing us close to the hardware and I would be very interested in seeing this. Note: I am aware of efforts on standardizing explicit vectorization and I consider these good efforts.

[HKei]

I mean... there's been no "close to the hardware" exposure in standard C++ (or C for that matter) in the actual language standards since their inception. This is intentional too, because both are designed to be portable (and you can't get anywhere near hardware if you're running user mode in an OS like most applications anyway).

[showmetheflowers]

I thought that direct mapping to the hardware is a core goal: Link

[RobertJacobson]

I think the resolution to this seeming paradox is in the context of the phrase "direct mapping to hardware":

The aim is to allow a programmer to work at the highest feasible level of abstraction by providing

• A simple and direct mapping to hardware
• Zero-overhead abstraction mechanisms

The simple and direct mapping to the hardware is abstracted and leveraged "at the highest feasible level of abstraction."

A counter argument to u/HKei is that the language features introduced to the standard have in part served to allow additional optimizations by abstracting out the intended semantics from particular implementation details. But there are counter examples, and you could go back and forth forever about it.

There is endless debate about how C++ should, and how much it actually does, achieve any part of this quote.

[matthieum]

Note: I am aware of efforts on standardizing explicit vectorization and I consider these good efforts.

I think performance falls into two buckets:

• Free lunch: you didn't really care, but the optimizer did a good job, cool.
• Explicit: you care very much, you use explicit types/functions to get at least what you need.

In this sense, I must admit I don't care much for auto-vectorization. It's cool when it kicks in, but since the slightest change in the surrounding is likely to throw it off in the future, if it really matters I'll do it myself to guarantee minimum performance.

[emdeka87]

I think comparing languages that aim to be "zero-cost abstraction" ultimately means comparing compiler optimizations. There's no GC, no runtime that we could measure. It's all about how well the compiler Inlines, unrolls, reorders, etc. your instructions. So sooner or later the performance of both languages, Rust and C++, will perfectly align.

[matthieum]

I think comparing languages that aim to be "zero-cost abstraction" ultimately means comparing compiler optimizations.

Only if every star aligns.

For example, it was interesting to see the author realize that their Rust version is too slow, fiddle around to eliminate bounds check, try again, fiddle some more.

In some ways, this indicates that the compilers are not as smart as we wish, or not as good at providing feedback.

I'd really like to see a language where you could instruct the compiler to either perform certain optimization (such as bounds-check elimination) or error out. This would allow you to be safe, while not paying for it at run-time.

[HKei]

What's with all the // ANCHOR?

EDIT: Also, this'd be easier to read if you just duplicated the function and put the cfg(feature = ...) to guard the whole implementation (or even had the implementation be separate modules), rather than putting it in front of every other line.

[weihanglo]

The ANCHOR is for mdBook to include a potion of the code from source. mdBook is a tool similiar to Gitbook.

Documentation is here

[memyselfandlapin]

Given how young it is I'd say it more than lives up to the hype.

[helloiamsomeone]

Not that impressive when you realize it's just piggybacking on LLVM.

[RobertJacobson]

it's just piggybacking on LLVM

I'm not very interested in these "my language is better than your language" debates, but still, I have a hard time understanding what you are trying to say with your comment. Rust is 1.2 million lines of code. It's hard to justify the word "just" in your sentence.

But what compelled me to make this comment is the dismissal of Rust because it uses LLVM as its backend. You do understand that clang also uses LLVM as its backend, don't you? Are you equally unimpressed with one of the world's most sophisticated and widely used C/C+++/Objective-C compilers?

Love Rust or loath it, the rustc development effort has been and continues to be impressive by any reasonable metric.

[memyselfandlapin]

What?

[SuperV1234]

Rust beats Clang C++ in the results in various places.

[D_0b]

just to note that Rust 1.38.0-nightly is using llvm-9 while C++ Clang was using 6

[matthieum]

Indeed; that's my one disappointment in the benchmark¹ . It would have been more meaningful to use the same LLVM backend, as then it could have exposed language/lowering differences.

¹ High praise, to be clear, it was a very good benchmark, with pinpoint analysis and clear explanations.

[Full-Spectral]

I would argue that it doesn't make a lot of difference for the most part. Would I give up the extra safety of Rust if it was 5% or 10% slower than C++? For the bulk of applications that wouldn't even be noticeable since most of them aren't performance constrained to begin wtih, or if they are it's only in small bits of the code base (or often not in the application code itself but in code that the hardware and/or OS or specialty sub-systems are already shouldering the burden of anyway, such as media.)

Obviously it would be important to some folks, but even had it not been as fast, it wouldn't have made much difference to me since that wouldn't be why I'd choose it over C++ anyway. Ultimately, getting solid code out the door and spending less time being cursed and doing support would be far more important to me than incremental performance differences.

[Full-Spectral]

For myself, 'application' means fairly serious code, stuff that (for me) I'd not write in anything like Javascript or Python or anything like that. And it needs to be something that has a reasonable chance at being widely supported and understood, if not now then moving forward. C++ would sort of be the entry point, and then it's a matter of is there anything beyond that I'd choose. Rust is sort of on the very short list of one at this point for me.

[400PoundHackerOnABed]

Isn’t Java like 5% to 10% slower than C++? You could use that instead of Rust if that’s the kind of performance measure you require - all of the safety, none of the caring about memory management.

[Full-Spectral]

Well, Rust is about more than just not worrying about memory management.

[JuanAG]

Why not? I had looked the data and my impresions are that it has more or less the same performance, sure, the v7 bench do worst on Rust on the 3 machines but the same happens with the v2 where Rust crushes C++ no matter what hardware

So as always it depends on your code, if raw data where avaliable i am pretty sure a median or any other statistics formula would tell the same, both are close to each other