4 ms·

The two biggest factors involved are (1) Runtime. Even though C has "no" runtime, there is some runtime overhead: Variable allocation / de-allocation and alig

by maxk42 7y ago

The two biggest factors involved are (1) Runtime. Even though C has "no" runtime, there is some runtime overhead: Variable allocation / de-allocation and alignment. Function invocation / call stack setup. Et cetera. I don't know enough about Rust to understand what its exact "runtime" is like, but I'd bet it's not exactly like C. (Rust is strongly-typed, is it not? Does it do run-time type-checking?) Exception handling in particular requires a non-negligible amount of run-time overhead and may account for a significant proportion of the difference between the performance of Rust and C. (2) Optimization. Rust and C are going to be compiled with either GCC or LLVM. The way both work is they compile the program to an internal representation of opcodes, which then get optimized and platform-specific, optimized machine code is then emitted. In some cases the specific set of opcodes or optimizations used with various conventions / data structures may be more efficient or less efficient. Over time this will improve.

atoav 7y ago
AFAIK Rust type checks only during compilation and won’t allow you to cast values of one into another without clearly defining how it should work. So if there are any type related checks done during runtime, they happen because you added them.
paulddraper 7y ago
> Rust is strongly-typed, is it not? Yes, at compile-time. > Does it do run-time type-checking? No. The closest thing is the occasional vtable-based dynamic dispatch. > Exception handling in particular requires a non-negligible amount of run-time overhead Wouldn't the side-table approach be used? That has essentially zero cost, if an exception is not thrown.
- maxk42 7y ago
  Well again -- I don't know how Rust does it specifically, but when you compile C++ programs in g++ with exceptions disabled you pretty consistently see a 10% speed improvement right off the bat and the performance falls more closely in line with the performance of C code. Specifics aside the broader point is that the runtimes between the two languages will differ.
  - paulddraper 7y ago
    Huh, that surprises me. g++ exceptions have been touted as zero-cost for the happy path. https://stackoverflow.com/a/13836329 https://stackoverflow.com/a/13836329 http://www.hexblog.com/wp-content/uploads/2012/06/Recon-2012-Skochinsky-Compiler-Internals.pdf http://www.hexblog.com/wp-content/uploads/2012/06/Recon-2012...
    - jcranmer 7y ago
      Zero-cost exception handling is only so cheap by excluding a lot of things from the cost/benefit analysis. It adds no extra code to the exception-free path. But it has a few major impacts: * Exception tables are not particularly small, and can involve extra relocations, which can increase the time it takes to load the binary. * Every function call where there is a variable with a destructor in scope has an implicit try/catch wrapped around it. This can increase code size tremendously, which hits your instruction cache. And, unlike the unwind tables, the relevant data is in the middle of your code sections, so you can't do tricks like lazy loading of the data. * Every time you call a function that may throw, you need to break up the basic blocks. So every optimization in the compiler that cannot work across basic block boundaries is going to perform much more poorly with ZCEH. * Of the various kinds of basic block edges, the exceptional edges are the hardest to reason about (computed goto edges being the second hardest). So many optimizations that can work across basic blocks are still going to bail out in ZCEH conditions. * It's possible to ameliorate the optimization costs if the compiler can figure out that the callee isn't going to throw an exception and turn a may-throw call into a may-not-throw call. But memory allocation may throw (by default), so anything that might allocate memory (say, adding a value to a std::vector) potentially throws an exception and inhibits optimization.
andolanra 7y ago
Others have pointed out that Rust's type-checking is all done at compile time. Rust also does not have exception handling. To be more specific: errors in Rust are either propagated by function return values (usually in the form of `Result` or `Option` types) which do not require any kind of runtime support, or by panicking, which unwinds the stack for clearing-up of resources and then halts the running thread. (Panics cannot be caught, although they can [EDIT: sometimes but not always; see burntsushi's comment below] be observed by a parent thread if they have occurred in a child thread.) Rust's "runtime", therefore is negligible, much like C's: it consists mainly of functions which can be called for things like stack unwinding or backtrace support.
- burntsushi 7y ago
  The thread boundary restriction for catching panics was lifted quite a while ago with std::panic::catch_unwind: https://doc.rust-lang.org/std/panic/fn.catch_unwind.html https://doc.rust-lang.org/std/panic/fn.catch_unwind.html Do note the caveats in the docs though. It isn't guaranteed to catch all panics. Indeed, unwinding can be disabled completely with a compiler option (instead, panics will abort).
- jadbox 7y ago
  AFAIK, some Rust types are checked at runtime. For example, RefCell: "Because RefCell<T> allows mutable borrows checked at runtime, you can mutate the value inside the RefCell<T> even when the RefCell<T> is immutable." *source https://doc.rust-lang.org/book/ch15-05-interior-mutability.html https://doc.rust-lang.org/book/ch15-05-interior-mutability.h... EDIT: Sorry, I don't mean 'runtime type checks' are slowing down Rust, but rather that Rust performs more general runtime safety checks (like RefCell).
  - pknopf 7y ago
    That isn't "type checking", that is just a guard to prevent simultaneous writes to the same data.
    - jadbox 7y ago
mlindner 7y ago
Please don't answer the question if you don't know enough to answer it. Rust doesn't have exception handling. Rust doesn't have a runtime.
- maxk42 7y ago
  Yes, rust has a runtime. Even most assemblers have runtimes these days. Take a look at this: https://imgur.com/lPOPj1G https://imgur.com/lPOPj1G You see that difference? That's not rust producing less-efficient code. That's the more complex rust runtime. Think it's an artifact of static linkage? Guess again. https://imgur.com/KsrApXC https://imgur.com/KsrApXC But IIRC rust doesn't statically link glibc by default. So the difference in runtime overhead is more than 10x the machine code size. That doesn't translate to a 10x slowdown and a lot of that is probably baked-in optimization but rust certainly has a runtime and associated overhead and it has a lot larger runtime than C.
  - deleted 7y ago
    [deleted]
fluffything 7y ago
> I don't know enough about Rust to understand what its exact "runtime" is like, but I'd bet it's not exactly like C. It is. > Rust is strongly-typed, is it not? Yes. > Does it do run-time type-checking? No. > Exception handling in particular requires a non-negligible amount of run-time overhead and may account for a significant proportion of the difference between the performance of Rust and C. Rust does not have exceptions, it has panics (fatal errors). It is correct for a panic to abort the program. You can provide an user-defined panic run-time that does whatever you want (unwinding, aborting, looping forever, `ud2`, etc.).

by maxk42 7y ago

atoav 7y ago

AFAIK Rust type checks only during compilation and won’t allow you to cast values of one into another without clearly defining how it should work. So if there are any type related checks done during runtime, they happen because you added them.

paulddraper 7y ago

> Rust is strongly-typed, is it not? Yes, at compile-time. > Does it do run-time type-checking? No. The closest thing is the occasional vtable-based dynamic dispatch. > Exception handling in particular requires a non-negligible amount of run-time overhead Wouldn't the side-table approach be used? That has essentially zero cost, if an exception is not thrown.

maxk42 7y ago
Well again -- I don't know how Rust does it specifically, but when you compile C++ programs in g++ with exceptions disabled you pretty consistently see a 10% speed improvement right off the bat and the performance falls more closely in line with the performance of C code. Specifics aside the broader point is that the runtimes between the two languages will differ.
- paulddraper 7y ago
  Huh, that surprises me. g++ exceptions have been touted as zero-cost for the happy path. https://stackoverflow.com/a/13836329 https://stackoverflow.com/a/13836329 http://www.hexblog.com/wp-content/uploads/2012/06/Recon-2012-Skochinsky-Compiler-Internals.pdf http://www.hexblog.com/wp-content/uploads/2012/06/Recon-2012...
  - jcranmer 7y ago
    Zero-cost exception handling is only so cheap by excluding a lot of things from the cost/benefit analysis. It adds no extra code to the exception-free path. But it has a few major impacts: * Exception tables are not particularly small, and can involve extra relocations, which can increase the time it takes to load the binary. * Every function call where there is a variable with a destructor in scope has an implicit try/catch wrapped around it. This can increase code size tremendously, which hits your instruction cache. And, unlike the unwind tables, the relevant data is in the middle of your code sections, so you can't do tricks like lazy loading of the data. * Every time you call a function that may throw, you need to break up the basic blocks. So every optimization in the compiler that cannot work across basic block boundaries is going to perform much more poorly with ZCEH. * Of the various kinds of basic block edges, the exceptional edges are the hardest to reason about (computed goto edges being the second hardest). So many optimizations that can work across basic blocks are still going to bail out in ZCEH conditions. * It's possible to ameliorate the optimization costs if the compiler can figure out that the callee isn't going to throw an exception and turn a may-throw call into a may-not-throw call. But memory allocation may throw (by default), so anything that might allocate memory (say, adding a value to a std::vector) potentially throws an exception and inhibits optimization.

andolanra 7y ago

Others have pointed out that Rust's type-checking is all done at compile time. Rust also does not have exception handling. To be more specific: errors in Rust are either propagated by function return values (usually in the form of `Result` or `Option` types) which do not require any kind of runtime support, or by panicking, which unwinds the stack for clearing-up of resources and then halts the running thread. (Panics cannot be caught, although they can [EDIT: sometimes but not always; see burntsushi's comment below] be observed by a parent thread if they have occurred in a child thread.) Rust's "runtime", therefore is negligible, much like C's: it consists mainly of functions which can be called for things like stack unwinding or backtrace support.

burntsushi 7y ago
The thread boundary restriction for catching panics was lifted quite a while ago with std::panic::catch_unwind: https://doc.rust-lang.org/std/panic/fn.catch_unwind.html https://doc.rust-lang.org/std/panic/fn.catch_unwind.html Do note the caveats in the docs though. It isn't guaranteed to catch all panics. Indeed, unwinding can be disabled completely with a compiler option (instead, panics will abort).
jadbox 7y ago
AFAIK, some Rust types are checked at runtime. For example, RefCell: "Because RefCell<T> allows mutable borrows checked at runtime, you can mutate the value inside the RefCell<T> even when the RefCell<T> is immutable." *source https://doc.rust-lang.org/book/ch15-05-interior-mutability.html https://doc.rust-lang.org/book/ch15-05-interior-mutability.h... EDIT: Sorry, I don't mean 'runtime type checks' are slowing down Rust, but rather that Rust performs more general runtime safety checks (like RefCell).
- pknopf 7y ago
  That isn't "type checking", that is just a guard to prevent simultaneous writes to the same data.
  - jadbox 7y ago

mlindner 7y ago

Please don't answer the question if you don't know enough to answer it. Rust doesn't have exception handling. Rust doesn't have a runtime.

maxk42 7y ago
Yes, rust has a runtime. Even most assemblers have runtimes these days. Take a look at this: https://imgur.com/lPOPj1G https://imgur.com/lPOPj1G You see that difference? That's not rust producing less-efficient code. That's the more complex rust runtime. Think it's an artifact of static linkage? Guess again. https://imgur.com/KsrApXC https://imgur.com/KsrApXC But IIRC rust doesn't statically link glibc by default. So the difference in runtime overhead is more than 10x the machine code size. That doesn't translate to a 10x slowdown and a lot of that is probably baked-in optimization but rust certainly has a runtime and associated overhead and it has a lot larger runtime than C.
- deleted 7y ago
  [deleted]

fluffything 7y ago

> I don't know enough about Rust to understand what its exact "runtime" is like, but I'd bet it's not exactly like C. It is. > Rust is strongly-typed, is it not? Yes. > Does it do run-time type-checking? No. > Exception handling in particular requires a non-negligible amount of run-time overhead and may account for a significant proportion of the difference between the performance of Rust and C. Rust does not have exceptions, it has panics (fatal errors). It is correct for a panic to abort the program. You can provide an user-defined panic run-time that does whatever you want (unwinding, aborting, looping forever, `ud2`, etc.).