Okay.
Great.
All right.
Our first speaker of today, that's not an organizer.
We'll be David, and he's going to tell us about his project,
Fafu-ti, and as you'll probably know this, or you know already,
that basically every quantum project has to have a cue in the name.
This one is no different.
Otherwise, we lose our license to do quantum computing.
And yeah, we'll be telling us about compiling to not just analog computers,
but analog quantum computers.
So, hi, I'm David.
I'm a little bit scared because there are way more people than I expected,
plus I'm speaking first, and I was hoping to have the opportunity to learn many
things from other people who spoke before me.
So, yeah.
And thank you for today, all you about FFu-ti.
So, FFu-ti is an ongoing experiment, more details in a second.
I work for Pascal.
Pascal is a hardware company that deals and deploys QPUs.
We are based in France.
We have offices all over the world.
And we also make open source software for tools, programming languages, libraries, etc.
Oh, pretty good at it, hopefully.
And I need to tell you that we have a community portal,
and we're launching it in a few days.
Thanks for me.
Hi.
I'm officially the open source coordinator for Pascal,
which means that I get to work on many libraries on topics that I do not necessarily understand.
Lots of fun.
Actually, it is. Lots of fun.
But as background, I'm not a quantum computing guy,
which is one more reason where I'm completely afraid and scared that I'm going to make a fool of myself.
That, and I forgot to read my mask.
I'm a system guy, a system programming,
a distributed programming, and a compiler guy.
So I've been contributing to open source for 20 plus years.
I have left a few tracks in a few programming languages, protocols, and open source software.
And so, yeah.
I am going to tell you about some quantum computing things.
Hopefully, I'm going to change your,
the way you view some problems.
I'm not going to introduce you to new quantum concepts
if you are already familiar with quantum computing.
So, what is this all about?
It's about difficulty.
It's an early stage experiment.
It's about compiling.
And it's about some of the lessons learned
trying to develop this compiler for analog quantum computing architectures.
Which means that I'm going to talk about quantum computing at some point.
I think I'm in the right room for that.
So, say hello to the Ising Hamiltonian.
Thank you.
This is, I mean, there are plenty of ways to look at what quantum computing,
including many ways I've not been exposed to,
but that's the way I look at it at the moment.
This is a pretty large matrix.
If you have any cubits, this is a two to the power of n squared matrix.
And it has very interesting properties.
The main interesting property, as far as I'm concerned for this presentation,
is that on a classical computer,
most of the interesting operations,
much all of the interesting operations on this matrix.
I have a time cost that is at least exponential in the number of cubits,
which means that too many cubits,
your computer just cannot execute them.
On the quantum computer, many operations, not all of them,
have a time cost that is polynomial in the number of cubits, probably,
strictly.
Which means that if you have a problem that you can quickly and
realistically encode as this kind of matrix,
you have the ability to run it theoretically,
much faster on the quantum computer than on a computer.
One on a classical computer,
at least if your number n is large.
That is the promise of quantum computing,
one of them.
That's the one I'm interested in at the moment.
But that's why quantum computing might change the world.
So there are two religions,
two schools of thought, at least on quantum computing.
One of them is the digital one,
all the illustrations on the previous presentation,
were about digital quantum computing.
So you have these big matrix,
and you take it by turning it into gates,
gates that are simple transformations.
I'm a compiler guy, I see those gates, I see,
oh well, that's what we call an intermediate representation.
When you compile, you start with source code,
at some point you end up with a machine code.
These gates are one way to simplify the work.
So an intermediate representation between this surface level
language and this machine language.
If you have been following a little bit,
actually, about quantum computing,
there are, there have been many,
a huge number of claims, but quite a few interesting discoveries
related to gates recently.
But one of the difficult gates is,
we're still in this noisy intermediate state quantum stage
at the moment, not all of these hypotheses
have been proven yet in practice.
There is, well, there is the hypothesis
that quantum gates are good for logical
or integer related algorithms,
and possibly not good for other applications.
Again, it's a possibility to hypothesis.
And then you have the other school,
which is analog quantum computing,
in which, basically, instead of going to the gates,
you embrace the fact that everything is noisy,
that you have these big, weird metrics,
and you go for these metrics,
so you have waves, your hypothesis,
but you have a way of a system to deal with.
And there is the hypothesis that maybe this is better
for simulations, machine learning,
and things that do not need exact arithmetics.
But by using analog,
we have a much more complex system.
So the question I'm trying to answer,
and I do not have a definite answer for from it.
The question I'm trying to answer is,
we find a good intermediate representation
that works nicely for analog.
A few limitations about quantum computing.
So first, I mentioned the word probabilistic.
I'm going to mention it again.
This makes things weird,
at least if you come from classical computing.
As I do,
you are never quite sure what you're observing at the end.
Was it, was it just luck or bad luck
that your experiment failed?
And clear.
Also, if you look at how things work,
at the moment we don't know how to do
an if or while or a jump or anything
like a conditional control element
in any kind of circuit,
at least not without wasting most of our students.
And also in classical computing,
there is a circuit called the flip-flop,
which is very convenient,
because you can store one and then you can change it
and store zero, etc.
It's the basics of how you have memory on computers.
To this day, as far as I know,
there is nothing that looks remotely
like that in quantum computing.
So it's a very different universe.
So in a way,
I have a few friends who do low-level GPU programming,
those limitations are not completely
dissimilar to what they have been dealing with
for GPU programming, just weather.
On the other hand,
their most applications,
most interesting applications,
are hybrid applications,
which combine CPU,
CPU, possibly several phases of CPU,
CPU, CPU, CPU, etc.
And of course your CPU,
your CPU has all the loops, has the memory
and is not probabilistic.
If you're a compiler guy,
this is not called hybrid computing.
This is called multi-tier compilation.
Multi-tier compilation is fun.
Yeah.
So,
clefty,
not finished.
Why do we want a compiler?
Because that's the alternative.
This is,
this is machine code as far as I'm concerned.
This is something running on some of the machine.
It's part of the integration test,
because it does our logo,
and I have no clue what it does.
In this materializes an algorithm,
what does it do? Who knows?
But as far as I'm concerned,
that's machine code.
So, we want to get away from machine code as much as possible.
We want to move from source code to machine code,
and usually when you're writing a compiler,
quite often you have a runtime,
for instance, if you're using Python or Java,
you have the garbage collector,
that is part of your runtime,
and ideally you have a machine.
So, not all the work that's done in quantum computing
field has a machine.
As it turns out, we have a machine.
We have actual QPUs, physical ones,
but this computer is running an emulator
that is going to simulate things.
The slides are not running on the emulator.
Compiling, you have your source code.
You're going to go through several intermediate representations.
So, let's start with the source code.
I did not pick the most sophisticated language to start with.
This is just a logical formula.
If I know that A and if I know that A implies B is B true,
I want to be able to compile this
to run it on a quantum architecture.
So, again, not the most sophisticated language in existence,
but there is at least one dev room this morning.
That's dedicated in part to these kind of languages.
So, it's not completely indigloable.
Also, importantly, we have to start somewhere,
and if we can find a good IR for this language,
we can start working towards more complicated languages.
If I have an IR for this, I actually know how to run more complicated things.
So, we're going to transform it.
First, we're going to get rid of the implications
to just have ends, ors, and negations,
and to have an idea of what we want to observe.
Then, second IR, we're going to get rid of the end
and turn it into a system.
We're going to go through this formulation.
It's called three sets. You can find it in every text book on a logical program.
I'm going to use a few variables to fill the scheme,
which may or may not be a good idea, but again, it's an experiment.
Then, you turn it quantum effect, sometimes it's observable.
Then, you turn it into another system,
which basically means the same thing,
but instead of having booleans, you have equality checks.
Then, you turn it into another system,
in which you have maximization instead of solving these equations.
That's the beginning of something called cubo,
if you're involved in quantum computing, you probably have heard of it.
And we want maximization, why?
Because maximization is something that our machine does it pretty well.
This cubo, this is the exact same thing,
but formulated as linear algebra,
which we can then turn by a process that is semi-magical,
basically, proved force at the moment, at least in my experiment.
Into this, which is basically the source code, and laser.
Which is basically the source code for that.
So, we have gone from source code, which was one logical formula.
And we have layout of, in our case, atoms for different
manner of implementing quantum computing, other things,
but for atoms, on a plane, plus some laser stuff.
So, in theory, we can run that.
Can we run that?
So, first step is the compiler.
So, it goes through the first few steps of intermediate for presentations.
And, oh, this is the same matrix we had earlier.
And, I made a mistake with copy and paste.
And then, it is waiting a little bit.
Yes.
So, when I said brute force, the entire time was spent in the brute force.
Here.
Oh, great, quality of 18%.
That's what can go wrong.
So, this is source code.
It's a bit unreadable, but it's basically, sorry, the machine code.
So, it's a bit unreadable, but it's basically why it showed you on the slides earlier.
And, no, let's run it.
So, this is non deterministic.
It doesn't always show something.
That is not a bug.
Actually, it's not a bug in that part.
It doesn't always show something, because sometimes there are just no usable results.
But, if you look at it, so, it gave me, I don't know if you can read this from what you are,
but it gave me solutions that are false.
Which is a bit annoying.
So, earlier this week, I had solutions that were right, but I found that it was a bug.
Well, at this point, I'm awfully confused.
Oh, gosh, what am I doing?
I gave a demo that failed.
What am I going to say when I get back home?
No.
I'm actually not showing something that works in this period of transparency.
Thank you for introducing the concept, because, yeah, we need that.
So, what went wrong?
So, to the best of my understanding, what went wrong is that.
So, this is the metrics we obtained at, I think, the fifth step of intermediate presentations,
and it has 36 numbers.
But, we are trying to get it to compile with six qubits, which may give us 18 parameters,
and a few physical constructs.
We have an impedance mismatch here.
So, naively, I tried to get it to work with some theoretical results that I found in a paper.
Those theoretical results are probably completely true, but don't work for me.
So, we have an impedance mismatch, because we have made a cardinal scene in compiler at some point.
We have an intermediate representation that is more powerful than the final representation,
and we cannot always go from one step to the next step.
So, what can we do?
So, it's an ongoing experiment.
So, there are other versions of cubo, this intermediate representation,
but require more cubits, and that hopefully works better.
I have started experimenting, but I haven't finished yet.
Or, invariant, perhaps we can find something non-cubo that would work.
I have vague intuitions here, but nothing that even remotely looks like an experiment yet.
So, we'll see next here about that.
So, a few last words.
Can we write a compiler?
Well, all of this suggests that, yes, we can probably write a compiler.
I mean, everything works right.
But, we might not have the right AR, I.R. Sorry.
So, maybe it's not entirely validated yet.
But, we can draw a few lessons.
Four one thing.
So, this name I.R. was not sufficient.
Despite the fact that the research papers were talking about it,
were really confident about their applicability.
In some of the cases, it should have worked here.
That's one thing.
Why did it take me so much time to understand the problem?
Because testing a probabilistic system is really complicated.
I don't think that we have a good solution for this yet.
If someone has a good solution and is speaking later today,
I would really, really learn to, I love to hear about this.
Another thing is, so many I.Rs, it's really easy to get lost,
especially since several of them are just numbers.
And, yeah, another thing is, you've seen the big break,
the big pose during compilation.
I actually overdid it because usually it's quicker.
I just increase the number of iterations.
But, this is going to be a problem for big hybrid systems,
in which you'll go from CPU to CPU to CPU to CPU.
Handle the results, produce a new computation, compile again,
to CPU to CPU to CPU to CPU to CPU to CPU.
So this is a problem that we will need to solve as a community at some point.
I have not seen anyone working on that yet, maybe I've just missed the research.
On the other hand, I have good hope for competitors,
because I don't think any of the problems is impossible to solve.
And, having using rest for prototyping is really useful
because of all the invariants that I needed to keep in mind,
having a strong type system really helped.
So, to do replace the cubo demonstrate other compiler frontends,
so other languages than these logical language,
I know how to do it for one or two languages, others I don't know yet.
And, I'm pretty confident that we can use fewer cubo,
or cubo, it's at some layer, maybe not all.
I asked you to remind me to tell you about the community.
Thank you for reminding me.
So, we are launching our community portal in a few days.
It's a good place to have tutorials and events course for collaboration.
We have for our first open source.
We definitely need to get in touch with you,
literally, about that.
And we also provide access to physical,
cubo use and hydrophotone museum innovator.
All the links are on the schedule.
Thank you.