added calcAmpSum backend #608
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Example PR A
Sub PR 2
This PR implements the backend of the
calcRealAmpSumfunction from PR #607, to demonstrate how accelerated functions are structured.In general, a function in
quest/src/apicalls alocaliser.cpproutine which communicates data between distributed nodes as necessary.It does this by invoking one or more routines within...
comm_routines.cppthen proceeds to invoke an
accelerator.cpproutine which decides whether to invoke CPU or GPU code.This calls either a...
cpu_subroutines.cpproutine which may use multithreading, or a...gpu_subroutines.cpproutine which will invoke either a custom kernel, a Thrust routine, or a cuStateVec routine. These three types of functions are respectively defined in:gpu_kernels.cuhgpu_thrust.cuhgpu_cuquantum.cuhIn this PR, the GPU backend for the function
calcAmpSumwas implemented using Thrust since it trivially mapped to an existing Thrust routine.Note that
calcRealAmpSumcan be called upon both a statevector and density matrixQureg. Since the simulation logic is agnostic to either, both types ofQuregwere passed to backend functions containing the_statevector_infix. If the statevector and density matrix logic had differed, we would additionally define backend functionsand invoke the appropriate localiser function at the top-level:
With the frontend and backends defined, the next step is to implement the unit tests like demonstrated in #609.