http://quantlib.414.s1.nabble.com/Removing-Boost-dependency-from-QuantLib-tp18381p18418.html
in my opinion cyl_bessel_il is a case where it would be natural to use its precursor in boost for compilers that do not yet support it in C++17 (i.e. have a check in the configure step for this). After a while you could just switch to the std:: version without much ado. But that’s again going back to my original question about avoiding boost for its own sake vs modernising the code to more recent C++ standards.
For clang you can check out its source code and build the latest release (or even the current master) on Linux yourself. That works well for me on Ubuntu. I guess when your QuantLib-noBoost builds with clang on Linux there won’t be issues on OS X (with the LLVM clang) either.
I would still be most interested in where the performance gain comes from exactly and if we can benefit from it in QuantLib classic as well, without C++17: It’s easy to say, let’s allow for 11, 14, 17, but there are still places where you have to work with MSVC 2010. In this situation you are happy that QL is still on 03 and you don’t have to backport it or use an older version. I’d be in favour of allowing 11 in QuantLib classic, but ideally maintaining a 03 branch which receives bug fixes, calendar updates etc.
> On 07 Jul 2017, at 22:50, Hao Zhang <
[hidden email]> wrote:
>
> Hi Peter,
>
> I just removed some GCC-specific code, and made it compile and run under Visual Studio 2017. Unfortunately I do not have access to a Mac, thus I cannot do any testing on macOS. If you have time, can you please try compiling the code again on Mac and send me the error message? I suppose Clang is more similar to GCC than to MSVC, thus if MSVC accept the code, making it run with Clang shouldn't be that hard...
>
> P.S. std::cyl_bessel_il is not too difficult to overcome. We already have modifiedBesselFunction_i and modifiedBesselFunction_k implemented in QuantLib. These functions just need to be modified for cases when the arguments become very large.
>
> Thanks and Best Regards,
>
> Hao
> On Friday, July 7, 2017 2:23:00 PM EDT Peter Caspers wrote:
>> Hi Hao, with the standard compiler on OS X El Capitan (Apple clang 8.0.0) there doesnât seem to be much hope to get it built. I also tried the LLVM clang 4.0.1 which is the latest release. That works much better, but there are still issues with C++17 support, some of which are easy to fix (missing template parameters) others not so easy (e.g. there is no support yet for std::cyl_bessel_il). gcc 7 seems to be the better alternative currently.
>> Best Regards
>> Peter
>>
>>> On 05 Jul 2017, at 23:03, Hao Zhang <
[hidden email]> wrote:
>>>
>>> Hi Peter,
>>>
>>> As I mentioned in the GitHub README, I have only tested the project with GCC7 on Linux as of now. I plan to make the project compatible with at least Windows and macOS in the near future, but the code will certainly not able to compile on these other platforms before some major changes are made.
>>>
>>> For your specific error, I think the reason is that with GCC the <limits> header is pulled in by <cmath> included by <ql/mathconstants.hpp>. On other platforms <cmath> may not include <limits>. I will include <limits> explicitly in the code, but I'm sure there are many other error messages remaining to be fixed with a non-GCC compiler.
>
>>>
>>> Hao
>>> On Wednesday, July 5, 2017 2:57:07 PM EDT Peter Caspers wrote:
>>>> Hi Hao, I am trying to build your project (on OSX with clang), I get the following weird error message though. Any idea where this could come from?
>>>>
>>>> make[1]: Entering directory `/Users/peter/QuantLib-noBoost/build'
>>>> make[2]: Entering directory `/Users/peter/QuantLib-noBoost/build'
>>>> make[2]: Leaving directory `/Users/peter/QuantLib-noBoost/build'
>>>> make[2]: Entering directory `/Users/peter/QuantLib-noBoost/build'
>>>> [ 1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflow.cpp.o
>>>> [ 1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/averagebmacoupon.cpp.o
>>>> [ 1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/capflooredcoupon.cpp.o
>>>> [ 1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/capflooredinflationcoupon.cpp.o
>>>> [ 1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/cashflows.cpp.o
>>>> [ 1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/cashflowvectors.cpp.o
>>>> [ 1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/cmscoupon.cpp.o
>>>> [ 1%] Building CXX object ql/CMakeFiles/QuantLib.dir/cashflows/conundrumpricer.cpp.o
>>>> In file included from /Users/peter/QuantLib-noBoost/ql/cashflow.cpp:21:
>>>> In file included from /Users/peter/QuantLib-noBoost/ql/cashflow.hpp:28:
>>>> In file included from /Users/peter/QuantLib-noBoost/ql/event.hpp:28:
>>>> In file included from /Users/peter/QuantLib-noBoost/ql/time/date.hpp:35:
>>>> /Users/peter/QuantLib-noBoost/ql/utilities/null.hpp:58:24: error: no member named 'numeric_limits' in namespace 'std'
>>>> return QL_NULL_REAL;
>>>> ^~~~~~~~~~~~
>>>> /Users/peter/QuantLib-noBoost/ql/qldefines.hpp:126:39: note: expanded from macro 'QL_NULL_REAL'
>>>> #define QL_NULL_REAL ((std::numeric_limits<float>::max)())
>>>> ~~~~~^
>>>>
>>>>
>>>>> On 04 Jul 2017, at 21:28, Hao Zhang <
[hidden email]> wrote:
>>>>>
>>>>> Hi Peter and Luigi,
>>>>>
>>>>> Thank you very much for your support! No, the performance gain is not from
>>>>> MKL, as MKL is not used in the default setting. I am sorry that I cannot
>>>>> pinpoint the exact source of performance gain yet. My hunch is that many
>>>>> Boost modules are quite general, and provide features that's not used by
>>>>> QuantLib. There are also safety checks in Boost that's not relevant to
>>>>> QuantLib. By targeting only QuantLib, I do not need to write many
>>>>> redundant features and safety checks, and avoid some extra instructions.
>>>>> Also the move semantics in modern C++ may also help with speed. I
>>>>> apologize that I cannot answer your question in more detail at this point.
>>>>>
>>>>> Best Regards,
>>>>>
>>>>> Hao
>>>>> On Tuesday, July 4, 2017 11:38:00 AM EDT Peter Caspers wrote:
>>>>>> Hi Hao, that's very interesting. Do you know where the performance gain
>>>>>> is coming from, is it mostly MKL vs. UBLAS? Or are there other drivers
>>>>>> as well? I'd also be interested in the motivation to do this in the
>>>>>> first place, I never thought boost as such was a bad thing? The upgrade
>>>>>> to C++17 is surely nice and makes sense, no doubt. Best Regards
>>>>>> Peter
>>>>>>
>>>>>>> On 04 Jul 2017, at 09:42, Luigi Ballabio <
[hidden email]>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hello Hao,
>>>>>>>
>>>>>>> that's great news---I've been wondering myself if this was
>>>>>>> possible. I'll be sure to check out your project.>
>>>>>>> I suggest you also post to quantlib-users for greater exposure.
>>>>>>>
>>>>>>> Later,
>>>>>>>
>>>>>>> Luigi
>>>>>>>
>>>>>>> On Tue, Jul 4, 2017 at 5:24 AM Hao Zhang via QuantLib-dev
>>>>>>> <
[hidden email]
>>>>>>> <mailto:
[hidden email] <mailto:
[hidden email]> <mailto:
[hidden email] <mailto:
[hidden email]>>>> wrote: Hello Everyone,
>>>>>>>
>>>>>>> I have removed all Boost dependency from QuantLib, and ported QuantLib
>>>>>>> to C++17. The code is hosted on GitHub
>>>>>>> (
https://github.com/haozhangphd/ <
https://github.com/haozhangphd/> <
https://github.com/haozhangphd/ <
https://github.com/haozhangphd/>> QuantLib-noBoost
>>>>>>> <
https://github.com/haozhangphd/QuantLib-noBoost <
https://github.com/haozhangphd/QuantLib-noBoost> <
https://github.com/haozhangphd/QuantLib-noBoost <
https://github.com/haozhangphd/QuantLib-noBoost>>>).
>>>>>>>
>>>>>>> The ported code passes all test cases, and there are significant
>>>>>>> performance improvements in SOME functionalities. Using the QuantLib
>>>>>>> Benchmark Suite, Quantlib-noBoost gives 3425 mflops (running time
>>>>>>> 13.15s), while unmodified QuantLib gives 1440 mflops (running time
>>>>>>> 44.8s) on my Dell Inspiron 13 i7348 laptop, both running under
>>>>>>> identical conditions with identical compiler flags. The total running
>>>>>>> time of the whole test suite is also shorter by ~10% after Boost is
>>>>>>> removed.
>>>>>>>
>>>>>>> I will continue maintaining this project, and regularly backporting
>>>>>>> latest commits from QuantLib. I will also make this project work on
>>>>>>> other compilers besides GCC in the near future.
>>>>>>>
>>>>>>> Best Regards,
>>>>>>>
>>>>>>> Hao
>>>>>>>
>>>>>>> ----------------------------------------------------------------------
>>>>>>> -------- Check out the vibrant tech community on one of the world's
>>>>>>> most engaging tech sites, Slashdot.org <
http://slashdot.org/> <
http://slashdot.org/ <
http://slashdot.org/>>!
http://sdm.link/slashdot <
http://sdm.link/slashdot><
http://sdm.link/slashdot <
http://sdm.link/slashdot>>
>>>>>>> <
http://sdm.link/slashdot <
http://sdm.link/slashdot> <
http://sdm.link/slashdot <
http://sdm.link/slashdot>>>
>>>>>>> _______________________________________________
>>>>>>> QuantLib-dev mailing list
>>>>>>>
[hidden email] <mailto:
[hidden email]> <mailto:
[hidden email] <mailto:
[hidden email]>>
>>>>>>> <mailto:
[hidden email] <mailto:
[hidden email]> <mailto:
[hidden email] <mailto:
[hidden email]>>>
>>>>>>>
https://lists.sourceforge.net/lists/listinfo/quantlib-dev <
https://lists.sourceforge.net/lists/listinfo/quantlib-dev> <
https://lists.sourceforge.net/lists/listinfo/quantlib-dev <
https://lists.sourceforge.net/lists/listinfo/quantlib-dev>>
>>>>>>> <
https://lists.sourceforge.net/lists/listinfo/quantlib-dev>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> --------- Check out the vibrant tech community on one of the world's
>>>>>>> most engaging tech sites, Slashdot.org!
>>>>>>>
http://sdm.link/slashdot_____________________________________________>>>>>>> __ QuantLib-dev mailing list
>>>>>>>
[hidden email]
>>>>>>>
https://lists.sourceforge.net/lists/listinfo/quantlib-dev>>
>
>