5 ms·

So, to paraphrase: BFS is vastly superior, but not in any way that you can actually measure. From my understanding, your interpretation is not correct. BFS is

by tsally 17y ago

So, to paraphrase: BFS is vastly superior, but not in any way that you can actually measure. From my understanding, your interpretation is not correct. BFS is about latency, not throughput. Ingo chose all the wrong benchmarks. Also, it's a dick move by Ingo. CK hasn't even made a public announcement about BFS yet. Finally, you should use code that has technical merit, regardless of the personality behind the writer. I imagine the kernel you're running on has code in it written by some pretty unfriendly people.

wmf 17y ago
It's not that Ingo chose the wrong benchmarks. The right benchmarks don't exist, and we're not even sure how to build them. Unfortunately, building a scheduler optimized for "unbenchmarkable" use cases is a recipe for misunderstanding.
- tsally 17y ago
  The right benchmarks for the stated goals of BFS do exist. BFS is hardly "unbemchmarkable"; the only thing being misunderstood here is the goal of BFS.
dfranke 17y ago
From my understanding, your interpretation is not correct. BFS is about latency, not throughput. Ingo chose all the wrong benchmarks. Then how about CK showing up the right ones? Also, it's a dick move by Ingo. CK hasn't even made a public announcement about BFS yet. He announced it publicly enough that I knew about it, and I haven't followed this stuff in years. Given that, I hardly think that commenting on his efforts on LKML constitutes a premature "outing". Finally, you should use code that has technical merit, regardless of the personality behind the writer. I imagine the kernel you're running on has code in it written by some pretty unfriendly people. Indeed: one of them murdered his wife. But you brought up personalities, not me. The part of CK's post that I quoted is rather dickish, but I deliberately avoided commenting on that.
- tsally 17y ago
  Then how about CK showing up the right ones? Why? It's not as if CK is trying to get it into the mainline. I think the only reason why CK got angry is that Ingo's benchmarks appear to be deliberately chosen to make BFS look bad. Anyone who took the time to read the documentation would realize that testing throughput is not correct. That'd be like benchmarking Python and C using matrix multiplication and concluding that Python sucks. Two different tools for different purposes. He announced it publicly enough that I knew about it, and I haven't followed this stuff in years. Given that, I hardly think that commenting on his efforts on LKML constitutes a premature "outing.". I think the announcement was mostly the work of Reddit et al., but fair enough. Indeed: one of them murdered his wife. But you brought up personalities, not me. Reiser was a crazy one. ;) I actually only brought up personalities because I was under the impression that you wouldn't try CK's patch because of his personality. I say if there's interesting code out there, it shouldn't go to waste because of the quirks of the author. I apologize if I misinterpreted.
  - dfranke 17y ago
    Why? It's not as if CK is trying to get it into the mainline. What does one have to do with the other? If I'm going to spend the necessary 20 minutes to compile a new kernel using CK's patch, I want some evidence that I'm going to be gaining something.
    - tsally 17y ago
      What does one have to do with the other? If I'm going to spend the necessary 20 minutes to compile a new kernel using CK's patch, I want some evidence that I'm going to be gaining something. Ok, I can accept that. For me personally though, the quality of -ck patchset is enough for me to give CK's new stuff a shot.
      - rbanffy 17y ago
        Personality can be a huge problem because the kernel and its parts are a long term project and I would prefer people that can work together for its entire duration. Accusations like "/me sees Ingo run off to find the right combination of hardware and benchmark to prove his point." is far from the level of civility I would entrust my favorite OS's kernel. The proper response would be something in the line "it will suck on this benchmarks, but it will excell in these others and in these hardware configurations" and show numbers. It's always possible to act in a civilized way. That said, CK seems only a bit off when compared to a couple others. There are a lot of people who like to be quite caustic from time to time. I must confess I have to refrain myself frequently and HN is not LKML. And, more important: this whole discussion is more or less pointless. It doesn't matter how good a modern scheduler is, all of them impose a very little penalty on a modern kernel. Are we really going to fight this bitterly over a couple percentage points? Would that be so hard as to include a "-scheduler=" switch in the kernel for it to be selectable at boot time (and so I can pick one that fits both my netbook and my SGI 4096 CPU monster when I want to)? This would pretty much end this discussion.
blasdel 17y ago
All good kernel micro-benchmarks will involve a ton of volume, and thus be exercising throughput. All the micro-benchmarks Ingo used are extremely latency-focused: a few processes blocking on Pipe I/O or messaging as frequently as possible -- the only subject of the test is how fast the scheduler can toggle between the processes. BFS was dramatically worse across the board in all the benchmarks, except curiously when the # of processes == # of logical processors -- to me that's evidence of extreme naivete in its design.

by tsally 17y ago

wmf 17y ago

It's not that Ingo chose the wrong benchmarks. The right benchmarks don't exist, and we're not even sure how to build them. Unfortunately, building a scheduler optimized for "unbenchmarkable" use cases is a recipe for misunderstanding.

tsally 17y ago
The right benchmarks for the stated goals of BFS do exist. BFS is hardly "unbemchmarkable"; the only thing being misunderstood here is the goal of BFS.

dfranke 17y ago

From my understanding, your interpretation is not correct. BFS is about latency, not throughput. Ingo chose all the wrong benchmarks. Then how about CK showing up the right ones? Also, it's a dick move by Ingo. CK hasn't even made a public announcement about BFS yet. He announced it publicly enough that I knew about it, and I haven't followed this stuff in years. Given that, I hardly think that commenting on his efforts on LKML constitutes a premature "outing". Finally, you should use code that has technical merit, regardless of the personality behind the writer. I imagine the kernel you're running on has code in it written by some pretty unfriendly people. Indeed: one of them murdered his wife. But you brought up personalities, not me. The part of CK's post that I quoted is rather dickish, but I deliberately avoided commenting on that.

tsally 17y ago
Then how about CK showing up the right ones? Why? It's not as if CK is trying to get it into the mainline. I think the only reason why CK got angry is that Ingo's benchmarks appear to be deliberately chosen to make BFS look bad. Anyone who took the time to read the documentation would realize that testing throughput is not correct. That'd be like benchmarking Python and C using matrix multiplication and concluding that Python sucks. Two different tools for different purposes. He announced it publicly enough that I knew about it, and I haven't followed this stuff in years. Given that, I hardly think that commenting on his efforts on LKML constitutes a premature "outing.". I think the announcement was mostly the work of Reddit et al., but fair enough. Indeed: one of them murdered his wife. But you brought up personalities, not me. Reiser was a crazy one. ;) I actually only brought up personalities because I was under the impression that you wouldn't try CK's patch because of his personality. I say if there's interesting code out there, it shouldn't go to waste because of the quirks of the author. I apologize if I misinterpreted.
- dfranke 17y ago
  Why? It's not as if CK is trying to get it into the mainline. What does one have to do with the other? If I'm going to spend the necessary 20 minutes to compile a new kernel using CK's patch, I want some evidence that I'm going to be gaining something.
  - tsally 17y ago
    What does one have to do with the other? If I'm going to spend the necessary 20 minutes to compile a new kernel using CK's patch, I want some evidence that I'm going to be gaining something. Ok, I can accept that. For me personally though, the quality of -ck patchset is enough for me to give CK's new stuff a shot.
    - rbanffy 17y ago
      Personality can be a huge problem because the kernel and its parts are a long term project and I would prefer people that can work together for its entire duration. Accusations like "/me sees Ingo run off to find the right combination of hardware and benchmark to prove his point." is far from the level of civility I would entrust my favorite OS's kernel. The proper response would be something in the line "it will suck on this benchmarks, but it will excell in these others and in these hardware configurations" and show numbers. It's always possible to act in a civilized way. That said, CK seems only a bit off when compared to a couple others. There are a lot of people who like to be quite caustic from time to time. I must confess I have to refrain myself frequently and HN is not LKML. And, more important: this whole discussion is more or less pointless. It doesn't matter how good a modern scheduler is, all of them impose a very little penalty on a modern kernel. Are we really going to fight this bitterly over a couple percentage points? Would that be so hard as to include a "-scheduler=" switch in the kernel for it to be selectable at boot time (and so I can pick one that fits both my netbook and my SGI 4096 CPU monster when I want to)? This would pretty much end this discussion.

blasdel 17y ago

All good kernel micro-benchmarks will involve a ton of volume, and thus be exercising throughput. All the micro-benchmarks Ingo used are extremely latency-focused: a few processes blocking on Pipe I/O or messaging as frequently as possible -- the only subject of the test is how fast the scheduler can toggle between the processes. BFS was dramatically worse across the board in all the benchmarks, except curiously when the # of processes == # of logical processors -- to me that's evidence of extreme naivete in its design.