## Where communities thrive

• Join over 1.5M+ people
• Join over 100K+ communities
• Free without limits
##### Activity
Francesco Biscani
@bluescarni
Regarding 2, the fact that the string constructor is still there but it does not operate as before is an unfortunate consequence of the fact that you can construct rationals from string. In piranha the poly ctor from string had a special meaning, while in obake the poly ctors other than copy/move simply forward the construction to the coefficient type.
Regarding the use of rationals as polynomial coefficients, obake does not implement yet an optimization that piranha had. piranha used to convert all rational coefficients in a poly multiplication to a common denominator, thus transforming a rational poly multiplication into an integer poly multiplication. This essentially means avoiding a lot of GCD computations which are not needed. obake will also have this optimisation, but it does not at the moment.
Andrew Corrigan
@andrewcorrigan
wow, so it can get even faster?
Francesco Biscani
@bluescarni
it should, but only if the polys are long enough I believe. In my tests I always used rather large polynomials and there the difference was very visible.
it might be possible that for shorter polynomials the difference is not that great, but it's something that needs to be studied/tuned.
Andrew Corrigan
@andrewcorrigan
large is important for me too
Francesco Biscani
@bluescarni
are your rational coefficients large in terms of bit width?
Andrew Corrigan
@andrewcorrigan
I don't know to be honest
how does that relate to digits?
sorry, I'm a bit ignorant of this stuff
Francesco Biscani
@bluescarni
no problem, just take the number of base 10 digits and multiply by ~3.3 (that is log(10)/log(2))
Andrew Corrigan
@andrewcorrigan
is that like if I could store the numerator/denominator using 32-bit / 64-bit / 128-bit integers?
Francesco Biscani
@bluescarni
yes
Andrew Corrigan
@andrewcorrigan
etc.
ok
Francesco Biscani
@bluescarni
I just wanted to get a feeling of whether your numerators/denominators are "small" (i.e., < 2**64) or not
Andrew Corrigan
@andrewcorrigan
I'm checking
yeah, they're small
well, at least at first, we perform many operations, so I imagine they grow quite a bit
Francesco Biscani
@bluescarni
ok, I see. I am pretty sure you'll see a speedup after I implement that optimisation, even though it might not be easy to say by how much exactly.
Andrew Corrigan
@andrewcorrigan
honestly, Piranha was already blazing fast (compared to Sympy), but I just implemented the d_packed_monomial , it's working great, and for a much larger problem it's close to 2x faster
Francesco Biscani
@bluescarni
great!
Andrew Corrigan
@andrewcorrigan
Here's an example of some the errors that -Werror triggers when the TBB headers are included:
[ 69%] Building CXX object /obake/CMakeFiles/obake.dir/src/series.cpp.o
In file included from /obake/src/series.cpp:14:
In file included from /obake/include/obake/series.hpp:41:
In file included from /third_party/tbb/include/tbb/blocked_range.h:20:
/third_party/tbb/include/tbb/tbb_stddef.h:350:16: error: use of old-style cast [-Werror,-Wold-style-cast]
return 0==((uintptr_t)pointer & (alignment-1));
^          ~~~~~~~
/third_party/tbb/include/tbb/tbb_stddef.h:476:33: error: use of old-style cast [-Werror,-Wold-style-cast]
static const size_t value = (size_t)((sizeof(size_t)==sizeof(u)) ? u : ull);
^       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /obake/src/series.cpp:14:
In file included from /obake/include/obake/series.hpp:42:
In file included from /third_party/tbb/include/tbb/parallel_for.h:21:
In file included from /third_party/tbb/include/tbb/tbb_machine.h:235:
In file included from /third_party/tbb/include/tbb/machine/linux_intel64.h:24:
/third_party/tbb/include/tbb/machine/gcc_ia32_common.h:29:12: error: implicit conversion changes signedness: 'uintptr_t' (aka 'unsigned long') to 'intptr_t' (aka 'long') [-Werror,-Wsign-conversion]
return j;
~~~~~~ ^
In file included from /obake/src/series.cpp:14:
In file included from /obake/include/obake/series.hpp:42:
In file included from /third_party/tbb/include/tbb/parallel_for.h:21:
In file included from /third_party/tbb/include/tbb/tbb_machine.h:235:
/third_party/tbb/include/tbb/machine/linux_intel64.h:70:1: error: use of old-style cast [-Werror,-Wold-style-cast]
__TBB_MACHINE_DEFINE_ATOMICS(1,int8_t,"")
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/third_party/tbb/include/tbb/machine/linux_intel64.h:44:49: note: expanded from macro '__TBB_MACHINE_DEFINE_ATOMICS'
: "=a"(result), "=m"(*(volatile T*)ptr)                    \
^            ~~~
/third_party/tbb/include/tbb/machine/linux_intel64.h:70:1: error: use of old-style cast [-Werror,-Wold-style-cast]
__TBB_MACHINE_DEFINE_ATOMICS(1,int8_t,"")
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/third_party/tbb/include/tbb/machine/linux_intel64.h:45:62: note: expanded from macro '__TBB_MACHINE_DEFINE_ATOMICS'
: "q"(value), "0"(comparand), "m"(*(volatile T*)ptr)       \
^            ~~~
/third_party/tbb/include/tbb/machine/linux_intel64.h:70:1: error: use of old-style cast [-Werror,-Wold-style-cast]
__TBB_MACHINE_DEFINE_ATOMICS(1,int8_t,"")
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/third_party/tbb/include/tbb/machine/linux_intel64.h:54:48: note: expanded from macro '__TBB_MACHINE_DEFINE_ATOMICS'
: "=r"(result),"=m"(*(volatile T*)ptr)                     \
^            ~~~
/third_party/tbb/include/tbb/machine/linux_intel64.h:70:1: error: use of old-style cast [-Werror,-Wold-style-cast]
__TBB_MACHINE_DEFINE_ATOMICS(1,int8_t,"")
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/third_party/tbb/include/tbb/machine/linux_intel64.h:55:47: note: expanded from macro '__TBB_MACHINE_DEFINE_ATOMICS'
^            ~~~
/third_party/tbb/include/tbb/machine/linux_intel64.h:70:1: error: use of old-style cast [-Werror,-Wold-style-cast]
__TBB_MACHINE_DEFINE_ATOMICS(1,int8_t,"")
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/third_party/tbb/include/tbb/machine/linux_intel64.h:64:48: note: expanded from macro '__TBB_MACHINE_DEFINE_ATOMICS'
: "=r"(result),"=m"(*(volatile T*)ptr)                     \
^            ~~~
/third_party/tb
This is using Clang 10 on Linux. Something similar happened with Xcode on OS X 10.14.
Francesco Biscani
@bluescarni
could you run make VERBOSE=1 and check if the TBB headers are included via -I or -isystem?
and what version of TBB is this?
Andrew Corrigan
@andrewcorrigan
The tbb version is the cmake-ified version from https://github.com/wjakob/tbb
Francesco Biscani
@bluescarni

It's not a problem in principle to selectively deactivate those warnings for the TBB headers, but I am a bit baffled by the fact that I cannot reproduce it and by the fact that similar warnings are not being produce by, e.g., Boost or other libraries obake depends on. It makes me think there's something specific in the way TBB is being included in your setup.

It could also be that TBB is being configured/built in a different way and on my system the offending code is bracketed in the dead branch of some #ifdef.

Andrew Corrigan
@andrewcorrigan
it's included via -I btw
Andrew Corrigan
@andrewcorrigan
Obake is great, thanks again. I'm currently trying to compile in VS2019 (/std:c++17 /Zc:__cplusplus). I'm encountering some errors. I see the documentation says that this compiler should be supported, but wasn't sure if it is in practice. Would you be interested in me reporting errors with reproducers to the issue tracker?
Francesco Biscani
@bluescarni

What version of VS2019 is this? There is a couple of CI builds using MSVC 2019 which works:

But in my experience MSVC tends to introduce regressions relatively frequently, so perhaps something changed in the meantime
Andrew Corrigan
@andrewcorrigan
16.7.2
cmake reports the compiler version as: "MSVC 19.27.29110.0".
hopefully one of those versions is meaningful
Francesco Biscani
@bluescarni
ok so in the continuous integration pipeline we test some 19.26.xxx versions, so it's possible that you are experiencing some compiler regression
Andrew Corrigan
@andrewcorrigan
I see, that's unfortunate
Andrew Corrigan
@andrewcorrigan
I understand msvc breaks a lot (I had to implement a bunch of workarounds in my code to get things working). Is there a way for CI to test newer versions as well to at least know where things stand?
Francesco Biscani
@bluescarni
feel free to report the errors here or on github, if the workarounds are not too heavy I have no problems including them
I think the CI automatically updates MSVC2019 periodically. It's possible that since June the images were actually updated but the CI has not been run for a couple of months.
Andrew Corrigan
@andrewcorrigan
It's still possible that I'm just doing something wrong, so maybe once you see the reproducer you'll just tell me I just goofed up :-)
Andrew Corrigan
@andrewcorrigan
Would you be interested in supporting an option to build Obake as a static library? I think it would just require tweaking the call to add_library and the OBAKE_DLL_PUBLIC macro. I can do this via a PR if that's helpful.
Francesco Biscani
@bluescarni
Feel free to open a PR. It was planned down the line, even if it is not high priority currently.
mp++ can also be compiled as a static library and I was planning to use the same approach for obake.
Francesco Biscani
@bluescarni
As you say, it should be a matter of tweaking the OBAKE_DLL_PUBLIC macro and applying some modifications to the build system. There's some extra setup to be done for MSVC, see here:
https://github.com/bluescarni/mppp/blob/master/CMakeLists.txt#L186
Andrew Corrigan
@andrewcorrigan
Great. I've already done most of it (following your naming conventions in mp++) . I think the only thing missing is the MSVC runtime library setup. I probably won't be able to submit it until October, but I'll definitely get it over to you asap
Francesco Biscani
@bluescarni
There's some extra setup in mp++ regarding the use of the dynamic MSVC runtime when compiling a static library (or perhaps viceversa) that I don't think is really relevant/needed for obake.
Andrew Corrigan
@andrewcorrigan
oh ok
Andrew Corrigan
@andrewcorrigan
Would it be feasible to have an option to disable TBB in Obake? I'd like to be able to run valgrind on my application and TBB triggers a lot of false positives.