Hi, I'm Alexander.
I'm quite a software tech lead up the scale, and I'm going to talk about a strategy, which
is that I'm no one used myself for, not a laughing master, very sad.
Basically, I'm going to also talk a little bit about the open source ecosystem at the end
and sort of some of the size in that direction, but basically, so I've been working
now three and a half years building one of the software professionally, the first is the
stock-to-cold Q&C, we're just doing pure software, which has its own particular requirements
to say, and then it got merged with the scale of the hardware company to make like a big
full stack, a quantum company, and before that, I was working in high-performance computing
and machine learning.
Today at Pascal, I'm here at the work on the HPC integration topic, combining basically figuring
out how to have quantum computers say a nice future center to do large scale competitions
that have forgotten languages, the libraries, and this analog computing that they were just
talking about, and of course, digital, getting as well.
How did that end up here?
Well, to be honest, I was home alone, and I was making whiskey, and I was seeing the CFP come
out.
At first, I read it and was like, ah, languages, tools, compilation, notification, I just think
this is just too much for me, on a Sunday, and then luckily, I saw the often beaten
tracks topics, lessons learned, insight, fun, visions, and this is more, this is more like it,
more, more, more Sunday appropriate material, and to be honest, the quantum software job
rolled out was presented in the instructor's slides, I think I feel I spend more time
making PowerPoints than any of that, so maybe maybe it is off the beaten track topic,
I guess, indeed, for me, I submitted it, it got accepted, I was like, ah, it's easy enough
to write a proposal, then I had to figure out what to say, that was harder, but I started
with saying, like, just googling, why no one used my software, get some inspiration.
I hit the jackpot in the first or so, it was great, it was actually article by company called
Lemon Learning, they have their software company, they make, let's say, a training tool,
a venture press software, so you're a big enterprise, you buy lots of software, you have
like your custom plugins and digrations, and they're basically the training for that.
I was reading to their list, and I was like, this resonates with me, this is exactly
the feeling I have, I'll say, quantum software, it turns out there's nothing special about it.
Your employees have too many software tools, we do have a lot of us, in quantum
memory thread, there's no added value of them, yes, this is arguably a problem,
practical software training and the spoke training, targeted training to Oste,
particular application or work area where with the users having support,
end up spending at least personally a lot of time and slack off on some of the questions,
and employees of the users don't feel heard, yes, they've told me that, and I try to get back
that, but it turns out that it's just a lot of problems with the software
as for enterprise software. We're going to have a bit of back and forth now digging through
these and looking at some concrete examples. How many mistakes do we really need for quantum
software? Every company in the field has their own, every big research that has their own,
and quite possibly in it, literally everyone has a quantum SDK these days, and I get it,
you're right one, you can put out the press release, you can call your favorite marketing
person, and you get the press release out, and you can say, eh, that doesn't use the K. I've been
there, done that, great. But what's the value at? So referring back to Oste the original slides here,
there's two great resources, there's this Oste of Quantum Software Refo and GitHub,
which basically lists every single or not, every single, but a big chunk of quantum software out there,
it's super long, most of them you've never heard of. You can look out the Uniter Foundation
survey as well, and you'll see that there's only a few that's really being used. So the value
out of most of those are questionable, potentially including some of mine. But let's go back,
take a step back to my first point domestic A. So I was turning the start of Q and Q
and we have an SDK because that's what you do. And I spelled on top of Q and skip, let's say,
this is all, you know, made up code, maybe even made to be worse than it really was, but, you know,
ill for the point. You basically just want to, I mean, you're a software startup, you want to have
your, your PIP, you want to reuse it, and for us, looking just at the back end, for example,
we ended up doing lots of derivatives because, you know, variational algorithms, good for startups,
so you have some derivative calculation, some excitation value, just a run method,
basically different ways of running quantum programs. This is all great. But then,
you're engineering instincts kicking in your figured, you know, I feel it's very, very amateurist.
I should put an abstract based class in there. And you probably would have a local backend that
executes locally and it's emulator, maybe you want to have a remote backend, you know,
adjustment inheritance, maybe even you have like a backend ABC class that, you know,
it's provides the ABC for the backend and you implemented to have, you know, more code we use.
And, you know, you keep on going, you're saying, ah, I should have a bit swing back in a
wave function background. Now, there's different types of result types that you can get in your
quantum computation. And yeah, it makes total sense. You get to reuse some code, you know,
you mostly have your application library somewhere else, it makes total sense, you know, you do
some dynamic import-led magic to do all the imports we are, a string, fantastic.
But it can get worse. You can say, ah, well, I have a partnership with IBM and I have
a partnership with Google. I have a partnership with Regethi, who knows, a partnership with Pascal,
and you end up having this for all the different providers as well. If you're not in the field,
this might look completely arbitrary, but I can assure you this is real. It was getting out of hand,
and it was getting difficult to onboard people on, after it's then, and also for our female
local services. So, but really, really, the onboarding was a big issue here. When we started,
we were like, I don't know, five people, but Napa sky was like over 300. So, onboarding people
in your software is a big, big, big concern. And I think that goes to the entire community,
figuring out how to make your software usable.
So, we talked about one thing first. That was better performance. So, we wrote an
numerical back end in Julia, because Jit compilation, and you know, it's fostering Python great.
We bought 80 GPUs, so we had to use them, make them go fast, did the work. Now, remember,
it was a lot of inheritance back in the past. Inheritance and multiple languages, Jit compilation
is, it gets nasty. And then, the Julia out of this just didn't work well enough. It was too
cumbersome to do the IR generated all the differentiation that Julia is doing. So, we made it a
Python function, and we used the Python out of this engine. And, yeah, this is this ended up
being very much of a bargain we couldn't do anywhere. So, we started from scratch, and it was all
in terms of software. But, started from scratch, that's software ended up being, being released,
open source. We had, we called it cadence in the end, and multiple issues with tackle here.
Another one was just that we were just tired of, you know, doing circuit, circuit,
ad, x, k, circuit, ad, y, gate, whatever, right. So, we were like, oh, we should have a different
syntax, like the syntax is fun. You can do something, you can have a publisher paper.
We need lots of parameters, because, type of work that we're doing, we have some special requirements
there. Also, you see later, what you saw also before, in David's talk, that registers are important
thus, because we're doing entanglement based on the topology of the chip or about mob chip atoms.
Various needs of differentiation. Some of those are, you know, back, back prop type, my machine learning,
differentiation, also like PSR, like the way you do circuit, differentiation, and ad joins,
all the good stuff. And this was a great idea. We, this is basically the, another form
of the Hamiltonian that David was showing before, especially shows how our device operates. You basically
have, we know, we use laser to trap atoms instead of vacuum chamber, and we can manipulate them,
and you can do that in the, you know, X, Y, and Z direction. There's a lot of restrictions,
let's not go into it, but this is basically what the program looks like. And in our main
program interface, called Polster, we expose this amor physics directly, and you end up having to,
you know, talk about the amplitude and detuning, which are the Omega and Delta parameters in
Hamiltonian. Specify the shape of it, face zero, which kind of laser you can be operating on.
This is requires a lot of knowledge. You need to be a physicist to understand that.
And I thought, okay, let's make this more quantum information, theoretical, kind of approach,
and more people can understand it. And if it's right, this works well, except,
so you can get a good buy-in from half the company. I was the half the company that worked with
digital and moved towards analog just to try to approach the hardware. From the half of the company
that works and starts from the hardware and moves upwards, there was no buy-in from this, this,
this didn't work out. I think it's an important lesson. We only listen to, let's say,
half the company when we send this. And for the half of the company that the digital,
there was value added, because they can now run stuff on the device more naturally. But for the
other one, they couldn't, and it wasn't maybe less expressive. As a, it's a meters stage
there. I have the slide that the GPUs to write back. How I spent the year in my life wasted on GPUs.
The algorithm seems to say, we want more performance GPUs. We wrote two backends and
pie torch and jacks. Keyboard count too low. We wrote the tenets of network back and those in
pie torch. Turns out, in this case, they did their work with those people. It's just too small
to really have a speed up with GPU considering the cost of GPU, and if they were tried to install
CUDA, well, these are the first part, well, but, you know, there's a lot of issues there.
So, I'm forwarding less than for me that was just requirements gathering, and also maybe
reaching out to all the people, because users will come at face of requirements, and they will not,
they may not need it. They, they, they hear the words, they see the papers of the groups,
they want that, and in the end, they may not use that. And I think as software engineers,
is our responsibility to push back on those kinds of requirements and try and perhaps to adopt
something else instead. Training is super important. I'm going to skip this slide. Basically,
just the importance of, of documentation of being there and speaking to people,
I think it's, it's super important, and also, I'm going to talk about how I like to try to be
very explicit when helping people skip this. There's, I have a different, interesting story,
but two libraries that we wrote that, that also didn't. Well, and then there might be,
might be successful, but the first version was very clean, you know, clean codes, type code,
dry, written vizofogenous, but the other one researchers were never able to use it, because it
turns out that when they do research, they always deviate slightly from what was known before.
That is their job. They, they have a state of the art. They try to push it by some delta, and
it's actually quite difficult to accommodate for that delta, like, that's light push in your
libraries. So, we're trying out to go from more lean libraries in general, and just to promote
their own business work, we're beginning to push out some things, strategy not yet decided
to ask David's previous speaker. And in other case, that was another library, which was only,
it only became really popular after we started removing features, because users are really smart.
I use as a real smart, they usually have PhD, quantum algorithms, they know what they're doing,
and we should try to let them be smart and not put engineering blocks in their way, because
maybe you think I shouldn't allow this, but then maybe they have a valid reason to ignore
what you think they should be allowed to do enough. Of course, that's a hard, it's hard to balance
that against the here, what's actually a feasible hardware, but I think that's best left for review.
Choosing your technologies is another topic, we had a great testament, look at me later,
that I loved it, because I liked working Julia, because Julia is really nice to write,
if you're a software engineer, and you don't have to buy this code.
It turns out to be a bit harder for the scientists who have a pure science background,
they're not even computational, they're the exact ground. I also wasted a lot of time trying to
deploy this at a customer site, the HE Center, HPC Center, because Julia didn't have the required
compilation to static file. I don't know what's the time when I built the convenience script to schedule
arbitrary jobs and AWS batch for our researchers, because we thought we needed more compute,
and I don't think anyone ever used that, not even a single time, I think someone tried to use that.
I'm going to skip this story, but basically once I neglect some software running in the cloud for
a year, because no one used it, and then all of a sudden people started to submit like 10,000,
50,000 jobs in like a single batch, and it experienced a bit of a bit about that, because it
wasn't been used for a year, basically. It crashed and burned, and we got angry time for images.
Getting the timing right in terms of software is difficult, because maybe what used things people
need, they don't need today. Maybe they do it in the future, but if you don't get a timing right,
that can be hard. I think that's going to be a big issue now that we move towards supernously
hardware, and people are starting to talk about full tolerance will be getting that timing right
and choosing what to work on in order to hit the user's need.
Quickly, some of the assignments, the errors from open source people,
I'd love more modular, reusable blocks that don't depend on me using, say,
just get your own open source framework. We had lots of bugs that I'm sure would have been easy
to catch, had we had like a SDK independent testing, just test cases, basically. It's a
backbone full of non-pile actors with some things. But I think we're getting there. I was
an interesting workshop on Friday with a European Commission where they're going to focus a lot
in the coming years on open source content software. And I think that's it. Thank you.
Any questions?
I have, we actually recently... I started, yes. Yes, I was thinking if I have considered not writing my own
software and trying to reuse other people's software and contribute back.
So, I mean, initially we've followed the man for the industry, which is that a company should have his own SDK and we did it just like it for that.
Press release yay.
We are now integrating more with other people. There was a big announcement in November between IBM and Pascal.
We're working together in Kisket, trying to develop a software stack, aligned with each other.
There's also, we also partners play over Nvidia, and they have a similar effort going on.
As a company that's sold devices to the EuroHPC and the European Commission will be forced to participate in things they will be great.
And also other places, but we are a hardware company.
So, we don't have really well-developed open hardware things yet.
So, that is still like a really big blocker for us.
We need basically some SDK in the middle.
But I like the idea, but it's...
Yeah.
No, it's a good way of getting the point back.
Anyone else?
One of the things you mentioned is about designing software for researchers who want to push a little bit past,
but what you've designed this is early forward.
Do you have any tips for giving that a general?
No, I have no idea. I'm still working on it.
I guess.
If there's any tips for how we can write software, which is designed for letting researchers push past the limits.
Push past what we know so far.
Honestly, I'm still working on it.
The best thing we tried so far was with this cadence library,
where we kind of removed a lot of modifications and restrictions that aren't really needed.
It just makes you feel better.
And we also re-did one of our libraries that was built on top of cadence with the same idea.
Removing basically any kind of check and just trusting the users to do it.
We had a big chunk of bugs to begin with, but by now they're really efficient with it.
And I think they're much happier now that we've removed the bricks.
It's also depends on who you're designing for.
We have 80 90 people in Pascal software now, most of which are experts that
are going to confuse things, and you might want to have them work without any breaks on,
but it's really hard to get into it.
So, working progress.
Anyone else?
I don't know.
If you consider creating a safe version of the program and a safe version of them,
so that like we can install an image for the people who might need them,
and still have them.
If I were considered having the option to turn the breaks on off.
No, maybe slightly, but in reality, no.
Maybe we could, but it's also really hard in Python.
We would usually work in Python.
If you have maybe a compile language, you can have this as a compiler,
you know, a specific compiler pass, but I think it's difficult in my current code days.
We're guarding Rust.
Regarding Rust, there are definitely people in Pascal who would like to move to Rust.
But it will take some time to get there, at least.
You know, it also depends on which level you do Rust, right?
You can do it at the operating system with device.
You can do it at the compiler itself, but then you still have the user interface and
top probably in Python, because that's what the workforce knows.
And yeah, that's it for me.
Thank you very much.