Cytnx-dev
Merge repo Cytnx_doc into this repo
I suggest keeping the document as close as the code so that the developers can keep the document aligned with the code easily. A case shows that putting the document and the code in the same repo benefits. Considering we are going to change dependency A to dependency B and also want to keep the document correct enough at any moment, we have to do three steps when the document and the code are located in different repos:
- Added B as a dependency in the document (A is still the dependency, so we cannot remove A from the document here.)
- Switch dependency A to dependency B in the codebase
- Removed dependency A from the document
It's worth to mention it is not possible to make the document aligned with the codebase at each moment when dependency A conflicts with dependency B in this case.
By merging the document repo into this repo, we can easily make the document aligned with the code over time. We only need one step, even one commit, to finish the job that needs three steps above while the document and the code are located in different repos. PyTorch also put their doc and code in the same repo.
Here is the steps for merging two git repos: https://stackoverflow.com/questions/1425892/how-do-you-merge-two-git-repositories
Steps:
- [x] Merge Cytnx_doc to Cytnx (#603).
- [x] Format the code in the new doc folder to follow the rules of Cytnx repo (#603).
- [ ] Move GitHub actions in the new doc folder to the Cytnx repo.
I believe this is the goal. The problem is the build process takes too long, so updating just user guides takes forever. The User guides were more designed as "blog" style posts instead of API documentation.
I think at least all parts of the projects should be under Cyntx-dev. Currently, the code, the API documentation and the user guide are all separate. Also, the links in the user guide to the API documentation are broken currently (see for example the linear algebra table), maybe there is a better way to link things.
We spend most of time on build HPTT. There are some ways to reuse the previous build to reduce the build time in GitHub actions.
We spend most of time on build HPTT. There are some ways to reuse the previous build to reduce the build time in GitHub actions.
Are we using HPTT in the production? I thought the default build doesn't use HPTT
We spend most of time on build HPTT. There are some ways to reuse the previous build to reduce the build time in GitHub actions.
Are we using HPTT in the production? I thought the default build doesn't use HPTT
Yes, we enable HPTT by default.
The messages from the latest GitHub action for releasing:
And here is the setting in setup.py.
https://github.com/Cytnx-dev/Cytnx/blob/cea390abad646958ac4a8ea08ec39cbbf606230d/setup.py#L43
@hunghaoti I wonder if there is a benchmark for with and without HPTT?
We don't have the benchmark for that but I can do it later.
@hunghaoti I wonder if there is a benchmark for with and without HPTT?
I benchmark UniTensor::contiguous_ function, which used HPTT.
Run on (8 X 4200 MHz CPU s)
cpu info:
CPU Caches:
L1 Data 48 KiB (x4)
L1 Instruction 32 KiB (x4)
L2 Unified 1280 KiB (x4)
L3 Unified 8192 KiB (x1)
Load Average: 2.30, 3.18, 3.78
with HPTT
---------------------------------------------------------------------
Benchmark Time CPU Iterations
---------------------------------------------------------------------
BM_Tensor_contiguous/100 0.020 ms 0.020 ms 33972
BM_Tensor_contiguous/1000 2.30 ms 2.29 ms 308
BM_Tensor_contiguous/10000 179 ms 178 ms 4
without HPTT
---------------------------------------------------------------------
Benchmark Time CPU Iterations
---------------------------------------------------------------------
BM_Tensor_contiguous/100 0.112 ms 0.112 ms 6258
BM_Tensor_contiguous/1000 12.5 ms 12.5 ms 56
BM_Tensor_contiguous/10000 1292 ms 1290 ms 1
I commit the benchmark code as PR604