<div dir="ltr"><div>Hi Andrew,</div><div><br></div><div>Sorry I didn't see this before. My reply to bugzilla didn't take into account the contents, here, so are probable moot.</div><div dir="ltr"><br></div><div dir="ltr">On Thu, 24 Jun 2021 at 17:22, Kaylor, Andrew <<a href="mailto:andrew.kaylor@intel.com">andrew.kaylor@intel.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div lang="EN-US" style="overflow-wrap: break-word;">
<div class="gmail-m_-1408260126145553323WordSection1">
<p class="gmail-m_-1408260126145553323MsoPlainText">I don't agree that the result doesn't matter for benchmarks. It seems that the benchmarks are some of the best tests we have for exercising optimizations like this and if the result is wrong by a wide enough margin that could indicate
 a problem. But I understand Renato’s point that the performance measurement is the primary purpose of the benchmarks, and some numeric differences should be acceptable.<br></p></div></div></blockquote><div>Yes, that's the point I was trying to make. You can't run a benchmark without understanding what it does and what the results mean. Small variations can be fine in one benchmark and totally unacceptable in others. However, what we have in the test-suite are benchmark-turned-tests and tests-turned-benchmarks in which the output is a lot less important if it's more important if it's totally different (ex. error messages, NaNs). My comment was just to the subset we have in the test-suite, not benchmarks in general.</div><div><br></div><div>If you truly want to benchmark LLVM, you should really be running specific benchmarks in specific ways and looking very carefully at the results, not relying on the test-suite.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US" style="overflow-wrap: break-word;"><div class="gmail-m_-1408260126145553323WordSection1"><p class="gmail-m_-1408260126145553323MsoPlainText">In the previous discussion of this issue, Sebastian Pop proposed having the program run twice -- once with "precise" FP results, and once with the optimizations being tested. For the Blur test, the floating point results are only intermediate
 and the final (printed) results are a matrix of 8-bit integers. I’m not sure what would constitute an acceptable result for this program. For any given value, an off-by-one result seems acceptable, but if there are too many off-by-one values that would probably
 indicate a problem. In the Polybench tests, Sebastian modified the tests to do a comparison within the test itself. I don’t know if that’s practical for Blur or if it would be better to have two runs and use a custom comparison tool.<br></p></div></div></blockquote><div>Given the point above about the difference between benchmarks and test-suite-benchmarks, I think having comparisons inside the program itself is probably the best way forward. I should have mentioned that on my list, as I did that, too, in the test-suite. </div><div><br></div><div>The main problem with that, for benchmarks, is that they can add substantial runtime and change the profile of the test. But that can be easily fixed by iterating a few more times on the kernel (from the ground state).</div><div><br></div><div>What we want is to make sure the program doesn't generate garbage, but garbage means different things for different tests, and having an external tool that knows what each of the tests think is garbage is not practical.</div><div><br></div><div>The way I see it, there are only three types of comparison:</div><div> * Text comparison, for tests that must be identical on every platform.</div><div> * Hash comparison, for those above where the output is too big.</div><div> * FP-comparison, for those where the text and integers must be identical but the FP numbers can vary a bit.</div><div><br></div><div>The weird behaviour of fpcmp looking at hashes and comparing the numbers in them is a bug, IMO. As is comparing integers and allowing wiggle room.</div><div><br></div><div>Using fpcmp for comparing text is fine, because what it does with text and integers should be exactly the same thing as diff, and if the text has FP output, then it also can change depending on precision and it's mostly fine if it does.</div><div><br></div><div>To me, the path forward is to fix the tests that break with one of the alternatives above, and make sure fpcmp doesn't identify hex, octal, binary or integers as floating-point, and treat them all as text.</div><div><br></div><div>For the Blur test, a quick comparison between the two matrices inside the program (with appropriate wiggle room) would suffice.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US" style="overflow-wrap: break-word;"><div class="gmail-m_-1408260126145553323WordSection1">
</div>
</div>

</blockquote></div></div>