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

# Edit detail for SpeedOfUserCode revision 4 of 4

 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/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.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?.