Edit detail for SpeedOfUserCode revision 4 of 4

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

(1) -> 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

)set messages time on
 

)set output tex off
 

)set output algebra on

-- first time we pay costs of domain lookups and compilation
do_sum(10.5::DoubleFloat, 10^7)

Compiling function do_sum with type (DoubleFloat, PositiveInteger)
       -> DoubleFloat 

   (2)  - 0.8942532397659797

Time: 0.75 (EV) + 0.08 (OT) = 0.83 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 interpreted 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 default 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?.