65x penalty in performance for using float instead of RealNumber

[sagetrac-pang]

The function random() returns a "float", but 1.0*random() is a "RealNumber". The following code:

%time
#1
N=5000
x=random()
for c in xrange(N):
    kk = exp(x)

takes 5.24 seconds, while

%time
#1
N=5000
x=random()*1.0
for c in xrange(N):
    kk = exp(x)

takes 0.08

Component: symbolics

Keywords: float, RealNumber

Reviewer: Maarten Derickx

Issue created by migration from https://trac.sagemath.org/ticket/11332

[sagetrac-pang]

comment:1

It's a bit worse:

x=random()
timeit('exp(x)')

125 loops, best of 3: 7.88 ms per loop

while

x=random()*1.0
timeit('exp(x)')

625 loops, best of 3: 48.3 µs per loop

so the ratio is rather around 150x.

[nbruin]

comment:2

note that "float" is the standard python float type, whereas RealNumber is a preferred type for sage. Furthermore, "exp" is a general sage function that can do all kinds of "exponentiation" (symbolic, numeric etc.), and that incurs overhead. Apparently a particularly bad one for "float" types. Setting the base line:

sage: x=random()
sage: y=RealNumber(x)
sage: z=RDF(x)
sage: timeit('exp(x)')
625 loops, best of 3: 1.15 ms per loop
sage: timeit('exp(y)')
625 loops, best of 3: 10.3 µs per loop
sage: timeit('exp(z)')
625 loops, best of 3: 3.52 µs per loop

Using python's own "exp" is the fastest:

sage: timeit('math.exp(x)')
625 loops, best of 3: 373 ns per loop

You can shave off some time from the RealNumber one too by calling a method specific for it. It's slower, but RealNumber has much more functionality (also multiprecision)

sage: timeit('y.exp()')
625 loops, best of 3: 6.28 µs per loop

RDF is supposed to be Sage's version of "double precision floats" and is indeed comparable:

sage: timeit('z.exp()')
625 loops, best of 3: 704 ns per loop

If you don't mind a float, math.exp seems to receive a fairly efficiently coerced float from either RealNumber or RDF

sage: timeit('math.exp(y)')
625 loops, best of 3: 510 ns per loop
sage: timeit('math.exp(z)')
625 loops, best of 3: 419 ns per loop

It would be nice if the generic "exp" would find a bit faster codepaths for some of these types, but I wouldn't consider the current behaviour a "defect".