Conversation
aleksei-fedotov
requested review from
akukanov,
isaevil,
kboyarinov,
omalyshe and
vossmjp
|
|
||
| 2. /Library/ | ||
|
|
||
| This number reflects the version of the binary. It consists of three numbers: =major=, =minor=, |
There was a problem hiding this comment.
Shouldn't be mentioned that this is only for Linux and for Windows binaries are not versioned?
There was a problem hiding this comment.
Changed to library to avoid confusion with the naming of executable files.
| number of available cores. | ||
| - *Load imbalance*: Some cores may be idle while others are overloaded due to poor resource | ||
| distribution. | ||
| - *Performance degradation*: The overall application performance suffers despite individual |
There was a problem hiding this comment.
Isn't this mostly covered by the three previous points. The reason why the individual components perform well in isolation but not together is due to resource contention, oversubscription or load imbalance. So maybe you can remove this point.
There was a problem hiding this comment.
I think you are right. Removed.
| allows different parallel components to: | ||
| 1. *Register their resource requirements*: Components can declare their threading needs and | ||
| constraints. | ||
| 2. *Negotiate resource allocation*: TCM mediates between components to determine optimal thread |
There was a problem hiding this comment.
Should it be "optimal resource distribution"? Its subtle, but since TCM doesn't hand out threads, maybe its better to avoid saying it optimizes thread distribution. The components get resources granted and the OS actually schedules the threads...
There was a problem hiding this comment.
Yeah, TCM is about resources, not threads - it's the name that might delude readers... Should we rename it to Resource Composability Manager if it is not too late? Just joking...
| *Key features include*: | ||
| 1. *Library-agnostic interface*: C-style interface simplifies integration with threading libraries. | ||
| 2. *Minimal overhead*: Designed to add negligible runtime cost to parallel operations. | ||
| 3. *Backward compatibility*: Existing applications can benefit without requiring extensive |
There was a problem hiding this comment.
Maybe "Non-intrusive" or "Minimally Intrusive" instead of "Backward Compatibility"? Since you go into Versioning later, introducing a different kind of backward compatibility here might be confusing.
| **** Note about building TCM as a static library | ||
| TCM is meant to run as a singleton to share its state across its clients, threading libraries. | ||
| Therefore, building static version of the TCM library breaks the whole point of the project, thus, | ||
| does not make sense. So, such option won't be provided. |
There was a problem hiding this comment.
What if all of the components are also statically linked -- could it make sense then?
There was a problem hiding this comment.
I think it could. I would prefer not to do such strong claims that "such option won't be provided" and etc. To me it simply sounds like current limitations of TCM.
There was a problem hiding this comment.
What if all of the components are also statically linked
Then each component will have its own copy of TCM, is not it? In this case TCM won't be able to compose anything, but just be an unnecessary overhead for each of such component.
Removed the sentence.
| distinguish between various packages with identical TCM library version inside. | ||
| ** Distribution | ||
| The TCM binary packages are to be distributed separately from oneTBB packages, but available for | ||
| download along with them through the same distribution channels. |
There was a problem hiding this comment.
Why not have a separate TCM package for those that only want TCM, but then a TBB package that also contains TCM? So TBB users more easily get TCM without needing a second step of getting TCM. Or maybe that's what you mean here?
There was a problem hiding this comment.
Not sure. On one hand, providing an additional oneTBB package that already contains TCM is convenient, but, on the other hand, polluting GitHub Release entry with various combinations of packages may look awkward.
Although, adding two more packages (Linux and Windows) does not seem like adding too much. Perhaps, we could use download statistics and see what packages people download and how many times.
Though, in the package managers I would put a dependency on TCM instead, not providing individual "oneTBB+TCM" package.
There was a problem hiding this comment.
If our long-term goal, particularly for package managers, is to have TCM packages independent from TBB ones, then I think we should be consistent everywhere and from the day one. I think that will help setting expectations and minimizing confusion.
There was a problem hiding this comment.
In this case, it would be good to have TCM source code uploaded as a separate entry too.
There was a problem hiding this comment.
Will TBB and TCM always be released in lock step? For example, can there be a TCM-only release at the releases page? If not, then will they also share milestones for planning?
There was a problem hiding this comment.
I think most of the time they should. If there will be a request or significant improvements to one or the other library, then we could consider separate one-time release. However, I think releasing them together makes it easier for everyone to understand what bits are most compatible.
| Since Thread Composability Manager provides a general interface to consult on CPU utilization and | ||
| allows any threading framework to get recommendations on the use of CPU resources, the proposal is | ||
| to make the TCM more available so that everyone interested can leverage its use and make their | ||
| parallel runtime composable with oneTBB and Intel's OpenMP now, and with more and more threading | ||
| runtimes in the future, allowing users to use those parallel runtimes in which they are fluent the | ||
| most and/or which fit computations the best. |
There was a problem hiding this comment.
I'd suggest also breaking it into two or more sentences since its rather long, which probably make its difficult to read.
| Since Thread Composability Manager provides a general interface to consult on CPU utilization and | |
| allows any threading framework to get recommendations on the use of CPU resources, the proposal is | |
| to make the TCM more available so that everyone interested can leverage its use and make their | |
| parallel runtime composable with oneTBB and Intel's OpenMP now, and with more and more threading | |
| runtimes in the future, allowing users to use those parallel runtimes in which they are fluent the | |
| most and/or which fit computations the best. | |
| Since Thread Composability Manager provides a general interface to consult on CPU utilization and | |
| allows any threading framework to get recommendations on the use of CPU resources, the proposal is | |
| to make the TCM more available so that everyone interested can use it. Integration with TCM will make a | |
| parallel runtime more composable with oneTBB and Intel's OpenMP now, and possibly more threading | |
| runtimes in the future. Users will then have more choice to use the parallel runtimes in which they are | |
| fluent and that best fit their computations, while still creating composable parallelism. |
| test rules with corresponding TCM rules if TCM dependencies are met, and TCM rules are not | ||
| explicitly disabled by the user. | ||
|
|
||
| Also, due to [[Independence][independent nature]] of the project, and to avoid repetition of building rules in the |
|
|
||
| ** Keeping project independence intact | ||
| Although, placed into the oneTBB source tree, TCM remains independent. The top =tcm= directory can | ||
| literally be copied/moved into other place and used from there without any dependence on oneTBB |
There was a problem hiding this comment.
What about oneTBB dependence on TCM? Currently oneTBB duplicates tcm.h in its src directory. Will it continue to do so, or depend on TCM sources for this?
There was a problem hiding this comment.
I believe it is preferable for oneTBB to start depending on tcm.h from TCM directory.
akukanov
left a comment
akukanov
left a comment
There was a problem hiding this comment.
The proposal now looks good to go; the suggestions below are not critical.
| To avoid confusion about whether a particular patch, issue or any other repository activity is | ||
| related to oneTBB or TCM project, '[TCM]' prefix will be used to mark TCM activities. |
There was a problem hiding this comment.
Does it make sense to also add a special label for TCM related "records" in the repo? The prefix is still needed for commit messages, so I am not sure if adding a label will be useful or not so much.
|
|
||
| ** Distribution | ||
| The TCM binary packages are to be distributed separately from oneTBB packages, but available for | ||
| download along with them through the same distribution channels. |
There was a problem hiding this comment.
Perhaps we need to be more specific about the "distribution channels" here. What are those, besides the GH release pages, and how will we make sure that TCM packages are distributed there "separately but along with TBB"?
There was a problem hiding this comment.
I replaced abstract channels with releases page at GitHub.
5 participants
Please read the RFC from this PR.