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

541–546 of 546 posts

Re: Speed of Rust vs. C

#541

Post by kibwen »

ameliaquining wrote: post #324
kibwen wrote: post #286

Earlier quoted context omitted.

You have correctly identified it as FUD. People have a bone to pick with Pin, so they irrationally latch on to it, but the general problem is the fact that the &mut invariants cannot currently permit any self-referential data, which is a useful concept in general (for intrusive data structures, etc) and whose lack that people have been hacking around since before 1.0, with crates like rental and owning_ref. The plan…

Source? I would like this to be true, but I haven't actually seen it anywhere.

Here's Niko Matsakis' take: https://github.com/rust-lang/rust/issues/63818#issuecomment-...

Re: Speed of Rust vs. C

#542

Post by kibwen »

dataangel wrote: post #354
kibwen wrote: post #286

Earlier quoted context omitted.

You have correctly identified it as FUD. People have a bone to pick with Pin, so they irrationally latch on to it, but the general problem is the fact that the &mut invariants cannot currently permit any self-referential data, which is a useful concept in general (for intrusive data structures, etc) and whose lack that people have been hacking around since before 1.0, with crates like rental and owning_ref. The plan…

> The plan to fix this is to make self-referentiality a first-class concept in the language, as a principled exception to the usual &mut uniqueness invariant that preserves memory safety while properly encoding the aliasing guarantees. Are there issues I can subscribe to or RFCs for this?

Yep, this one: https://github.com/rust-lang/rust/issues/63818 (the comment I'm summarizing is https://github.com/rust-lang/rust/issues/63818#issuecomment-... )

Re: Speed of Rust vs. C

#543

Post by kbenson »

fhunt wrote: post #512
kbenson wrote: post #485

Earlier quoted context omitted.

The claim isn't that it's impossible, or "rocket science", it's that it's hard to do right and was made much easier. You're bringing up for comparison a game engine that has been in constant development by experts for over two decades (Unreal Engine) and a game engine in constant development for over a decade ago (RAGE). Just because someone makes a professional product using tens or hundreds of millions of dollars d…

Yeah, but just picking one of many requirements in game dev and advocating why lang x can do this better than y ignores all the other checkboxes. Yeah, C++ is nerve-wrecking but Rust can be even more. IIRC there was a thread about Zig vs Rust and why Rust is just the wrong tool (for OPs use case in that case). IDK but there is a reason why C++ dominates game dev and a reason why Rust still struggles with mainstream a…

Game dev has nothing to do with it.

The claim was that Rust made making something parallel easy/easier, and the illustrative example given was someone trying to parallelize something in a game engine. Whether Rust is good for game development or not is irrelevant to the point that was being made.

Even if everyone accepted that Rust was horrible for game development on most metrics, the example given would still carry the exact same weight, because it's really about "parallelizing this would be very hard in C++, but it was very easy because of Rust."

Re: Speed of Rust vs. C

#544

Post by burntsushi »

eru wrote: post #535
burntsushi wrote: post #520

Earlier quoted context omitted.

> About large character classes: how are those harder than in approaches? If you build any FSM you have to deal with those, don't you? I mean specifically in the context of derivatives. IIRC, the formulation used in Turon's paper wasn't amenable to large classes. Yes, interval sets work great: https://github.com/rust-lang/regex/blob/master/regex-syntax/... This is why I asked if a production grade regex engine based…

> If I'm remembering correctly, I think the problem with derivatives is that they jump straight to a DFA. You can't do that in a production regex engine because a DFA's worst case size is exponential in the size of the regex. Oh, that's interesting! Because I actually worked on some approaches that don't jump directly to the DFA. The problem is the notion of (extended) NFA you need is quite a bit more complicated whe…

Indeed. And in the regex crate and RE2, for example, captures are only implemented in the "NFA" engines (specifically, the PikeVM and the bounded backtracker). So if you support captures, then those engines have to be able to support everything.

Re: Speed of Rust vs. C

#545

Post by tsegratis »

burntsushi wrote: post #544
eru wrote: post #535

Earlier quoted context omitted.

> If I'm remembering correctly, I think the problem with derivatives is that they jump straight to a DFA. You can't do that in a production regex engine because a DFA's worst case size is exponential in the size of the regex. Oh, that's interesting! Because I actually worked on some approaches that don't jump directly to the DFA. The problem is the notion of (extended) NFA you need is quite a bit more complicated whe…

Indeed. And in the regex crate and RE2, for example, captures are only implemented in the "NFA" engines (specifically, the PikeVM and the bounded backtracker). So if you support captures, then those engines have to be able to support everything.

Can I ask; what about a zdd?

The seem similar to closed languages with a disjunct and conjunct

Though I don't think I will, I was considering adding zdd or bdd to a PEG, to provide that conjunct

ofc, sat solver can represent a regex with conjuncts, but is this a good way of going about it, particularly with unbounded strings??

Would love to hear your thoughts on that

Re: Speed of Rust vs. C

#546

Post by snovv_crash »

roca wrote: post #531
snovv_crash wrote: post #498

Earlier quoted context omitted.

If the APIs that you're interacting with are side-effect free then it's easy. If they are full of side effects, then they aren't written with multithreading in mind and you wouldn't be able to even compile it in Rust. C++ just takes off the training wheels.

It's a bit more complicated than that, because code can be thread-safe but not side-effect-free, but basically you're just restating what I said. C++ makes it hard to be sure code is really safe to use across threads, which means in practice developers should be more reluctant to do so.

If it isn't side effect free then it probably doesn't parallelize very well, even if it has sufficient mutexes etc to be threadsafe.
Post reply on HN