simulator run_batch and hardware run_batch have different interfaces

[ncrubin]

run_batch is available in the simulator and through the hardware but the call seems to have a different API. Would it make sense to have the same return type at least?

[viathor]

This issue should exhibit the present and desired function signatures.

[balopat]

TODO: add function signatures here for the discussion

[verult]

@ncrubin could you provide the function signatures you're envisioning?

cc @MichaelBroughton

[maffoo]

Not sure if this is what @ncrubin was referring to, but there's a rather big difference between Sampler.run_batch and the various flavours of EngineProcessor.run_batch:

# Sampler
def run_batch(
    self,
    programs: Sequence['cirq.AbstractCircuit'],
    params_list: Optional[List['cirq.Sweepable']] = None,
    repetitions: Union[int, List[int]] = 1,
) -> Sequence[Sequence['cirq.Result']]:
    ...

# EngineProcessor et al.
def run_batch(
    self,
    programs: Sequence[cirq.AbstractCircuit],
    program_id: Optional[str] = None,
    job_id: Optional[str] = None,
    params_list: Sequence[cirq.Sweepable] = None,
    repetitions: int = 1,
    gate_set: Optional[serializer.Serializer] = None,
    program_description: Optional[str] = None,
    program_labels: Optional[Dict[str, str]] = None,
    job_description: Optional[str] = None,
    job_labels: Optional[Dict[str, str]] = None,
) -> 'abstract_job.AbstractJob':
    ...

All the metadata (program and job ids, labels, and descriptions) are not really applicable when running on most samplers where work is ephemeral and doesn't get persisted with metadata to be looked up later. Also, the sampler method returns the results directly, while the engine processor method returns a job object which can be used to fetch the results later.

I would suggest that we try to use the Sampler interface more, i.e. use QuantumEngineSampler whose run_batch signature matches that of Sampler, but I don't know to what extent people are currently relying on things like job and program metadata which are only available on EngineProcessor. One thing we want to do to enrich the Sampler interface is to have better support for async workflows, so we'd want to add run_batch_async to go along with the existing run_async and run_sweep_async methods (we're working on improving async support in the engine API generally, starting with updating the generated code: #5139).

[verult]

Ack, @maffoo my understanding of your comment is that the functions are different by design, and that we should try to rely on Sampler more going forward. I'll close this issue since the original concern is by design, but please feel free to reopen this @ncrubin if the comments haven't addressed your concerns.