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

371–380 of 402 posts

Re: Is Rust faster than C?

#371

Post by jibal »

aw1621107 wrote: post #257
jibal wrote: post #159

Earlier quoted context omitted.

We recently had a post here where the claim being refuted was in quotes in the title, but half the comments were as if the article were making the claim, clearly indicating that people didn't read it (and don't understand how quote marks work).

Assuming I'm thinking of the same submission as you, the quotes were not present in the original submission [0]. [0]: https://news.ycombinator.com/item?id=46525937

They were (are) in the article title, so that doesn't change the point that it proves that people didn't read it.

Re: Is Rust faster than C?

#372

Post by ActorNightly »

mid-kid wrote: post #54

I almost ignored this post because I can't stand this particular war, where examples are cherry picked to prove either answer. I'm very happy to see the nuanced take in this article, slowly deconstructing the implicit assumptions proposed by the person asking this question, to arrive at the same conclusion that I long have. I hope this post reaches the right people. A particular language doesn't have a "speed", a par…

Here is my issue

> Is Rust faster than C

> Example:

>... unsafe...

Its like Rust proponents can't even see the irony.

Re: Is Rust faster than C?

#373

Post by superkuh »

junon wrote: post #369
superkuh wrote: post #363

Earlier quoted context omitted.

It's not a hypothetical. I was put off the entire language after it happened to me three times in a row with unrelated Rust written software. This was 1 month after Debian 12 was released (June 10, 2023) and I was running the brand new Debian 12 with rustc 1.63.0 from August 11, 2022. I ran into it with some web serial spidering and epub creation rust software (rust-wildbow-scraper). I ran into with a software define…

No, it's not. Your own misunderstandings of rust stable vs nightly and editions and using an unofficial installation method for a toolchain are not Rust's shortcomings. Sorry.

Ah, I see you are confused. I am claiming that rust is only for rolling distros because of it's needs for it's unique "official installation method" because of rapid addition of features making rustc need to be upgraded constantly. These facts are not in dispute though one's appreciation of the consequences apparently is.

Re: Is Rust faster than C?

#374

Post by steveklabnik »

johnisgood wrote: post #364
steveklabnik wrote: post #345

Earlier quoted context omitted.

When a basic question is asked, a basic answer is given. I didn’t say that I think that’s the coolest or most interesting answer. It’s just the most obvious, straightforward one. It’s not even about Rust! (And also, I don’t think things like work stealing queues are relevant to editors, but maybe that’s my own ignorance.)

You cannot have it both ways though. Either these are meaningful examples of Rust's benefits, or they are not worth mentioning. In a thread about Rust's concurrency advantages, these editors were cited as examples. "Don't block the UI thread" as justification only works if Rust actually provides something novel here. If it is just basic threading that every language has done for decades, it should not have been broug…

Here is the question that was asked:

> What do you think are good use cases for multi threading in these editors?

That question is not even about Rust. I answered the question, not some other related question.

Re: Is Rust faster than C?

#375

Post by steveklabnik »

steveklabnik wrote: post #346
marcosdumay wrote: post #234

Earlier quoted context omitted.

> you can store that T in any other generic struct that's parametrized by BarTrait, for example Not really. You can store it on any struct that specializes to the same type of the value you received. If you get a pre-built struct from somewhere and try to store it there, your code won't compile.

Can you show me what you’re talking about? I don’t understand what you mean. I’ll add a code example of what I mean in a bit.

Here's what I'm talking about: https://play.rust-lang.org/?version=stable&mode=debug&editio...

Re: Is Rust faster than C?

#376

Post by mywittyname »

ActorNightly wrote: post #372
mid-kid wrote: post #54

I almost ignored this post because I can't stand this particular war, where examples are cherry picked to prove either answer. I'm very happy to see the nuanced take in this article, slowly deconstructing the implicit assumptions proposed by the person asking this question, to arrive at the same conclusion that I long have. I hope this post reaches the right people. A particular language doesn't have a "speed", a par…

Here is my issue > Is Rust faster than C > Example: >... unsafe... Its like Rust proponents can't even see the irony.

I agree, I thought this was a weird example - but I'm not a Rust nor C programmer.

I assume this example is used because programmers of either language reach for asm when looking for raw performance. But to me, it's shouldn't even be a discussion point, since even I know both languages can be made to emit the same assembly.

Also, I think it side-steps the hard parts of the question - which is, what are the performance impacts of Rust safety?

Re: Is Rust faster than C?

#377

Post by tick_tock_tick »

josephg wrote: post #288
jandrewrogers wrote: post #286

Earlier quoted context omitted.

They are likely referring to the scope of fine-grained specialization and compile-time codegen that is possible in modern C++ via template metaprogramming. Some types of complex optimizations common in C++ are not really expressible in Rust because the generics and compile-time facilities are significantly more limited. As with C, there is nothing preventing anyone from writing all of that generated code by hand. It…

Again, can you provide an example or two? Its hard to agree or disagree without an example. I think all C++ wild template stuff can be done via proc macros. Eg, in rust you can add #[derive(Serialize, Deserialize)] to have a highly performant JSON parser & serializer. And thats just lovely. But I might be wrong? And maybe its ugly? Its hard to tell without real examples.

Rust doesn't allow specialization and likely never will because it's unsound https://www.reddit.com/r/rust/comments/1p346th/specializatio... has a couple of nice comments about it.

But yes it's basically

template class Example { vector generic; };

template class Example { int bitpackinhere; }

Re: Is Rust faster than C?

#378

Post by seanw444 »

pjmlp wrote: post #370
seanw444 wrote: post #367

Earlier quoted context omitted.

Assembly itself is an abstraction. UNIX should have been written in machine code.

It was until version 4, when the C rewrite took place as it wasn't fun to keep writing it in Assembly.

Assembly code != machine code

Re: Is Rust faster than C?

#379

Post by pjmlp »

seanw444 wrote: post #378
pjmlp wrote: post #370

Earlier quoted context omitted.

It was until version 4, when the C rewrite took place as it wasn't fun to keep writing it in Assembly.

Assembly code != machine code

Depends if you have an Assembler at hand, or a plain hexdump monitor, hopefully with a checksum entry on each row.

Re: Is Rust faster than C?

#380

Post by 1718627440 »

OskarS wrote: post #124
foldr wrote: post #99

Earlier quoted context omitted.

>in Rust and C++, the standard library sorting functions are templated on the comparison function. This means it's much easier for the compiler to specialize the sorting function, inline the comparisons and optimize around it. I think this is something of a myth. Typically, a C compiler can't inline the comparison function passed to qsort because libc is dynamically linked (so the code for qsort isn't available). But…

qsort is obviously just an example, this situation applies to anything that takes a callback: in C++/Rust, that's almost always generic and the compiler will monomorphize the function and optimize around it, and in C it's almost always a function pointer and a userData argument for state passed on the stack. (and, of course, it applies not just to callbacks, but more broadly to anything templated). I'm actually very…

If you choose to put a boundary in your code that makes it span over several binaries, so that they can be swapped out at runtime, no compiler in any language can optimize that away, because that would be against the interface you explicitly chose. That's what dynamic linking aka. runtime linking is in C.

This is not an issue for libc, because the behaviour of that is not specified by the code itself, but by the spec, which is why C compilers can and do completely remove or change calls to libc, much to the distress of someone expecting a portable assembler.

Post reply on HN