undefined | Better HN

0 pointsjblow5y ago0 comments

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

0 comments

burntsushi5y ago

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

jblowOP5y ago

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.

Rusky5y ago

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?

burntsushi5y ago

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.

howinteresting5y ago

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.

j / k navigate · click thread line to collapse

0 pointsjblow5y ago0 comments

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

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

0 comments

burntsushi5y ago

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

jblowOP5y ago

Rusky5y ago

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

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

burntsushi5y ago

howinteresting5y ago

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.

j / k navigate · click thread line to collapse