Toon Moene wrote:
I can measure the contribution of the cbrt effect in isolation, though
(given the above change of HIRLAM source code).
Well, the effect of the cbrt change (X ** (1./3.) -> cbrt(X)) is close
to zero.
Some other change must have diminished the number of pow[f] calls
substan
Richard Guenther wrote:
>> I wrote:
The speed up is around 5 %.
Is this because of cbrt or a combined effect? Can you measure the cbrt
effect in isolation?
This is a combined effect (assuming that things like x**1.5 didn't
expand to x * sqrt (x) before) - however, the number of opportunit
On 12/5/06, Toon Moene <[EMAIL PROTECTED]> wrote:
Toon Moene wrote:
> Toon Moene wrote:
>
>> Richard Guenther wrote:
>>
>>> It's a matter of making the cbrt builtin available - I have a patch
>>> for this,
>
> Oh, BTW, my own version of this patch (plus your work in the area of
> sqrt) had the f
Toon Moene wrote:
Toon Moene wrote:
Richard Guenther wrote:
It's a matter of making the cbrt builtin available - I have a patch
for this,
Oh, BTW, my own version of this patch (plus your work in the area of
sqrt) had the following effect on a profile breakdown
The speed up is around 5
On Dec 5, 2006, at 12:32 PM, Toon Moene wrote:
Couldn't libgfortran just simply borrow, errr, include the glibc
version ?
No, not without asking the FSF (rms) as I think the license is
different (GPL v GPL+libgcc exception).
On 12/5/06, Toon Moene <[EMAIL PROTECTED]> wrote:
Richard Guenther wrote:
> It's a matter of making the cbrt builtin available - I have a patch for
> this, but wondered if the fortran frontend can rely on the cbrt library call
> being available? Or available in a fast variant, not a fallback
>
Toon Moene wrote:
Richard Guenther wrote:
It's a matter of making the cbrt builtin available - I have a patch
for this,
Oh, BTW, my own version of this patch (plus your work in the area of
sqrt) had the following effect on a profile breakdown (every routine
above 2 %) of the forecasting co
Richard Guenther wrote:
It's a matter of making the cbrt builtin available - I have a patch for
this, but wondered if the fortran frontend can rely on the cbrt library call
being available? Or available in a fast variant, not a fallback
implementation in libgfortran which does pow (x, 1./3.)
On Dec 4, 2006, at 20:19, Howard Hinnant wrote:
If that is the question, I'm afraid your answer is not accurate.
In the example I showed the difference is 2 ulp. The difference
appears to grow with the magnitude of the argument. On my systems,
when the argument is DBL_MAX, the difference
Howard Hinnant wrote:
On Dec 4, 2006, at 6:08 PM, Richard Guenther wrote:
The question
is whether a correctly rounded "exact" cbrt differs from the pow
replacement by more than 1ulp - it looks like this is not the case.
If that is the question, I'm afraid your answer is not accurate. In
th
On Dec 4, 2006, at 6:08 PM, Richard Guenther wrote:
The question
is whether a correctly rounded "exact" cbrt differs from the pow
replacement by more than 1ulp - it looks like this is not the case.
If that is the question, I'm afraid your answer is not accurate. In
the example I showed the
On 12/5/06, Joseph S. Myers <[EMAIL PROTECTED]> wrote:
On Tue, 5 Dec 2006, Richard Guenther wrote:
> is whether a correctly rounded "exact" cbrt differs from the pow
> replacement by more than 1ulp - it looks like this is not the case.
They fairly obviously differ for negative arguments, which
On Tue, 5 Dec 2006, Richard Guenther wrote:
> is whether a correctly rounded "exact" cbrt differs from the pow
> replacement by more than 1ulp - it looks like this is not the case.
They fairly obviously differ for negative arguments, which are valid for
cbrt but not for pow (raising to a fractio
On 12/4/06, Howard Hinnant <[EMAIL PROTECTED]> wrote:
On Dec 4, 2006, at 4:57 PM, Richard Guenther wrote:
>
>> My inclination is that if pow(x, 1./3.) (computed
>> correctly to the last bit) ever differs from cbrt(x) (computed
>> correctly to the last bit) then this substitution should not be do
On Dec 4, 2006, at 4:57 PM, Richard Guenther wrote:
My inclination is that if pow(x, 1./3.) (computed
correctly to the last bit) ever differs from cbrt(x) (computed
correctly to the last bit) then this substitution should not be done.
C99 7.12.7.1 says "The cbrt functions compute the real cu
On 12/4/06, Howard Hinnant <[EMAIL PROTECTED]> wrote:
On Dec 4, 2006, at 11:27 AM, Richard Guenther wrote:
> On 12/3/06, Toon Moene <[EMAIL PROTECTED]> wrote:
>> Richard,
>>
>> Somewhere, in a mail lost in my large e-mail clash with my ISP
>> (verizon), you said that gfortran couldn't profit fro
On Dec 4, 2006, at 11:27 AM, Richard Guenther wrote:
On 12/3/06, Toon Moene <[EMAIL PROTECTED]> wrote:
Richard,
Somewhere, in a mail lost in my large e-mail clash with my ISP
(verizon), you said that gfortran couldn't profit from the pow(x,
1./3.)
-> cbrt(x) conversion because gfortran didn
On 12/3/06, Toon Moene <[EMAIL PROTECTED]> wrote:
Richard,
Somewhere, in a mail lost in my large e-mail clash with my ISP
(verizon), you said that gfortran couldn't profit from the pow(x, 1./3.)
-> cbrt(x) conversion because gfortran didn't "know" of cbrt.
Could you be more explicit about this
18 matches
Mail list logo
