異なる量子コンピューティングデバイスをどのように比較する必要がありますか?


15

過去数年間、原理実証、小規模、非フォールトトレラントな量子計算(またはノイズのある中間規模の量子テクノロジー、それらがどのように参照されたか)を実行できるデバイスのデモが盛んに行われました

これについては、Google、Microsoft、Rigetti Computing、Blattのグループなどのグループ(およびおそらく今忘れている他のグループ)が示す超伝導およびイオントラップデバイスを主に参照しています。

これらのデバイスとそれに続くデバイスは、しばしば根本的に異なります(アーキテクチャ、実装が容易/困難なゲート、キュービット数、キュービット間の接続性、コヒーレンスとゲート時間、生成に関して)読み取り機能、ゲート忠実度、最も明白な要因を挙げます)。

一方、プレスリリースや非技術的なニュースでは、「新しいXデバイスには以前よりも多くのキュービットがあるため、非常に強力です」と言うのが一般的です。

量子ビットの数は、これらのデバイスを評価する上で本当に重要な要素ですか?または、代わりに異なるメトリックを使用する必要がありますか?より一般的には、さまざまなデバイスを定性的かつ有意義に比較するために使用できる「単純な」メトリックはありますか?

回答:


5

答えはあなたがそれらを比較している理由に依存すると思います。量子ボリュームのようなものは、エンドユーザーに十分な情報を提供するよりも、デバイスの開発の進捗を定義するのにおそらく適しています。

たとえば、新しいラップトップを購入する場合、おそらくそれらを比較するときは、1つ以上の数字を使用します。同じことが量子プロセッサにも当てはまります。デバイスには多くの異なる側面があります。キュービットの数、接続性、すべての異なる種類のノイズ、測定時間(そして測定結果からのフィードバックが実行可能かどうか)、ゲート動作時間などです。実際に知っておく必要があることを1つ教えてください。実行するプログラムを実行できますか。つまり、常に最も適切な比較になると思います。しかし、それは最もトリッキーでもあります。


14

これは非常に議論されているトピックであり、現時点であなたの質問に対する答えがあるかどうかはわかりません。ただし、IEEE(Institute of Electrical and Electronics Engineers)は、PAR 7131- Quantum Computing Performance Metrics&Performance Benchmarkingの標準を提案しています。

このプロジェクトの目的は、標準化されたパフォーマンスメトリックのセットと、さまざまなタイプの量子コンピューティングハードウェアおよびソフトウェアの速度/パフォーマンスをベンチマークする標準化された方法論を提供し、これらのパフォーマンスメトリックを従来のコンピューターの同一のメトリックと比較して、このドキュメントは、特定のアプリケーションの量子コンピューターの速度を簡単に、確実に、コンピューターのパフォーマンスを比較することができます。

私は現在、Quantum Computing Standards Workgroupの議長を務めており、このPARが最初に提案された理由は、さまざまな量子コンピューティングアーキテクチャを従来のアーキテクチャなどに対してテストするためのドキュメント/標準がないためです。上で見た要因

量子ビット数、量子ビット間の接続性、コヒーレンスとゲート時間、生成と読み出し機能、ゲート忠実度

他のいくつかの要因と同様にすべて含まれています。重要なこととして、我々はソルバーを標準化する方法にも取り組んできました。ベンチマークで見落とされがちなコンポーネント。最適化されていないソルバーは、量子アーキテクチャを従来のアーキテクチャと比較する際に、量子マシンの恩恵を受けることがよくあります。つまり、量子アーキテクチャで実行されるソルバーは、従来のアーキテクチャで実行されるソルバーが最適化されていない場合、常に最適化されます。これにより、量子アーキテクチャに有利な固有のバイアスが生じます。

この規格の開発に参加することに興味がある場合は、私に知らせてください。議論の量子的側面と古典的側面の両方からより多くの人々が関与するほど、より良い私見が得られます。それまでの間、PARはまもなく作業を開始し、他の標準化団体との取り組みを調整して、バイアスのない単一の共通標準が将来のパフォーマンスとベンチマークに対処できるようにします。


非常に興味深い、答えてくれてありがとう。「ソルバーの標準化」とはどういう意味ですか?「ソルバー」と言うとき、コンパイラー、つまり量子ゲート分解を行うアルゴリズムを意味しますか?
glS

1
嬉しいことに、「ソルバー」とは、各システムで実行される数学的コードを意味します。コンパイラ、数学ソフトウェア、スタンドアロンプ​​ログラム、またはソフトウェアライブラリの形式である可能性があります。
whurley

9

あなたが言うように、キュービットの数はそのような測定基準の一部であるべきですが、それはすべてとはほど遠いです。

ただし、2つの異なる完全に異なるデバイス(たとえば、超伝導と線形光学)を比較することは、最も簡単な作業ではありません1

要因

コヒーレンスとゲート時間について質問することは、忠実度とゲート時間について質問することと同等です1。実装がより困難または簡単なゲートは、忠実度に再び影響します。

初期化率、量子ビット/エンタングルメントの生成、読み出し機能などは、全体的な忠実度に影響を与えます。 「十分な忠実度」のアイデア))。

アーキテクチャに関しては、より多くのマクロアーキテクチャ(qRAMなど)には、読み出し時間などの独自の標準とベンチマークがあります。「オンデマンドで読み出しますか?」そしてもちろん、忠実。

より多くのマイクロアーキテクチャは、接続という同じ概念の下で説明できます。

別の、しばしば無視されるメトリックは、使用される電力/リソースです。

全体的に、これはこのリストをわずかに絞り込んだかもしれませんが、それでもかなりの量の比較を含むリストです。同じ方法を使用するさまざまなデバイスを比較することは、(現在の技術レベルでは)単純なことでもないため、キュービット数が多いプロセッサーは忠実度が低いことがよくあります2

量子量

ありがたいことに、IBMの少数の人々が上記を使用し(使用電力とアーキテクチャを除く)、「量子ビット数」よりも少し有用なものを定義し、それを量子ボリュームと呼びました。これで、ランダムなペアの2 量子ビットは、最初に実効エラー率を定義し、 ϵeff、デバイスと同じエラーを生成するために他の点では完全なシステムで必要なゲートエラーを考慮することによって。これには、接続性が低い場合はSWAPを使用し、実装可能なゲートの数が少ない場合はSolovay-Kitaev風の方法を使用する必要があります。システムに「高速測定とフィードバック」およびその他の適切な方法がある場合、テレポーテーションを使用することでこれに対抗します。

量子ビットの総数について n 「アクティブなキュービット」の数を最大化すること、 n、量子体積は

VQ=最大nn[n1ϵeffn]2

もちろん、私たちは科学のポイントを超えてエンジニアリングに移行したいと考えています。そのためには、標準3が必要です。Whurleyの回答で詳述されているように、これは現在計画中です。

ただし、そのようなリスト間の比較は簡単ではないため、Quantum Awesomenessなど、より主観的な方法が常に存在します。この場合、ゲームの楽しみはプロセッサの性能に依存します4


1この特定のケースでは、1つの例として、光子がデコヒーリングしないため、実現状態が理想状態への良好な近似でなくなる前に、時間の長さまたはゲート数について尋ねるように適応する必要があります。忠実度、または忠実度とゲート時間を求めているだけです

2少なくともこれを試してみましたが、これでさえ最も楽しいタスクではありません

3 XKCD 927とは異なり、最初の

4筆者の意見では、プロセッサがどれほど優れているかを知るのに素晴らしいアイデアであり、役に立つ一方で、そのようなゲームであるプロセッサが他のプロセッサより優れているというのは、あるプロセッサが実際に優れているかどうかを判断するには少し主観的すぎるということです別の


6

IBMは、単一の数値でゲートモデルマシンのパワーを定量化する量子ボリュームこれも参照)のアイデアを推進しています。IBMの前に、Rigettiから総量子係数を定義する試みがありました。アプリケーションのデバイスの有用性の観点から、私たちが望むものをキャプチャするかどうかは不明です。量子体積のようなものは、至高の実験を念頭に置いて設計されているようです。私は、メトリックが本当にアプリケーション固有であるべきだと思うように傾いています。サンプリングのために、この作業ではqBASスコアを使用することを提案しました。

量子アニーリングおよび類似のアナログアプローチの場合、コミュニティは解決までの時間に同意しているようですとバリエーションにです。繰り返しますが、アプリケーションの詳細です。

コミュニティはメトリクスの定義に取り組んでおり、2018年には、さまざまなデバイスで同じ問題が実際に実行されることを期待しています(経験的比較)。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.