Optimized RDF element allocation "a bit", new benchmarks:
%pyrex
def foo(R, a, b, c, n):
cdef int i
a = R(a); b = R(b); c = R(c)
for i from 0 <= i < n:
z = a*b + b*c + c*a
sage: time foo(RR, 3, 4.5, 200, N)
CPU time: 0.32 s, Wall time: 0.33 s
sage: time foo(RDF, 3, 4.5, 200, N)
CPU time: 0.06 s, Wall time: 0.06 s
def foo(R, a, b, c, n):
cdef int i
a = R(a); b = R(b); c = R(c)
for i from 0 <= i < n:
z = a.sin() + b.sin() - c.sin()
sage: time foo(RR, 3, 4.5, 200, N)
CPU time: 5.57 s, Wall time: 5.71 s
sage: time foo(RDF, 3, 4.5, 200, N)
CPU time: 0.16 s, Wall time: 0.15 s
Unfortunately, I know MPFR can't be sped up that much...
- Robert
On Mar 28, 2007, at 5:29 PM, Robert Bradshaw wrote:
> I ran lots of benchmarks before starting this post, I should have
> included them. Here they are some typical ones:
>
> %pyrex
> def foo(R, a, b, c, n):
> cdef int i
> a = R(a); b = R(b); c = R(c)
> for i from 0 <= i < n:
> z = a.sin().sin()
>
> sage: time foo(RR, 3, 4.5, 200, 10^5)
> CPU time: 2.58 s, Wall time: 2.62 s
> sage: time foo(RDF, 3, 4.5, 200, 10^5) # this is using the GSL sin
> () function, _not_ the clib one.
> CPU time: 0.11 s, Wall time: 0.14 s
>
> %pyrex
> def foo(R, a, b, c, n):
> cdef int i
> a = R(a); b = R(b); c = R(c)
> for i from 0 <= i < n:
> z = a*b + b*c + c*a
>
> sage: time foo(RR, 3, 4.5, 200, 10^5)
> CPU time: 0.30 s, Wall time: 0.31 s
> sage: time foo(RDF, 3, 4.5, 200, 10^5)
> CPU time: 0.15 s, Wall time: 0.14 s
>
>
> %pyrex
> def foo(R a, b, c, n):
> cdef int i
> a = R(a); b = R(b); c = R(c)
> for i from 0 <= i < n:
> z = a/b + b/c + c/a
>
> sage: time foo(RR, 3, 4.5, 200, 10^5)
> CPU time: 0.33 s, Wall time: 0.35 s
> sage: time foo(RDF, 3, 4.5, 200, 10^5)
> CPU time: 0.14 s, Wall time: 0.15 s
>
>
> Perhaps some more tests are in order, but I think the arithmetic
> vs. object-creation-time ratio for RDF is huge, and has more room
> for optimization (given the simple structure) than even the
> integers had (and it would be much easier). As for using SageX to
> do the benchmarks, I think that often if one cares about speed, the
> functions you will be passing such arguments into will be written
> in SageX.
>
> This was actually all a footnote to the main question of the
> original post, namely having an UnparsedLiteralDecimal class used
> by the preparser to avoid awkwardness like
>
> sage: RealField(100)('1.2') == RealField(100)(1.2)
> False
>
> I've received (good) feedback on this issue from only two people.
>
> - Robert
>
>
>
> On Mar 28, 2007, at 4:54 PM, William Stein wrote:
>
>> On 3/28/07, Robert Bradshaw <[EMAIL PROTECTED]> wrote:
>>>> If we decide that we value portability but not necessarily
>>>> precision,
>>>> we could use RDF but avoid using C library implementations of the
>>>> mathematical functions. (Currently, RDF uses the C library for
>>>> tan(),
>>>> acos(), asin(), atan(), cosh(), sinh(), tanh(), according to a
>>>> quick
>>>> scan of real_double.pyx -- I may have missed some.) We would also
>>>> want to verify that the GSL implementations are portable across
>>>> architectures, and do something about 32-bit x86.
>>>
>>> I'm leaning towards this too. There area actually fpu_fix_*
>>> functions
>>> in the quad double package to handle 32-bit x86 that might be useful
>>> to look at.
>>
>> My impression of the discussion so far is this:
>> * There is a vague impression that RDF is "vastly faster" than
>> RR (mpfr),
>> so people are considering changing things so RDF is the
>> default 53-bit
>> real field in SAGE, purely for efficiency reasons.
>> * There is no discussions so far about actual benchmarks, and
>> how much
>> faster RDF really is.
>> * RDF (=machine floats) mostly uses the C library float
>> special functions that are potentially very
>> inaccurate in comparison to mpfr special functions, so the
>> suggestion
>> is to maybe make RDF use better special functions.
>>
>> I did a few benchmarks (see below), and 53-bit RR mpfr arithmetic in
>> the interpreter is maybe 10% slower than RDF, i.e., arithmetic
>> doesn't
>> make enough of a difference to warrant even considering switching to
>> RDF from RR. I then did benchmarks with some trig functions and
>> there
>> RDF is vastly faster, over 20 times faster in one benchmark.
>>
>> Conclusion: The only justifiable reason to switch to RDF for the
>> default 53-bit real field is to speed up special function evaluation.
>> But ironically, the fast special functions fror 53-bit floats have
>> serious quality and precision issues, so we probably wouldn't switch
>> unless we made them better, which will necessarily make them much
>> slower (?).
>>
>> Benchmarks:
>>
>> {{{
>> %time
>> a = RDF(1.5); b = RDF(27.3)
>> for i in range(10^6):
>> c = a*b + a+b + a-b
>> ///
>> CPU time: 2.09 s, Wall time: 3.33 s
>> }}}
>>
>> {{{
>> %time
>> a = RR(1.5); b = RR(27.3)
>> for i in range(10^6):
>> c = a*b + a+b + a-b
>> ///
>> CPU time: 2.14 s, Wall time: 3.95 s
>> }}}
>>
>> {{{
>> %time
>> a = RDF(1.5); b = RDF(27.3)
>> for i in range(10^6):
>> c = a*b
>> ///
>> CPU time: 0.58 s, Wall time: 1.06 s
>> }}}
>>
>> {{{
>> %time
>> a = RR(1.5); b = RR(27.3)
>> for i in range(10^6):
>> c = a*b
>> ///
>> CPU time: 0.69 s, Wall time: 0.97 s
>> }}}
>>
>> {{{
>> %time
>> a = RDF(1.5); b = RDF(27.3)
>> for i in range(10^6):
>> c = a.sin() * b.cos()
>> ///
>> CPU time: 1.64 s, Wall time: 3.01 s
>> }}}
>>
>> {{{
>> %time
>> a = RR(1.5); b = RR(27.3)
>> for i in range(10^6):
>> c = a.sin() * b.cos()
>> ///
>> CPU time: 22.17 s, Wall time: 36.39 s
>> }}}
>>
>> >
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~----------~----~----~----~------~----~------~--~---
