Major / minor changes

[Juan Jose Garcia-Ripoll]

Hi,

due to some personal projects, I need to reboot some of the features of the tensor library.

In the short term, I will migrate this library (and cblapack, mps, mps-bundle) to cmake. I have been studying this and it would definitely simplify migration to Microsoft VS, which is a priority for my group. 

In the mid-term (a few months), I would like to upgrade the code to support C++11 or, even better, C++17. There are features that are important in this, such as thread-safe shared pointers, which the library currently does not have. Also, move optimizations might simplify some of the code, and constexpr optimizations and a bit of more clever template metaprogramming (optional) would be interesting for some of those projects I need to pursue.

I would like to hear the thoughts of people around.

Cheers,

Juanjo

--

Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain) 
http://juanjose.garciaripoll.googlepages.com

[Ulf Lorenz]

On Sun, 22 Nov 2020 10:28:51 +0100
Juan Jose Garcia-Ripoll <juanjose.g...@gmail.com> wrote:

> Hi,
>
> due to some personal projects, I need to reboot some of the features
> of the tensor library.
>
> In the short term, I will migrate this library (and cblapack, mps,
> mps-bundle) to cmake. I have been studying this and it would
> definitely simplify migration to Microsoft VS, which is a priority
> for my group.
>
> In the mid-term (a few months), I would like to upgrade the code to
> support C++11 or, even better, C++17. There are features that are
> important in this, such as thread-safe shared pointers, which the
> library currently does not have. Also, move optimizations might
> simplify some of the code, and constexpr optimizations and a bit of
> more clever template metaprogramming (optional) would be interesting
> for some of those projects I need to pursue.
>
> I would like to hear the thoughts of people around.

I think I already lobbied for both features some time ago. :)

I definitely think that the tensor library should support C++11.
With C++-17 you have to be a bit careful AFAIR, because one or the
other feature is not implemented yet or something (for example, the
not latest gcc for current Debian stable has an extra library for
std::filesystem, which is a bit cumbersome), but there should be plenty
of room for constexpr and move optimizations in any case.

For CMake, I not only vote for the modification, but would volunteer
to assist. I happened to have migrated two major, somewhat shrewd
applications at our company this year, so I guess this qualifies as
professional (though I have somewhat less experience with cross-platform
development, anwyay).

To start, I would recommend the book "Professional CMake", which
contains also more exotic issues, and is rather cheap (at $30 netto)
https://crascit.com/professional-cmake/. At least when we looked for
references a year ago, this was the only good text we found.

Some other thoughts:
* This is a major change also with respect to compatibility, so one
could consider what to do with the then "legacy" code (there should
be at least a release, do you want to support it in case of bugfixes
etc.). Should there be something like versioning?
* Personally, in case I participate here, I would prefer specific
work packages, because I have other projects to take care of etc. So
some advance planning where to go, and how to cut the work into,
preferably independent, pieces, might be helpful.


Ulf

[Juan Jose Garcia-Ripoll]

Hi Ulf,

Thanks for chiming in!

On Sun, Nov 22, 2020 at 8:27 PM Ulf Lorenz <u...@wavepacket.org> wrote:

I think I already lobbied for both features some time ago. :)

Indeed, and that is what got me thinking, even if slowly.

 

I definitely think that the tensor library should support C++11.

I have been discussing with colleagues supporting similar projects. It seems that C++14 is advanced enough and supported enough that it might be a better option. I believe it also has std::make_shared(), which is a bit more efficient than std::shared_ptr(new ...).

 

For CMake, I not only vote for the modification, but would volunteer
to assist. I happened to have migrated two major, somewhat shrewd
applications at our company this year, so I guess this qualifies as
professional (though I have somewhat less experience with cross-platform
development, anwyay).

That would be helpful. Right now what I am doing is porting some supporting packages, which are used in platforms without fortran compilers, or as backup (f2c99, cblapack, etc), to understand how to optimally package this.

 

* This is a major change also with respect to compatibility, so one
  could consider what to do with the then "legacy" code (there should
  be at least a release, do you want to support it in case of bugfixes
  etc.). Should there be something like versioning?

At the moment, working with those libraries has revealed that it is possible to make first release that has _both_ cmake and automake builds. The process of doing this reveals hidden assumptions and allows cleaning up the code a bit (e.g. test suite building, actual dependencies, etc). That would be a closed release, which can be forked if someone is interested in maintaining legacy or back-porting fixes. We would then build a branch to work on until porting to C++11/14 is completed, at which point it will become _the_ supported version.

 

* Personally, in case I participate here, I would prefer specific
  work packages, because I have other projects to take care of etc. So
  some advance planning where to go, and how to cut the work into,
  preferably independent, pieces, might be helpful.

Thanks, I will let you know. Right now I am still reading the code and working on those earlier ports. 

[Juan Jose Garcia-Ripoll]

On Sun, Nov 22, 2020 at 8:27 PM Ulf Lorenz <u...@wavepacket.org> wrote:

For CMake, I not only vote for the modification, but would volunteer
to assist. I happened to have migrated two major, somewhat shrewd
applications at our company this year, so I guess this qualifies as
professional (though I have somewhat less experience with cross-platform
development, anwyay).

I have finished a first iteration of CMakeLists.txt files in the branch 'cmake'. I would appreciate if you could have a look and find the mistakes I must have made :-)

This version is a hack and has the following two problems

- It relies on FindBLAS/FindLAPACK for finding the numerical libraries, which is not as customizable as the original code and does not set C/C++ include directories. This has to be fixed by changing the module used.

- It does not have an option to activate the ARPACK frameworks (we currently have 3, two included ones and the possibility of linking an external one provided by the OS).

- It does not have yet support for Google Tests (although I read that it comes with cmake)

I would prioritize checking the structure of the build system and fixing #3 to make sure nothing is broken, and then move on to #1 and #2.

Cheers,

Juanjo