Not-condition performance

[ej-psi]

Required prerequisites

• Search the issue tracker to check if your feature has already been mentioned or rejected in other issues.

Describe the feature

We're seeing some very common cases where the GPU state-vector sim is slower then our CPU sim, specifically because of not-conditions.

Application functions such as QROM and arithmetic often have "open-bubble" controls.

In order to do this with CUDA-Q, we currently are required to insert X gates. For a large state vector (like above 30 qubits), the cost for all of these X gates is substantially more than the rest of the computation.

Here you can see the X gates inserted in the CUDA-Q program.

As mentioned, this case is so common that we're seeing it make our GPU programs slower than the same programs on CPU.

Side note: For CNOT gates (only one control), CUDA-Q allows use of the ~qubit syntax for not-conditions, however this appears to insert X gates, and also doesn't seem to work for gates with 2 or more controls.

Implementing not-conditions without inserting X gates would increase the performance of all CUDA-Q programs which use high-level algorithms!

[1tnguyen]

Thanks @ej-psi for the feature request.

Indeed, CUDA-Q handles control negation at the front-end level (inserting X gates before and after on negated control qubits):

cuda-quantum/lib/Frontend/nvqpp/ConvertExpr.cpp

Lines 1944 to 1948 in 9666c0e

	inlinedStartControlNegations();
	builder.create<quake::ApplyOp>(loc, TypeRange{}, calleeSymbol,
	/*isAdjoint=*/false, ctrlValues,
	kernelArgs);
	return inlinedFinishControlNegations();

Specifically, quake::ApplyOp only captures controlled qubits, not negation information. This matches CUDA-Q's NVQIR runtime, whereby we only support the conventional controlled gates, e.g., __quantum__qis__x__ctl takes an array of controlled qubits without bit values (denoting the control negation information).

To enable this simulation enhancement, we might need a holistic (re-)design of the frontend-backend flow to capture control-negation information.
For example, a viable solution may be:

• quake::ApplyOp op to store control negations in addition to control qubits.
• New variants of controlled quantum gates (e.g., __quantum__qis__x__ctl, __quantum__qis__y__ctl) in the NVQIR runtime are needed to capture control negations (lowered from quake::ApplyOp).
• An update to the base CircuitSimulator interface is required to wire the control negation information to the simulator.

Hence, we'd need to triage this request in our feature planning.

[ej-psi]

Thanks for this thorough response! I'm available to help with fast not-controls (we've built them into our CPU sim).

Currently our workaround is to have our main ops kernel (the one which loops through instructions rapidly and applies them) insert X gates, and canceling them when there are two in a row. For now this will work, and I'll try to keep an eye on the performance loss from the "Xtra" ops. :]