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

Speed of Rust vs. C

kornel.ski

Post reply on HN
Print view View original

361–370 of 546 posts

Re: Speed of Rust vs. C

#361

Post by cb321 »

burntsushi wrote: post #351
pjmlp wrote: post #332

Earlier quoted context omitted.

Python isn't really something I would even think as possible example, Common Lisp, D, Nim, Swift, most likely.

So? I said, "higher level language." I didn't say, "Python specifically." I would guess D could do it. I don't know enough about Nim or Swift. I would learn something if Common Lisp did it. I'd also learn something if Haskell or Go did it.

I am not trying to contradict anyone here, but any language mature enough to have an impl/way to not have arbitrary performance ceilings needs access to inline assembly/SIMD. Cython/Nim/SBCL can all do that..probably Haskell..Not so sure about Go or Swift. Anyway, many languages can respond well to optimization effort. I doubt anyone disagrees.

At the point of realizing the above no ceiling bit, the argument devolves to more one about (fairly subjective) high/low levelness of the code itself/the effort applied to optimizing, not about the language the code is written in. So, it's not very informative and tends to go nowhere (EDIT: especially when the focus is on a single, highly optimized tool like `rg` as opposed to "broad demographic traits" of pools of developers, and "levelness" is often somewhat subjective, too).

Re: Speed of Rust vs. C

#362

Post by hctaw »

howinteresting wrote: post #325
planetis wrote: post #176

Its just amusing, in this thread everyone with critical thinking and skeptical is down voted, even if one expresses himself moderately. It shows how much of zealots, Rust fanboys have become.

Bothsidesism is unhelpful in technical discussions just as much as in politics. If you have specific critiques please share them. I have a number of specific critiques of Rust, chief being that APIs and implementations are bound too tightly. &[String] and &[&str] are logically similar but changing from one to the other in your implementation might mean a breaking API change.

    fn func (slice: &[impl AsRef]) {
        // ...
    }

Re: Speed of Rust vs. C

#363

Post by anaerobicover »

eru wrote: post #175
anfilt wrote: post #118

Earlier quoted context omitted.

Firefox's is compiled code is mostly written in C++ not C. You conflate C with C++, Java, and C#. C++ while has source compatibility with C tends to end up much different than C. C will not give you the OOP hell-scape you can dig yourself into with those three languages. C code tends be simpler and much more close to the assembly that will be generated than you would get in those language. Moreover, Java and C# are n…

> Some people even feel C++ keeps adding too many new features too fast. It's not so much that they keep adding features, but that they (almost?) never remove any.

Are there many other programming languages that remove features?

Re: Speed of Rust vs. C

#364

Post by pornel »

secondcoming wrote: post #173
vlmutolo wrote: post #4

> "Clever" memory use is frowned upon in Rust. In C, anything goes. For example, in C I'd be tempted to reuse a buffer allocated for one purpose for another purpose later (a technique known as HEARTBLEED). This made me laugh

It was quite funny but it's quite likely you'll be reusing memory anyway whether it's on the stack or the heap, no? The issue with this is that 'clever' compilers can optimise out any memset calls you do.

Rust's safety rules also forbid access to uninitialized memory, even if it's just a basic array of bytes. This is an extra protection against accidentally disclosing data from a previous "recycled" allocation.

Re: Speed of Rust vs. C

#365

Post by steveklabnik »

Tuna-Fish wrote: post #352
loeg wrote: post #343

Earlier quoted context omitted.

> As someone who uses a lot of rust, they are sort of the red-headed stepchild. As a minimum to make the properly usable, we need a way of passing one object with multiple different traits. What do you mean? fn foo (x: T) { T.something(); }

Unless TraitB is an auto trait, that isn't currently valid? From the reference: > Trait objects are written as the optional keyword dyn followed by a set of trait bounds, but with the following restrictions on the trait bounds. All traits except the first trait must be auto traits, there may not be more than one lifetime, and opt-out bounds (e.g. ?Sized) are not allowed. The only one of those restrictions that is acc…

This is not a trait object, and so that part of the reference is irrelevant.

Here's that example working: https://play.rust-lang.org/?version=stable&mode=debug&editio...

I am not entirely sure that it answers your point though; what you want is trait A or trait B, not both, right?

Re: Speed of Rust vs. C

#366

Post by vll100 »

ben0x539 wrote: post #162
dig1 wrote: post #142

> For example, in C I'd be tempted to reuse a buffer allocated for one purpose for another purpose later (a technique known as HEARTBLEED). You can do that in Java (with byte arrays) or in Common Lisp, so what is the point here? It is not practice in Java, Lisp nor in C and C++. > It's convenient to have fixed-size buffers for variable-size data (e.g. PATH_MAX) to avoid (re)allocation of growing buffers This is becau…

Any book you'd recommend to back up your claims?

How about learning some C instead of asking passive aggressive questions all over this discussion?

Re: Speed of Rust vs. C

#367

Post by jmacjmac »

dralley wrote: post #298
jmacjmac wrote: post #188

Earlier quoted context omitted.

https://github.com/emmericp/ixy/blob/0e00605be4153b06df06184... Looks like you're compiling C code with -O2. Does Rust build set -O3 on clang? Did you try -O3 with C? I know it's not guaranteed to be faster, just curious.

It looks like the answer is "yes" https://doc.rust-lang.org/cargo/reference/profiles.html#rele...

Then a fair benchmark would be compiling C code with clang -O3 :)

Re: Speed of Rust vs. C

#368

Post by Tuna-Fish »

steveklabnik wrote: post #365
Tuna-Fish wrote: post #352

Earlier quoted context omitted.

Unless TraitB is an auto trait, that isn't currently valid? From the reference: > Trait objects are written as the optional keyword dyn followed by a set of trait bounds, but with the following restrictions on the trait bounds. All traits except the first trait must be auto traits, there may not be more than one lifetime, and opt-out bounds (e.g. ?Sized) are not allowed. The only one of those restrictions that is acc…

This is not a trait object, and so that part of the reference is irrelevant. Here's that example working: https://play.rust-lang.org/?version=stable&mode=debug&editio... I am not entirely sure that it answers your point though; what you want is trait A or trait B, not both, right?

Ah sorry, no, what I want is specifically a trait object that satisfies both trait A and B.

Re: Speed of Rust vs. C

#369

Post by burntsushi »

cb321 wrote: post #361
burntsushi wrote: post #351

Earlier quoted context omitted.

So? I said, "higher level language." I didn't say, "Python specifically." I would guess D could do it. I don't know enough about Nim or Swift. I would learn something if Common Lisp did it. I'd also learn something if Haskell or Go did it.

I am not trying to contradict anyone here, but any language mature enough to have an impl/way to not have arbitrary performance ceilings needs access to inline assembly/SIMD. Cython/Nim/SBCL can all do that..probably Haskell..Not so sure about Go or Swift. Anyway, many languages can respond well to optimization effort. I doubt anyone disagrees. At the point of realizing the above no ceiling bit, the argument devolves…

You're missing the context I think. Look at what I was responding to in my initial message in this thread:

> If you have an architecture where you can afford real parallelism you can afford higher level languages anyway.

My response is, "no you can't, and here's an example."

> but any language mature enough to have an impl/way to not have arbitrary performance ceilings needs access to inline assembly/SIMD

If you ported ripgrep to Python and the vast majority of it was in C or Assembly, then I would say, "that's consistent with my claim: your port isn't in Python."

My claim is likely more subtle than you might imagine. ripgrep has many performance sensitive areas. It isn't enough to, say, implement the regex engine in C and write some glue code around that. It won't be good enough. (Or at least, that's my claim. If I'm proven wrong, then as I said, I'd learn something.)

> At the point of realizing the above no ceiling bit, the argument devolves to more one about (fairly subjective) high/low levelness of the code itself/the effort applied to optimizing, not about the language the code is written in. So, it's not very informative and tends to go nowhere.

I agree that it's pretty subjective and wishy washy. But when someone goes around talking nonsense like "if parallelism is a benefit then you're fine with a higher level language," you kind of have to work with what you got. A good counter example to that nonsense is to show a program that is written is a "lower" level language that simultaneously benefits from parallelism and wouldn't be appropriate to do in a higher level language. I happen to have one of those in my back-pocket. :-) (xsv is another example. Compare it with csvkit, even though csvkit's CSV parser is written in C, it's still dog slow, because the code around the CSV parser matters.)

Re: Speed of Rust vs. C

#370

Post by nindalf »

cambalache wrote: post #358
nindalf wrote: post #264

Earlier quoted context omitted.

The problem is that most people criticising Rust don't make the case very well. If you want to read good critique, I'd recommend this - https://matklad.github.io/2020/09/20/why-not-rust.html . This post up-to-date, succinct and objective. And most pertinently, this critique was written by someone who genuinely loves programming in Rust. Shows you that Rust users aren't blinded to the faults of the language. You shoul…

> And most pertinently, this critique was written by someone who genuinely loves programming in Rust. That is putting the bar impossible high. I would expect most of the criticism to come from people who hate to program in Rust, which it is fine as long as the criticism is well argued.

I'm not putting the bar high. I'm giving an example of people who love Rust criticising Rust. Person I replied to claimed that Rust fanboys didn't do this because they were zealots. That's not true, clearly.

I've read a lot of criticism of Rust and most of it is from people who tried it for a weekend, couldn't understand the borrow checker and wrote some low quality criticism of it. If someone points out problems in that post, they are accused of zealotry and fanboyism.

Read the post I linked. It covers all the issues and makes the strongest possible case against the language. Then tell me if you've ever seen one that is as negative, accurate and succinct as that one.

Post reply on HN