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

501–510 of 546 posts

Re: Speed of Rust vs. C

#501

Post by rstuart4133 »

andrepd wrote: post #257
pdimitar wrote: post #201

Earlier quoted context omitted.

Lately on another Rust thread somebody pointed out that C programs use a lot of indirection like pointers and vtable dispatches which actually detracts from the supposed mega-speed of the low-level C. I found that to be mind-blowing and felt stupid for not remembering that earlier.

I don't think vtables are often used in C.

It's true they aren't that common, but have you looked at the Linux kernel code? It's written in C, and vtables are everywhere.

I've also used them on occasions. They do a particular job people call pluggable implementations / dynamic typing / sub-classing depending on their background. If there isn't some central place that knows all the types (if there is you can use switch/case/match), there isn't much choice, it's vtables or nothing. But needing to do that job is rare, so seeing it in languages that don't use vtables promiscuously to implement OO is correspondingly rare.

Which is as it should be, because vtables are more expensive than a direct call, very expensive if they prevent inlining. One of rust's triumphs is it provides them, but you have to go out of your way to use them so it encourages avoiding their overheads.

Re: Speed of Rust vs. C

#502

Post by branko_d »

Chilinot wrote: post #139
bluejekyll wrote: post #137

Earlier quoted context omitted.

Rust won’t prevent all manner of bugs, but if you need to prevent multiple parts of your application from accessing a resource concurrently, it’s fairly trivial to design types that would guarantee that at compile time. If you need to do it across processes, then you need a file system that supports exclusive file opens. The db question is a red-herring, because to properly solve for concurrency in the db, you need t…

You dont necessarily need to use locks in the db. You can use transactions as well, unless you want to do major changes to the DB where transactions would be in constant conflict state.

Locks and transactions are intertwined. Write locks are typically released only when the transaction ends, and read locks too at some transaction isolation levels.

Re: Speed of Rust vs. C

#503

Post by rstuart4133 »

burntsushi wrote: post #319
tsegratis wrote: post #309

Earlier quoted context omitted.

The interesting thing here is that rust has good threading and fantastic crates I played with making a regex library in rust. Which, as per RE2 design involves constructing graphs and glueing them together as the regex is traversed This requires a cycle catching gc, or, just a preallocated arena... It was my first foray into rust and felt I would need to be hitting into unsafe, which I wasn't ready for. Array indexin…

You're overcomplicating it. When it comes to finite state machines at least, it's very easy to use an ID index instead of the raw pointer itself. That's exactly what the regex crate does. For reference, I am also the author of the regex crate. The only unsafe it uses specific to finite automata is to do explicit elimination of bounds checks in the core hybrid NFA/DFA loop.

> When it comes to finite state machines at least, it's very easy to use an ID index instead of the raw pointer itself.

As an old C programmer, the difference between an array index and a pointer caught me by surprise. In C a pointer is just an unchecked offset into memory. A real array index is just a unchecked offset into ... maybe a smaller chunk of raw memory.

But in rust, an array index is something that comes with additional bounds checking overheads with every use. And the memory it points to is also constrained - the entire array has to be initialised, so if the index passes the bounds check you are guaranteed rusts memory consistency invariants are preserved. Indexes also allow you to escape the borrow checker. If you own the slice, there is no need to prove you can access an element of the slice.

So yeah, you can use indexes instead of pointers, but for rust that's like saying you can use recursion instead of iteration. Indexing and pointers are two very different things in rust.

Re: Speed of Rust vs. C

#504

Post by shakow »

pjmlp wrote: post #317
hderms wrote: post #200

Earlier quoted context omitted.

Yeah it would be a grave misinterpretation of "fearless concurrency" to think Rust somehow validates that access to some shared resource with it's own semantics is also safe. I'm not educated on the subject but that problem seems pretty intractable for a language to solve in a general sense.

Indeed, yet that is not how many Rust advocacy blog posts sell it.

Such as?

Re: Speed of Rust vs. C

#505

Post by cb321 »

rocqua wrote: post #380
cb321 wrote: post #211

Earlier quoted context omitted.

You are right in a library-demographical sense, but not in a fundamental sense. There is a 3rd way. Have a look at the CTL I linked to (downvoted..maybe I should have explained more?). Once you give up the closed source/prebuilt binary library idea and embrace the C++-like header library idea and write implemenations in terms of "assumed macro/inline function" definitions, the problem becomes straightforward with no…

I had a look, and it feels like template programming but with even worse guarantees. Having a type declaration dependent on #define P whether it is plain old data or not, and needing to know what that means, is not the kind of ergonomics I'd want. That requires learning a whole new paradigm to ensure I am not doing wrong things. In my mind it is so big an extension of the C language, that it leaves the C headspace an…

Yeah. It's not for everyone. I think "different ergonomic issues" may cover that and I did mention the type checking already. :-)

It is a smaller learning curve from pure C than "all of Rust" or even "all of C++/STL". You got the basic idea in short order (that may be for ill as well as good..I was never trying to make a normative claim).

Re: Speed of Rust vs. C

#506

Post by eru »

pjmlp wrote: post #496
eru wrote: post #489

Earlier quoted context omitted.

Haskell has also removed some features over time.

Haskell or GHC? If you mean GHC, the language version is whatever the pile of configuration flags at each source file ends up meaning, some of them even contradict themselves. Great for language research, which is Haskell main purpose in life, hardly a good idea for getting industry love.

I am talking about Haskell, specifically the removal of 'n+k patterns' and 'monad comprehensions'.

About GHC: I think their approach with pragmas is great and something for other languages to emulate. It's also great in production, with the caveat that you might want to restrict that mechanism to surface level changes only, and nothing that changes the intermediate format.

Re: Speed of Rust vs. C

#507

Post by [deleted] »

ben0x539 wrote: post #426
carols10cents wrote: post #355

Earlier quoted context omitted.

Why would you guess about how much C or Rust code that ripgrep contains when you could very quickly look? https://github.com/BurntSushi/ripgrep

Hm, how do I go from the github repo to a language breakdown of the dependency tree?

[deleted]

Re: Speed of Rust vs. C

#508

Post by cambalache »

steveklabnik wrote: post #372
cambalache wrote: post #358

Earlier quoted context omitted.

> 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.

You've got the contrapositive there. The claim was that folks who love Rust do not accept criticism of the language. Therefore, a criticism by someone who loves the language was presented, to show that claim was false. Your parent isn't saying that only folks who love Rust can criticize Rust.

Point A: The claim was that folks who love Rust do not accept criticism of the language.

Point B: a criticism by someone who loves the language was presented, to show that claim was false.

Point B does not contradict point A at all. That is like saying that is false I cannot accept criticism because , hey, look at the weak points I have and I gladly mention("I am too perfectionist","I work too hard", "I put the wellness of the company ahead of myself")

Re: Speed of Rust vs. C

#509

Post by shakow »

gspr wrote: post #197
rectang wrote: post #18

Earlier quoted context omitted.

> ABI compatibility Rust provides ABI compatibility against its C ABI, and if you want you can dynamically link against that. What Rust eschews is the insane fragile ABI compatibility of C++, which is a huge pain to deal with as a user: https://community.kde.org/Policies/Binary_Compatibility_Issu... I don't think we'll ever see as comprehensive an ABI out of Rust as we get out of C++, because exposing that much incid…

Rust seems great to me, but aren't we losing a lot by giving up on C's dynamic linking and shared libraries?

Dynamic linking and shared libraries are an OS feature, not a C one. C worked fine on DOS with no DLLs at the time.

This being said, Rust has no problem using dynamic libraries.

Re: Speed of Rust vs. C

#510

Post by cambalache »

nindalf wrote: post #370
cambalache wrote: post #358

Earlier quoted context omitted.

> 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…

> 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

But that was OP's point.If your best example of Rust lovers accepting criticism of the language is the existence of a critical article written by a Rust lover, that does no say anything. The bar is naively high if the best example you got of tolerance to criticism was a critical article made by a member of the "tribe". The implicit point is that those kind of articles will be the ones playing "soft ball" with the language,so any perceived tolerance to criticism is almost meaningless.

Post reply on HN