These are chat archives for symengine/symengine

29th
Aug 2016
Francesco Biscani
@bluescarni
Aug 29 2016 14:28
@isuruf @certik I have started some preliminary work on the new integer class here: https://github.com/bluescarni/mppp. Some points:
  • I am trying to keep things compilable in MSVC - I haven't actually tried it yet, but I will get to it soon
  • the design is similar in spirit to piranha's mp_integer class, but there are a few simplifications
  • the limb type is now fixed to be exactly mp_limb_t (same as GMP, whatever it is), and for the time being I have hard-coded 2 limbs of static storage (same as mp_integer)
  • do you think the number of static limbs should be configurable? I have kept the option open so far and it's not hard to change now
  • the general plan is to enable the use of 128bit integers if they are available (as currently done in mp_integer), and otherwise fallback to using low-level GMP functions https://gmplib.org/manual/Low_002dlevel-Functions.html#Low_002dlevel-Functions if necessary (possibly some operations on MSVC will have to be implemented this way)
  • I am keeping track of performance via nonius (in the benchmark directory). I am comparing to Boost multiprecision's gmp_int (a straightforward GMP wrapper) and seeing good speedup (you can run the benchmarks to test yourself)
  • part of the performance comes from using thread-local caches. I believe the thread_local keyword has been only recently supported on OSX with the stock compiler (although it has been available for long on homebrew's clang), so that might be a portability question mark in practice
Isuru Fernando
@isuruf
Aug 29 2016 14:55
@bluescarni, that's great. One other interesting idea to try is to have a mpz_struct_t pool like Sage does, where the dynamic array is reused instead of discarding.
Francesco Biscani
@bluescarni
Aug 29 2016 14:56
you mean when the destructor is called?
Isuru Fernando
@isuruf
Aug 29 2016 14:56
yes
Francesco Biscani
@bluescarni
Aug 29 2016 14:57
right yes sounds good, I can imagine workloads where it would help
I need to catch the train back home, but I'll read later if you have any other comment
talk later o/
Isuru Fernando
@isuruf
Aug 29 2016 14:58
Okay. Thanks for the update
From the looks of it static thread_local can be deleted in most cases and it would just work for OS X.
I don't like the way mpz_to_stris implemented though. It's easy to get a wrong result
Francesco Biscani
@bluescarni
Aug 29 2016 18:01
what do you mean about mpz_to_str?
Francesco Biscani
@bluescarni
Aug 29 2016 18:09
I thought it's a bit non-standard because it returns a pointer to some invisible storage, maybe you are concerned about calling it multiple times inadvertently possibly overwriting the expected output?
what I like about it is that it allows to do string output without allocating each time, maybe we could keep the low-level function but provide a wrapper that returns an owning std::string in the high level API