[burntsushi]

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

[jblow]

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

[burntsushi]

> You chose an embarrassingly parallel problem

Well, I mean, you chose an embarrassingly general statement to make? Play stupid games, win stupid prizes.

> which most programs are not

Programs? Or problems? Who says? It's not at all obvious to me that it's true. And even if it were true, "embarrassingly parallel" problems are nowhere close to uncommon.

> When you try to parallelize a structurally complicated algorithm, the biggest issue is contention.

With respect to performance, I agree.

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

The question is itself flawed. Technology isn't fixed. We "advance" and try to do more stuff. This is not me saying, "this explains everything." Or even that "more stuff" is a good thing. This is me saying, "there's more to it than your over-simplifications."

[jblow]

If you do not understand that "embarrassingly parallel" is a technical term and that it's generally understood that most programs are not easily parallelizable, there is not a discussion we can have here.

[Rusky]

Really feels like you're just digging yourself deeper into a hole here:

Burntsushi began with "here, parallelization is beating out memory locality and optimization in its impact," but explicitly declined to generalize this the way you generalized your claim about memory.

He further pointed out that ripgrep is fast not just because of parallelization, but also because of how it handles memory.

Then you come back with "you can't always parallelize this well" (which burntsushi agreed with from the beginning) and "you also need to deal with memory" (which ripgrep does)? How is this burntsushi's problem with understanding "embarrassingly parallel" and not your problem with understanding Rust?

[burntsushi]

I agree that a discussion is difficult. Your comments are so vague and generalized that it's not clear what you're talking about at all. Bring something more specific to the table like the OP did instead of pontificating on generalities.

[howinteresting]

Thanks for making The Witness, Jonathan. It's one of my favorite games of all time and an exemplar of what it means to work through the consequences of logical axioms.

Makes me all the more sad that you're consistently unable to work through the consequences of Rust's axioms.