Dear Reader,

I’m writing this while sitting on the train from Montreal to Toronto. Why did I visit Montreal?

To attend IEEE Quantum Week 2024, also known as QCE24!

This was my 3rd Quantum Week and I was looking forward to it! It’s a big conference (~1500 participants) with up to 14 tracks happening simultaneously. So obviously I couldn’t keep track of everything that was going on and my perspective is biased, but I hope this will be useful for some people nonetheless. So here are some of my main takeaways from the conference.

Need for better abstraction hierarchy

Given that we’ve recently published a paper about abstraction hierarchy that I was presenting at the conference, I’ve been vigilant about the topic. However, the need for better abstraction layers and separation of concerns in quantum software was a common theme in many sessions I attended:

  • Quantum Algorithm Design Automation Workshops
  • Keynote by Jay Gambetta
  • Workshop on Intermediate Representations
  • Munich QS Software Stack Workshop
  • Keynote by Margaret Martonosi

I’ll write more about our paper and this problem in general in a separate blogpost, so here I’m just mentioning it as it’s clearly becoming an important topic in the community.

Standardization

Another important topic that was coming up over and over in many sessions and discussions was standardization. This allowed me to learn more about it and refine my view.

There are basically two positions in the community, which seem to be at odds with each other.

Some people say that it’s too early to standardize. We are still experimenting with many different conventions, abstractions, formats and in general ways to write software for quantum computers. The hardware landscape also changes very quickly. If we try to standardize too early, we’ll stifle the progress and we increase the risk of some nasty technology lock-in.

On the other hand, other people say that it’s really hard to collaborate and make progress. Everyone’s software is special in its own way, people are using competing conventions. Even if someone else solved your problem, then they most likely use a different format and different toolset and it might be faster to reproduce their code rather than to integrate with it.

However, after talking with various people it turns out that these two positions can be reconciled. You see, the problem is the word “standard”. When most people hear “standard”, they think “IEEE-level standard, that will take a whole committee and a thousand meetings over 3 years to come up with”. That’s also what I was thinking, but I changed my perspective after I talked with someone from NIST (which is an organization that surely treats standards seriously). She said that “standards” are basically just “agreements” and it’s all about people reaching a consensus rather than necessarily going through a formal committee. Sure, the formal standards also have their place, but in some cases, they’re an overkill.

So if instead of saying “We need standardization” we would start saying “As a community we need to agree on certain things, such as conventions and dataformats”, then I think this is a very different discussion, where we could get many more people on board. I like to use the word “community standard” for such agreements to indicate their informal character.

I’ve been working on such a “community standard” for the format to write fault-tolerant quantum algorithms for resource estimation. If this is something of interest to you, please reach out to me at mstechly@psiquantum.com!

Darpa QB program

In the past, I was involved in DARPA’s Quantum Benchmarking program. For those who don’t know about it, the goal of the program is to do a rigorous search for promising applications of fault-tolerant quantum computers and estimate the resources needed to run them when we finally have these machines. I see this program as pivotal for accelerating the progress in the field as well as guiding policymakers. For me personally, participation in this program has been one of the greatest professional experiences I had.

Therefore, it was a pleasure to see either the program itself (or the research coming out of it) mentioned several times across the conference! For those of you who’re not familiar with it, you can find more information, including the papers and tools that are output of the program here.

QRE workshops

One of the events I’ve organized was a workshop focused on Quantum Resource Estimation. I won’t write a detailed summary similarly as I did last year, so here’s a quick recap.

We had three sessions.

In the “Tools and Methods” session Mariia Mykhailova from Microsoft gave an overview of Azure Quantum Resource Estimator. It was cool to see how this tool became more extensible in the last year. In particular, Mariia showed an example of doing resource estimation for the hardware by Alice & Bob.

Then Arianna Van de Griend presented work by Alexandru Paler and Ioanna Moflic (who unfortunately couldn’t join) about the compilation of really large circuits. Representing circuits as tables in the PostgreSQL database? Wow, this was something new for me!

Lastly, Murphy Niu from UC Santa Barbara presented her work with Daniel Bochen Tan and Craig Gidney on the compilation of lattice surgery operations (e.g. those described in Game of Surface Codes). They took those operations, translated them into the “crazy pipeline diagrams from Craig Gidney’s papers” and then optimized them. Impressive!

Then we had an “Applications and Algorithms” session, where we had:

  • Sophia Simon (University of Toronto): “Superpolynomial improvement in precision for quantum simulations of coupled quantum-classical dynamics”
  • Fionn Malone (Google): “Resource estimation for the quantum computation of stopping power”
  • Amara Katabarwa (Zapata): “Feasibility of accelerating incompressible computational fluid dynamics simulations with fault-tolerant quantum computers”.

I think an important part of these talks was in 2 out of 3 talks, the authors relied heavily on the software tools to perform resource estimation, and not just mathematical analysis. This is important since the constant factors can sometimes be much more important than the theoretical scaling. Actually, Eleanor Rieffel (NASA) made a good comment on this in her keynote – for one algorithm she worked on, the scaling is better, but the threshold for utilizing this gain is \(n=10^{18}\) !

Lastly, we had a presentation of the projects coming from the QRE Challenge that we had organized prior to the workshops by Petra Brčić and Walden Killick. And then a panel with:

  • Matt Harrigan (Google)
  • Antonio Corcoles (IBM)
  • Athena Caesura (PsiQuantum)
  • Neil Gillespie (Riverlane)

lead by Kevin Obenland (MIT LL)

Some highlights from the panel:

  • Making tools amenable to different computational models would be really important. For example, there are cases where counting Clifford operations is important and some, where they aren’t.
  • Our tools need to be able to make use of algorithm structure and not just work on bare circuits.
  • The QRE tools will keep evolving as we get closer to the actual working machine. It’s ok for them to be somewhat rough today, as before we get to the FT computer, a lot of the methods and assumptions will change.
  • In order to make sure that people who are not QC domain experts will not get scared of the outrageous numbers that we produce today, we should accompany them with a clear plan on what we plan to do to bring them down.
  • What we have now can be treated as 1st generation QRE tools, now we see that we’re slowly getting into 2nd generation. Maybe it’s somewhat trivial to say this, but it is a useful framing for me.

How to make things happen

One of the complaints I heard was that there was a lot of NISQ-related activity at the conference and not enough FTQC-related. Indeed – quickly scanning the list of workshops, I found only 3 out of 36 workshops, which were specifically focused on FTQC-related topics: one on Quantum Error Correction (QEC), one on decoding and ours on QRE.

However, this conference is a community effort. If you think a particular topic is important and underrepresented, please propose a session on the topic! It can be a workshop, panel, birds of feather session or something else.

Since I’ve been involved in organizing a few of these already, I could write a blogpost that explains how to approach it – if this would be useful to people, please let me know, either through a comment or e-mail!

Closing

These are some of my main takeaways. I hope this has been an interesting perspective for you. If so, please leave a comment or let me know, cause if no one reads it, I won’t be writing another one next year :)

Have a great day!

Michał