https://software.intel.com/de-de/forums/topic/362218/feed
deI looked at the generated
https://software.intel.com/de-de/comment/1722760#comment-1722760
<a id="comment-1722760"></a>
<div class="field field-name-comment-body field-type-text-long field-label-hidden"><div class="field-items"><div class="field-item even" property="content:encoded"><p>I looked at the generated code and the optimizer removed the whole loop assigning to result_iex because you never used the result. This is a classic problem in constructing benchmarks. When I fix that, and replace the integer exponent with the constant 4, I get:</p>
<p> Difference between results: 0.000000000000000E+000<br /> Elapsed time integer exponent in sec: 0.173999999999069<br /> Elapsed time real exponent in sec: 0.172000000005937<br /> Factor: 0.988505747165849</p>
<p>So this proves my point - using an integer-valued real constant exponent is just as fast as an integer exponent. If the exponent is a variable, then this doesn't apply. A PARAMETER constant is the same as a literal.</p>
</div></div></div>Tue, 29 Jan 2013 22:08:05 +0000mad\sblionelcomment 1722760 at https://software.intel.comDear TimP,
https://software.intel.com/de-de/comment/1722697#comment-1722697
<a id="comment-1722697"></a>
<div class="field field-name-comment-body field-type-text-long field-label-hidden"><div class="field-items"><div class="field-item even" property="content:encoded"><p>Dear TimP,</p>
<p>I tested a little bit with a negative base and real exponents ((-1000.d0)**4.1d0) and the intel compiler delivers NaN with a double precision real as result variable. As mathematically the result is a complex number I set the result as a complex and extended the input to ((-1000.d0,0.d0)**4.1d0) . The result is as expected. With a whole-number exponent the double precision real result variable delivers the correct result, too.</p>
<p>I don't tested how gcc interprets this because I don't have any negative bases and real exponents in combinition in my programs so far...</p>
<p>Kind regards,</p>
<p>Johannes</p>
</div></div></div>Tue, 29 Jan 2013 08:57:57 +0000JRieke@nordex-online.comcomment 1722697 at https://software.intel.comDear Steve,
https://software.intel.com/de-de/comment/1722696#comment-1722696
<a id="comment-1722696"></a>
<div class="field field-name-comment-body field-type-text-long field-label-hidden"><div class="field-items"><div class="field-item even" property="content:encoded"><p>Dear Steve,</p>
<p>thanks for your hint on the recognation of real as a whole-number by the compiler. I tested it with the example program above and replaced line 39 be <pre class="brush: fortran">result_rex(i) = (1000.1d0+dble(i))**4.d0</pre>. And again the results are not what I thought:</p>
<p>in debug mode</p>
<p>Difference between results: 0.000000000000000E+000<br />Elapsed time integer exponent in sec: 2.43299999999726<br />Elapsed time real exponent in sec: 2.43400000000111<br />Factor: 1.00041101520914</p>
<p>in release mode</p>
<p>Difference between results: 0.000000000000000E+000<br />Elapsed time integer exponent in sec: 0.000000000000000E+000<br />Elapsed time real exponent in sec: 0.243999999998778<br />Factor: Infinity</p>
<p>With optimization in release mode the real exponent is still slower than the integer counterpart. Not much but measurable. In debug mode both calculation times are nearly equal, varied a little each new run. Why is there a difference after optimization, if the compiler recognize the exponent as a whole-number? Assigning r_exponent as a parameter delivers the same results as using 4.d0 directly.</p>
<p>Again writing the exponent as an integer seems to be the best solution.</p>
<p>Kind regards,</p>
<p>Johannes</p>
</div></div></div>Tue, 29 Jan 2013 08:53:34 +0000JRieke@nordex-online.comcomment 1722696 at https://software.intel.comThe compiler will recognize
https://software.intel.com/de-de/comment/1722628#comment-1722628
<a id="comment-1722628"></a>
<div class="field field-name-comment-body field-type-text-long field-label-hidden"><div class="field-items"><div class="field-item even" property="content:encoded"><p>The compiler will recognize integer-valued real constant exponents and treat them as integers. Your test program uses variables, so that can't be done. But it does definitely use different sequences for a real exponent and an integer exponent, with the latter being faster.</p>
</div></div></div>Mon, 28 Jan 2013 16:20:34 +0000mad\sblionelcomment 1722628 at https://software.intel.comThere are benchmarks such as
https://software.intel.com/de-de/comment/1722507#comment-1722507
<a id="comment-1722507"></a>
<div class="field field-name-comment-body field-type-text-long field-label-hidden"><div class="field-items"><div class="field-item even" property="content:encoded"><p>There are benchmarks such as Polyhedron which are written gratuitously with integer valued real exponents, where good results require that the compiler make the non-standard optimization for simple cases of treating them as integers.</p>
<p>In the more difficult cases, the integer exponents should produce better accuracy, if the compiler doesn't recognize the integer-valued reals and make the substitution. As the case of negative numbers raised to a real power is not defined by Fortran, some compilers choose to let you take your chances on whether raising to an even integral-valued power gives you a "correct" numerical result or NaN. Fortran doesn't even set requirements for the case of negative number raised to a zero power, and there are inconsistencies among various otherwise highly regarded implementations on the treatment of NaN raised to an integer or real zero power.</p>
</div></div></div>Sat, 26 Jan 2013 03:47:41 +0000tim18comment 1722507 at https://software.intel.com