Gbts in throughput mt

[m-brettell]

Adding the option to use GBTS in the full_chain_alg -> throughput_mt
Reads in the needed layer linking scheme configuration information from the file

Also adds placeholder configurations to other backends to keep the signature of full_chain_alg's constructor consistent between backends.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
8.4% Duplication on New Code

See analysis details on SonarQube Cloud

[stephenswat]

@m-brettell what is the status of this PR? Can it be reviewed and merged?

[krasznaa]

Making it possible to use GBTS in the throughput applications would indeed be super helpful. Please do go ahead with this development!

I would prefer to do it differently though. 🤔 Instead of modifying all the existing full chain algorithms, you should just introduce a new algorithm just for CUDA (traccc::cuda::full_chain_algorithm_gbts?). And then build a separate set of executables (traccc_throughput_st_cuda_gbts, traccc_throughput_mt_cuda_gbts) using that full chain algorithm.

Once every language has GBTS available, we could re-visit this. But for now I think this would work better. 🤔

[stephenswat]

I would prefer to do it differently though. 🤔 Instead of modifying all the existing full chain algorithms, you should just introduce a new algorithm just for CUDA (traccc::cuda::full_chain_algorithm_gbts?). And then build a separate set of executables (traccc_throughput_st_cuda_gbts, traccc_throughput_mt_cuda_gbts) using that full chain algorithm.

What? 😕 I thought we agreed to reduce the number of executables, not increase it. Mark's approach is perfectly reasonable and a lot more maintainable than what you are suggesting.

[krasznaa]

What? 😕 I thought we agreed to reduce the number of executables, not increase it. Mark's approach is perfectly reasonable and a lot more maintainable than what you are suggesting.

I want to reduce the number of individual application source files. The throughput applications are very well synchronized in their code already. The new executables will need this code:

#include "../common/throughput_mt.hpp"

#include "full_chain_algorithm_gbts.hpp"

int main(int argc, char* argv[]) {

    // Execute the throughput test.
    return traccc::throughput_mt<traccc::cuda::full_chain_algorithm_gbts>(
        "Multi-threaded CUDA (GBTS) GPU throughput tests", argc, argv);
}

And:

#include "../common/throughput_st.hpp"

#include "full_chain_algorithm_gbts.hpp"

int main(int argc, char* argv[]) {

    // Execute the throughput test.
    return traccc::throughput_st<traccc::cuda::full_chain_algorithm_gbts>(
        "Single-threaded CUDA (GBTS) GPU throughput tests", argc, argv);
}

Please stop arguing with absolutely everything that I would suggest.

[stephenswat]

I want to reduce the number of individual application source files. The throughput applications are very well synchronized in their code already. The new executables will need this code:

Yes, and to make that happen we'll need to make a duplicate of the full_chain_algorithm.cpp and full_chain_algorithm.hpp source files which total 450 lines of code per backend. 😛

Please stop arguing with absolutely everything that I would suggest.

I remind you that you are the one arguing with someone else's suggestion here. 😉

[mimodekjaer]

This will add type of ascii '0' and ascii '1', which have the int value of 48 and 49. Which as far as I can see it not intended.

[m-brettell]

Added cast to fix, thanks.

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
9.2% Duplication on New Code

See analysis details on SonarQube Cloud