3 ms·
I understand where your coming from, Intel's communication on this issue was pretty awful. But in this specific case I don't really mind them publishing an "ex
by jo909 9y ago
I understand where your coming from, Intel's communication on this issue was pretty awful.
But in this specific case I don't really mind them publishing an "expected" result of one benchmark together with a lot of other ones. Not everybody understands the problem as well and is able to tell which use cases are affected or not. If you send them to this site and all they see are negative numbers they might not be able to tell that nevertheless there are other use cases without significant impacts.
And I find it completely fair for them to show that not everything is affected the same, and show the whole spectrum starting with zero impact.
- philjohn 9y agoThey should have been running actual workloads that are common in data centres, rather than synthetic benchmarks.
- semi-extrinsic 9y agoWell, to put it bluntly, I can tell you all the Real Programmers at national labs, universities, government agencies etc who buy processors by the tens of thousands for running big simulations of Important Things (as opposed to running bucketfuls of Mongo instances for sharing streaksnaps and cat pictures) are very interested in any effect on these synthetic benchmarks.
- criley2 9y agoI love Hot Takes(TM) like this which purport to imply that the majority of profitable programming isn't Real(TM), and only those applications that are government, military or academic are somehow Real(TM). The irony is of course that the software and hardware in use is only as powerful and useful as it is because a billion people wanted processors to take, share and look at cat pictures... (That, and programmers with "real jobs" [see what I did there] happen to think the opposite, that cashing your government grant isn't a real job!)
- nickpsecurity 9y agoIt was probably a reference to this old piece of satire: http://web.mit.edu/humor/Computers/real.programmers http://web.mit.edu/humor/Computers/real.programmers In this case, there would be lots of programmers in HPC field alone who want the micro and macro benchmarks to be good since they're squeezing every bit of number crunching they can out piles of machines they spent a fortune on. When I studied supercomputing, they were timing everything from latency of memory operations (esp NUMA) to context switches on CPU's to raw MIPS. The suppliers were competing on that stuff, too.
- semi-extrinsic 9y agoYes, I was not entirely serious. The word I was looking for was "flippant", but I couldn't conjure it up when writing so I wrote "blunt".
- vvanders 9y agoAnyone who does SoC evaluation or large purchases know that any synthetic benchmark are BS. Every vendor tailor-adapts their drivers/workloads/etc to make them look "the best"[1]. See: GPU drivers checking running process, bumping voltages and all sorts of other shenanigans. [1] https://www.anandtech.com/show/7384/state-of-cheating-in-android-benchmarks https://www.anandtech.com/show/7384/state-of-cheating-in-and...
- semi-extrinsic 9y agoWell, yes and no. Linpack is pretty useless, but STREAMS Triad is actually a very good proxy for problems that are memory bandwidth bound, and the only way to "game" it is to actually provide a better chip.
- vvanders 9y agoOh you can totally game those things by ignoring your thermal limits and/or overclock briefly since you know the exact duration of the test. It's a really common approach in the GPU chip space. The right way to do things is have a private test that matches a slice of your real workload. That way the vendor can't tailor their chips/drivers to it.