Removing Boost dependency from QuantLib

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Removing Boost dependency from QuantLib

quantlib-dev mailing list
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/
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://sdm.link/slashdot
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing Boost dependency from QuantLib

Luigi Ballabio
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]> 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/
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://sdm.link/slashdot
_______________________________________________
QuantLib-dev mailing list
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: Removing Boost dependency from QuantLib

Peter Caspers-4
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]> 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/
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://sdm.link/slashdot
_______________________________________________
QuantLib-dev mailing list
[hidden email]
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


------------------------------------------------------------------------------
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
Reply | Threaded
Open this post in threaded view
|

Re: Removing Boost dependency from QuantLib

quantlib-dev mailing list
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]>> 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/ 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://sdm.link/slashdot
> > <http://sdm.link/slashdot>
> > _______________________________________________
> > QuantLib-dev mailing list
> > [hidden email]
> > <mailto:[hidden email]>
> > 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



------------------------------------------------------------------------------
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
Reply | Threaded
Open this post in threaded view
|

Re: Removing Boost dependency from QuantLib

Johannes Göttker-Schnetmann
In reply to this post by Peter Caspers-4
Hi Hao, Peter,

I also find this very interesting. Since C++ is moving at a better pace for some time we need at some point decide how QuantLib reacts to this. Personally I am using modern compilers and like the features modern C++ provides. Therefore I would appreciate if QuantLib decides to fork or move completely to a modern C++ version.

Boost is in part an incubator of ideas, which at some point might make it into the C++ standard. For QuantLib the most prominent instances are boost::shared_pointer and boost:unique_pointer which are both in the standard for quite some time now. I would prefer to use the standard libraries instead of boost in those cases.

Kind regards,
Johannes

On 4. Jul 2017, at 17:38, Peter Caspers <[hidden email]> 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]> 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/
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://sdm.link/slashdot
_______________________________________________
QuantLib-dev mailing list
[hidden email]
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

------------------------------------------------------------------------------
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


------------------------------------------------------------------------------
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
Reply | Threaded
Open this post in threaded view
|

Re: Removing Boost dependency from QuantLib

Luigi Ballabio
A warning on shared_ptr, though: unlike boost::shared_ptr, std::shared_ptr can't be configured to throw an exception when accessing a null pointer, so a call to p->foo() segfaults.  Currently we rely on boost's behavior and don't have checks for null pointers (which is convenient, but we're probably making lots of unnecessary checks at each method call instead of checking for nulls just once) so they should probably be added before the library is safely usable.

Luigi


On Wed, Jul 5, 2017 at 12:05 PM Johannes Göttker-Schnetmann <[hidden email]> wrote:
Hi Hao, Peter,

I also find this very interesting. Since C++ is moving at a better pace for some time we need at some point decide how QuantLib reacts to this. Personally I am using modern compilers and like the features modern C++ provides. Therefore I would appreciate if QuantLib decides to fork or move completely to a modern C++ version.

Boost is in part an incubator of ideas, which at some point might make it into the C++ standard. For QuantLib the most prominent instances are boost::shared_pointer and boost:unique_pointer which are both in the standard for quite some time now. I would prefer to use the standard libraries instead of boost in those cases.

Kind regards,
Johannes

On 4. Jul 2017, at 17:38, Peter Caspers <[hidden email]> 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]> 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/
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://sdm.link/slashdot
_______________________________________________
QuantLib-dev mailing list
[hidden email]
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

------------------------------------------------------------------------------
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

------------------------------------------------------------------------------
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

------------------------------------------------------------------------------
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
Reply | Threaded
Open this post in threaded view
|

Re: Removing Boost dependency from QuantLib

quantlib-dev mailing list
Hi Luigi,

I was not aware of the difference between std::shared_ptr and boost::shared_ptr. After checking the source code for GCC, I found that at least in GCC, std::shared_ptr also has the check for nullptr. However this check is only available in debug mode.

Hao
On Wednesday, July 5, 2017 8:31:05 AM EDT Luigi Ballabio wrote:

> A warning on shared_ptr, though: unlike boost::shared_ptr, std::shared_ptr
> can't be configured to throw an exception when accessing a null pointer, so
> a call to p->foo() segfaults.  Currently we rely on boost's behavior and
> don't have checks for null pointers (which is convenient, but we're
> probably making lots of unnecessary checks at each method call instead of
> checking for nulls just once) so they should probably be added before the
> library is safely usable.
>
> Luigi
>
>
> On Wed, Jul 5, 2017 at 12:05 PM Johannes Göttker-Schnetmann <
> [hidden email]> wrote:
>
> > Hi Hao, Peter,
> >
> > I also find this very interesting. Since C++ is moving at a better pace
> > for some time we need at some point decide how QuantLib reacts to this.
> > Personally I am using modern compilers and like the features modern C++
> > provides. Therefore I would appreciate if QuantLib decides to fork or move
> > completely to a modern C++ version.
> >
> > Boost is in part an incubator of ideas, which at some point might make it
> > into the C++ standard. For QuantLib the most prominent instances are
> > boost::shared_pointer and boost:unique_pointer which are both in the
> > standard for quite some time now. I would prefer to use the standard
> > libraries instead of boost in those cases.
> >
> > Kind regards,
> > Johannes
> >
> > On 4. Jul 2017, at 17:38, Peter Caspers <[hidden email]> 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]> 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/
> >> 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://sdm.link/slashdot
> >> _______________________________________________
> >> QuantLib-dev mailing list
> >> [hidden email]
> >> 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://slashdot.org/>!
> > http://sdm.link/slashdot_______________________________________________
> > QuantLib-dev mailing list
> > [hidden email]
> > 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
> >
> >
> >
> > ------------------------------------------------------------------------------
> > 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
> >



------------------------------------------------------------------------------
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
Reply | Threaded
Open this post in threaded view
|

Re: Removing Boost dependency from QuantLib

Klaus Spanderen-2
In reply to this post by Johannes Göttker-Schnetmann
Hi,

Awesome work. The major achievement for me is the lift to C++17 - even subtle
details like the thread-safe observer pattern have been ported !  I wouldn't
mind if boost is stilled present for some minor use cases. It will be difficult
to replace all of it on all supported platforms.

I would also appreciate if we move completely to a modern C++ version after
10++ years of C++03.

best regards
Klaus

On Mittwoch, 5. Juli 2017 12:02:20 CEST Johannes Göttker-Schnetmann wrote:

> Hi Hao, Peter,
>
> I also find this very interesting. Since C++ is moving at a better pace for
> some time we need at some point decide how QuantLib reacts to this.
> Personally I am using modern compilers and like the features modern C++
> provides. Therefore I would appreciate if QuantLib decides to fork or move
> completely to a modern C++ version.
>
> Boost is in part an incubator of ideas, which at some point might make it
> into the C++ standard. For QuantLib the most prominent instances are
> boost::shared_pointer and boost:unique_pointer which are both in the
> standard for quite some time now. I would prefer to use the standard
> libraries instead of boost in those cases.
>
> Kind regards,
> Johannes
>
> On 4. Jul 2017, at 17:38, Peter Caspers <[hidden email]> 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]> 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/
> > 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://sdm.link/slashdot
> > _______________________________________________
> > QuantLib-dev mailing list
> > [hidden email]
> > 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://slashdot.org/>!
> http://sdm.link/slashdot_______________________________________________
> QuantLib-dev mailing list
> [hidden email]
> 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



------------------------------------------------------------------------------
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
Reply | Threaded
Open this post in threaded view
|

Re: Removing Boost dependency from QuantLib

quantlib-dev mailing list
In reply to this post by quantlib-dev mailing list
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]>>> 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/> 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://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]>>
> >>> 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
>



------------------------------------------------------------------------------
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
Reply | Threaded
Open this post in threaded view
|

Re: Removing Boost dependency from QuantLib

quantlib-dev mailing list
In reply to this post by Klaus Spanderen-2
Hi Klaus,

Thank you very much for your support. I try my best to only use standard-compliant C++ in my code, and avoid using any GNU extensions (in the default configuration at least). Thus it is not impossible to make it work on any platforms with a C++17-standard-compliant compiler.

Best Regards,

Hao
On Wednesday, July 5, 2017 3:54:18 PM EDT Klaus Spanderen wrote:

> Hi,
>
> Awesome work. The major achievement for me is the lift to C++17 - even subtle
> details like the thread-safe observer pattern have been ported !  I wouldn't
> mind if boost is stilled present for some minor use cases. It will be difficult
> to replace all of it on all supported platforms.
>
> I would also appreciate if we move completely to a modern C++ version after
> 10++ years of C++03.
>
> best regards
> Klaus
>
> On Mittwoch, 5. Juli 2017 12:02:20 CEST Johannes Göttker-Schnetmann wrote:
> > Hi Hao, Peter,
> >
> > I also find this very interesting. Since C++ is moving at a better pace for
> > some time we need at some point decide how QuantLib reacts to this.
> > Personally I am using modern compilers and like the features modern C++
> > provides. Therefore I would appreciate if QuantLib decides to fork or move
> > completely to a modern C++ version.
> >
> > Boost is in part an incubator of ideas, which at some point might make it
> > into the C++ standard. For QuantLib the most prominent instances are
> > boost::shared_pointer and boost:unique_pointer which are both in the
> > standard for quite some time now. I would prefer to use the standard
> > libraries instead of boost in those cases.
> >
> > Kind regards,
> > Johannes
> >
> > On 4. Jul 2017, at 17:38, Peter Caspers <[hidden email]> 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]> 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/
> > > 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://sdm.link/slashdot
> > > _______________________________________________
> > > QuantLib-dev mailing list
> > > [hidden email]
> > > 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://slashdot.org/>!
> > http://sdm.link/slashdot_______________________________________________
> > QuantLib-dev mailing list
> > [hidden email]
> > 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
>
>
>
> ------------------------------------------------------------------------------
> 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
>



------------------------------------------------------------------------------
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
Reply | Threaded
Open this post in threaded view
|

Re: Removing Boost dependency from QuantLib

Peter Caspers-4
In reply to this post by quantlib-dev mailing list
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]
<[hidden email] <[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/> 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://sdm.link/slashdot<http://sdm.link/slashdot>
<http://sdm.link/slashdot <http://sdm.link/slashdot>>
_______________________________________________
QuantLib-dev mailing list
[hidden email] <[hidden email]>
<[hidden email] <[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>
---------------------------------------------------------------------
--------- 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


------------------------------------------------------------------------------
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
Reply | Threaded
Open this post in threaded view
|

Re: Removing Boost dependency from QuantLib

quantlib-dev mailing list
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
>



------------------------------------------------------------------------------
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
Reply | Threaded
Open this post in threaded view
|

Re: Removing Boost dependency from QuantLib

Peter Caspers-4
Hi Hao,

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.

Best Regards
Peter

> 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
>>
>
>


------------------------------------------------------------------------------
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
Reply | Threaded
Open this post in threaded view
|

Re: Removing Boost dependency from QuantLib

quantlib-dev mailing list
Hi Peter,

Thank you for your suggestion. The code now compiles and runs under Clang 4 and libc++ 4.

Best Regards,

Hao
On Saturday, July 8, 2017 2:33:17 AM MDT you wrote:

> Hi Hao,
>
> 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.
>
> Best Regards
> Peter
>
> > 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
> >>
> >
> >
>



------------------------------------------------------------------------------
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
Reply | Threaded
Open this post in threaded view
|

Re: Removing Boost dependency from QuantLib

Peter Caspers-4
Thanks a lot Hao, it also builds on OS X now. I looked a bit closer at the benchmark results and I think there is an issue in the port of the code to catch, causing the first case to be executed n times instead of each of the n original cases once. I’ll send a merge request with a fix.
Best Regards, Peter

> On 09 Jul 2017, at 01:51, Hao Zhang <[hidden email]> wrote:
>
> Hi Peter,
>
> Thank you for your suggestion. The code now compiles and runs under Clang 4 and libc++ 4.
>
> Best Regards,
>
> Hao
> On Saturday, July 8, 2017 2:33:17 AM MDT you wrote:
>> Hi Hao,
>>
>> 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.
>>
>> Best Regards
>> Peter
>>
>>> 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
>>>>
>>>
>>>
>>
>
>


------------------------------------------------------------------------------
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
Reply | Threaded
Open this post in threaded view
|

Re: Removing Boost dependency from QuantLib

quantlib-dev mailing list
Hi Peter,

Thank you very much for helping. So the earlier benchmark results were clearly wrong. I really apologize for the overstated benchmark results. That was not intentional and I have removed the overstated values from README.md.

Best Regards,

Hao
On Sunday, July 9, 2017 8:50:01 AM EDT Peter Caspers wrote:

> Thanks a lot Hao, it also builds on OS X now. I looked a bit closer at the benchmark results and I think there is an issue in the port of the code to catch, causing the first case to be executed n times instead of each of the n original cases once. I’ll send a merge request with a fix.
> Best Regards, Peter
>
> > On 09 Jul 2017, at 01:51, Hao Zhang <[hidden email]> wrote:
> >
> > Hi Peter,
> >
> > Thank you for your suggestion. The code now compiles and runs under Clang 4 and libc++ 4.
> >
> > Best Regards,
> >
> > Hao
> > On Saturday, July 8, 2017 2:33:17 AM MDT you wrote:
> >> Hi Hao,
> >>
> >> 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.
> >>
> >> Best Regards
> >> Peter
> >>
> >>> 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
> >>>>
> >>>
> >>>
> >>
> >
> >
>



------------------------------------------------------------------------------
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
Reply | Threaded
Open this post in threaded view
|

Re: Removing Boost dependency from QuantLib

Peter Caspers-4
Hi Hao, no problem at all, the benchmark results are by far not all that makes the project interesting, it’s great stuff.
Best Regards, Peter

> On 09 Jul 2017, at 20:11, Hao Zhang <[hidden email]> wrote:
>
> Hi Peter,
>
> Thank you very much for helping. So the earlier benchmark results were clearly wrong. I really apologize for the overstated benchmark results. That was not intentional and I have removed the overstated values from README.md.
>
> Best Regards,
>
> Hao
> On Sunday, July 9, 2017 8:50:01 AM EDT Peter Caspers wrote:
>> Thanks a lot Hao, it also builds on OS X now. I looked a bit closer at the benchmark results and I think there is an issue in the port of the code to catch, causing the first case to be executed n times instead of each of the n original cases once. I’ll send a merge request with a fix.
>> Best Regards, Peter
>>
>>> On 09 Jul 2017, at 01:51, Hao Zhang <[hidden email]> wrote:
>>>
>>> Hi Peter,
>>>
>>> Thank you for your suggestion. The code now compiles and runs under Clang 4 and libc++ 4.
>>>
>>> Best Regards,
>>>
>>> Hao
>>> On Saturday, July 8, 2017 2:33:17 AM MDT you wrote:
>>>> Hi Hao,
>>>>
>>>> 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.
>>>>
>>>> Best Regards
>>>> Peter
>>>>
>>>>> 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
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>


------------------------------------------------------------------------------
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
Reply | Threaded
Open this post in threaded view
|

Re: Removing Boost dependency from QuantLib

quantlib-dev mailing list
In reply to this post by quantlib-dev mailing list
Hi Johannes,

Thank you very much. Actually I am working on that right now... There are more than 3000 lines that need to be changed (including the test suites). Regular expression replacement can help, but there is still quite a lot of labor. I think I've replaced about 3/4 of the operator new already, and I should be able to finish replacing all of them by this weekend.

Best Regards,

Hao
On Thursday, July 13, 2017 2:04:22 PM MDT you wrote:

> Hi Hao,
>
> at last I got my new laptop up and running and tried the compile with VisualStudio 2017 - nothing to report, just ran out of the box. Very nice! If you like, I would work on using std::make_shared instead of std::shared_ptr<..>(new …)
>
> Kind regards,
> Johannes
>
> > On 7. Jul 2017, at 22:50, Hao Zhang via QuantLib-dev <[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
> >>
> >
> >
> >
> > ------------------------------------------------------------------------------
> > 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
>



------------------------------------------------------------------------------
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