This weekend at the Southern California Linux Expo in Los Angeles, Matthew Tippett and I presented a talk entitled Five Stages of Benchmark Loss: PTS and You. In this hour-long talk, we covered Linux benchmarking, what has been learned over the years of benchmarking at Phoronix, the Phoronix Test Suite, and the five stages that users and developers generally go through when they lose out on benchmarking results. For those that were unable to attend this event, here are the slides and recordings.
You have my sincere appreciation for providing the slides and audio in open formats! I have downloaded both and look forward to the video. Please consider providing the video in an unencumbered format (e.g. Theora) as well. Again, thank you very much for supporting open formats and setting a positive example for content providers!
Having only looked at the slides (not listened to the audio yet, don't have an hour to kill right now) I must say that this looks great. Hopefully some more awareness of this can get a larger part of the community to stage 4 and 5.
However, I think phoronix.com is as much a part of the problem as it is a part of the solution. The PTS is great, no arguments there, but unfortunately most articles on phoronix.com stop after comparing, and leaves the contrasting to the comments. And as you have noticed, those often stop at stage 2 or 3. I think it would be a great benefit if more of the phoronix.com articles continued all the way to stage 4.
In fact, it is the analysis (stage 4) that makes me prefer lwn.net over phoronx.com, even though the news covered by phoronix.com is closer to what I'm actually interested in...
The PTS is great, no arguments there, but unfortunately most articles on phoronix.com stop after comparing, and leaves the contrasting to the comments. And as you have noticed, those often stop at stage 2 or 3. I think it would be a great benefit if more of the phoronix.com articles continued all the way to stage 4.
It's simply not feasible to always dig to the bottom of every single regression found by myself. There would rarely ever be a new Phoronix article published due to the immense amount of time required. When regressions are found, the community and particularly the project responsible for the regression are more easily able to analyze what happened.
Easy stuff for programmers to remember and get their egos out of the way:
- All code sucks
- It's "the" code, not "my" or "your" code.
Only a few programmers really stand out and most of that remainder disqualify themselves because of the ownership issues above. People need to get over themselves in general, especially programmers.
I'd wouldn't be so strong, but yes, in my professional domain, I tend to use inanimate terms around components - it's the kernel component that's broken, not it's your kernel that's broken. It goes a long way in removing ego and personality from the discussion.
In a lot of cases, the industry and the community are wonderful at their component, but have too little awareness of the system that they are part of. Given particularly in the community, you have possibly tens to hundreds of variants floating around.
The issue for me is the automatic dismissal rather than the asking questions or floating assumptions or causes. Automatically saying "the other team must have built it wrong is completely not helpful.