<story><title>When code is suspiciously fast: adventures in dead code elimination</title><url>http://jeffq.com/blog/when-code-is-suspiciously-fast-adventures-in-dead-code-elimination/</url></story><parent_chain></parent_chain><comment><author>sp332</author><text>In the book Permutation City, rich people could upload their brains into computers, but they were running very slowly. A billionaire loaded a copy of his brain into a supercomputer and ran an optimizer on it. After a few years it spit out an empty file and said, &amp;quot;This program produces no output&amp;quot;. I liked that book!</text></comment>
<story><title>When code is suspiciously fast: adventures in dead code elimination</title><url>http://jeffq.com/blog/when-code-is-suspiciously-fast-adventures-in-dead-code-elimination/</url></story><parent_chain></parent_chain><comment><author>Athas</author><text>My experience with benchmarking is that the benchmark program must actually &lt;i&gt;do&lt;/i&gt; something with the result (like, printing it).  Not only because you cannot trust a benchmark to do self-validation, but also because you otherwise end up fighting the optimiser.&lt;p&gt;You don&amp;#x27;t have to print the result within the body of code that you are timing (which would skew the result), but you must have some confidence that the benchmarking setup is sufficiently close to real-world usage conditions.  This usually involves the computation now knowing how its result is going to be used.&lt;p&gt;(In a similar vein, I am also very skeptical about benchmark programs that hard-code their input, rather than read it at runtime.)</text></comment>