LeapHybridSolver timing overhead

F V

June 30, 2021 15:35

Hi everyone,

I'm using LeapHybridSampler() to solve an optimization problem. In order to compare it with other classical solvers, I use the time.time() function to measure the computation time. However, the computation time of different runs of the same problem solved with LeapHybridSampler() span from 15 to 200 s. Analyzing the memory and CPU usage, it seems to me that the process waits for something. I would like to discern the actual local CPU computation from waiting time, since from the task manager it is not so simple.

Thank you in advance for the clarification,

Francesco

Comments

6 comments

David J (Report)
June 30, 2021 22:39 (Edited February 23, 2024 18:24)
Hello,

To get more accurate runtimes for the LeapHybridSampler, please use the timing information as outlined in the documentation:
https://docs.dwavesys.com/docs/latest/doc_leap_hybrid.html#solver-timing

You can access the timing info from the SampleSet returned from a sample() call like this:
```
...
sampler = LeapHybridSampler()
sampleset = sampler.sample(bqm)
print(sampleset.info["timing"])
...
```
Using the time.time() function can vary quite a bit.
This function will vary with the type of computer you have, what is running on the machine concurrently with your code, the network connectivity in your area, and other such factors.
Since the samplers make calls to the QPU over the network, this can affect the value calculated using time.time().

Hopefully this helps. Please let us know if you have any questions.
0

Comment actions Permalink
F V (Report)
July 01, 2021 09:26

Thank you for your quick reply. I already know that it is possible to retrieve that kind of information. However, the computation time obtained using time.time() varies too much. I think it depends on QPU scheduling due to the number of tasks in the queue. Is this intuition correct or not?

0

Comment actions Permalink
David J (Report)
July 03, 2021 00:44 (Edited July 03, 2021 00:46)

Hello,

Although it is possible for QPU scheduling and number of tasks in the queue to affect the time.time() result, it does not seem likely in this case, but I will inquire further to be certain. I will update as soon as I have more information.
I believe the variation is expected and is just part of the nature of the sampler.

One thing I was curious about is the time range. Is it 15 - 200 s or 15 - 200 ms?

Thank you for your patience and coordination.

0

Comment actions Permalink
David J (Report)
July 05, 2021 13:35

It looks like the problems ran a total of 4-11 seconds for problems run on the hybrid solver.
Does this look right?

0

Comment actions Permalink
F V (Report)
July 07, 2021 08:31

Yes, it looks like a reasonable time. Maybe, it was a temporary Dwave's problem. However, it is not clear to me how to distinguish computation time (QPU access time and CPU run time) from queuing time, if present.

0

Comment actions Permalink
David J (Report)
August 05, 2021 00:11

Unfortunately we do not have a way of explicitly identifying queueing time, however it is possible to take the difference between the run_time in the timing info provided by the sampler and the total runtime of the call to the sample() function. This difference will include queueing time, network latency, data transfer time, etc.

0

Comment actions Permalink

Please sign in to leave a comment.

Didn't find what you were looking for?

New post