WEBVTT

00:00.000 --> 00:07.000
Hi, I'm Alexander.

00:07.000 --> 00:12.880
I'm quite a software tech lead up the scale, and I'm going to talk about a strategy, which

00:12.880 --> 00:19.840
is that I'm no one used myself for, not a laughing master, very sad.

00:19.840 --> 00:25.440
Basically, I'm going to also talk a little bit about the open source ecosystem at the end

00:25.440 --> 00:33.360
and sort of some of the size in that direction, but basically, so I've been working

00:33.360 --> 00:37.840
now three and a half years building one of the software professionally, the first is the

00:37.840 --> 00:44.800
stock-to-cold Q&C, we're just doing pure software, which has its own particular requirements

00:44.800 --> 00:50.080
to say, and then it got merged with the scale of the hardware company to make like a big

00:50.080 --> 00:56.240
full stack, a quantum company, and before that, I was working in high-performance computing

00:56.240 --> 00:58.240
and machine learning.

00:58.240 --> 01:06.880
Today at Pascal, I'm here at the work on the HPC integration topic, combining basically figuring

01:06.880 --> 01:13.440
out how to have quantum computers say a nice future center to do large scale competitions

01:13.520 --> 01:19.680
that have forgotten languages, the libraries, and this analog computing that they were just

01:19.680 --> 01:24.800
talking about, and of course, digital, getting as well.

01:24.800 --> 01:25.800
How did that end up here?

01:25.800 --> 01:32.240
Well, to be honest, I was home alone, and I was making whiskey, and I was seeing the CFP come

01:32.240 --> 01:34.240
out.

01:34.240 --> 01:40.400
At first, I read it and was like, ah, languages, tools, compilation, notification, I just think

01:40.480 --> 01:47.280
this is just too much for me, on a Sunday, and then luckily, I saw the often beaten

01:47.280 --> 01:55.680
tracks topics, lessons learned, insight, fun, visions, and this is more, this is more like it,

01:56.480 --> 02:02.960
more, more, more Sunday appropriate material, and to be honest, the quantum software job

02:02.960 --> 02:08.080
rolled out was presented in the instructor's slides, I think I feel I spend more time

02:08.160 --> 02:14.400
making PowerPoints than any of that, so maybe maybe it is off the beaten track topic,

02:14.400 --> 02:22.400
I guess, indeed, for me, I submitted it, it got accepted, I was like, ah, it's easy enough

02:22.400 --> 02:28.800
to write a proposal, then I had to figure out what to say, that was harder, but I started

02:28.800 --> 02:34.480
with saying, like, just googling, why no one used my software, get some inspiration.

02:34.560 --> 02:42.400
I hit the jackpot in the first or so, it was great, it was actually article by company called

02:42.400 --> 02:49.280
Lemon Learning, they have their software company, they make, let's say, a training tool,

02:49.280 --> 02:53.680
a venture press software, so you're a big enterprise, you buy lots of software, you have

02:53.680 --> 02:58.160
like your custom plugins and digrations, and they're basically the training for that.

02:58.880 --> 03:03.760
I was reading to their list, and I was like, this resonates with me, this is exactly

03:04.080 --> 03:08.640
the feeling I have, I'll say, quantum software, it turns out there's nothing special about it.

03:10.000 --> 03:15.600
Your employees have too many software tools, we do have a lot of us, in quantum

03:15.600 --> 03:22.480
memory thread, there's no added value of them, yes, this is arguably a problem,

03:23.840 --> 03:29.280
practical software training and the spoke training, targeted training to Oste,

03:29.360 --> 03:36.640
particular application or work area where with the users having support,

03:38.480 --> 03:42.320
end up spending at least personally a lot of time and slack off on some of the questions,

03:43.120 --> 03:50.320
and employees of the users don't feel heard, yes, they've told me that, and I try to get back

03:50.320 --> 03:55.440
that, but it turns out that it's just a lot of problems with the software

03:55.440 --> 04:00.960
as for enterprise software. We're going to have a bit of back and forth now digging through

04:00.960 --> 04:08.080
these and looking at some concrete examples. How many mistakes do we really need for quantum

04:08.080 --> 04:14.720
software? Every company in the field has their own, every big research that has their own,

04:14.720 --> 04:20.160
and quite possibly in it, literally everyone has a quantum SDK these days, and I get it,

04:20.160 --> 04:23.440
you're right one, you can put out the press release, you can call your favorite marketing

04:23.440 --> 04:28.960
person, and you get the press release out, and you can say, eh, that doesn't use the K. I've been

04:28.960 --> 04:36.960
there, done that, great. But what's the value at? So referring back to Oste the original slides here,

04:36.960 --> 04:42.880
there's two great resources, there's this Oste of Quantum Software Refo and GitHub,

04:42.880 --> 04:49.360
which basically lists every single or not, every single, but a big chunk of quantum software out there,

04:50.240 --> 04:55.680
it's super long, most of them you've never heard of. You can look out the Uniter Foundation

04:55.680 --> 05:03.760
survey as well, and you'll see that there's only a few that's really being used. So the value

05:03.760 --> 05:11.200
out of most of those are questionable, potentially including some of mine. But let's go back,

05:11.840 --> 05:17.840
take a step back to my first point domestic A. So I was turning the start of Q and Q

05:17.840 --> 05:23.920
and we have an SDK because that's what you do. And I spelled on top of Q and skip, let's say,

05:25.440 --> 05:32.000
this is all, you know, made up code, maybe even made to be worse than it really was, but, you know,

05:32.000 --> 05:37.600
ill for the point. You basically just want to, I mean, you're a software startup, you want to have

05:37.600 --> 05:44.480
your, your PIP, you want to reuse it, and for us, looking just at the back end, for example,

05:44.560 --> 05:50.560
we ended up doing lots of derivatives because, you know, variational algorithms, good for startups,

05:51.440 --> 05:56.320
so you have some derivative calculation, some excitation value, just a run method,

05:57.200 --> 06:04.160
basically different ways of running quantum programs. This is all great. But then,

06:05.200 --> 06:12.640
you're engineering instincts kicking in your figured, you know, I feel it's very, very amateurist.

06:12.720 --> 06:20.960
I should put an abstract based class in there. And you probably would have a local backend that

06:20.960 --> 06:26.800
executes locally and it's emulator, maybe you want to have a remote backend, you know,

06:26.800 --> 06:33.040
adjustment inheritance, maybe even you have like a backend ABC class that, you know,

06:33.040 --> 06:38.960
it's provides the ABC for the backend and you implemented to have, you know, more code we use.

06:39.840 --> 06:46.160
And, you know, you keep on going, you're saying, ah, I should have a bit swing back in a

06:46.160 --> 06:49.520
wave function background. Now, there's different types of result types that you can get in your

06:49.520 --> 06:55.200
quantum computation. And yeah, it makes total sense. You get to reuse some code, you know,

06:55.200 --> 06:59.280
you mostly have your application library somewhere else, it makes total sense, you know, you do

06:59.280 --> 07:06.000
some dynamic import-led magic to do all the imports we are, a string, fantastic.

07:08.960 --> 07:13.680
But it can get worse. You can say, ah, well, I have a partnership with IBM and I have

07:13.680 --> 07:19.120
a partnership with Google. I have a partnership with Regethi, who knows, a partnership with Pascal,

07:19.680 --> 07:27.120
and you end up having this for all the different providers as well. If you're not in the field,

07:27.120 --> 07:33.680
this might look completely arbitrary, but I can assure you this is real. It was getting out of hand,

07:34.320 --> 07:41.120
and it was getting difficult to onboard people on, after it's then, and also for our female

07:41.120 --> 07:47.360
local services. So, but really, really, the onboarding was a big issue here. When we started,

07:47.360 --> 07:53.600
we were like, I don't know, five people, but Napa sky was like over 300. So, onboarding people

07:53.600 --> 07:57.280
in your software is a big, big, big concern. And I think that goes to the entire community,

07:58.880 --> 08:01.280
figuring out how to make your software usable.

08:04.000 --> 08:08.720
So, we talked about one thing first. That was better performance. So, we wrote an

08:08.720 --> 08:14.560
numerical back end in Julia, because Jit compilation, and you know, it's fostering Python great.

08:16.160 --> 08:24.800
We bought 80 GPUs, so we had to use them, make them go fast, did the work. Now, remember,

08:24.800 --> 08:33.120
it was a lot of inheritance back in the past. Inheritance and multiple languages, Jit compilation

08:33.120 --> 08:39.920
is, it gets nasty. And then, the Julia out of this just didn't work well enough. It was too

08:39.920 --> 08:46.480
cumbersome to do the IR generated all the differentiation that Julia is doing. So, we made it a

08:46.480 --> 08:57.040
Python function, and we used the Python out of this engine. And, yeah, this is this ended up

08:57.040 --> 09:02.160
being very much of a bargain we couldn't do anywhere. So, we started from scratch, and it was all

09:02.240 --> 09:08.320
in terms of software. But, started from scratch, that's software ended up being, being released,

09:08.320 --> 09:16.480
open source. We had, we called it cadence in the end, and multiple issues with tackle here.

09:16.480 --> 09:23.520
Another one was just that we were just tired of, you know, doing circuit, circuit,

09:23.520 --> 09:28.640
ad, x, k, circuit, ad, y, gate, whatever, right. So, we were like, oh, we should have a different

09:28.640 --> 09:31.840
syntax, like the syntax is fun. You can do something, you can have a publisher paper.

09:33.440 --> 09:38.720
We need lots of parameters, because, type of work that we're doing, we have some special requirements

09:38.720 --> 09:43.920
there. Also, you see later, what you saw also before, in David's talk, that registers are important

09:43.920 --> 09:49.360
thus, because we're doing entanglement based on the topology of the chip or about mob chip atoms.

09:51.520 --> 09:58.240
Various needs of differentiation. Some of those are, you know, back, back prop type, my machine learning,

09:58.960 --> 10:04.640
differentiation, also like PSR, like the way you do circuit, differentiation, and ad joins,

10:05.440 --> 10:16.160
all the good stuff. And this was a great idea. We, this is basically the, another form

10:16.160 --> 10:22.000
of the Hamiltonian that David was showing before, especially shows how our device operates. You basically

10:22.000 --> 10:27.120
have, we know, we use laser to trap atoms instead of vacuum chamber, and we can manipulate them,

10:27.200 --> 10:33.200
and you can do that in the, you know, X, Y, and Z direction. There's a lot of restrictions,

10:33.200 --> 10:37.840
let's not go into it, but this is basically what the program looks like. And in our main

10:39.040 --> 10:47.600
program interface, called Polster, we expose this amor physics directly, and you end up having to,

10:47.600 --> 10:53.040
you know, talk about the amplitude and detuning, which are the Omega and Delta parameters in

10:53.040 --> 11:02.080
Hamiltonian. Specify the shape of it, face zero, which kind of laser you can be operating on.

11:02.640 --> 11:06.800
This is requires a lot of knowledge. You need to be a physicist to understand that.

11:08.080 --> 11:16.240
And I thought, okay, let's make this more quantum information, theoretical, kind of approach,

11:16.240 --> 11:21.760
and more people can understand it. And if it's right, this works well, except,

11:22.800 --> 11:28.800
so you can get a good buy-in from half the company. I was the half the company that worked with

11:28.800 --> 11:34.880
digital and moved towards analog just to try to approach the hardware. From the half of the company

11:34.880 --> 11:41.440
that works and starts from the hardware and moves upwards, there was no buy-in from this, this,

11:41.440 --> 11:50.720
this didn't work out. I think it's an important lesson. We only listen to, let's say,

11:50.720 --> 12:00.560
half the company when we send this. And for the half of the company that the digital,

12:00.560 --> 12:06.160
there was value added, because they can now run stuff on the device more naturally. But for the

12:06.160 --> 12:16.000
other one, they couldn't, and it wasn't maybe less expressive. As a, it's a meters stage

12:16.000 --> 12:22.400
there. I have the slide that the GPUs to write back. How I spent the year in my life wasted on GPUs.

12:25.120 --> 12:31.680
The algorithm seems to say, we want more performance GPUs. We wrote two backends and

12:31.680 --> 12:37.520
pie torch and jacks. Keyboard count too low. We wrote the tenets of network back and those in

12:37.520 --> 12:47.120
pie torch. Turns out, in this case, they did their work with those people. It's just too small

12:47.120 --> 12:52.960
to really have a speed up with GPU considering the cost of GPU, and if they were tried to install

12:52.960 --> 13:00.000
CUDA, well, these are the first part, well, but, you know, there's a lot of issues there.

13:03.200 --> 13:08.480
So, I'm forwarding less than for me that was just requirements gathering, and also maybe

13:08.480 --> 13:16.800
reaching out to all the people, because users will come at face of requirements, and they will not,

13:17.600 --> 13:21.840
they may not need it. They, they, they hear the words, they see the papers of the groups,

13:21.840 --> 13:29.200
they want that, and in the end, they may not use that. And I think as software engineers,

13:29.200 --> 13:34.800
is our responsibility to push back on those kinds of requirements and try and perhaps to adopt

13:34.800 --> 13:44.160
something else instead. Training is super important. I'm going to skip this slide. Basically,

13:44.560 --> 13:50.640
just the importance of, of documentation of being there and speaking to people,

13:51.360 --> 13:56.000
I think it's, it's super important, and also, I'm going to talk about how I like to try to be

13:56.000 --> 14:03.040
very explicit when helping people skip this. There's, I have a different, interesting story,

14:03.760 --> 14:09.840
but two libraries that we wrote that, that also didn't. Well, and then there might be,

14:10.400 --> 14:16.160
might be successful, but the first version was very clean, you know, clean codes, type code,

14:16.960 --> 14:23.600
dry, written vizofogenous, but the other one researchers were never able to use it, because it

14:23.600 --> 14:29.760
turns out that when they do research, they always deviate slightly from what was known before.

14:29.760 --> 14:35.040
That is their job. They, they have a state of the art. They try to push it by some delta, and

14:36.000 --> 14:41.360
it's actually quite difficult to accommodate for that delta, like, that's light push in your

14:41.360 --> 14:49.840
libraries. So, we're trying out to go from more lean libraries in general, and just to promote

14:49.840 --> 14:57.680
their own business work, we're beginning to push out some things, strategy not yet decided

14:57.680 --> 15:05.200
to ask David's previous speaker. And in other case, that was another library, which was only,

15:05.200 --> 15:11.760
it only became really popular after we started removing features, because users are really smart.

15:11.760 --> 15:18.480
I use as a real smart, they usually have PhD, quantum algorithms, they know what they're doing,

15:19.280 --> 15:26.720
and we should try to let them be smart and not put engineering blocks in their way, because

15:26.720 --> 15:32.240
maybe you think I shouldn't allow this, but then maybe they have a valid reason to ignore

15:32.240 --> 15:38.800
what you think they should be allowed to do enough. Of course, that's a hard, it's hard to balance

15:38.800 --> 15:47.760
that against the here, what's actually a feasible hardware, but I think that's best left for review.

15:48.480 --> 15:56.720
Choosing your technologies is another topic, we had a great testament, look at me later,

15:57.920 --> 16:02.640
that I loved it, because I liked working Julia, because Julia is really nice to write,

16:03.520 --> 16:05.920
if you're a software engineer, and you don't have to buy this code.

16:07.760 --> 16:15.280
It turns out to be a bit harder for the scientists who have a pure science background,

16:15.280 --> 16:23.680
they're not even computational, they're the exact ground. I also wasted a lot of time trying to

16:23.680 --> 16:30.960
deploy this at a customer site, the HE Center, HPC Center, because Julia didn't have the required

16:31.040 --> 16:46.080
compilation to static file. I don't know what's the time when I built the convenience script to schedule

16:46.080 --> 16:51.200
arbitrary jobs and AWS batch for our researchers, because we thought we needed more compute,

16:51.200 --> 16:56.400
and I don't think anyone ever used that, not even a single time, I think someone tried to use that.

17:01.840 --> 17:08.080
I'm going to skip this story, but basically once I neglect some software running in the cloud for

17:08.080 --> 17:13.600
a year, because no one used it, and then all of a sudden people started to submit like 10,000,

17:13.600 --> 17:20.480
50,000 jobs in like a single batch, and it experienced a bit of a bit about that, because it

17:20.480 --> 17:26.240
wasn't been used for a year, basically. It crashed and burned, and we got angry time for images.

17:26.240 --> 17:33.600
Getting the timing right in terms of software is difficult, because maybe what used things people

17:33.600 --> 17:37.840
need, they don't need today. Maybe they do it in the future, but if you don't get a timing right,

17:38.400 --> 17:43.280
that can be hard. I think that's going to be a big issue now that we move towards supernously

17:43.280 --> 17:48.960
hardware, and people are starting to talk about full tolerance will be getting that timing right

17:49.040 --> 17:53.840
and choosing what to work on in order to hit the user's need.

17:55.200 --> 17:58.640
Quickly, some of the assignments, the errors from open source people,

18:00.400 --> 18:07.360
I'd love more modular, reusable blocks that don't depend on me using, say,

18:07.360 --> 18:15.520
just get your own open source framework. We had lots of bugs that I'm sure would have been easy

18:15.520 --> 18:26.560
to catch, had we had like a SDK independent testing, just test cases, basically. It's a

18:26.560 --> 18:32.640
backbone full of non-pile actors with some things. But I think we're getting there. I was

18:32.640 --> 18:38.720
an interesting workshop on Friday with a European Commission where they're going to focus a lot

18:38.800 --> 18:45.920
in the coming years on open source content software. And I think that's it. Thank you.

18:55.120 --> 18:55.920
Any questions?

19:09.520 --> 19:31.760
I have, we actually recently... I started, yes. Yes, I was thinking if I have considered not writing my own

19:31.760 --> 19:36.080
software and trying to reuse other people's software and contribute back.

19:38.720 --> 19:45.720
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.

19:45.720 --> 19:47.720
Press release yay.

19:47.720 --> 19:56.720
We are now integrating more with other people. There was a big announcement in November between IBM and Pascal.

19:56.720 --> 20:04.720
We're working together in Kisket, trying to develop a software stack, aligned with each other.

20:04.720 --> 20:11.720
There's also, we also partners play over Nvidia, and they have a similar effort going on.

20:11.720 --> 20:20.720
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.

20:20.720 --> 20:24.720
And also other places, but we are a hardware company.

20:24.720 --> 20:31.720
So, we don't have really well-developed open hardware things yet.

20:31.720 --> 20:35.720
So, that is still like a really big blocker for us.

20:35.720 --> 20:39.720
We need basically some SDK in the middle.

20:39.720 --> 20:47.720
But I like the idea, but it's...

20:47.720 --> 20:49.720
Yeah.

20:49.720 --> 20:52.720
No, it's a good way of getting the point back.

20:52.720 --> 20:55.720
Anyone else?

20:55.720 --> 21:01.720
One of the things you mentioned is about designing software for researchers who want to push a little bit past,

21:01.720 --> 21:03.720
but what you've designed this is early forward.

21:03.720 --> 21:06.720
Do you have any tips for giving that a general?

21:06.720 --> 21:10.720
No, I have no idea. I'm still working on it.

21:10.720 --> 21:11.720
I guess.

21:11.720 --> 21:21.720
If there's any tips for how we can write software, which is designed for letting researchers push past the limits.

21:21.720 --> 21:23.720
Push past what we know so far.

21:23.720 --> 21:26.720
Honestly, I'm still working on it.

21:26.720 --> 21:30.720
The best thing we tried so far was with this cadence library,

21:30.720 --> 21:38.720
where we kind of removed a lot of modifications and restrictions that aren't really needed.

21:38.720 --> 21:40.720
It just makes you feel better.

21:40.720 --> 21:51.720
And we also re-did one of our libraries that was built on top of cadence with the same idea.

21:51.720 --> 21:57.720
Removing basically any kind of check and just trusting the users to do it.

21:57.720 --> 22:02.720
We had a big chunk of bugs to begin with, but by now they're really efficient with it.

22:02.720 --> 22:09.720
And I think they're much happier now that we've removed the bricks.

22:09.720 --> 22:12.720
It's also depends on who you're designing for.

22:12.720 --> 22:20.720
We have 80 90 people in Pascal software now, most of which are experts that

22:20.720 --> 22:24.720
are going to confuse things, and you might want to have them work without any breaks on,

22:24.720 --> 22:26.720
but it's really hard to get into it.

22:26.720 --> 22:29.720
So, working progress.

22:33.720 --> 22:34.720
Anyone else?

22:34.720 --> 22:35.720
I don't know.

22:35.720 --> 22:40.720
If you consider creating a safe version of the program and a safe version of them,

22:40.720 --> 22:44.720
so that like we can install an image for the people who might need them,

22:44.720 --> 22:46.720
and still have them.

22:46.720 --> 22:52.720
If I were considered having the option to turn the breaks on off.

22:52.720 --> 22:57.720
No, maybe slightly, but in reality, no.

22:57.720 --> 23:02.720
Maybe we could, but it's also really hard in Python.

23:02.720 --> 23:04.720
We would usually work in Python.

23:04.720 --> 23:09.720
If you have maybe a compile language, you can have this as a compiler,

23:09.720 --> 23:15.720
you know, a specific compiler pass, but I think it's difficult in my current code days.

23:15.720 --> 23:20.720
We're guarding Rust.

23:20.720 --> 23:28.720
Regarding Rust, there are definitely people in Pascal who would like to move to Rust.

23:28.720 --> 23:32.720
But it will take some time to get there, at least.

23:32.720 --> 23:36.720
You know, it also depends on which level you do Rust, right?

23:36.720 --> 23:39.720
You can do it at the operating system with device.

23:39.720 --> 23:43.720
You can do it at the compiler itself, but then you still have the user interface and

23:43.720 --> 23:48.720
top probably in Python, because that's what the workforce knows.

23:48.720 --> 23:50.720
And yeah, that's it for me.

23:50.720 --> 23:52.720
Thank you very much.

