<br><br><div><span class="gmail_quote">On 7/21/07, <b class="gmail_sendername">chris clepper</b> <<a href="mailto:cgclepper@gmail.com">cgclepper@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<span class="q">On 7/21/07, <b class="gmail_sendername">Miller Puckette</b> <<a href="mailto:mpuckett@imusic1.ucsd.edu" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">mpuckett@imusic1.ucsd.edu</a>
> wrote:</span><div><span class="q"><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Just as<br>a teaser, I tried running the same patch as 32-bit and 64-bit programs on<br>my 64-bit machine, hoping to find the 32-bit version so much faster that I<br>could just forget optimizing the 64 bit version entirely. But I found the
<br>64-bit one 33% faster than the 32-bit one for the particular patch I tried.<br>So 64-bit compatibility has to be taken seriously!</blockquote></span><div><br>If I had to hazard a guess that speedup is due to the compiler. The 64 bit CPUs are all quite recent and the assumptions about what the fast paths are a much smaller and generally much more efficient set than the 32 bit options. No doubt some of that comes from the gamesmanship involved in rigging and hyping scores on the baleful SPEC test suite.
<br></div></div><br>
</blockquote></div><br>