You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: gsoc-2020/executors.md
+35-10Lines changed: 35 additions & 10 deletions
Original file line number
Diff line number
Diff line change
@@ -5,26 +5,51 @@ short: GSoC 2020 Executors
5
5
permalink: /gsoc-2020/executors/
6
6
---
7
7
8
-
Executors have been a long-standing proposal under discussion and review by the C++ Standard Committee. The earliest proposal dates back to 2012 and was initially proposed by Google based on some concepts that were being used internally by them. Since then, the design has gone through multiple iterations and has evolved into something completely different, but the fundamental has remained the same: to provide a mechanism to have control over the execution of a function.
8
+
Executors have been a long-standing proposal under discussion and review by the C++ Standard Committee. The earliest proposal dates back to 2012 and was initially proposed by Google based on some concepts that were being used internally by them. Since then, the design has gone through multiple iterations and has evolved into something completely different, but the fundamental has remained the same: provide a mechanism to have control over the execution of a function.
9
9
A fascinating analogy was provided in one of the early design documents by Christopher Kohlhoff: "An executor is to function execution as an allocator is to allocation."
10
10
11
-
This post is in no way a technical document describing executors or their implementation in PCL. For that, there are numerous proposals (over 30!) that can be found [here](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p0443r13.html). For details regarding PCL's implementation, you can read the design document or go through the Code API.
11
+
This post is in no way a technical document describing executors or their implementation in PCL. For that, there are numerous proposals (over 30!) that can be found [here](http://wg21.link/P0443R13). For details regarding PCL's implementation, you can read the [design document](https://pcl.readthedocs.io/projects/tutorials/en/master/executor_design.html) or go through the Code API.
12
12
13
-
To summarize, executors aim to allow programmers to control the where and how functions are executed. In PCL, there was a need for a standardized way to run algorithms on facilities like OpenMP, SIMD & CUDA while also supporting any future facilities like thread pools. All of this pointed to executors. Though, only a limited and specific set of features were needed in PCL since asynchronous implementations are not available. Another factor that influenced a simpler design is that most PCL users would not care about having fine-grained control over the execution of an algorithm. At the most, they would need to control on which facility the algorithm runs.
14
-
These influenced the design to be a simple yet offer all the customizations a user could need.
13
+
To summarize, executors aim to allow programmers to control the where and how functions are executed. In PCL, there was a need for a standardized way to run algorithms on facilities like OpenMP, SIMD & CUDA while also supporting any future facilities like thread pools. All of this pointed to executors. In PCL, only a limited and specific set of features were needed as there were no plans to add asynchronous operations and task parallelism support to the library in the near future. Another factor that influenced a simpler design is that most PCL users would not care about having fine-grained control over the execution of an algorithm. At the most, they would need to control on which facility the algorithm runs. These factors influenced the design to be simple yet offer all the customizations a user could need.
15
14
16
-
The design chosen was a template-based design which offered advantages such as no runtime overhead, errors related to usage and properties of executors are caught during compilation. Finally, it offered more flexibility in terms of being able to evolve the design rapidly based on feedback without breaking code existing executor compatible code. Extra effort was put into trying to follow the proposal as closely as possible to minimize refactoring within PCL so that when it is finally accepted into the standard library, it can be used in PCL as is.
17
-
This posed a challenge, going deep into template metaprogramming, especially to a person like me who had to search what metaprogramming is and being surprised that such a concept and was Turing complete nevertheless! Since then, I have come a long way and am more comfortable with template metaprogramming and find it a playful challenge to be able to apply this technique in places people generally might not think of using it. (Looking forward to the metaclasses proposal in C++ now).
15
+
The design chosen was a template-based design which offered advantages such as no runtime overhead and offers static checks related to usage and properties of executors. Finally, it provided more flexibility in terms of being able to evolve the design rapidly based on feedback, without breaking code existing executor compatible code. Extra effort was put into trying to follow the proposal as closely as possible while minimizing refactoring within PCL, so that when it is finally accepted into the standard library, it can be used in PCL as is.
18
16
19
-
The second challenge that I faced was reading through the relevant proposals and trying to interpret their meaning. The proposal uses quite a technical language, which is not easy to understand if you are not familiar with it. Since each proposal builds on the previous ones with new ideas being introduced and features being removed, this involved spending considerable time going through all the relevant proposals. This took multiple iterations of reading and trying to make sense of the concepts mentioned as the documents were the primary source of understanding and some discussions and videos. A lot of concepts I was not well versed with were used, so I spend a considerable amount of time in the browser searching stuff (no wonder my Chrome screen time was off the roof).
17
+
Going deep into template metaprogramming posed a challenge, especially to a person like me who had to search what metaprogramming is. I was surprised to discover that not only metaprogramming "is a thing", but it is also Turing complete! Since then, I have come a long way and I am more comfortable with template metaprogramming. I find it a playful challenge to be able to apply this technique in places people generally might not think of using it. (Looking forward to the metaclasses proposal in C++ now). The second challenge faced was reading through the relevant proposals and trying to interpret their meaning. The proposals use very particular style of technical writing, which is not easy to understand if you are not familiar with it. Since each proposal builds on the previous ones, with new ideas being introduced and features being removed, going through them consumed considerable time. It took multiple iterations of reading while trying to make sense of the concepts mentioned, using the documents as the primary information source and complementing them with discussions and videos. I was not well versed with a lot of the concepts used, so I spend a considerable amount of time looking them up.
20
18
21
-
This altered my goals quite a bit from my original proposal, where I had envisioned spending a notable amount of time adding support for other facilities and integrating executors into various algorithms. I had not expected so much time in the design phase for executors. There were many discussions, ideas, and design iterations with my mentorsas executors could be fundamental to how PCL handled execution internally. So it was essential to get the fundamentals right and not come up with something that would have to be scrapped or redesigned from the ground up after a short amount of time. Therefore, the timeline had to be modified, and more time was spent on the design of executors themselves in PCL.
19
+
This altered quite a bit my original proposal's goals, where I had envisioned spending a notable amount of time adding support for other facilities and integrating executors into various algorithms. I did not expected to spend so much time in the design phase for executors. There were many discussions, ideas and design iterations with my mentors, such as how executors could be fundamental to the way PCL handled execution internally. So it was essential to get the foundations right and not come up with something that would have been scrapped or redesigned from the ground up after a short amount of time. Therefore, the timeline had to be modified, and more time was spent on the design of executors themselves in PCL.
22
20
23
21
You can see the development cycle in the [unified-executors](https://github.com/shrijitsingh99/unified-executors/) repo.
This project has been a great learning experience. There was a learning curve, but I was able to go deep into the C++ language itself and become familiar with some handy tools and libraries that I would not have come across on my own under normal circumstances. All the hours I put into GSoC have definitely been worth it. This is, in large part, to the fantastic mentors I had. The amount of hours they themselves have put into this project in reviewing my code, helping build prototypes of features, teaching various language tricks and concepts, and in general, just guiding me throughout the project has helped make this experience worthwhile in itself.
48
+
49
+
Kudos to my mentors @kunaltyagi and @SergioRAgostinho.
50
+
Shoutouts to @aPonza and @larshg for doing a fabulous job mentoring other projects as well.
0 commit comments