[GSOC2020][Boost.uBLAS] C++20-ification of uBLAS

Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[GSOC2020][Boost.uBLAS] C++20-ification of uBLAS

Boost - uBLAS mailing list
Hi
My name is Ashar, a pre-final year undergraduate student. Last year I worked with Boost.uBLAS and added Boost.YAP Expression template and another student Amit added some new interfaces like subtensor view and other really cool things.

During the development and addition of new YAP based ET, I did faced many issues with the legacy C++ code in matrix and vectors, this was more pronounced as Boost.uBLAS.tensor was targetting C++17 and rest of the uBLAS had C++11 or earlier code. The new project about C++20-ification of Boost.uBLAS seems a really nice step towards creating a more unified and standardized experience across all 3 types (vector, matrix, tensor) also we can experiment if C++20 does makes things faster or not.

I have been following C++20 since its first draft (July 2017, Toronto) and now that it has been finalized, I have tested and experimented with most of its features with clang/gcc/trunks. So, I believe this makes me a potential candidate for this project.

I am interested in working in this project and Here are some of the ideas in general that I have toward C++20-ification of uBLAS. 

1. concepts : We have so many type_traits.hpp and all those legacy traits which can be really replaced by new concepts. It will make template type errors really short and nice to debug. 

2. The one ranges : Eric Neibler's one ranges will be very nice to have in uBLAS, we currently have iterator based abstraction but since ranges are the new way to interact with containers in C++20, addition of this will really make uBLAS one of its kind in Linear algebra. Further more, Amit's work can be used here and we can have views and adapter (only for tensor upto now).

3. std::span : Span are used widely in linear algebra and with C++20, Standard has added it. Albeit uBLAS has its own span and extents it will be very good to make them compatible or interoperable with standard spans.

4. Constexpr-ification : C++20 made so much things constexpr, try/catch to even dynamic containers like vector and strings. We can really leverage the new constexpr abilities like memory allocation and freeing to build a really awesome constexpr vector/matrix/tensor interfaces.

5. Modules : Finally we got rid of leaky include directives, making uBLAS modules based will be I think the first library in Boost to have it. 

6. New Tool-chains : Travis CI is used for CI and its at best cannot give over 18.04LTS for jobs, Setting up CI with modern tool-chain to build and run C++20 will also be a job of its own.

7. Misc: spaceship operator and other minor changes like feature/test-macros and other minor topping that comes with C++20 can be used really nicely.


I am also very aware of that all these can take much more time than what we get in GSOC, but I will choose and prioritise the task, I have just proposed some new things that I would like to add if given a chance to work on it. I have intensionally left coroutines and other features because I can't find any practical use of those features for uBLAS. If you have some ideas, how we can use it to improve then please its welcomed.

Cem and David are the mentors that I am seeking and I will be submitting my C++20 competency test to one of you very soon. Please consider this as official application email and we can always further discuss and finalize the direction of the work directly.

Regards

_______________________________________________
ublas mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [GSOC2020][Boost.uBLAS] C++20-ification of uBLAS

Boost - uBLAS mailing list
Hi Ashar,

happy to have you back.

While 20++-ification is a necessary step for uBLAS, we have to be cautious as many features of the 20++ standard are not even implemented yet, see https://en.cppreference.com/w/cpp/compiler_support.



Am Fr., 13. März 2020 um 19:10 Uhr schrieb Ashar via ublas <[hidden email]>:
Hi
My name is Ashar, a pre-final year undergraduate student. Last year I worked with Boost.uBLAS and added Boost.YAP Expression template and another student Amit added some new interfaces like subtensor view and other really cool things.

They are! Indeed.
 

During the development and addition of new YAP based ET, I did faced many issues with the legacy C++ code in matrix and vectors, this was more pronounced as Boost.uBLAS.tensor was targetting C++17 and rest of the uBLAS had C++11 or earlier code. The new project about C++20-ification of Boost.uBLAS seems a really nice step towards creating a more unified and standardized experience across all 3 types (vector, matrix, tensor) also we can experiment if C++20 does makes things faster or not.

I have been following C++20 since its first draft (July 2017, Toronto) and now that it has been finalized, I have tested and experimented with most of its features with clang/gcc/trunks. So, I believe this makes me a potential candidate for this project.

I am interested in working in this project and Here are some of the ideas in general that I have toward C++20-ification of uBLAS. 

Very happy about that. Let me go through your list.
 

1. concepts : We have so many type_traits.hpp and all those legacy traits which can be really replaced by new concepts. It will make template type errors really short and nice to debug. 

Agree. I would like to slowly approach this topic and start with it when the tensor data type with subtensors are finalized.
 

2. The one ranges : Eric Neibler's one ranges will be very nice to have in uBLAS, we currently have iterator based abstraction but since ranges are the new way to interact with containers in C++20, addition of this will really make uBLAS one of its kind in Linear algebra. Further more, Amit's work can be used here and we can have views and adapter (only for tensor upto now).

This topic might be too early for an investigation right now. Once subtensors are included in boost we should try to
 

3. std::span : Span are used widely in linear algebra and with C++20, Standard has added it. Albeit uBLAS has its own span and extents it will be very good to make them compatible or interoperable with standard spans.

std::span and boost::numeric::ublas::span have different meanings. The latter is used for tensor selections with three member variables while the other is refering to a static or dynamic memory region with a pointer to the memory region and its length. Still std::span could be a good use for ublas.

 
4. Constexpr-ification : C++20 made so much things constexpr, try/catch to even dynamic containers like vector and strings. We can really leverage the new constexpr abilities like memory allocation and freeing to build a really awesome constexpr vector/matrix/tensor interfaces.

This is a good point. I think that C++17 gave us already the right opportunities.
 

5. Modules : Finally we got rid of leaky include directives, making uBLAS modules based will be I think the first library in Boost to have it. 

We should see how and when the boost community switches to modules.
 

6. New Tool-chains : Travis CI is used for CI and its at best cannot give over 18.04LTS for jobs, Setting up CI with modern tool-chain to build and run C++20 will also be a job of its own.

Oh. I am totally for stabilizing our current development branch. This is something ublas needs to do.
 

7. Misc: spaceship operator and other minor changes like feature/test-macros and other minor topping that comes with C++20 can be used really nicely.


I am also very aware of that all these can take much more time than what we get in GSOC, but I will choose and prioritise the task, I have just proposed some new things that I would like to add if given a chance to work on it. I have intensionally left coroutines and other features because I can't find any practical use of those features for uBLAS. If you have some ideas, how we can use it to improve then please its welcomed.

Cem and David are the mentors that I am seeking and I will be submitting my C++20 competency test to one of you very soon. Please consider this as official application email and we can always further discuss and finalize the direction of the work directly.


All in all I find the inclusion of most C++20 features very important - yet too early. We already made a huge step with C++17.

Therefore, my suggestion for ublas is to name this gosc project (stablizing and improving code quality ublas) :
  1. (not part as gsoc) make a final decision about yapp

  2. stablilize and improve the code from the previous gsoc implementation (static rank and extents, subtensor)
  3. improve code quality using advanced and modern toolchains like cmake, clang-static-analyzer, clang-tidy, etc.
  4. improve code quality by enhancing the code-covarge percentage for tensor only
  5. improve the constexpr-ness of tensor and subtensor (finalization with C++17)
  6. prepare a matrix and vector data structures as an instance of tensor<T,rank=2> and tensor<T,rank=1>

  7. using a different branch, improve code quality using c++20 contracts and attributes for tensor, using (expects,ensure,assert) contract
  8. prepare concepts

Best,
Cem

 
Regards
_______________________________________________
ublas mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: [hidden email]

_______________________________________________
ublas mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [GSOC2020][Boost.uBLAS] C++20-ification of uBLAS

Boost - uBLAS mailing list

  1. using a different branch, improve code quality using c++20 contracts and attributes for tensor, using (expects,ensure,assert) contra
Hey Cem,

Are you sure to add contracts in uBLAS. Contracts was proposed for C++17 and did not made it up to C++20 and I have no idea when it will come to but there are some implementation of contracts TS draft by some third party compiler hackers who implement things, So I will have to compile the compiler with contract support and then test it during development. I have no problems doing it, I can see all the great places it will be used.

Will it be worth doing something that can't be directly used by other?

In addition to the above, I was thinking of also having complete compile time tensor. c++20 has new and delete marked constexpr, so we can use std::vector container which is now compile-time and modify current to have a complete compile time tensor class. With examples and how to use it, this will be easy, if I use Amit's static extents. This is I believe an extension to the list of ideas you presented above.

I still need your view on if I should go ahead with the contracts? Concepts are okay and So is constexpr thing! Also I believe eventually if I follow up your list of ideas tensor<2, rank> can be matrix and tensor<1, rank> can become a vector and in a long run it can replace the specially designed matrix and vector of ublas. (backward compatibility could be provided thought). We will have one expression template (YAP), C++17 or 20 everywhere, it will also make maintaining the library easy because currently tensor is a separate things and matrix and vector of ublas are separator thing. 

This will also eventually give us many performance boost that David was talking about from modern paradigms of C++.

Regards
Ashar

_______________________________________________
ublas mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [GSOC2020][Boost.uBLAS] C++20-ification of uBLAS

Boost - uBLAS mailing list


Am Do., 19. März 2020 um 18:36 Uhr schrieb Ashar via ublas <[hidden email]>:

  1. (not part as gsoc) make a final decision about yapp

  2. stablilize and improve the code from the previous gsoc implementation (static rank and extents, subtensor)
  3. improve code quality using advanced and modern toolchains like cmake, clang-static-analyzer, clang-tidy, etc.
  4. improve code quality by enhancing the code-covarge percentage for tensor only
  5. improve the constexpr-ness of tensor and subtensor (finalization with C++17)
  6. prepare a matrix and vector data structures as an instance of tensor<T,rank=2> and tensor<T,rank=1>

  7. using a different branch, improve code quality using c++20 contracts and attributes for tensor, using (expects,ensure,assert) contract
  8. prepare for concepts
Hey Cem,

Are you sure to add contracts in uBLAS. Contracts was proposed for C++17 and did not made it up to C++20 and I have no idea when it will come to but there are some implementation of contracts TS draft by some third party compiler hackers who implement things, So I will have to compile the compiler with contract support and then test it during development. I have no problems doing it, I can see all the great places it will be used.

Will it be worth doing something that can't be directly used by other?

you are right about contracts.
 

In addition to the above, I was thinking of also having complete compile time tensor. c++20 has new and delete marked constexpr, so we can use std::vector container which is now compile-time and modify current to have a complete compile time tensor class. With examples and how to use it, this will be easy, if I use Amit's static extents. This is I believe an extension to the list of ideas you presented above.

yes. doumenting and stablizing the software and preparing it for matrix and vector templates would be the number one priority. 
 

I still need your view on if I should go ahead with the contracts? Concepts are okay and So is constexpr thing!

for now, I would like to put concepts at the very end of the
 
Also I believe eventually if I follow up your list of ideas tensor<2, rank> can be matrix and tensor<1, rank> can become a vector and in a long run it can replace the specially designed matrix and vector of ublas. (backward compatibility could be provided thought).

yes. according to the list that is the way we should go.
 
We will have one expression template (YAP), C++17 or 20 everywhere, it will also make maintaining the library easy because currently tensor is a separate things and matrix and vector of ublas are separator thing. 

agree.


This will also eventually give us many performance boost that David was talking about from modern paradigms of C++.

Regards
Ashar
_______________________________________________
ublas mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: [hidden email]

_______________________________________________
ublas mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [GSOC2020][Boost.uBLAS] C++20-ification of uBLAS

Boost - uBLAS mailing list
Hi Cem,

Thanks for the clarification. All my concerns and doubt about the proposal are finished and we are good to go. I will be sharing the proposal soon here titled : "Boost.uBLAS: Stabilizing, Enhancing and C++20-ification". Each phase will have one of the thing mentioned here completed. During first phase, I will be stabilizing the code that we worked last year, notably the static_extent, sub tensor and other interfaces. Second phase will be enhancing which will involve producing a new matrix and vector type based on tensor, Finally I would be implementing the C++20 concepts to replace all meta functions and restricting the template parameters. This will be as per your wish could be carried on a different branch.

Regards
Ashar

_______________________________________________
ublas mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [GSOC2020][Boost.uBLAS] C++20-ification of uBLAS

Boost - uBLAS mailing list
Thanks Ashar.

I would like you to also analyze the following proposal: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1385r5.pdf
What is your take on engine types. Let us discuss about that.

Best,
Cem

Am Fr., 20. März 2020 um 13:42 Uhr schrieb Ashar via ublas <[hidden email]>:
Hi Cem,

Thanks for the clarification. All my concerns and doubt about the proposal are finished and we are good to go. I will be sharing the proposal soon here titled : "Boost.uBLAS: Stabilizing, Enhancing and C++20-ification". Each phase will have one of the thing mentioned here completed. During first phase, I will be stabilizing the code that we worked last year, notably the static_extent, sub tensor and other interfaces. Second phase will be enhancing which will involve producing a new matrix and vector type based on tensor, Finally I would be implementing the C++20 concepts to replace all meta functions and restricting the template parameters. This will be as per your wish could be carried on a different branch.

Regards
Ashar
_______________________________________________
ublas mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: [hidden email]

_______________________________________________
ublas mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: [hidden email]