hey everyone thanks for the invite sorry
we're a little bit late we're still in
West Coast time flew in from San
Francisco
so thank you for giving us the
opportunity to speak here
I'm from Rigetti computing I'm a
software engineer there and I would love
to talk to you about some of the
software that runs the quantum computers
that we build down in Berkeley
California
so Rigetti computing is a full-stack
quantum computing company and when I say
full-stack I really mean it we build
both the hardware the devices and the
software necessary to do quantum
computing with superconducting qubits so
here's some pictures of our lab down in
Berkeley and this is currently where we
have a fleet of quantum computers some
of which are publicly accessible over
the cloud and this here is a picture of
our fabrication facility in Fremont
California and that's kind of where
everything begins so we built this
facility from scratch specializing it
for the manufacturer of quantum
integrated circuits and we think this is
likely the first facility of its kind
that's dedicated to making
superconducting quantum processors and
so that's what one of the quantum
devices that we manufactures looks like
it's a this is an eight qubit device but
obviously we're we're scaling up and you
know this this this type of device for
people who are familiar with more
traditional computing that looks a
little bit foreign but there's actually
a number of things that are familiar
about it when you compare it to sort of
traditional semiconductor manufacturing
it's printed on a piece of silicon or
silicon wafer and then we spray on metal
using various kind of traditional
fabrication processes the big difference
obviously is with semiconductors is that
this is not semiconducting but rather it
becomes superconducting when we
sufficiently cool it down oops but I'm
not here to talk about the fabrication
process because I don't know a ton about
it I'm here to talk about the software
which I do know a lot about and in
particular I want to give you kind of a
behind-the-scenes look at the software
that it takes to actually run one of
these devices and get it accessible for
people like you to run programs
so my personal background is in software
engineering my last job was working at
LinkedIn so if you received many
messages for cruder messages i'm sorry
about that the so I spent three years
there and then wanted to try something
completely different and Righetti
computing has a very diverse staff in
terms of background we have software
engineers physicists theorists
mechanical engineers really anyone
needed to come together and build this
very difficult machine so you know I'd
love to kind of give you a bit of a
behind-the-scenes look in the software
that it takes to get your program down
to our computers so the way we write
quantum programs at Righetti is using a
language that we specified called quill
and that's short for quantum instruction
language now quill looks very similar to
assembly code it's a step-by-step list
of operations that should be executed on
particular qubits so on the left you can
see some of the examples and you'll
probably be familiar with some of these
gates but on the right is how you would
execute them with quill you specify the
gate name and then the qubits that that
cade operates on so for instance there's
an Hadamard see not gates and so forth
and then to finish off your program you
append measure instructions at the end
and that reads out a single bit of
information from the qubit and stores it
in a classical register for you then to
then continue doing any more work with
it so step one of executing a Ponton
program is obviously get it into this
format and describe to us the gates that
you'd like to perform so the quill
program is packaged up and sent to us
over the cloud and because every quantum
computers or beside every quantum
computer is a regular old classical
computer that we call the control
computer and it has a number of steps to
do with that quantum program before it
can actually be physically realized on
our devices so the first step is
compilation
and to explain what a quantum compiler
what does I'll first contrast it with a
compiler for a classical computer so if
you take a language like skele which is
my favorite programming language and you
compile it it eventually gets compiled
down to JVM bytecode so another way to
say that is that the source language is
Scala the target language is the JVM
bytecode and then the compiler itself is
written in scala for us we made some
unique choices for our compiler so we
take in quill as input and what we
output is a subset of quill called proto
quill so our devices do not support
arbitrary unitary operations they only
support a few different types of gates
that we've calibrated so to take an
arbitrary program that you give us and
get it to something that can actually
run on our hardware we need to perform
various identities and so forth to
transform your program from which is
arbitrary gates into a program that our
computers could understand so that's
what our compiler does and proto quill
is the result of that which is quill
that is restricted to a subset of
operations that can be performed on our
computers so our compiler is written in
Common Lisp which for people who have
been in software engineering for a while
I shouldn't be a surprise it's a good
language for doing any sort of
structural matching and transformations
and so forth
so even in amongst the computers that we
have it were Getti there are different
natural gate sets and so the compiler
needs to be customized for each one of
these to allow it to get down to the
most efficient most optimal protocol
program for the quill program that you
give as input so for instance what the
compiler does is there's a number of it
can take several lines of instructions
and also optimize it into one so there
are a number of identities programs on
the Left which are longer than
equivalent programs on the right and our
compiler is aware of some of these
transformations and can make them for
you to get the program
to a more optimal size so this is
obviously really an exercise in in
linear algebra each of these is a matrix
operation which then can be decomposed
changed basis all sorts of things to get
us to the type of code that we want to
run on our computer so another challenge
that the compiler has to deal with is
the limited subset of the limited caught
activity of our devices so the qubits
and our devices are not all - all
connected rather you can only perform
two cubic operations on neighboring
qubits so to perform an arbitrary
quantum program you need to take any two
cubic eights on non nearest neighbors
and get them into a program that only
performs on nearest neighbor qubits so
here's a picture of our 20 qubit device
if you zoom in you can see that each
qubit is connected to at most two of its
neighbors our 3 of its neighbors rather
and some of the qubits obviously around
the edges even have fewer neighbors than
this so there's one kind of orphan on
the bottom left that's only connected to
one other key bit and so how does the
compiler deal with this here's the same
picture again but in graph form it shows
you the various edges that we have
active and the qubits so if we wanted to
perform an operation against qubits 1
and 10 we would first have to perform a
series of swaps to get the quantum
information next to each other in order
to perform those operations and so the
compiler is both kind of doing this
linear algebra problem which is taking
arbitrary quantum programs and turning
them into our natural gate set and it's
also doing this sort of graph
optimization problem which is to try and
figure out the minimum number of extra
operations it needs to throw in there in
order to take a fully connected program
and turn it into something that runs
under limited connectivity devices
all right so that's step one and the
next step is to convert these abstract
instructions that come out as a result
of the compiler into something that's
physical so our quantum computers
respond to bundles of photons that are
sent to them by pulse generators and the
pulse program is a series of these
pulses so if you extend my compiler
analogy from before there are usually
multiple steps in compilation so for
instance with Scalla you can pile it
down to JVM bytecode and then that JVM
bytecode again gets converted or
translated into native machine
instructions that the CPU would
understand and similarly with our
quantum programs the final step is to
take the quill code and turn it into a
pulse program which is something that
can keep the computer will actually
react to and we do this using Python so
I'm going to explain a little bit more
about what I mean by pulse programs
let's say the qubit is in the zero state
to flip it to the one state we need to
send it in our X PI instruction but that
instruction on its own has no meaning to
the quantum computer so the pulse is the
thing that will actually cause it to
perform a some sort of quantum
mechanical interaction so we send when
we send the pulse to the qubit it
responds by flipping the state I put a
lot of work into that animation so I
hope you're impressive let's see it one
more time cool all right so it works
take a moment to think about how this
differs from a classical computer so in
a classical computer you have a CPU and
on it it has various accumulators and
circuits and so forth for doing
different types of computations you then
send the data through the CPU so this is
really complete opposite of a quantum
computer where in a quantum computer
that data is what you send in or the
data is what stays rather and then you
send in the program so as opposed to the
data kind of flowing around the computer
you're actually keeping the data in one
place and then sending in the program
by varying the length of the pulse you
can change for instance how far the
state of the qubit moves with a short
pulse it may only fill quarter the way
around
and with a longer pulse you can get it
to do a full rx by instruction so you
can kind of think of the pulse program
almost as like a musical score you need
to know which pulses to play which notes
to play in which order for how long and
how loud and at what frequency and all
these sorts of things so this gets us
kind of to the real crux of the
difficulty of my job in the difficulty
of building software that runs these
corner computers and that is that their
analog by nature so each of these pulse
parameters can be varied in a number of
different ways and they're all analog
parameters so we're trying to take
something that's digital like a like an
X instruction and turn it into something
that a it's the number of real numbers
involved and it's a real challenge for
us on the software engineering side to
actually find these numbers every
parameter is a continuous real number
and performing highly accurate and
numerical calculations to find these
things is obviously incredibly important
and then if that weren't already hard
enough the other challenge for the
software is that these parameters are
not fixed so various changes to the
computers environment including even the
temperature of the air outside will
create noise and affect its operation so
programs that you run in the morning
will look significantly different than
programs that you run in the evening so
this means that the system has to
continuously be going undergoing
recalibration in order to find and
correct the right parameters depending
on the environment so there is an
enormous amount of data being collected
every day about these quantum variables
and their effect on the computer's
accuracy and you know this is kind of
the data mining big interesting problem
that
a lot of software engineers are really
excited about other companies but you
know back when I was at LinkedIn I was
mining information about people and your
relationships and whether you'd respond
to my job invites but and now we're
mining and trying to take in all this
data that's coming out of our our
instruments and trying to match it
against the changes in the environment
in order to keep the computer calibrated
alright so assuming you've managed to
get all that right and you've kept all
these parameters calibrated as changes
to the environment happen you can then
send it to the quantum computer to
execute so our quantum devices like the
one I showed in the picture earlier I
only become superconducting at
incredibly low temperatures just above
absolute zero so therefore they must run
inside a special type of refrigerator
called a dilution refrigerator and you
know when you make these things that
cold obviously presents additional
challenges all that stuff that you saw
in the kind of first picture of our lab
is is all the infrastructure needed to
keep the chip cold and the chip itself
is tiny about the size of a fingernail
but then you end up with these giant
sort of refrigerators and all this extra
instruments just to keep that little
thing cold so assuming that you've got
your pulse program correct and
everything's hooked up and the command
the device is cold enough you can send
it the pulse program and it will
physically realize the program on the
qubits
we're getting computing in particular
emphasizes a special type of conic
programming called hybrid quantum
classical programming so that's where
you can sort of do two things you can
perform cubed operations but then you
can also perform classical operations
like if statements and so forth in order
to kind of modify your program
on-the-fly
now unfortunately for for software
engineers you don't really have a lot of
time to insert any changes into a client
program as it's happening so you know
again back when I back in my old job we
were pretty impressed if a page loaded
within 20 milliseconds but at Righetti
you the qubit decoherence times means
that you have far less than that
to insert any classical instructions
into the program so if you want to do
some pre progress processing in the
middle you really don't even have time
to get back to a CPU and you have to
start looking at specialized hardware
FPGAs and so forth it's also physically
close to the device because even the
travel time to get the information out
of the computer and back in is going to
be in effect when you're trying when
your budget is like a hundred
microseconds all right so we're almost
kind of through the cycle of what
happens behind the scenes when you run a
cloner program so the final step is
obviously to get as someone who's just
submitted upon a program is you want the
results back and we call this step
readout so the analog problem is going
to show up again here and that the data
coming out of the computer unlike in the
classical computer is not going to be
clear-cut between zero and one there is
some inherent accuracy in our inaccuracy
in our instruments there is a bunch of
noise in the environment of course and
so the data that we get out actually
looks doesn't look like straight zeros
and ones it looks more like this and
then we need to do some little bit of
classification on this data to realize
that for instance the the orange is the
zero States and the green
the one-state but other times it's less
clear-cut than this and there's some
ambiguity for in terms of readout
accuracy as to how certain you can be
that a zero is actually a 0 and a 1 is
actually 1 but anyways assuming you end
up with a nice chart like this where the
classification is easily separate
separable you can return the zeros and
ones back to the user alright so that's
it that's the the full cycle of what
goes on behind the scenes at our office
and in terms of software when you write
a quantum program and send it to us and
I'm hopefully that gave you some
indication of the kind of software
challenges at least that we face in
order to make quantum computing a
reality of course you know software
challenges are just one small fraction
of the total challenges required to
build something like this but hopefully
you know I've kind of scratched the
surface of some of the software things
so let's assume you're you'd like to
give this a try
run run some quantum programs for
yourself against our our computers and
have them flow through that entire cycle
you can do that our website if you go to
it we've just redesigned our website so
let us know what you think you can go
get an API key and that'll allow you to
execute quantum programs against our
simulator and it's very easy to get up
and running so - here's some Python code
to get through that entire cycle of
everything I showed you compilation
pulse program physically realizing the
program and then read out that entire
thing only takes about ten lines of code
so here's the Python that you need in
order to do a bell state a couple
imports specify your program using quill
send it to us using the cue connection
or cubm connection which is our
simulator and we'll send you back
the one piece of data or one bit string
for each shot that you've asked for so
in this case we've asked for a bell
state with ten shots we get back 10
pairs of binary numbers representing the
readout for those quantum programs that
were performed and if you get tired of
the simulator and would like to run on
real quantum hardware we can set that up
for you as well so please feel free to
email support
Righetti comm or talk to Ryan here or
email him Ryan Carl at Righetti comm
will get you set up running against some
of our physical devices so you can try
out how your program responds under
realistic noise so what are people in
quantum information using our platform
to do a whole number of things so some
of our users in quantum computers
quantum information are interested in
for instance characterizing the quantum
computers reducing the effective noise
or building more robust layers of
interaction to make quantum computing
more accessible other users are more set
on getting the most out of our existing
quantum computers by pushing on
algorithms that tolerate device noise or
by pushing quantum information along
information theory and computer science
to try and find new uses for quantum
computers so 11 papers in this year
alone have been published using our real
quantum hardware both the 8 qubit and 19
qubit devices many of these users were
either new to quantum chemistry or
economy information however they were
able to take advantage of our software
tools and community software tools such
as open Fermi on to take their ideas
take their take their research and
physically realize it so open Fermi on
is pretty cool it's an electric
structure package for doing vqe which is
a particularly promising one of these
hybrid algorithms and you know we've
we've seen a lot of people this year do
very meaningful work against our
platform
so you know if you're interested in any
of this which I imagine you are
hopefully like I said you can sign up
for free right now in a few minutes to
access our simulator if you'd like to
access the real quantum hardware come
and talk to Ryan or email him and of
course if you're interested in
specifically the software side I'd love
to talk to you there's my twitter and
there's my email so thank you very much
for inviting me here doc you see
yeah
yeah so because you only have well you
have whatever the coherence time is
which is getting better than 20
microseconds lately but you you really
don't want to put a classical computer
any in any step of that so we send the
entire program to some pulse generators
control hardware and then we synchronize
the time across all of these different
pulse generators so there's there's one
per qubit and will synchronize the time
across all these instruments and then
give it an exact start time down to the
nanosecond basically and then the
instrument itself is able to just play
the entire program in real time and be
synchronized with all the other
instruments
so you basically kind of the ant I guess
this short answer to your question is
you're giving the entire prost pulse
program at the beginning it's not
something like where you're going
through a loop and then saying you know
pulsed run pulsed out run you you need
to package up the whole thing at the
beginning send it out synchronize the
time and then trigger the execution
otherwise there's literally no hope of
getting any kind of classical feedback
within that time other questions
and feedback they usually have a decoder
in mind and sometimes a non-trivial and
decoder so we imagined because it has to
be very quick will use either an FPGA or
application-specific chip but you know
for the miss arrow or the North you know
the near term era variation may be using
like that FPGA I mean you hinted towards
it to like using FPGA that could run
your optimizer maybe all the strangers
think that would be like really fast
right if you cut three orders of
magnitude on your your time between your
possible optimizer and your next program
then that would you know really increase
the wall a long time I'll keep running
something's out with this which can take
some time because there's a lot of
samples for now yeah I think I mean I
think the direction that we're going is
that first we'll start out with being
able to kind of program in very
specialized use cases such as error
correction such as fast reset fast reset
is where once you read out a qubit if
you see that it's in the one state you
immediately apply an X pulse and that
will allow it to relax at the zero State
faster than just waiting and that would
allow you to take your shot rate would
be much higher so specialized uses like
air correction rep rate fast reset
rather I imagine we'll see sort of
custom-designed Hardware put in the
fridge or beside the fridge to run those
things and then but then the direction
that we want to go is is general-purpose
classical program where we make no
assumptions in the hardware about
exactly what the classical feedback is
going to be and so quill supports this
at the language level which it has its
you know turn complete it has full set
of classical instructions in
architecture as well but the hardware is
going to need to catch up to be able to
perform kind of arbitrary classical
interventions during the program so you
know these sorts of specialized uses I
can see coming pretty soon but
in order to support the more general
classical case the language supports it
but the hardware will will need to catch
up yeah
very different and really often so each
individual qubit is going to have kind
of its own personality
I guess and each one of them also varies
in our accuracy and our ability to
accurately determine whether something
is a 0 or a 1
so the one that I showed you in the
slide was a particularly nice case we
can measure the readout fidelity by
saying you know basically what's the
likelihood that if you think something
is a zero that it was truly a zero and
you know you can get them figures up in
the high 90s other qubits are not going
to look that nice you'll see those two
kind of big blobs of points overlap a
little bit and then if you end up with a
point that's in the middle you really
don't know whether it's a zero or one
have to worry about just to the
separation control in sewing the fridge
but trouble without the shell
yep
yeah so I think the trend is that these
kind of generic off-the-shelf components
that we that we have been using for
generating the pulses and doing readout
are not going to work in the long term
for for a number of reasons
another reason is just that sometimes
they're too accurate or sometimes
they're not accurate enough so you know
with with quantum computing and with our
pulse programs we care about very
specific things that the original
hardware manufacturers of these kind of
generic devices may not have cared so
much about and one of those would be for
instance the ability to run under low
temperatures so I think really the only
solution at that point is to start
looking at some more customizable parts
Hardware together
yeah
yeah so it has a major effect obviously
any to any additional to qubit gate you
add to the program is going to decrease
the overall program fidelity by you know
some measure of the individual to qubit
gate fidelity and at this point you know
adding adding a handful of these to your
programs is not going to be a good thing
so we're not at the era of kind of
generalized quantum programming yet
people need to ideally be aware of the
connectivity of their device out of our
devices that we have on offer and try
and sort of program around that as
opposed to being Hardware agnostic or
unaware of the device and and relying
entirely on the compiler to give you a
program that would be high fidelity you
can find all the Fidelity's of all our
devices actually on our on our website
and so we have an eight cubic device
which is the current live one and we
will periodically about once a week
update the fidelity's we update the the
readout fidelity the one cubic a
fidelity to cubic a fidelity and the
coherence times and that's all public
you can find that on our website
okay that's a Coker second talk and
thanks Steven again
