

last edited 3 years ago by test1 
1 2 3 4  
Editor: test1
Time: 2019/06/25 14:11:05 GMT+0 

Note: 
changed: Here w show FriCAS version of benchmark presented at Here we show FriCAS version of benchmark presented at
Here we show FriCAS version of benchmark presented at http://cosmosimple.blogspot.de/2013/12/somebenchmarksofmathematicavs.html
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.60 (EV) + 0.06 (OT) = 0.66 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?.