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

521–530 of 546 posts

Re: Speed of Rust vs. C

#521

Post by burntsushi »

eru wrote: post #493
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 suspect Don Stewart might be able to do it in Haskell. That's basically by knowing enough about GHC to carefully trigger all the relevant optimizations.

Hah. I'm highly skeptical. But I suppose if anyone could do it, it'd be him. I would certainly learn something. :-)

I've tried optimizing Haskell code myself before. It did not go well. It was an implementation of the Viterbi algorithm actually. We ported it to Standard ML and C and measured performance. mlton did quite well at least.

We published a paper about the process of writing Viterbi in Haskell in ICFP a few years back: https://dl.acm.org/doi/pdf/10.1145/2364527.2364560?casa_toke...

Unfortunately, the performance aspect of it was only a small part, and we didn't talk about the C or mlton ports in the paper.

Re: Speed of Rust vs. C

#522

Post by loeg »

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…

I didn't understand what you meant by a trait object, mea culpa.

Re: Speed of Rust vs. C

#523

Post by tsegratis »

eru wrote: post #466
tsegratis wrote: post #321

Earlier quoted context omitted.

I anticipated my own falsity. I'm aware and at home with it

Huh? Why do you say something that you anticipate to be false?

Simply bervity

I anticipated I could well be wrong. I ALSO anticipated it would be a hard statement for people to take

I think it was a reasonable statement -- I can't research everything I say, and I had read re2 and regexes in rust to be the same

Interesting to read about redgrep and derivatives approach. Currently I'm programming a language that adds turing completeness to PEG expressions -- as in functions, but extended so the lhs is like a PEG -- just as function body can call sub functions, so too can the lhs

I'm hoping this will give a simple unified language

--

Philosophically:

We make mistakes. If we can't handle that, then either we don't speak or program; or we deny it, program in c, then have flamewars and real wars

Or thirdly, we accept it, program in rust, and let others correct us

We can say you are my rustc compiler. So in effect I used a rust philosophy..... While programming in c

Re: Speed of Rust vs. C

#524

Post by shakow »

pjmlp wrote: post #515
shakow wrote: post #504

Earlier quoted context omitted.

Such as?

Any blog post that gives examples accessing shared variables and never goes beyond anything else, leaving to the reader that it works the same way regardless of what resources are being accessed. https://blog.knoldus.com/how-we-can-do-fearless-concurrency-... Now rewrite the same blog post using SQL queries to update the same counter variable on a table row. The Rustonomicon is quite clear that it wouldn't work, > Ho…

You really had to dig a post that has less text than code?

> leaving to the reader that it works the same way regardless of what resources are being accessed.

If that's how readers envision that non-language-managed resources work, they should go back to CS102 right now.

And concerning the nomicon, it explicitly states that Rust can't handle all races condition, I don't get your point.

Re: Speed of Rust vs. C

#525

Post by up2isomorphism »

ben0x539 wrote: post #427
up2isomorphism wrote: post #290

Earlier quoted context omitted.

Actually I never see any occasion that a C guys jump into a well establish project and ask them to rewrite that in C. And TBH I rarely see other popular language did the similar things either, including very popular ones like python, Java or Go. And you even observe there is thing called "C evangelism" actually exists?

Yeah? Check out any very public discussion of Rust and to a first approxiation there's always gonna be someone talking about how we should all just be using C instead. It's also not hard to find instances in open source projects of people ascribing ulterior motives or brain damage or ineptitude or whatever to anyone using another programming language. They don't call it C-lioning for nothing :^)

Can you give an example instead of just describing something rarely happened?

For rust this is certainly the case, demonstrated by this thread and almost any other thread about rust, it is . TBH it is a pattern to see title "fastest xxx written in rust".

C programmers do not have the tradition to ASK other people to write something in C, they WRITE something in C. That's the real difference here.

Re: Speed of Rust vs. C

#526

Post by drran »

bsder wrote: post #110
scorpion95 wrote: post #90

Earlier quoted context omitted.

Which form of Rust parallelism did you choose? I’ve read that the old one sucks. Certainly Rust is different beast than C. Code converted from C to Rust seems much more voluminous. Perhaps it’s easier to maintain if you know Rust well? I cannot believe at first that Rust is ever more performant than C, as C could be made parallel and seems more barebones. One of the languages that CUDA can be used with is C, so I sus…

> Code converted from C to Rust seems much more voluminous. This is a fairly odd claim. If you have to deal with strings (ASCII and UTF-8) properly, C is stupidly verbose. If you need a data structure more complex than an array of something, C is stupidly verbose. If you want to deal with pattern matching/regexen, C is ridiculously verbose. Do I agree that Rust is far more verbose for an embedded "blinky" (the embedd…

Blink in rust is concise as well:

  // Main function
  #[arduino_uno::entry]
  fn main() -> ! {
    let peripherals = arduino_uno::Peripherals::take().unwrap();

    let mut pins = arduino_uno::Pins::new(
        peripherals.PORTB,
        peripherals.PORTC,
        peripherals.PORTD,
    );

    // Pin D13 is connected to L led
    let mut led = pins.d13.into_output(&mut pins.ddr);

    loop {
        led.toggle().void_unwrap();
        arduino_uno::delay_ms(500);
    }
  }
https://github.com/vlisivka/rust-arduino-blink/blob/main/src...

Re: Speed of Rust vs. C

#527

Post by up2isomorphism »

BatmanAoD wrote: post #481
up2isomorphism wrote: post #283

My experience is that languages survives not because of a particular feature, but because they are USEFUL in practice to produce a software. The fact that C is used in so many places speaks for itself about it usefulness. And this is done by writing software by majority of C programmers instead of jumping on every forum to attack other languages, writing extended blog posts just to convince people that they "should"…

Nothing in this article seems to be saying that C "isn't useful". It also doesn't state that bounds checks are the "most difficult thing in software development." As the article mentions, C is 50 years old. The fact that it's still used is evidence of its usefulness, sure. It has outlasted almost all of its peers. Rust has been stable for under 6 years. In that time, it's been adopted by a slew of major companies, an…

The article is using one or two features in a quick marketing style to promote rust.

- Regardless it is true or not, this seldom works in long term. I just simply point this observation out.

In fact language as tool is never about more features, it is about minimum features for maximize utilities, and Rust is already on the domain of "feature-rich" language.

Re: Speed of Rust vs. C

#528

Post by tsegratis »

tsegratis wrote: post #523
eru wrote: post #466

Earlier quoted context omitted.

Huh? Why do you say something that you anticipate to be false?

Simply bervity I anticipated I could well be wrong. I ALSO anticipated it would be a hard statement for people to take I think it was a reasonable statement -- I can't research everything I say, and I had read re2 and regexes in rust to be the same Interesting to read about redgrep and derivatives approach. Currently I'm programming a language that adds turing completeness to PEG expressions -- as in functions, but e…

In one word: Jesus

Re: Speed of Rust vs. C

#529

Post by mplanchard »

tsegratis wrote: post #523
eru wrote: post #466

Earlier quoted context omitted.

Huh? Why do you say something that you anticipate to be false?

Simply bervity I anticipated I could well be wrong. I ALSO anticipated it would be a hard statement for people to take I think it was a reasonable statement -- I can't research everything I say, and I had read re2 and regexes in rust to be the same Interesting to read about redgrep and derivatives approach. Currently I'm programming a language that adds turing completeness to PEG expressions -- as in functions, but e…

I guess the thing is that if we’re not sure whether or not what we’re saying is true, it can be considerate to phrase it that way, e.g. “I think ripgrep’s regex library is written in C” rather than stating it as a fact. While it is particularly likely that folks on this website will correct mistaken statements, stating them as fact seems more likely to potentially spread misinformation.

But anyways, cheers and good luck with your programming language!

Re: Speed of Rust vs. C

#530

Post by howinteresting »

pjmlp wrote: post #499
howinteresting wrote: post #449

Earlier quoted context omitted.

There is a very big difference between what particular environments offer in theory (yes, you can write object pools in Java and many high-performance projects use them) and the situation in practice (there are people who spend a large chunk of their professional careers doing JVM tuning). Idiomatic Rust avoids the situations which require JVM tuning experts. You can write a Rust service, put it into production and t…

Only when speaking about kernel code, drivers, and similar scenarios. You are the one focusing in Java, and in your answer proved exactly my point of knowing stacks superficially. Object pools aren't the only way to reduce memory footprint in Java. A bit of FFI into host OS syscalls and it is done, or a tiny high performance native library for a custom data structures and ready for the races. No need to throw away 25…

I've written three of those sorts of native libraries before, and it's just awfully inconvenient compared to just using Rust to be honest.
Post reply on HN