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

331–340 of 546 posts

Re: Speed of Rust vs. C

#331

Post by zozbot234 »

jblow wrote: post #322

This entire article is nonsense. To a first approximation, the speed of your program in 2021 is determined by locality of memory access and overhead with regard to allocation and deallocation. C allows you to do bulk memory operations, Rust does not (unless you turn off the things about Rust that everyone says are good). Thus C is tremendously faster. There is this habit in both academia and industry where people say…

> (If you don't get what I am saying here, it might help to know that performance programmers consider malloc to be tremendously slow and don't use it except at startup or in cases when it is amortized by a factor of 1000 or more).

Rust is now getting support for custom local allocators ala C++, including in default core types like Box, Vec and HashMap. It's an unstable feature, hence not yet part of stable Rust but it's absolutely being worked on.

Re: Speed of Rust vs. C

#332

Post by pjmlp »

burntsushi wrote: post #223
alerighi wrote: post #144

Earlier quoted context omitted.

Also Rust is risky to parallelize: you can get deadlocks. I don't get the obsession of parallel code in low level languages by the way. If you have an architecture where you can afford real parallelism you can afford higher level languages anyway. In embedded applications you don't usually have the possibility to have parallel code, and even in low level software (for example the classical UNIX utilities), for simpli…

This is a bad take. ripgrep, to my knowledge, cannot be written in a higher level language without becoming a lot slower.[1] And yet, if I removed its use of parallelism by default, there will be a significantly degraded user experience by virtue of it being a lot slower. This isn't an "obsession." It's engineering. [1] - I make this claim loosely. Absence of evidence isn't evidence of absence and all that. But if I…

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

Re: Speed of Rust vs. C

#333

Post by howinteresting »

pjmlp wrote: post #132
gridspy wrote: post #103

Earlier quoted context omitted.

> The evangelism is exhausting. My best guess is that people who are "stuck" working in C or C++ wish they could use Rust at their Jobs. Or that others would make the leap and get over the learning curve.

Not until it reaches the same level as Visual Studio, Android Studio, QtCreator, XCode, CUDA and SYSCL tooling for graphical applications and GPGPU. For anything else managed languages are a much more productive option, other than writing kernel and drivers.

Have you ever had to deal with tail latency due to memory pressure on web or backend services?

Command-line tools are also ideal for Rust because startup performance matters a lot there.

Re: Speed of Rust vs. C

#334

Post by burntsushi »

jblow wrote: post #322

This entire article is nonsense. To a first approximation, the speed of your program in 2021 is determined by locality of memory access and overhead with regard to allocation and deallocation. C allows you to do bulk memory operations, Rust does not (unless you turn off the things about Rust that everyone says are good). Thus C is tremendously faster. There is this habit in both academia and industry where people say…

> To a first approximation, the speed of your program in 2021 is determined by locality of memory access and overhead with regard to allocation and deallocation.

I wouldn't call that a first approximation. Take ripgrep as an example. In a checkout of the Linux kernel with everything in my page cache:

    $ time rg zqzqzqzq -j1

    real    0.609
    user    0.315
    sys     0.286
    maxmem  7 MB
    faults  0

    $ time rg zqzqzqzq -j8

    real    0.116
    user    0.381
    sys     0.464
    maxmem  9 MB
    faults  0
This alone, to me, says "to a first approximation, the speed of your program in 2021 is determined by the number of cores it uses" would be better than your statement. But I wouldn't even say that. Because performance is complicated and it's difficult to generalize.

Using Rust made it a lot easier to parallelize ripgrep.

> C allows you to do bulk memory operations, Rust does not (unless you turn off the things about Rust that everyone says are good). Thus C is tremendously faster.

Talk about nonsense. I do bulk memory operations in Rust all the time. Amortizing allocation is exceptionally common in Rust. And it doesn't turn off anything. It's used in ripgrep in several places.

> There is this habit in both academia and industry where people say "as fast as C" and justify this by comparing to a tremendously slow C program, but don't even know they are doing it. It's the blind leading the blind.

I've never heard anyone refer to GNU grep as a "tremendously slow C program."

> The question you should be asking yourself is, "If all these claims I keep seeing about X being as fast as Y are true, then why does software keep getting slower over time?"

There are many possible answers to this. The question itself is so general that I don't know how to glean much, if anything, useful from it.

Re: Speed of Rust vs. C

#335

Post by jblow »

zozbot234 wrote: post #331
jblow wrote: post #322

This entire article is nonsense. To a first approximation, the speed of your program in 2021 is determined by locality of memory access and overhead with regard to allocation and deallocation. C allows you to do bulk memory operations, Rust does not (unless you turn off the things about Rust that everyone says are good). Thus C is tremendously faster. There is this habit in both academia and industry where people say…

> (If you don't get what I am saying here, it might help to know that performance programmers consider malloc to be tremendously slow and don't use it except at startup or in cases when it is amortized by a factor of 1000 or more). Rust is now getting support for custom local allocators ala C++, including in default core types like Box , Vec and HashMap . It's an unstable feature, hence not yet part of stable Rust bu…

Sure, but you are still going to be constrained greatly in terms of what those allocators are able to do, are you not?

Re: Speed of Rust vs. C

#336

Post by Kutta »

zozbot234 wrote: post #331
jblow wrote: post #322

This entire article is nonsense. To a first approximation, the speed of your program in 2021 is determined by locality of memory access and overhead with regard to allocation and deallocation. C allows you to do bulk memory operations, Rust does not (unless you turn off the things about Rust that everyone says are good). Thus C is tremendously faster. There is this habit in both academia and industry where people say…

> (If you don't get what I am saying here, it might help to know that performance programmers consider malloc to be tremendously slow and don't use it except at startup or in cases when it is amortized by a factor of 1000 or more). Rust is now getting support for custom local allocators ala C++, including in default core types like Box , Vec and HashMap . It's an unstable feature, hence not yet part of stable Rust bu…

Arenas have been used in Rust for a long time.

Re: Speed of Rust vs. C

#337

Post by pornel »

jblow wrote: post #322

This entire article is nonsense. To a first approximation, the speed of your program in 2021 is determined by locality of memory access and overhead with regard to allocation and deallocation. C allows you to do bulk memory operations, Rust does not (unless you turn off the things about Rust that everyone says are good). Thus C is tremendously faster. There is this habit in both academia and industry where people say…

I don't disagree that memory access is nowadays critical for speed, but I haven't found Rust standing in the way of optimizing it.

As I've pointed out in the article, Rust does give you precise control over memory layout. Heap allocations are explicit and optional. In safe code. You don't even need to avoid any nice features (e.g. closures and iterators can be entirely on stack, no allocations needed).

Move semantics enables `memcpy`ing objects anywhere, so they don't have a permanent address, and don't need to be allocated individually.

In this regard Rust is different from e.g. Swift and Go, which claim to have C-like speed, but will autobox objects for you.

Re: Speed of Rust vs. C

#338

Post by bluejekyll »

zelphirkalt wrote: post #303
bluejekyll wrote: post #154

Earlier quoted context omitted.

Erlang has a great concurrency model with higher overhead than Rust, but similar cross thread safety, doesn’t do anything about exterior resources to the application. I’ve not worked with Coyote, but if it is the system for .net, it describes itself as a framework, “Coyote provides developers a programming framework for confidently building reliable asynchronous software on the .NET platform”. Orleans similarly descr…

If I understand correctly, the Erlang point was, that you can have a distributed system by using Beam to scale to multiple machines and have them communicate via message passing, which is all possible and encouraged, because of how you structure and write code in Erlang, as actors with mailboxes, isolating actors from each other, except for the messages, that are passed. You say, that the Erlang concurrency model has…

That wasn’t meant to be a snide comment about Erlang in any way. All I meant by the comment about higher-overhead was that the language itself generally has more costs to run, i.e. runtime, memory usage, garbage collector, interpreted, etc, than Rust.

The “process” model of Erlang is about as lightweight as you can get, agreed.

In terms of capabilities of beam across systems, point taken. Though we start stretching some of the understanding of where languages end and runtimes begin... Rust and C make those boundaries a little more clear.

Re: Speed of Rust vs. C

#339

Post by jblow »

burntsushi wrote: post #334
jblow wrote: post #322

This entire article is nonsense. To a first approximation, the speed of your program in 2021 is determined by locality of memory access and overhead with regard to allocation and deallocation. C allows you to do bulk memory operations, Rust does not (unless you turn off the things about Rust that everyone says are good). Thus C is tremendously faster. There is this habit in both academia and industry where people say…

> To a first approximation, the speed of your program in 2021 is determined by locality of memory access and overhead with regard to allocation and deallocation. I wouldn't call that a first approximation. Take ripgrep as an example. In a checkout of the Linux kernel with everything in my page cache: $ time rg zqzqzqzq -j1 real 0.609 user 0.315 sys 0.286 maxmem 7 MB faults 0 $ time rg zqzqzqzq -j8 real 0.116 user 0.3…

> This alone, to me, says "to a first approximation, the speed of your program in 2021 is determined by the number of cores it uses" would be better than your statement. But I wouldn't even say that.

You chose an embarrassingly parallel problem, which most programs are not. So you cannot generalize this example across most software. When you try to parallelize a structurally complicated algorithm, the biggest issue is contention. I was leaving this out because it really is a 2nd order problem -- most software today would get faster if you just cleaned up its memory usage, than if you just tried to parallelize it. (Of course it'd get even faster if you did both, but memory is the E1).

> There are many possible answers to this.

How come so few people are concerned with the answers to that question and which are true, but so many people are concerned with making performance claims?

Re: Speed of Rust vs. C

#340

Post by jblow »

pornel wrote: post #337
jblow wrote: post #322

This entire article is nonsense. To a first approximation, the speed of your program in 2021 is determined by locality of memory access and overhead with regard to allocation and deallocation. C allows you to do bulk memory operations, Rust does not (unless you turn off the things about Rust that everyone says are good). Thus C is tremendously faster. There is this habit in both academia and industry where people say…

I don't disagree that memory access is nowadays critical for speed, but I haven't found Rust standing in the way of optimizing it. As I've pointed out in the article, Rust does give you precise control over memory layout. Heap allocations are explicit and optional. In safe code. You don't even need to avoid any nice features (e.g. closures and iterators can be entirely on stack, no allocations needed). Move semantics…

Bulk operations are not really about layout, they are about whether you mentally consider each little data structure to be an individual entity with its own lifetime, or not, because this determines what the code looks like, which determines how fast it is. (Though layout does help with regard to cache hits and so forth).
Post reply on HN