Rust vs. C++: Fine-grained Performance

by beshrkayali • 10 years ago

211 126 10 years ago

jasode• 10 years ago

The author compares gcc vs rustc.[1]

I'm curious if the author considered comparing clang vs rustc since both use the LLVM backend. (I'm guessing the more mature C++ code generation would still win the benchmark but one could study the intermediate code emitted by clang/rustc instead of the final machine code emitted by gcc.)

[1]https://github.com/ncm/nytm-spelling-bee/blob/master/Makefil...

jtxx0002• 10 years ago

On my Macbook Pro, the rust version seems consistently faster (20% or so) than the c++ version compiled with clang.

jtxx0002• 10 years ago

As a followup, if I use __builtin_expect as recommended by the article, the situation reverses, with c++ being significantly faster.

nkurz2• 10 years ago

Curiously, most variations of the C++ version run only half as fast as they should on Intel Haswell chips, probably because of branch prediction failures

I haven't looked at the code yet (time for bed) but this note from Agner seems like it might be relevant:

  3.8 Branch prediction in Intel Haswell, Broadwell and Skylake

  The branch predictor appears to have been redesigned in the 
  Haswell, but very little is known about its construction.

  The measured throughput for jumps and branches varies 
  between one branch per clock cycle and one branch per two 
  clock cycles for jumps and predicted taken branches. 
  Predicted not taken branches have an even higher throughput   
  of up to two branches per clock cycle.

  The high throughput for taken branches of one per clock was 
  observed for up to 128 branches with no more than one 
  branch per 16 bytes of code. If there is more than one 
  branch per 16 bytes of code then the throughput is reduced 
  to one jump per two clock cycles. If there are more than 
  128 branches in the critical part of the code, and if they 
  are spaced by at least 16 bytes, then apparently the first 
  128 branches have the high throughput and the remaining 
  have the low throughput.

  These observations may indicate that there are two branch 
  prediction methods: a fast method tied to the μop cache and 
  the instruction cache, and a slower method using a branch 
  target buffer.

http://www.agner.org/optimize/microarchitecture.pdf

At a glance, the symptoms seem like this might match. Separately, I think there is still a limit of 3 branches per 16B before the branch prediction starts to fail. It's rare to hit this in normal code, but something this optimized might.

wscott• 10 years ago

I found the branch prediction claim to be a bit weak without perfmon data to support it. The references point out that the Intel 'popcnt %r1, %r2' instruction has a false input dependency on the output variable and neither gcc nor clang seem to know about that and adjust register scheduling. This is usually caused because the chip uses the same scheduling bucket used for instructions like 'add'. So putting 'popcnt %rax, %rax' inside a tight loop will prevent that loop from being unrolled in the processor. As a result the code is highly sensitive to random changes because the compiler occasionally gets lucky and breaks the chain.

nly• 10 years ago

I've recently experienced what I believe was likely branch predictor failure. I rewrote essentially the same algorithm, with the same complexity, in a completely new way, to reduce constant factors. The new code was beautiful, and I was expecting perhaps 15-20% performance improvement. (40% of the runtime in the old version was in one function, the new version should, and did, call that function with less data to grind on average). Memory access patterns should be identical. Grand.

So what happened with my standard benchmark on Haswell (GCC 5.3, -march=native -O2)?

Old version, without PGO: ~8 minutes (baseline)

Old version, with PGO on: ~9 minutes (yes, PGO made it slower)

New version, without PGO: 11 minutes (60% slower)

New version, with PGO on: 7 minutes (~15% faster)

All of these benchmarks were replicated with a common set of functions tagged noinline, and I inspected the assembly to see if there was a difference with regard to loop unrolling. Nope, no unrolling. Afaict it appeared to be entirely to do with the way GCC had laid out code with respect to branches. The differences were minor in key areas and seemed like arbitrary compiler choices.

I eventually narrowed this down with callgrinds branch-predictor simulator to a few hot spots. I added a redundant if-statement to check for and short-circuit a common case, even though it shouldn't have mattered, and a few __builtin_expects, and suddenly I was getting the 15% speedup without PGO.

melted• 10 years ago

Don't know about Clang/LLVM, but in GCC you can give the compiler a hint if a branch is likely to be taken. As far as I can tell from disassembly, most of the time it just puts that branch first in the instruction stream, but I have measured significant benefit in very hot code paths.

nkurz2• 10 years ago

I've now looked at it more closely, and tested on Skylake and Haswell. I don't think the case described in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67153 is actually a bug in either the compiler or the processor. Rather, it's the behavior you would expect if the compiler (at compile time) guesses wrong about whether a branch is likely to be taken or not.

Which choice is fastest on the depends on the runtime word list, and thus there is no reason to fault the compiler for either choice. For the processor, the difference is simply that a "branch not taken" is faster than a branch taken. The fast version involves a loop that executes in a single cycle:

   77.21 │210:┌─→add    $0x4,%rcx 
    0.66 │    │  cmp    %rcx,%r8  
         │    │↓ je     260       
    4.20 │219:│  mov    (%rcx),%edi 
    0.88 │    │  test   %r9d,%edi   
         │    └──jne    210

The cmp/je and test/jne instructions fuse into on µop each, so that (incredibly) the processor can execute the remaining 4 fused µops at an iteration per cycle. If the loop is rearranged so that the middle branch is taken, each iteration takes a minimum of 2 cycles instead.

The solution (as the author mentions in a parenthetical) is to give more information to the compiler with "__builtin_expect". I wasn't able to test on Sandy Bridge or earlier, but my strong guess would be that Haswell and Skylake have a potential speedup, rather than a regression. I'll try to add a comment to the bug later tonight.

threeseed• 10 years ago

This is really fantastic to get an understanding of how Rust works in a real world environment. As a non-systems developer I am finding the Rust language to be a little cryptic though in particular the many new syntax elements that don't exist in other languages.

I would be curious to know if there are plans like Swift to simplify the language syntax in the future or if it is just something to get used to.

steveklabnik16• 10 years ago

It depends on what you mean by "simplify". We've just accepted an RFC for ?, for example, which should make certain code more concise, but it is an additional feature, so is that more simple?

quickben2• 10 years ago

General notes: - Semicolons inconsistent usage makes Rust harder to process. Is that semicolon extra? Is it not? Will that be a compilation error? Saving single keystrokes will be paid in cognitive load. Programming is already a demanding task, this isn't helping. - Chaining multiple statements on a single line is bad for various reasons.

Dependencies / headers / modules: - C++ is better precisely because it's more grained on the initialization side. The paragraph starting with 'Rust wins, here', is just a general turnoff to read the rest of the article. When I read the title 'Rust vs. C++: Fine-grained performance' I was honestly expecting either a table with performance times across various algorithms, or a savvy optimization guide. I wasn't expecting a LoC duke-it-out.

Input file processing - Both are conceptually boilerplate code. There is more for Rust apparently. - There is an interesting &⊛env:: in there that makes the language looks like it needs a bit more work. Three operators just to do something with the first object? - Are they intentionally trying to copy C++ with the :: operator but removing visually arbitrary semicolons? Just replace the :: with something else.

Data structure and input setup - Remove the 'let' from the language, and it does look cleaner than the C++.

Input state machine - Why isn't "(0..7).rev()" "(7..0)" - On the bottom part, lamba-like usage will makes in less comprehensible (and probably undebuggable the way it's written)

General lack of performance numbers - "I found that iterating over an array with (e.g.) “array.iter()” was much faster than with “&array”, although it should be the same..." "Curiously, changing scores to an array of 16-bit values slowed down (earlier versions of) the C++ program by quite a large amount – almost 10% in some tests – as the compiler yields to temptation and forces scores into an XMM register. The Rust program was also affected, but less so."

Edit: Unicode

anfroid555• 10 years ago

Rust = c syntax with Erlang conventions

biokoda• 10 years ago

Ehm no not even close.

pdpi• 10 years ago

You would've hit closer to home if you'd said "ML" or "Haskell" instead of Erlang, though you'd still be shooting wide.

Rust's borrow checker is its single most distinctive feature, and that is inspired by the work done in the Cyclone language.

sitkack3• 10 years ago

http://doc.rust-lang.org/reference.html#appendix-influences

Ace172• 10 years ago

If you want to compare the verbosity of both languages, why not use 'using namespace std' ?

Why write:

std::vector<unsigned> counts; counts.resize(sevens.size());

When you can write:

auto counts = vector<unsigned>(sevens.size());

Doesn't seem like a fair comparison to me.

svalorzen2• 10 years ago

I don't agree on the general usage of "using namespace std", so that part does not bother me.

For an even shorter init:

std::vector<unsigned> counts(sevens.size());

Ace172• 10 years ago

I don't agree on the general usage of "using namespace std", so that part does not bother me.

It should: we're comparing to Rust, whose namespace system seems very similar to a "using namespace std".

rosshemsley• 10 years ago

Bringing namespaces into scope is perfectly idiomatic C++, just don't do it in your headers.

vkjv• 10 years ago

I think one thing of note here is that the author did not want to make the program parallel. One of the benefits touted by Rust is "fearless concurrency." If this feature was introduced this is where # lines or performance may have diverged.

sitkack3• 10 years ago

Parallel is of course very important. But if serial speed isn't in the same range, go parallel will be the same perf crutch as the Python folks who say drop to native. Rust programs shouldn't be parallel to beat a single threaded C++ program.

toolz• 10 years ago

Rust programs shouldn't be parallel to beat a single threaded C++ program.

I don't write code in either language, but as an outsider my impression is that rust was created to make programming for parallel execution, easier.

If that's the case, why are we comparing a use case c++ is optimized for against a use case rust isn't optimized for?

zanny• 10 years ago

I think well designed C++ can maintain parity, especially with async() using http://en.cppreference.com/w/cpp/thread.

The problem is more that Rust is going to be automatic in your security more often, while C++ would require more thorough review.

But the code in this article is micro-optimized, and overlooks the common trend of micro-optimization in C++ often leading you into the twilight zone of unexpected undocumented behavior and "luck" when getting desired results rather than granularity well defined syntax. You basically compare the two with artful precision which means you do not get to notice the very common trend of what is safe Rust is often unsafe C++ in the default design.

pcwalton19• 10 years ago

I think well designed C++ can maintain parity, especially with async() using http://en.cppreference.com/w/cpp/thread.

No, the entire point of Rust's "fearless concurrency" is guaranteed data race freedom by the compiler, something C++ doesn't even try to enforce. Modern C++ can still easily have data races.

zvrba• 10 years ago

Most insightful part for me was this one:

Many variations [he's talking about Rust] that seemed like they ought to run the same speed or faster turned out slower, often much slower. By contrast, in C++ it was surprisingly difficult to discover a way to express the same operations differently and get a different run time.

This is an insidious pitfall that may earn Rust the "slow" label, akin to what happened to Common Lisp.

infinity0• 10 years ago

Yeah, I wish he had gone through this in more detail, too.

humanrebar• 10 years ago

This is an insidious pitfall that may earn Rust the "slow" label, akin to what happened to Common Lisp.

Could it just be that the language is still young and all the edge cases in the optimizer haven't been implemented yet?

steveklabnik16• 10 years ago

Not just that, but there's a lot of optimizations that would be nice, but we haven't implemented yet. (Though some of these will end up being more to help with compile times than runtime performance, though)

imh• 10 years ago

I thought Rust left the optimization to LLVM. Is that not the case?

hellofunk4• 10 years ago

This is a problem in Haskell as well, from everything I've read.

koloron• 10 years ago

Can you share some links?

_yosefk• 10 years ago

I dunno, it's very easy for me to express things differently in C++ and get a different runtime. It's easy enough for a bunch of C++ programmers writing needlessly slow code whom I've known. It must be equally easy for the author. The reason he doesn't ought to be vast experience with C++, so that he doesn't try obviously dumb things (as in things that malloc a ton of stuff needlessly, etc.), whereas his Rust experience is necessarily smaller. I think you need quite a bit of experience to declare that, well, experience just doesn't help because the performance model of this thing is weird!

CyberDildonics• 10 years ago

I would never call software good to go until I have profiled it to weed out all the places where a slow technique meets an important path.

In my experience profiling and optimization is usually sort of like a victory lap - low hanging fruit for substantial differences.

pcwalton19• 10 years ago

This is an insidious pitfall that may earn Rust the "slow" label, akin to what happened to Common Lisp.

This doesn't match my experience at all with Rust, for what it's worth. Not having copy constructors makes up for any difference in that regard: in C++ it's way too easy to accidentally deep copy a vector and the entire object graph underneath it--all it takes is "auto a = b" as opposed to "auto& a = b"--with very bad performance consequences. Rust, on the other hand, doesn't let you deep copy unless you explicitly ask it to.

Manishearth2• 10 years ago

When I went back to C++ after learning Rust and used a vector again, I realized this and it hit me like a brick. I used to program in C++ before, so it wasn't like I didn't know this, but it was something rather unremarkable to me. Then I go back to C++ and throw vectors around willy-nilly and stuff works. Huh, I thought, this feels strange, I wonder how C++ accomplishes this without a garbage collector or ownership. Then it hit me -- it deep copies All The Things. Again, I already knew this, but I hadn't ever thought about it much. But the change in perspective made it stick out like a sore thumb.

yongjik• 10 years ago

I got so worried about accidentally deep-copying stuff that I ended up with an ugly C++ hack:

    C(const C &) = delete;
    C &operator=(const C &) = delete;
    C(C &&) noexcept = default;
    C &operator=(C &&) noexcept = default;

    struct MakeCopy {
        const C &src;
        MakeCopy(const C &src) : src(src) { }
    };

    MakeCopy make_copy() const { return *this; }
    C(MakeCopy src) : field1(src.src.field1), (blah blah) { }

Then, when you really want to copy stuff, you have to say "a = b.make_copy();".

This isn't really clean, because it's too easy to add a field to C and then forget to add it to the "manual copy constructor", but so far I found it good enough for me.

jkarneges• 10 years ago

The Qt C++ library does some neat tricks to avoid copying. For example its vector class (like nearly all of its container/value classes) overloads the "=" operator to perform shallow copies. So even though default behavior in C++ is to deep copy, it's possible to override.

Qt even takes it further by providing automatic copy-on-write. Methods that read data operate on the shared copy. Methods that change data cause the object to deep copy and detach first. This allows writing programs using values rather than references, while retaining the performance of references.

bsder• 10 years ago

I laughed at this. I STILL write "++foo;" rather than "foo++;" as a default because C++ used to create copies at odd places.

twic2• 10 years ago

I'm surprised by the small warts in the Rust code. In this line:

  let fname = &*env::args().nth(1).unwrap_or("/usr/share/dict/words".into());

Neither the &* not the .into() add much to the meaning for me as a reader. Why are they necessary for the compiler?

Why is there an .unwrap() on writeln! ? To force a panic if the write failed?

steveklabnik16• 10 years ago

They used `into()` because it's the shortest. The more idiomatic options are all of the other ones: String::from, .to_string(), and .to_owned() (Strings implement a lot of generic interfaces.)

The &* converts a String to a &str. I would have done it in the match rather than here, personally.

  > Why are they necessary for the compiler?

Rust does not heap allocate things automatically nor convert types automatically. This is the side effect: you can see exactly how much allocation is going on, and know exactly how stuff is being converted.

(We do have a very small and very specific set of conversions that will happen, they don't here, though.)

  > Why is there an .unwrap() on writeln! ? To force a panic if the write failed?

Yes. The compiler will warn you that you're ignoring the errors on the write, and panicking is one way of handling it.

twic2• 10 years ago

So the string literal is a str, but it gets turned into a String with the .into(), and then back into a str (well, &str) on the same line. That seems like a lot of travelling to go a short distance.

Is this because args() ultimately gives you a String, and you need to get that and the string literal out of a single expression?

Why does args() give you String rather than str? Couldn't command-line arguments be static more-or-less constants?

Would there be any way to turn the output of args straight into a &str, so you didn't need to .into() the literal?

Why are String and str separate types, rather than different uses of a single type? Are there any other examples of pairs of types with the same relationship? Arrays and slices? Any others? Is there something like this for maps/dictionaries/hashes?

I realise i've asked a lot of basic questions about strings here, and that you (and any other knowledgeable people reading this) are probably pretty tired of explaining this over and over again. I would be equally grateful for a link to some relevant documentation or whatever as for a detailed answer!

conceit• 10 years ago

If a panic is forced and used like an exception, that's just so wrong ...

Tuna-Fish• 10 years ago

.into() Why are they necessary ...

"foo" in Rust has the type &'static str. That is, a pointer and a length to an immutable piece of memory that never goes out of scope, which in the case of a literal is allocated statically. Because Rust tracks ownership of memory, this kind of a reference is of a different type than a heap-allocated owned string.

Rust also does no allocations or conversions without you telling it to do so. The programmer wanted a heap-allocated String, so he had to call a conversion function, which allocated memory and copied the string.

eddyb• 10 years ago

I'm not sure why the author kept &*s, I have suggested &s[..] instead (i.e. "take a slice of the whole string").

And .into() seems to be used as a &str -> String (allocating) conversion for brevity only.

The more idiomatic form would therefore be:

  let fname = &env::args().nth(1).unwrap_or(String::from("/usr/share/dict/words"))[..];

Although I would move the &...[..] slicing to the places where fname is used, which should work fine with &String instead of &str (or automatically coerce to get the latter).

hellofunk4• 10 years ago

but I’m amazed that Intel released Haswell that way. I don’t know yet if it Intel fixed it in Broadwell or Skylake.

I would love to know more about this; how curious indeed.

ufo• 10 years ago

    Incidentally, I don’t know why I can write  
        let (mut word, mut len, mut ones) = (0u32, 0, 0);
    but not
        (word, len, ones) = (0, 0, 0);

Marking variable declarations with let is a good thing and makes it clear if something is an assignment or a variable declaration. It also leads to cleaner code when you use nested functions (I always hated the "nonlocal" keyword in Python)

losvedir• 10 years ago

I think the author was indicating that while you can use that syntax to declare and initialize variables, you can't use it later to assign new values to them. I don't think they had any problems with the concept of `let`.

And it does strike me as a little weird as well to only be able to take advantage of the pattern match destructuring on initialization, but I'm sure there's a good technical reason.

deng• 10 years ago

I read it the same way. There's an open issue for it:

https://github.com/rust-lang/rfcs/issues/372

I think one of the main reasons this isn't done is because of the grammar issue. I dimly remember that one of the goals of Rust was to be parseable with a LL(1) grammar.

sremani2• 10 years ago

let (word, len, ones) = (0, 0, 0)

looks like a cleaner version that works in F# (and I am not sure in Rust). This is extremely useful when initializing values from a function that returns a tuple and do not want to change them (unlike the mut word etc.)

let (x, y, z) = GetStartPoint3d()

steveklabnik16• 10 years ago

That works in Rust if you add a ; on the end.

cppishellacool3• 10 years ago

Do you want C++ compiler to also prevent data races? Then use const functions by default, seriously.

http://youtu.be/Y1KOuFYtTF4 (starts at 29:00)

C++ template meta programming language is such a powerful and expressive tool for writing libraries and safe abstraction. Imagine if all the effort of 8 years of Rust team went into a modern C++ safety library.

Such a library would have been more useful contribution and more people would have benefited.

steveklabnik16• 10 years ago

Using const does not prevent data races.

We made Rust because you can't actually retrofit it's guarantees on C++ without breaking backwards compatibility. The CPP Core Guidelines are an example of this: Herb said that data race prevention is a non-goal, and in general, how it interacts with concurrency is not yet understood.

cppishellacool3• 10 years ago

Did you watch the video?

Curious why you think using const functions doesn't prevent data races after watching

at 29:00 he says the C++ standard guarantees const member functions are data race free.

pcwalton19• 10 years ago

Do you want C++ compiler to also prevent data races? Then use const functions by default, seriously.

Tell me how to use const functions to enforce that I take a lock before accessing data guarded by a mutex. Or how to mutate data local to the current thread only, while forbidding mutation of shared data.

Imagine if all the effort of 8 years of Rust team went into a modern C++ safety library.

I imagine our 8 years would have been wasted chasing the impossible.

zerr2• 10 years ago

It seems Rust sacrifice too much for the sake of safety. If Swift will evolve to truly cross-platform language, I think it is in the golden middle of safety vs usability trade-off (without requiring non-deterministic GC like D).

autoreleasepool14• 10 years ago

I think after about Swift 4.0, if you're writing a native application in [systems language] and you're using Arc/Rc/shared_ptr all over the place you need to seriously take a step back and ask yourself why you're not using Swift.

If Swift had structural references (for all intents and purposes in Swift, all structs are value types and all classes are automatically reference counted pointers) and move semantics Swift would absolutely kill it.

It's an exciting time to be a PL nerd.

kibwen• 10 years ago

I'm a Rust fan, but I'll still be excited if Swift manages to add some sort of borrow checker to the language in a future revision (C++, D, and Nim have all also at least alluded towards such a direction, but only C++ has made any progress so far). From what I've seen though, I'm still not sure that Chris Lattner has given serious thought to such an addition. I'm waiting for a concrete proposal before getting my hopes up, because Rust had to make put significant effort into tailoring the base language to borrow checking and implementing such an analysis after the fact runs the risk of serious divergence (or worse, breakage) in the ecosystem.

(There's also the fact that, as of the hypothetical Swift 4k, none of the library ecosystem will be leveraging the borrow checker and so Rust will still have a substantial head start for people who want thoroughly static ownership.)

Other than that I'm a bit dismayed that Swift just punts concurrency to GCD, given how many other new languages make concurrency such a major focus (especially Rust).

gnuvince• 10 years ago

It seems Rust sacrifice too much for the sake of safety.

Like what? Given the constraints that Rust has, I don't see much that could radically be changed. Little things like the ? operator (equivalent to try!()) can improve the common tasks, but how do you ensure memory safety in the absence of a garbage collector without the programming being explicit about what he wants to do?

pcwalton19• 10 years ago

How is this related to the article?

And what, exactly, does Rust sacrifice for safety?

zerr2• 10 years ago

How is this related to the article?

The article compares Rust vs C++. No surprise that the [potential] language in the middle of these two extremes is mentioned....

And what, exactly, does Rust sacrifice for safety?

Clarity, usability... Here is Alexandrescu's quick overview of it:

https://www.quora.com/Which-language-has-the-brightest-futur...

shin_lao• 10 years ago

To my knowledge std::ifstream is pretty slow, I think the author should load the whole file in memory with a cache friendly layout and try the benchmark again.

Animats• 10 years ago

I need to learn Rust again. I haven't used it in a year, and the language has changed a lot. Everything now seems to require a closure or some ".into()" idiom. Like this:

     let file: Box<Read> = match fname {
            "-" => Box::new(stdin.lock()),
             _  => Box::new(fs::File::open(fname).unwrap_or_else(|err| {
                     writeln!(io::stderr(), "{}: \"{}\"", err, fname).unwrap();
                     process::exit(1);
                 }))
        };

Type Result has its very own set of control flow primitives.[1] So does type Option.[2] Any type can have its very own flow control primitives. Are we going to see

    date.if_weekday(|day| { ... })

and similar cruft for every type? I hope not.

Hopefully the setup of closures that probably won't be executed isnt't too expensive. Do those require a heap allocation and release when not used, or is this all on the stack? The run time variation for small changes indicates that some constructs are more expensive than others, but it's hard to know which ones are bad.

I understand the rationale behind the Rust approach to error handling, but it's just painful to look at. After seeing the gyrations people go through in Go and Rust to deal with the lack of exceptions, it looks like leaving exceptions does not make a language simpler. From a compiler perspective, the compiler can generally assume that exceptions are the rare case, and can optimize accordingly. Rust has no idea which closure a function will call, if any.

[1] https://doc.rust-lang.org/std/result/enum.Result.html [2] https://doc.rust-lang.org/std/option/enum.Option.html

heinrich59912• 10 years ago

Closures are just as expensive as normal control flow, if they're not passed as a trait object (which is unusual).

To expand: No closures require heap allocation. If you pass the closure as trait object, calling it will require a virtual function call, which is more expensive than a normal one.

steveklabnik16• 10 years ago

Closures aren't more expensive than what you use; they're not heap-allocated by default, and a closure that doesn't close over everything should end up being a regular old function.

We just merged an RFC for ? syntax, which should make error handling less verbose.

dbaupp3• 10 years ago

Hopefully the setup of closures that probably won't be executed isnt't too expensive. Do those require a heap allocation and release when not used, or is this all on the stack?

Creating a closure with |...| { ... } is literally as expensive as creating a tuple containing (references to) the variables it captures. That is, they're on the stack by default like everything else in Rust, and there's no implicit heap allocations. For more details, see, for instance, http://huonw.github.io/blog/2015/05/finding-closure-in-rust/ .

Rust has no idea which closure a function will call, if any.

It does. As my link above discusses, each closure has a unique type, allowing monomorphisation to kick in and hence the compiler can easily optimise and inline calls to closures (as long as the author of the closure-taking function doesn't opt-in to only allowing virtual dispatch).

Manishearth2• 10 years ago

it looks like leaving exceptions does not make a language simpler.

I don't think that this ever was the claim. Rust leaves exceptions out because they make code hard to work with and because it prefers errors be acknowledged. I don't think monadic errors are "simpler" than exceptions.

(Though I suspect they are simpler to teach than exceptions to people who have learned neither)

Once `?` lands in Rust I expect these "gyrations" become much simpler.

Are we going to see > date.if_weekday(|day| { ... }) > and similar cruft for every type? I hope not.

Not sure where this comes from. As the others have mentioned, closures are pretty cheap, but anyway you don't need to use the control flow primitives. There are many ways of dealing with errors, including using `if let`, `match`, `unwrap_or_else`, `try!`, and the upcoming `?`.

Rust vs. C++: Fine-grained Performance

Related Stories