Oh, also, I don&#39;t think that cache effects are the main bottleneck because switching to single-precision floats for both input and output has a negligible effect on performance even though it cuts the size of the working set in half.<br>
<br><div class="gmail_quote">On Mon, Aug 2, 2010 at 10:23 AM, Don Clugston <span dir="ltr">&lt;<a href="mailto:dclugston@googlemail.com">dclugston@googlemail.com</a>&gt;</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 15:41, David Simcha &lt;<a href="mailto:dsimcha@gmail.com">dsimcha@gmail.com</a>&gt; wrote:<br>
&gt; Unfortunately I just downloaded the benchmark program for FFTW and my FFT is<br>
&gt; a ton slower, depending on how you look at it.  Using size 2^20 as my<br>
&gt; benchmark, FFTW takes about 131 seconds to create its plan, even using<br>
&gt; -oestimate, the fastest planner.  However, the plan can be reused if<br>
&gt; performing multiple FFTs of the same size, and once the plan is created, it<br>
&gt; can do an FFT of size 2^20 in about 53 milliseconds (which I find almost<br>
&gt; unbelievable because even sorting an array of size 2^20 using a<br>
&gt; well-optimized quick sort takes almost that long, and FFT seems like it<br>
&gt; should should have a much larger constant than quick sort), compared to my<br>
&gt; latest improvements to around 730 on the hardware I&#39;m benchmarking on.<br>
&gt;<br>
&gt; On the other hand, for one-off use cases, the lack of needing to create a<br>
&gt; plan is a big win, both from a speed and a simplicity of API point of view.<br>
&gt;  Benchmarking against R, which doesn&#39;t appear to use plans, making the<br>
&gt; comparison somewhat more relevant, things look better for my FFT:  R takes<br>
&gt; about 610 milliseconds for a size 2^20 pure real FFT.<br>
<br>
</div>All you&#39;re seeing is the L2 cache. Did you see the link I posted to<br>
the NG about the internals of FFTW? The graph at the top shows FFTW is<br>
40 times faster than the &#39;numerical recipes&#39; code for 2^^20. So your<br>
factor of 13 isn&#39;t so bad. Based on that graph, if you reduce it to<br>
say 2^^15, the factor should drop significantly. Adding a little bit<br>
of cache awareness (using core.cpuid) should be able to avoid the<br>
performance cliff.<br>
Also, DMD&#39;s floating point optimiser is so primitive, you lose up to a<br>
factor of two immediately.<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>