Use qibo as a backend for vegasflow

[scarlehoff]

At the moment it just uses qiboteam/qibolab#1138 to generate the random numbers which then are casted to tensorflow, which at that point is used basically as numpy.

As it is now Vegas could inherit from it already and use the qrng device.

[scarlehoff]

In the log below, the first two runs are just uniform sampling and the second two the quantum device. The first just a plain monte carlo and the second going through the vegas algorithm.

> Running plain for 100000 events
[INFO] Checking whether the integrand outputs the correct shape (note, this will run a very small number of events and potentially trigger a retrace)
[INFO] Result for iteration 0: 0.9932 +/- 0.0121(took 0.01019 s)
[INFO] Result for iteration 1: 0.9933 +/- 0.0122(took 0.00580 s)
[INFO] Result for iteration 2: 0.9935 +/- 0.0122(took 0.00596 s)
[INFO] Result for iteration 3: 1.0129 +/- 0.0123(took 0.00619 s)
[INFO] Result for iteration 4: 1.0031 +/- 0.0122(took 0.00632 s)
[INFO]  > Final results: 0.999088 +/- 0.00546193
This run took 0.045812368392944336

> Running vegas for 100000 events
[INFO] Checking whether the integrand outputs the correct shape (note, this will run a very small number of events and potentially trigger a retrace)
[INFO] Result for iteration 0: 0.9898 +/- 0.0121(took 0.18835 s)
[INFO] Result for iteration 1: 0.9987 +/- 0.0019(took 0.19447 s)
[INFO] Result for iteration 2: 1.0004 +/- 0.0010(took 0.19820 s)
[INFO] Result for iteration 3: 1.0002 +/- 0.0010(took 0.18120 s)
[INFO] Result for iteration 4: 1.0010 +/- 0.0010(took 0.18201 s)
[INFO]  > Final results: 1.00033 +/- 0.000558294
This run took 0.9491708278656006

> Running quantum for 100000 events
Sucessfuly connected to quantum device in /dev/ttyACM0
[INFO] Checking whether the integrand outputs the correct shape (note, this will run a very small number of events and potentially trigger a retrace)
[INFO] Result for iteration 0: 1.0699 +/- 0.0126(took 254.54615 s)
[INFO] Result for iteration 1: 1.0303 +/- 0.0125(took 254.49300 s)
[INFO] Result for iteration 2: 1.0298 +/- 0.0125(took 254.48034 s)
[INFO] Result for iteration 3: 0.9990 +/- 0.0123(took 254.47564 s)
[INFO] Result for iteration 4: 0.9911 +/- 0.0121(took 254.43809 s)
[INFO]  > Final results: 1.02329 +/- 0.00554131
This run took 1274.0707886219025

> Running quantumflow for 100000 events
Sucessfuly connected to quantum device in /dev/ttyACM0
[INFO] Checking whether the integrand outputs the correct shape (note, this will run a very small number of events and potentially trigger a retrace)
[INFO] Result for iteration 0: 0.9865 +/- 0.0121(took 254.70932 s)
[INFO] Result for iteration 1: 0.9945 +/- 0.0019(took 254.71308 s)
[INFO] Result for iteration 2: 1.0016 +/- 0.0010(took 254.72152 s)
[INFO] Result for iteration 3: 1.0003 +/- 0.0010(took 254.70259 s)
[INFO] Result for iteration 4: 0.9989 +/- 0.0010(took 254.71654 s)
[INFO]  > Final results: 0.999807 +/- 0.0005604
This run took 1273.5763764381409

1e5 events x2 dim in ~20 minutes, which is okish for using it as a backend I'd say @scarrazza (in this case the integrand is trivial, in a more complicated case I'd expect the integrand cost to take over)

The results seems to be compatible with the initial sampling for all but the first run. It might be a fluctuation but I've run this test twice and the first run (iteration 0 of the 3rd run in the log above) was also more off than what the error would suggest.

[alecandido]

Instead of connecting and disconnecting every time, why don't you keep the connection in the object? (and just disconnect on delete)

[alecandido]

I'm not claiming that is going to be the main performance bottleneck - but it's certainly some overhead (if it can be avoided).

[scarlehoff]

Because while I was testing I got several times an error along the lines of "someone else is using the device" which I thought maybe it was @stravos11 testing so I thought it was better to close it asap to avoid making his stuff error out in the same way.

(indeed, in the first commit I do as you suggest)

[stavros11]

It was not me, so it is either a different kind of error that we would need to address if it appears often, or someone else tried to use at the same time, but I don't think anyone other than us and @scarrazza would. Personally, I have another qrng that I connect directly to my computer for debugging so I avoid using the one in the qrccluster.

Also, I don't think connect() and disconnect() will have any effect on others. Based on a quick experiment I did, if someone else tries to access numbers while you are sampling, your connection will automatically drop (with an error) and their job will start. So basically the last one always wins. Also, I think connect() and disconnect() have no effect on the qrng device itself, they just create/destroy the Serial object in your Python runtime.

[scarlehoff]

ok, then I'll redo what I was doing before and paste the error. By disconecting inmediately after use like now i didn't see the error

[alecandido]

Yes, I actually thought that could be the case, but I was unsure about the setup. It may be that you're actually trying reconnecting multiple times somehow (e.g., instantiating the object multiple times).

In case you still experience the error, would you post it?

[alecandido]

Also, I think connect() and disconnect() have no effect on the qrng device itself, they just create/destroy the Serial object in your Python runtime.

@stavros11 while on the device it may have no effect (not so expert in serial interfaces...), for sure it has an effect on the OS, since it has at least to open a file descriptor for the communication. Then, this will be handled by the given fs, and potentially boil down to a tiny and likely negligible operation.

[scarlehoff]

Based on a quick experiment I did, if someone else tries to access numbers while you are sampling, your connection will automatically drop (with an error) and their job will start. So basically the last one always wins.

In case you still experience the error, would you post it?

I ran a long test yesterday evening and didn't experience the error again. I think I might have really clashed with you or someone else who tried to use it?

In any case, I can "force" the error by just login in twice to the node and running the same script in both, one of them will error out with:

serial.serialutil.SerialException: device reports readiness to read but returned no data (device disconnected or multiple access on port?)

(the crash happened in the one that ran second fwiw)

[scarrazza]

@scarlehoff the drivers for the qrng are available now in qibolab v0.2.3.