memory accesses run into the thousands of cpu cycles these days, partly due to these things being massively speculative and superscalar; x86 performance programming has been all about caching and careful memory access since the pentium1.
I agree -- dealing with a cache miss can indeed take thousands of cycles, or more. If something's in the cache, the P-IV and Core2 CPUs can get at it with a throughput of 1 cycle usually. And many register-based instructions can achieve throughputs of more than 1 instruction per cycle.
anyway, no more speculation: these things can easily be measured. on something like a core 2 duo (and newer) you'll be really amazed at what you find
Yes. I wish I had the time to do this! I'm sure it would be educational. I can say that my high-precision multiplication code runs significantly faster on my Core2 system than it does on my P-IV system, even without adjusting for the clock speed difference (2.4 GHz Core2 vs 3.2 GHz P-IV) so the more advanced architecture is definitely a major factor.
I guess the main point to reiterate is that most efforts for optimizing code for fractal generation should focus on the parts of the computation that involve transcendental operations. The number of such instructions should be minimized. Formula writers should be aware that multiplying, dividing, and especially performing exponentiation or transcendental operations on complex numbers is much more computationally intensive than doing the same operations on real numbers. Formula code shoudl be carefully structured their code to minimize such operations.
That said, due to the superscalar and highly cached architecture of modern CPUs (everything beyond 486-era units) many counterintuitive effects can arise in timings. A cache miss caused by an unfortunate, but well-intentioned, attempt to save an intermediate result can indeed cost more than re-doing the calculation. This was something I didn't think of in my earlier comments.
Interesting discussion.
January 26, 2009, 04:59:30 AM
Dilber MC Theme by HarzeM