Yea, I also just ran it on a machine with a 4MB L2 cache instead of the 512KB one I had been using. These machines usually are about equally fast for purely CPU-bound stuff in my experience, and that holds here, too: They're within 5% of each other.<br>
<br><div class="gmail_quote">On Mon, Aug 2, 2010 at 3:37 PM, Don Clugston <span dir="ltr"><<a href="mailto:dclugston@googlemail.com">dclugston@googlemail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On 2 August 2010 19:49, David Simcha <<a href="mailto:dsimcha@gmail.com">dsimcha@gmail.com</a>> wrote:<br>
> Oh, also, I don't think that cache effects are the main bottleneck because<br>
> switching to single-precision floats for both input and output has a<br>
> negligible effect on performance even though it cuts the size of the working<br>
> set in half.<br>
<br>
</div>Interesting. Still, I think that because of the way FFT works, once<br>
you're bigger than the cache, nearly every memory access will be a<br>
cache miss. It could be that although the memory footprint halves, the<br>
number of cache misses remains constant.<br>
<br>
Anyway, the reason I posted the link was not so much to help with<br>
implementation, but more because it gives a great feel for what's<br>
involved in a "state of the art" FFT library. I suspect there's a<br>
sweet spot with high convenience, small code size, and good-enough<br>
performance.<br>
<div><div></div><div class="h5">_______________________________________________<br>
phobos mailing list<br>
<a href="mailto:phobos@puremagic.com">phobos@puremagic.com</a><br>
<a href="http://lists.puremagic.com/mailman/listinfo/phobos" target="_blank">http://lists.puremagic.com/mailman/listinfo/phobos</a><br>
</div></div></blockquote></div><br>