login  home  contents  what's new  discussion  bug reports     help  links  subscribe  changes  refresh  edit

Edit detail for SpeedOfUserCode revision 2 of 4

1 2 3 4
Editor: test1
Time: 2016/09/16 14:18:52 GMT+0
Note:

changed:
-in library calls 'sin' and 'tan'.  Still, since C execution time is
-quite small most of time for other systems are likely to be overhead
-and benchmark shows that FriCAS overhead is quite low.
in library calls 'sin' and 'tan'.  Fourth, 'sin' argument does not
change within loop so can be moved outside.  Examining output of C
compiler shows that it is indeed moving 'sin' out of the loop.
And measurement indicate that 'sin' call is twice as expensive as
'tan' call.  Any system which does not move 'sin' out of the loop
will spent about 3 time more in actual computations than C code.
In particular FriCAS does not perform this optimization.
Still, since C execution time is quite small most of time for other
systems are likely to be overhead and benchmark shows that FriCAS
overhead is quite low.

Here w show FriCAS? version of benchmark presented at http://cosmosimple.blogspot.de/2013/12/some-benchmarks-of-mathematica-vs.html

fricas
do_sum(x, n) ==
    sum := 0.0::DoubleFloat
    inc := 1.0::DoubleFloat
    for i in 1..n repeat
        inc := inc*sin(x)/(i::DoubleFloat)
        sum := sum + tan(inc)
    sum
Type: Void
fricas
)set messages time on
 
fricas
)set output tex off
 
fricas
)set output algebra on
-- first time we pay costs of domain lookups and compilation do_sum(10.5::DoubleFloat, 10^7)
fricas
Compiling function do_sum with type (DoubleFloat,PositiveInteger)
       -> DoubleFloat 
(2) - 0.8942532397659797
Type: DoubleFloat?
fricas
Time: 0.03 (IN) + 1.35 (EV) + 0.07 (OT) = 1.45 sec

The original article gives the following execution times for 10^8 iterations: 2320s (estimated) for normal Mathematica code (180s with underflow checking turned off), 6.80s for Mathematica code compiled to VM, 1.04s for Mathematica code compiled to C, 0.66s for native C code, 702s for Maxima, 59.6s for Python.

The article did not not specify machine speed, but detail suggest it was a fast one. So we can can infer that FriCAS? performs quite well on this benchmark, probably slower than compiled Mathematica code, but better than interpreded system. Note that FriCAS? time includes compilation time.

Note1: There are several flaws in this benchmark. Fist, it operates on extremally small numbers, systems which catch underflow may be unfairly punished (as is the case with dafault Mathematica timing). Second, the computation is purely numeric, while we should compare symbolic capabilities. Third, most of actual computation should be spent in library calls sin and tan. Fourth, sin argument does not change within loop so can be moved outside. Examining output of C compiler shows that it is indeed moving sin out of the loop. And measurement indicate that sin call is twice as expensive as tan call. Any system which does not move sin out of the loop will spent about 3 time more in actual computations than C code. In particular FriCAS? does not perform this optimization. Still, since C execution time is quite small most of time for other systems are likely to be overhead and benchmark shows that FriCAS? overhead is quite low.

Note2: This is also shows that types lead to better execution speed: FriCAS? knows types so can use faster specialized routines, instead of dispatching on types. Also, we specified argument to be DoubleFloat?. Otherwise FriCAS? would perform calculations using Float, which has arbitrary precision but is implemented entirely is software, so is much slower than DoubleFloat?.