Live data from Hacker News

Speed of Rust vs. C

kornel.ski

461–470 of 546 posts

Re: Speed of Rust vs. C

#461
post #398

Earlier quoted context omitted.

* You have to remember to do that. * I was thinking return values. * Also you can't use that style in an enum definition if you want to return a custom enum.

If you need api flexibility you use generics, and that is the way to be generic over types that refer to strs. I'm pretty sure this is in the book, and it's common enough that even someone who doesn't use rust full time (myself) knows it off the top of their head You can use impl Trait in returns, this is actually one of the reasons why that feature exists. And yes, you can use generics in an enum.

I think it's a valid criticism.

Ownership, mutability, and thread-safety are not easy to abstract over and hide as implementation details in Rust.

It's a side effect of the fact that Rust actually cares about these and checks them strictly, but for users coming from eg Java that's a bit of a shock.

Re: Speed of Rust vs. C

#462
post #424

Earlier quoted context omitted.

When I used to write in Cython + NumPy I would pre-allocate numpy arrays written into by Cython. It's C-like, but because of the gradual typing I think firmly in the high er level (for some value of "er"). One can certainly do that stuff in Nim/SBCL/etc. (and one sees it done). While allocation is pretty pervasive, I'm skeptical that everywhere or even most places you do it is an important perf bottleneck. Without a…

> While allocation is pretty pervasive, I'm skeptical that everywhere or even most places you do it is an important perf bottleneck. Without a count of these 20 times it matters and these 40 it doesn't, it's just kind guesswork from an all too often frail human memory/attention that "ignores the noise" by its very nature. You might be right. Just trying to add some color. :-) In general I agree. But I'm saying what I…

I feel we've talked past each other about what is/is not Python a few times. There is Cython and Pythran and Pypy and ShedSkin and Numba and others that are targeting, for lack of a more precise term, "extreme compatibility with" CPython, but also trying to provide an escape hatch for performance which includes in-language low levelness including allocation tricks that are not "mainstream CPython" (well, Pypy may not have those...).

My first reply was questioning "what counts" as "Python". Cython is its own language, not just "C", nor just "Python", but can do "low level things" such as using C's alloca. Maybe the only prior update here is on the diversity of "Python" impls. There are a lot. This is another reason why language levelness is hard to pin down which was always my main point, upon which we do not disagree. Maybe this is what you meant by "exceptionally general", but I kinda feel like "there isn't just one 'Python'" got lost. { There used to be a joke.."Linux isn't" related to the variety of distros/default configs/etc. :-) }

Advice-wise, I would say that your claim can be closer to easily true if you adjust it to say "ripgrep needs 'low level tricks' to be fast and a language that allows them, such as Rust". That phrasing side-steps worrying about levelnesses in the large of programming languages, re-assigns it to techniques which is more concrete and begs the question of technique enumeration. That is the right question to beg, though, if not in this conversation then in others. You might learn how each and every technique has representation in various other programming languages. It's late for me, though. So, good night!

Re: Speed of Rust vs. C

#463
post #186

Earlier quoted context omitted.

Somewhat off-topic: I just looked into zig, because you mentioned it. > C++, D, and Go have throw/catch exceptions, so foo() might throw an exception, and prevent bar() from being called. (Of course, even in Zig foo() could deadlock and prevent bar() from being called, but that can happen in any Turing-complete language.) Well, you could bite the bullet and carefully make Zig non-Turing complete. (Or at least put Tur…

With respect to deadlocks, there’s little practical difference between an infinite loop and a loop that holds the lock for a very long time. Languages like Idris and Agda are different because sometimes code isn’t executed at all. A proof may depend on knowing that some code will terminate without running it .

> Languages like Idris and Agda are different because sometimes code isn’t executed at all. A proof may depend on knowing that some code will terminate without running it.

Yes. They are rather different in other respects as well. Though you can produce executable code from Idris and Agda, of course.

> With respect to deadlocks, there’s little practical difference between an infinite loop and a loop that holds the lock for a very long time.

Yes, that's true. Though as a practical matter, I have heard that it's much harder to produce the latter by accident, even though only the former is forbidden.

For perhaps a more practical example, have a look at https://dhall-lang.org/ which also terminates, but doesn't have nearly as much involved proving.

Re: Speed of Rust vs. C

#464

Earlier quoted context omitted.

ripgrep is based on re2, a c library I would guess it contains more c than rust code... But what I love about this article is its lack of hype. It makes clear arguments both ways and all of them I can get behind Hype doesn't help Edit: To all my downvoters; I anticipated you :) With love and best wishes

No it's not. Its regex library is written in Rust, but was inspired by RE2. It shares no code with RE2. (And RE2 is a C++ library, not C.) Off the top of my head, the only C code in ripgrep is optional integration with PCRE2. In addition to whatever libc is being used on POSIX platforms. Everything else is pure Rust.

It couldn't figure it out from looking through ripgrep's website: does ripgrep support intersection and complement of expressions? Like eg https://github.com/google/redgrep does.

Regular languages are closed under those operations after all.

Re: Speed of Rust vs. C

#465

Earlier quoted context omitted.

To be clear, ripgrep has no runtime dependency on any LLVM or C++ library. rustc does.

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…

> 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

You could instead go with a derivatives approach.

https://en.wikipedia.org/wiki/Brzozowski_derivative

Re: Speed of Rust vs. C

#466

Earlier quoted context omitted.

I don’t think people are downvoting you because they disagree on a matter of opinion. You’ve literally got the author of ripgrep having replied to you to tell you that what you’ve said is categorically false.

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?

Re: Speed of Rust vs. C

#467
post #462

Earlier quoted context omitted.

> While allocation is pretty pervasive, I'm skeptical that everywhere or even most places you do it is an important perf bottleneck. Without a count of these 20 times it matters and these 40 it doesn't, it's just kind guesswork from an all too often frail human memory/attention that "ignores the noise" by its very nature. You might be right. Just trying to add some color. :-) In general I agree. But I'm saying what I…

I feel we've talked past each other about what is/is not Python a few times. There is Cython and Pythran and Pypy and ShedSkin and Numba and others that are targeting, for lack of a more precise term, "extreme compatibility with" CPython, but also trying to provide an escape hatch for performance which includes in-language low levelness including allocation tricks that are not "mainstream CPython" (well, Pypy may not…

Ah I see. You are right. I missed that you were going after that. I'm personally only really familiar with CPython, so that is indeed what I had in mind. To be honest, I don't really know what a ripgrep in Cython would look like. Is there a separate Cython standard library, for example? Or do you still use Python's main standard library?

We don't have to tumble down that rabbit hole though. If someone wrote a ripgrep in Cython and matched performance, then I would definitely learn something.

> "ripgrep needs 'low level tricks' to be fast and a language that allows them, such as Rust"

I might use that, sure. I think my point above was that I had to riff off of someone else's language. But I think we covered that. :-) In any case, yes, that phrasing sounds better.

Anyway, good chatting with you, good night!

Re: Speed of Rust vs. C

#468

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.

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…

Another one is a comparison between rust and zig: https://news.ycombinator.com/item?id=24835357

Re: Speed of Rust vs. C

#469
post #458

Earlier quoted context omitted.

> here you imply they would be used internally to data structures, in a way that doesn't reach out to user-level. Ah! I think I am understanding you a bit better. The thing is, ultimately, Rust is as flexible as you want it to be, and so there are a variety of options. This can make it tricky, when folks are talking about slightly different things, in slightly different contexts. When you say "doesn't reach out to us…

> rather than sweeping, incorrect statements that lead people to believe things that aren't true I agree, and if I say things that are incorrect, then I definitely want to fix them, because I value being correct. But what I am meeting in this thread is people wanting to do some language-lawyer version of trying to prove I am incorrect, without addressing the substance of what I am actually saying. I think your replie…

Thanks for expanding on that. Now I think I get what you mean.

Rust does case (3) with arenas. In your frame loop you'd create or reset an arena and then borrow it. That would limit lifetime of its items to a single loop iteration. The cost would be only in a noisy syntax with `'arena` in several places, but other than that it compiles to plain pointers with no magic. Lifetimes are merely compile-time assertions for a static analyzer. Note that in Rust borrowing is unrelated to RAII and theoretically separate from single ownership.

Rust's `async fn` is one case where a task can hold all of the memory it will need, as one tagged union.

As for unsafe, the point is in encapsulating it in safe abstractions.

Imagine you're implementing a high level sandbox language. Your language is meant to be bulletproof safe, but your compiler for that language may is in C. The fact that the compiler might do unsafe things doesn't make the safe language pointless.

Rust does that, but the safe language vs unsafe compiler barrier is shifted a but, so that users can add "compiler internals" themselves for the safe language side.

eg. `String` implementation is full of unsafe code, but once that one implementation has been verified manually to be sound, and hidden behind a safe API, nobody else using it can screw it up when eg concatenating strings.

I know it seems pointless if you can access unsafe at all, so why bother? But in practice it really helps, for reasons that are mostly social.

* There are clear universal rules about what is a safe API. That helps review the code, because the API contract can't be arbitrary or "just be careful not to…". It either is or isn't, and you mark it as such. Not everything can be expressed in terms of safe APIs, but enough things can.

* Unsafe parts can be left to be written by more experienced devs, or flagged for more thorough review, or fuzzed, etc. Rust's unsafe requires as much diligence as equivalent C code. The difference is that thanks to encapsulation you don't need to write the whole program with maximum care, and you know where to focus your efforts to ensure safety. You focus on designing safe abstraction once, and then can rely on the compiler upholding it everywhere else.

Re: Speed of Rust vs. C

#470

I'm a Rust evangelist, but the article is titled "Speed of Rust vs. C" and doesn't seem to contain even one benchmark. For fuck's sake.

Here's my completely unbiased benchmark which use different data structure, uses outside library in one language and non recursive implementation. I hope you don't need the link.
Post reply on HN