Commit graph

10 commits

Author SHA1 Message Date
Sebastian Ullrich
76753a0696 test(tests/playground/expr_const_folding): add Swift translation 2019-02-19 11:24:10 +01:00
Sebastian Ullrich
ddab7bcea8 test(tests/playground/expr_const_folding): Haskell version 2019-02-18 14:59:33 +01:00
Sebastian Ullrich
59d19aee2b test(tests/playground/expr_const_folding): fix Lean version 2019-02-18 14:29:07 +01:00
Leonardo de Moura
aff5f96a3d test(tests/playground): simple task benchmarks 2019-02-17 11:47:02 -08:00
Leonardo de Moura
821bdcdac0 chore(tests/playground): add helper files 2019-02-15 18:13:37 -08:00
Leonardo de Moura
eef60279e4 tests(tests/playground/expr_const_folding): another example for the paper
@kha I implemented a more complex example for the paper. The difference
in performance is awesome. On my Linux desktop:

Lean time:  3.34  secs
OCaml time: 11.72 secs

I believe that the difference in performance is due to destructive
updates happening in transformation functions such as `reassoc` and
`const_folding`. I will add a flag to Lean to disable `reuse/reset`
automatic insertion.

BTW, this test requires `ulimit -s unlimited` to avoid stack overflows.
2019-02-15 12:07:52 -08:00
Leonardo de Moura
f879cdb12f test(tests/playground): add new example in Lean and OCaml
@kha I wrote a simple test in Lean and OCaml. Right now, the numbers on
my machine are

arith_eval.ml         8.13 secs
arith_eval_nat.lean   10.71 secs

OCaml is computing with machine boxed integers, and we are computing
with `nat`. Our version is more expensive since we have to check
whether the number is small or big, and whether the result needs to be a
mpz value or not.

Almost half of our runtime is spent deallocating the big object returned
by `mk_expr`. The deferred free feature does not help here because
we don't deallocate the object in the end but as we execute `eeval`.
So, we perform many small invocations to `del`. None of them take
long, but the overall cost is super high. I can use a different strategy
where `del(o)` just updates the `g_to_free` list, and we deallocate
at most `LEAN_DEFERRED_FREE_QUOTA` at each allocation. The current
deferred free approach would also work if we could use the borrowed
annotations in `eeval`. In this case, we would not delete the input
expression as we evaluate it.

As an experiment, I manually added a `lean::inc` before invoking
`eeval`. The idea was prevent memory deallocation. With this
modification, the program runs in 5.87 secs.

BTW, I also wrote a version using uint32 (arith_eval_uint32.lean),
but the current compiler generates poor code for it.
I know how to fix the performance problem.
2019-02-14 15:50:07 -08:00
Leonardo de Moura
6083bde3bc chore(tests/playground/deriv): add example for testing in the playground 2019-02-14 10:49:46 -08:00
Leonardo de Moura
1716f1f6c9 test(tests/playground/perf): performance test
On my macbook,
- with default kind STHeap: 3.15 secs
- with default kind MTHeap: 3.75 secs

@cc kha
2019-02-14 08:43:04 -08:00
Leonardo de Moura
6f852cf7af feat(tests/playground): add run.sh script for running tests
@kha I have added `timeit` for running experiments for the paper.
We have to be careful because `timeit` may produce incorrect results
due to compiler optimizations (e.g., ground term extraction).
Here are examples that do not produce the result we expect:

```
def main : io uint32 :=
timeit "tst" (io.println' ("result " ++ to_string (tst 1000000))) *>
pure 0
```

```
def main (xs : list string) : io uint32 :=
timeit "tst" (io.println' ("result " ++ to_string (tst xs.head.to_nat))) *>
pure 0
```
2019-02-13 17:17:14 -08:00