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

Is Rust faster than C?

steveklabnik.com

Post reply on HN
Print view View original

301–310 of 402 posts

Re: Is Rust faster than C?

#301

Post by pjmlp »

jenadine wrote: post #292
sebtron wrote: post #126

Earlier quoted context omitted.

> Are people making user facing apps in rust with uis? We are talking not only about Rust, but also about C and C++. There are lots of C++ UI applications. Rust poses itself as an alternative to C++, so it is definitely intended to be used for UI applications too - it was created to write a browser! At work I am using tools such as uv [1] and ruff [2], which are user-facing (although not GUI), and I definitely apprec…

> There are lots of C++ UI applications. Is there? UI applications historically used to be written in C++. But in this decade, I don't think many new GUI are being written in C++

Games are, anything based on Qt/KDE, UWP/WinUI (even if it is mostly Microsoft employees).

Now even if it is Flutter, React Native, or Chrome/Electron, they are powered by C++ graphics engine, and language runtimes.

Re: Is Rust faster than C?

#302

Post by pjmlp »

groundzeros2015 wrote: post #207
gf000 wrote: post #205

Earlier quoted context omitted.

> The example you gave of a compiler is canonically implemented as multiple process making .o files from .c files, not threads. This is a huge limitation of C's compilation model, and basically every other language since then does it differently, so not sure if that's a good example. You do want some "interconnection" between translation units, or at least less fine-grained units.

And yet despite that theoretical limit C compiles faster than any other language. Even C++ is very fast if you are not using header-only style. What’s better? Rust? Haskell? Swift? It’s very hard to do multithreading at a more granular level without hitting amdahl’s law and synchronization traps.

No it doesn't, try it against a language with modules support, even the oldie Turbo Pascal for MS-DOS.

Re: Is Rust faster than C?

#303

Post by pjmlp »

cyberax wrote: post #283
pjmlp wrote: post #178

Earlier quoted context omitted.

Unless one uses VC++, which can debug release builds. Similar capabilities could be made available in other compilers.

You can debug release builds with gcc/clang just fine. They don't generate debug information by default, but you can always request it ("-O3 -g" is a perfectly fine combination of flags).

Not really, because some optimizations get the step through and such rather confusing.

VC++ dynamic debugging pretends the code motion, inlining and similar optimizations aren't there and maps back to the original code as written.

Unless this has been improved for gdb,lldb.

Re: Is Rust faster than C?

#304

Post by stonogo »

pornel wrote: post #76

In short, the maximum possible speed is the same (+/- some nitpicks), but there can be significant differences in typical code, and it's hard to define what's a realistic typical example. The big one is multi-threading. In Rust, whether you use threads or not, all globals must be thread-safe, and the borrow checker requires memory access to be shared XOR mutable. When writing single-threaded code takes 90% of effort…

    Even just spawning a thread is going to make somebody complain that they can't build the code on their platform due to C11/pthread/openmp.
This matches squarely with my experience, but it's not limited to threading, and Rust evades a large swath of these problems by relatively limited platform support. I look forward to the day I can run Rust wherever I run C!

Re: Is Rust faster than C?

#305

Post by pjmlp »

pmarin wrote: post #182
bfrog wrote: post #9

One example where Rust enables better and faster abstractions is traits. C you can do this with some ugly methods like macros and such but in Rust it’s not the implementers choice it’s the callers choice whether to use dynamic dispatch (function pointer table in C) or static dispatch (direct function calls!) In c the caller isn’t choosing typically. The author of some library or api decides this for you. This turns o…

The C way is to avoid abstractions in first place.

Yet it is one in itself, otherwise UNIX would still be written in Assembly.

Re: Is Rust faster than C?

#306

Post by pjmlp »

OskarS wrote: post #51

I think personally the answer is "basically no", Rust, C and C++ are all the same kind of low-level languages with the same kind of compiler backends and optimizations, any performance thing you could do in one you can basically do in the other two. However, in the spirit of the question: someone mentioned the stricter aliasing rules, that one does come to mind on Rust's side over C/C++. On the other hand, signed int…

And compile time execution.

With C you only have macro soup and the hope the compiler might optimise some code during compilation into some kind of constant values.

With C++ and Rust you're sure that happens.

Re: Is Rust faster than C?

#307

Post by pjmlp »

jandrewrogers wrote: post #172
gf000 wrote: post #139

Earlier quoted context omitted.

> I can write C that is as fast as C++ I generally agree with your take, but I don't think C is in the same league as Rust or C++. C has absolutely terrible expressivity, you can't even have proper generic data structures. And something like small string optimization that is in standard C++ is basically impossible in C - it's not an effort question, it's a question of "are you even writing code, or assembly".

Yes, it is the difference between "in theory" and "in practice". In practice, almost no one would write the C required to keep up with the expressiveness of modern C++. The difference in effort is too large to be worth even considering. It is why I stopped using C for most things. There is a similar argument around using "unsafe" in Rust. You need to use a lot of it in some cases to maintain performance parity with C…

Also in theory, one could be using a static analyser all the time as a C or C++ build step.

Lint is part of UNIX toolset since 1979, and we have modern versions freely available like clang tidy.

In practice, many devs keep thinking they know better.

Re: Is Rust faster than C?

#308

Post by usrnm »

oconnor663 wrote: post #281
arghwhat wrote: post #112

Earlier quoted context omitted.

To be honest, I think a lot of the justification here is just a difference in standard library and ease of use. I wouldn't consider there to be any notable effort in making thread build on target platforms in C relative to normal effort levels in C, but it's objectively more work than `std::thread::spawn(move || { ... });`. Despite benefits, I don't actually think the memory safety really plays a role in the usage ra…

> Despite benefits, I don't actually think the memory safety really plays a role in the usage rate of parallelism. I can see what you mean with explicit things like thread::spawn, but I think Tokio is a major exception. Multithreaded by default seems like it would be an insane choice without all the safety machinery. But we have the machinery, so instead most of the async ecosystem is automatically multithreaded, and…

> Multithreaded by default seems like it would be an insane choice without all the safety machinery

You're describing golang, and somehow it's fine. Bugs are possible, but not super common

Re: Is Rust faster than C?

#309

Post by rtpg »

stonogo wrote: post #304
pornel wrote: post #76

In short, the maximum possible speed is the same (+/- some nitpicks), but there can be significant differences in typical code, and it's hard to define what's a realistic typical example. The big one is multi-threading. In Rust, whether you use threads or not, all globals must be thread-safe, and the borrow checker requires memory access to be shared XOR mutable. When writing single-threaded code takes 90% of effort…

Even just spawning a thread is going to make somebody complain that they can't build the code on their platform due to C11/pthread/openmp. This matches squarely with my experience, but it's not limited to threading, and Rust evades a large swath of these problems by relatively limited platform support. I look forward to the day I can run Rust wherever I run C!

While Rust doesn't have C coverage, it has (by my last check) better coverage than something like CPython currently does.

The big thing though is Rust is honest about their tiers of support, whereas for many projects "supported platform" for minor platforms often mean "it still compiles (at least we think it does, when the maintainer tries it and it fails they will fix it)"

Not to be too glib though, there are obviously tools out there that have as much or more rigor than Rust and cover more platforms. Just... "supported platforms" means different things in different contexts.

Re: Is Rust faster than C?

#310

Post by vlovich123 »

OskarS wrote: post #51

I think personally the answer is "basically no", Rust, C and C++ are all the same kind of low-level languages with the same kind of compiler backends and optimizations, any performance thing you could do in one you can basically do in the other two. However, in the spirit of the question: someone mentioned the stricter aliasing rules, that one does come to mind on Rust's side over C/C++. On the other hand, signed int…

I’m not sure about the other UB opportunities, but in idiomatic rust code this just doesn’t come up.

In C, you frequently write for loops with signed integer counters for the compiler to realize the loop must hit the condition. In Rust you write for..each loops or invoke heavily inlined functional operators. It ends up all lowering to the same assembly. C++ is the worst here because size_t is everywhere in the standard library so you usually end up using size_t for the loop counter, negating the ability for the compiler to exploit UB.

Post reply on HN