Sumith : Optimized Awesomeness

26 Jun 2015

GSoC Progress - Week 5

Programming · GSoC · SymPy

Hello, this post contains the fourth report of my GSoC progress. We hit Piranha's speed, the highlight of this week.

Progress

We were able to reach Piranha's speed. At an average 14-ish ms to the benchmark, we are happy enough (still can be improved) to start wrapping this low-level implementation to a Polynomial class. Last week I had reported speed 23ms and this week we are better.

We had missed out a compiler flag, DNDEBUG to indicate Release mode of Piranha leading to slow-down, #482.
Adding this compiler flag means we should not be using assert statement, which SymEngine does in SYMENGINE_ASSERT and test files too. These had to be sorted out if Piranha were to be a hard dependency of SymEngine's polynomial module.

Hence, the issue of moving the tests suite from asserts to a well-developed test framework came up again, #282. We explored a couple, but Catch still seemed to be the best option.
Catch was implemented, which is a benefit to SymEngine in the long run too.
As for the SYMENGINE_ASSERT, we decided to change our macro to raise an exception or just abort the program.
Catch is a very good tool. We thank Phil Nash and all the contributors for making it.

Next up, wrapping into Polynomial.

  • We need some functionality to convert a SymEngine expression(Basic) into one of hashset representations directly. Now I convert basic to poly and then to hashset as just getting the speed right was the issue.

  • Domains of coefficients need to be thought of. SymPy and Sage will be need to looked into and their APIs need to be studied. We need ZZ, QQ and EX, the work for EX has been done by Francesco Biscani, this will be patched for the latest master and commited in his name. There could also be an automatic mode, which figures out the fastest representation for the given expression, at the price of a little slower conversion, as it needs to traverse the expression to figure out what representation fits.

  • tuple to packed conversion when exponents don't fit. Also encode supports signed ints which is a boon to us, as we don't have to worry about negative exponents. For rational exponents we use tuple.

I still haven't figured out the reason for slow down of expand2 and expand2b in my packint branch. I have been suggested to use git bisect. Will do next week.

Report

expand2d results:

Result of 10 execution:
14ms
14ms
14ms
15ms
14ms
15ms
14ms
14ms
15ms
14ms

Maximum: 15ms
Minimum: 14ms
Average: 14.3ms

Here, the evaluate_sparsity() gave the following result for the hash_set

0,11488
1,3605
2,1206
3,85

Piranha has the following results

Average: 13.421ms
Maximum: 13.875ms
Minimum: 12.964ms

A more detailed report of benchmarks and comparisons can be found here

A minor PR where MPFR was added as a Piranha dependency, 472 was merged.

Another PR in which the tests where moved to Catch is good to play with and merge, minor build nits remaining, 484.

Targets for Week 5

  • Figure out the reason for slow down in benchmarks, fix that.
  • Change the SYMENGINE_ASSERT macro to raise an exception.
  • Add the DNDEBUG flag for with Piranha builds, as now SymEngine doesn't use assert, close issue #482.
  • Port @bluescarni's work of EX to SymEngine.
  • Wrap the lower-level into Polynomial for signed integer exponents in ZZ domain with functionality atleast that of UnivariatePolynomial.

That's all this week.
Sbohem

Related Posts