Well, thank you everyone for sticking around to the last talk.
I'll try to keep things relatively short and we can all get on our way to whatever is
coming after this.
So, yeah, I'm going to talk about the Unitary Compiler Collection which is a technically
yet-to-be-released project, so this is a bit of a sneak preview.
The GitHub is public, but we haven't like officially kind of put it out there, so this
is kind of the first getting a first preview.
So this is the team that's been working on it.
This is our fun logo.
There's a sticker over here for it if you want to take one.
Jordan has been leading this project, unfortunately they cannot be here, but yeah, this
is props to the team.
So let's go over what's in the name, so Unitary Compiler Collection.
So Unitary because Unitary matrices and Unitary operators are the things that under like
quantum mechanics, the things that we operate on in quantum computation, and then compilers
are things that translate code from usually a higher level of abstraction to a lower level
of abstraction, and just a note here on terminology in quantum, the word transpilers often
used, or maybe a gate optimizer or something, and usually these things are used when the
level of abstraction is roughly equivalent, so if you're taking a circuit and optimizing
it, and we'll go over an example of that, and then a collection, a group of things.
The idea here is that we don't want to necessarily be the only ones developing things like
transpiler passes because there's only so much that a limited group of people can do,
and also every application of quantum computation may need a different particular compiler
pass to make the problem more efficient.
Obviously, what's in the name is reminiscent of GCC, the GNU Compiler Collection, and
taking a lot of inspiration from the classical compiler infrastructure that's been built
over the past 50 years, and there's already a lot of things happening in that area, but
yeah, obviously want to take away a lot of lessons from things learned in that development.
So first let's just talk about what is a quantum compiler, or maybe in this instance
this is going to be something we're going to do a transpilation, and then a compilation
as well.
So we've seen a bunch of quantum circuits already in today's talks, and so we're
going to think about what are some operations that we can do on a circuit that looks
like this to reduce the gate count, reduce the depth of the circuit, and ultimately,
run on the quantum computer.
We want our circuits to be as short as possible, because they'll run faster, they'll
be less opportunities for errors to occur, and so we get more accurate results.
And errors are generally something that happen a lot more on quantum computers than
they do on classical computers.
When we do classical compilers, we just want to make things fast, and error correction is
a thing, but a lot lower rate of errors on the classical computer than a quantum computer.
So let's zoom in to these two gates.
Let's just say for a sake of example, that there are two RZ gates, and they're very similar
type of gate, but they have a different angle that's parameterizing them.
We can take that, we can compile that into a single gate where the argument or the angle
that you're rotating your cube bit by is the sum of those two angles that you are doing
previously.
Okay, that's a very simple one that's like a people optimization, but these are things
that you can't take into account, and you'd rather do that rotation in one operation rather
than do a rotation, and then take the next step, and then do another rotation.
Okay, so now we've compiled, we've made our circuit just a little bit shorter.
Now let's look over here at these three operations.
Let's say in this example, that we have a C0, and then we have two Z gates.
So the C0 operation is the control not, and a little bit of mathematics, you know, you
just massage the matrices a little bit, will show you that you can actually just do one
Z on the target cube it before the C0, and that's equivalent to doing two Zs, basically
the Z propagates through the C0 in such a way where instead of doing two Zs, you can
do one.
One gate reduction, wonderful.
Okay, so we've done that.
Those are just, again, some examples of maybe what people would call people optimizations.
They're just a nice little trick, basically.
And now let's say you're ready to take this circuit, and you want to go run it on some
QPU on some quantum hardware.
Most quantum hardware does not have a three-cube gate, and so whatever classical software
that you use to generate the circuit, you know, maybe doesn't know that, and maybe you
probably don't want it to know what the hardware actually looks like.
You want it to generate something, and then you compile.
So then let's say, for example, a common three-cube gate is the controlled control not
gate, and you want to say, okay, the computer can't do that, so I need to decompose it
into operations that the computer can do.
Okay, and there is a nice decomposition of the controlled control not or the topple
gate into single-cube gates and two-cube gates, but it's really, really big.
So it introduces a whole lot of new gates and a new, and new operations into your circuit.
Okay, so now we're getting this idea that like, we did this, we did this decomposition,
and now you might want to redo some of the optimizations that you've had previously
because maybe this had a margin actually can join in this operation, or maybe there
is a gate here that it cancels with, and you want to do some analysis after you do decomposition.
But let's say you go about doing that, you do another compilation pass, and there's one other
thing, which is let's say you're running on a machine with limited connectivity in the
qubits.
So right now we're introducing an operation that touches qubit one and qubit three, but what
if those two qubits on the device are not actually connected, not actually connected, not
actually connected in such a way where you can do a two-cube operation between them.
Then you need to introduce swaps, or you need to rearrange the qubits so that the ones that
you're acting on are, they actually have some physical coupling on the quantum computer.
So now there's no operations between qubit one and qubit three, everything is just between
one and two and two and three.
So we've satisfied what's called like the coupling map constraint, which is sometimes
referred to as like qubit routing, qubit mapping, these kind of things.
So you can see all the problems that we're dealing with are very intertwined in that you
may want to do one and then go back and do an optimization pass and then do another and
then optimization pass.
So it's not very trivial.
Okay, so that's our quick example of doing quantum circuit compilation.
That's like the overall goal that you see is working towards and so why are we building
a new tool?
We've heard a lot about a lot of the existing tools that are out there.
So let's take a look at what the ecosystem looks like and highly incomplete picture.
There's like 20 more blocks here of companies with their own specific tooling mostly and
Google has a circuit and they transpile down to their QPUs and IBM as Kiske and they have
a transpiler or a compiler down to their hardware and basically every company is doing this
because the tools that are extremely useful just don't exist for everyone.
And this creates a problem, oh, and there is chasm and we've heard a little bit about that.
There is chasm which kind of goes to everyone but not everyone has full buy-in as to using
chasm to be an intermediate representation.
And so it's important to look here like what's so good about classical compilers, what
have they enabled and what should we be drawing from them?
So there is a question previously about like, oh, you know the diagram that Harshit should
previously has this network and in order to compile from one you take this path on a graph and
someone asked about like a hub and spoke model and that's very much like intimately related to
in classical compilers one thing you can have or when running classical code you can have maybe you have
whatever language you have then you want to run to different back ends and you can support a direct pipe to each
one of those instructions at architectures but this is very intensive because then you need
a connection between every language and every back end which is one a lot of code and two
it's a lot of maintenance that needs to be kept up and as something changes on the instructions
at architecture you need to maintain every one of these n times m connections.
So you know obviously one thing that's been learned in in classical compilers is that if you
have a standardized intermediate representation that the compiler can operate on and do most of the
optimizations on then you only need to maintain you know like the rust to LLVM IR pipe and then
all the optimizations can just happen on that which is a much conceptually simpler and you know
produces the amount of work and maintenance that needs to go into like this whole infrastructure that we need to
build.
Okay so that's the motivation behind UCC how do I install it it's the Python package she
pip install it and then using it right now we support these four however you define your circuit
and it's just the call to UCC.com pile.
We've made it to be very extensible so if you want to do a custom optimization pass or
something these are the default passes that happen when you run UCC just names.
If you want to define a custom pass let's say you want to do some fancy LLVD composition
of you know your unitaries you basically just make a new class and you inherit from something
like a transformation pass a lot of what we built so far is is basically extensions of
kizkik because the kizkik compiler is quite good and quite performant and we want to plug
in other compilers to it to see like or you know as we've been doing to you know see if we
draw for multiple different places how does can we get performance gain.
So here's just some positive how it performs generally what you want to be looking at here is
like this is compiled gate count so you want lower as you can see the compiler that we've
introduced UCC is performant with everyone else and everyone basically does most of the same things
so you know we still need a lot of compiler research to you know continue pushing down gate counts
but yeah we're competitive with everyone else but this is a very new project we need lots of
new ideas the compiler infrastructure for quantum is is relatively lacking as everyone has heard
today like everyone has their own tooling and there's not a ton of collaboration between
between the companies between the silos of information so yeah here's our repo we have
some documentation but we need yeah we need people using it we need people testing it out and so
yeah if you have a quantum workload please just check it out and then just the last thing a
little bit of advertisement for alessandra and i both work for the unitary foundation if anything
that you saw today inspired you to want to work on quantum software the unitary foundation gives
micro grants to people who are doing this no strings attached it's $4,000 and it's generally
for things that are open source community projects you know whether you're developing a chat we
had given a micro grant to the talk that we saw previously about quantum type language it's a
short application and yeah so you can go here unitary dot foundation slash grants and get some more
information and yeah please check it out with that thank you all again for coming for today
yeah I forget what the QR code is I'm pretty sure it's too our repository but
you skated find out sweet well that's uh that's all for for a quantum computing devroom for
for 2025 yeah thanks everyone for your participation
yeah