Closed exAClior closed 1 year ago
Hi thanks for the proposal, I like this idea actually, this is definitely a good enhancement!
I think it doesn't need to add this info globally tho, though a Timed
block should suffice. The reasons are:
thus basically need something like the following
struct TimedBlock <: TagBlock
content
duration::Float64
end
this gonna require users to manually set a duration (which I think is good if you work on different hardware, and we can always provide some alias). Ideally, this information should be inferred from a lower-level IR (intermediate representation) but this is something we may address in the future with a better compiler pipeline.
It'd be nice if you could join our community call, and we can discuss it this Thursday, please email contact@yaolang.dev then I'll send you the calendar invite (since I'm not allowed to share the zoom link publicly)
In https://github.com/QuantumBFS/Yao.jl/issues/253 there seems to be the inclination towards giving the user real quantum machine usage. Might as well make things more native towards hardware.
Might be too much of a complication on the simple and elegant Block implementation. Not many folks would really need this feature for now. This is more like the pulse-level quantum circuit in Qiskit.
There is real hardware support usable actually, and for simple cases (e.g via the IBMQClient package), it actually works pretty well, this is mainly because, at this stage, most of the quantum hardware is provided through cloud service via a REST API, and thus the way to operate the machine to generate a JSON schema and send it to the REST API. So on the client side, the compilation doesn't need to be too complicated at this level.
But considering the progress of hardware and compilation techniques, this is probably not true anymore, many machines can do lots of fast control flows, and more control on native pulses, and the requirement of compilation pipelines like error mitigation, and postprocessing is getting more complicated.
What is actually missing here, is general compilation support, and that was why I haven't been spending much time on integrating the current implementation with the machine, but instead thinking about how to refactor the pipeline. Tho we do support naive circuit transform based on Julia's multiple dispatch since the early days, an elegant and powerful solution is still not there yet.
But I think while we are still working on a new pipeline, it would be nice to have these new use cases included in YaoBlocks before that happens so we can learn more about different use cases.
FYI, the next Yao community call is Thursday 12AM (today, midnight). It happens monthly.
@Roger-luo My apologies! I was not able to join the community call due to traveling and relocating. Thank you for the comprehensive response regarding my proposal! I also talked to @GiggleLiu about this issue after the community call happened. Seems like my concern was true. My proposal conflicts with the philosophy of Yao. So the next move should be done with more care. I think I will close this issue for now. Should time permit, I think more conversation on the compilation pipeline etc should be done before I do / propose anything.
Enhancement Idea
In #426, enhancement of
Block
on the account of revealing circuit depth is requested. On a related topic, it might be rewarding to also add the information of gate time intoBlock
as well.Motivation
On real machines,
XGate
andCXGate
will have drastically different duration.Block
representation ignores such difference. WithBlock
representation, anXGate
applied on qubit 1 andCXGate
applied on qubit 2,3 will make it look like all three qubits experienced some sort of control for the same amount of time. But in fact, qubit 1 will remain idle for a long time.Error mitigation techniques like Dynamical Decoupling requires inserting random gates on idle qubits.
Block
s with timing information could helpBlocks
in a Tetris style. Then, insertion location of random gates could perhaps be found more easily.In #253 there seems to be the inclination towards giving the user real quantum machine usage. Might as well make things more native towards hardware.
Concerns
Might be too much of a complication on the simple and elegant
Block
implementation. Not many folks would really need this feature for now. This is more like the pulse-level quantum circuit in Qiskit.If you think this is a good enhancement, I would be glad to help with the implementation or the related issue #426.