ブログ
27
December
,
2023
Israel Reichental

Classiqプラットフォームにおけるハードウェアに対応した合成

Share the article
Our library

はじめに

古典コンピューティングにおいては、メモリという物理的要素がソフトウェアのパフォーマンスにとって非常に重要です。しかし、多くのアルゴリズム開発者はこうした点を気にせず、プログラミング活動に専念しています。このようなことが可能なのは、業界標準の最適化されたライブラリや自動化ツールが、多くのケースで十分にその負担を肩代わりしてくれるからです。同様に量子アルゴリズムの開発においても、同じような恩恵を受けることが望まれます。量子コンピュータはまだ黎明期にありますが、同じような考え方を取り入れることはできるでしょう。では、一体どのような方法によってでしょうか?それは2つの要素である中間計算を一時的に保存する補助量子(アンシラ)ビットと、メモリの物理的特性である量子ビット間の接続性を考慮することによって可能になります。本ブログ記事では、これらがどのように関係しているかを説明し、Classiqのプラットフォームを使用して最適化を自動化する方法をご紹介します。

概要 

Dmitri Maslovが相対位相トフォリゲートを使用した多重制御量子ゲートの新しい実装を提案した際、彼は論理レベルの指標を他の実装と比較することでその方法の利点を示しました。しかし、その論文では量子ビットの接続パターンは考慮されていないことや、実際に物理空間は3次元にしか広がっておらず、すべての量子ビットが有限次元空間内で他のあらゆる量子ビットにスケーラブルに接続できるわけではないことが述べられています。当然ながら量子アルゴリズム設計の専門家であるMaslovは、ハードウェアが課す要件は明確に認識しています。ここでは、Classiqのプラットフォームを使ってMaslovの発言を検証し、多重制御量子ゲートに対する量子ビット接続性の影響について述べていきます。

まず、多重制御演算について簡単に説明した上で、Classiqライブラリの実装について説明しましょう。次に、量子回路をゲートレベルで設計する際のハードウェアの接続性とその制約について掘り下げます。最後に、Classiqの合成エンジンがハードウェアの接続性に応じて異なる実装を選択する機能について実証します。このような調整は、ハードウェアから得られる低レベル情報が論理レベルでの回路設計を決定する、量子回路の協調設計の一例です。

多重制御演算

多重制御演算は、グローバーのアルゴリズムや算術演算などの標準的な量子アルゴリズムの構成要素です。簡便化のため、多重制御反転演算(MCX)に焦点を当てます。実際のところ、あらゆる多重制御の量子演算は、MCXゲートと1つの制御された量子演算を使って表すことができます(簡単な練習として試してみてください)。

Maslovの実装以外にも、長年にわたって様々なMCXゲートが提案されており、それらは文献やQiskit、TKetのようなオープンソースライブラリで参照できます。これらに共通するパターンは、補助量子ビットの数と回路の深さおよび制御反転(CX)ゲートの数とのトレードオフです。(まれに指数関数的に精密なゲートを必要とする例もありますが、ここでは簡便化のために避けます)。 

では補助量子ビットとは何でしょうか? 補助量子ビットは、量子計算における一時的なメモリストレージとして機能するもので、量子計算の開始時に割り当てられ、終了時に初期状態(未計算状態)に戻ります。補助量子ビットは、他の計算リソースを削減するために必要となることがあります。例えば、回路の深さやCXゲートの数は、特にノイズの多い量子デバイスでは、フィデリティが損なわれ、プログラムの品質に影響を与える可能性があります。

Classiqのライブラリではこれらの異なる実装を組み合わせて(これはまた別のブログ記事でご紹介しましょう)、このトレードオフを利用した一連の回路を構成します。合成エンジンは、ユーザーから与えられた制約に従って実装を選択します。 

ハードウェアの接続性

古典プログラムを設計する際、通常はソフトウェアが動作する物理的なデバイスについては考慮しません。この部分は、中間レベルや低レベルの自動最適化によってバックグラウンドで処理され、専門家によってさらに微調整されます。重要な点として、プロセッサ(CPU)とさまざまなメモリデバイス間の物理的な通信によるオーバーヘッドがあります。オンチップメモリ(キャッシュ)は小さいもののCPUとの距離が近く、メインメモリであるランダムアクセスメモリ(RAM)は離れたところにあります。そのため、キャッシュの利用率はプログラムの性能を決定する上で非常に重要であり、時には計算操作の回数を最小化するよりも重要な意味を持つことがあります。この問題に対処するための具体例として、行列演算のアルゴリズム的実装、ループブロッキングやアンローリングといったコンパイルパス、およびスタック上のメモリとヒープ上のメモリの割り当てに関する検討などがあります。

これに対応できる量子アナログはあるのでしょうか? 量子コンピュータはまだ複雑なメモリアーキテクチャには対応していませんが、補助量子ビットをメモリと見なすことができます。この類似性をさらに説明するためには、コンパイルプロセスの一部としての、ルーティングの概念を理解する必要があります。

多くの量子コンピューティングアーキテクチャ(超伝導量子ビットなど)では、量子ビットは直接接続されていません。例えば、Classiqのプラットフォームから抽出した下記のIBMのEagleプロセッサの接続図をご覧ください。14〜15の量子ビットを垂直に積み重ね、それらを交互の4つの量子ビット層を介して接続することで形成されています。

例えば論理回路ゲート(CXなど)が、青で示した2つのような隣接しない量子ビットの間にあるとしましょう。ゲート演算を行うために、これらの量子ビットを接続する選択された経路に沿ってSWAPゲートを導入し、情報をターゲット量子ビットに伝達します。 

SWAPゲート演算は高コストであり、なんと各SWAPゲートはそれぞれ3つのCXゲートにも相当します! 従って、与えられた論理回路のルーティングステージを最適化することはパフォーマンスにとって非常に重要なのです。残念ながら、ルーティングの最適化はNP困難問題であるため、コンパイルされた回路内のCXゲートの数を事前に計算することはできません。いくつかの発見的なルーティングアルゴリズムは開発されており、文献やオープンソースライブラリで入手可能です。

Classiqによるハードウェアに対応した合成

ここで、次の疑問が浮かんでくることでしょう:ルーティング問題を踏まえると、補助量子ビットを使用することでリターンが減少する可能性はあるのでしょうか?より具体的には、CXゲート数を可能な限り減らすことを目的としたMCXゲートの実装があった場合、この実装は完全に接続されていないハードウェアに対して最適と言えるのでしょうか、それともルーティングのオーバーヘッドによって補助ビットの使用は無駄なものになるのでしょうか?

この疑問に答えるために、Classiqの合成エンジンに30制御キュービットのMCXゲートを構築させてみましょう。基本ゲートをCXとUに調整し、CXゲート数を最適化します。皆さんも試してみてください:

  • まずはAll-to-All接続を合成します。 予想通り、エンジンは最大数の補助量子ビットを使用するMaslov的な実装を選択しました。その結果として得られた回路では、45量子ビット(30制御量子ビットと1ターゲット量子ビットに分割された31機能量子ビットと、14補助量子ビット)を必要とします。 
  • 次に、50量子ビットの1次元最近傍接続パターンを持つ回路に対して同じMCXゲートを生成します。 その結果、今度は論理レベル回路は42量子ビットしか使用しなくなりました。実際のところ、補助量子ビットを多く使いすぎると、量子計算を一時的に保存することで得られる利点よりもルーティングのオーバーヘッドが大きくなってしまいます。

注1:2番目のケースでは、42量子ビットは論理レベル回路を表します。ルーティングアルゴリズムを適用すると、量子ビットの数は増える可能性があります。ここでの重要な違いは、Classiqを使用したことで論理レベルの実装が変更され、結果としてより良い回路が得られたということです。

注2:これは最終的な結論ではなく、将来的にはさらに優れた実装方法が見つかる可能性があります。さらに、プロセス中に適用されるゲートレベルの最適化など、他の要因も最終的な回路に影響を与える可能性があります。とはいえこの例では、補助量子ビットを追加しすぎることによるリターン逓減の挙動を提示しており、これはClassiqの自動合成エンジンを使用して解決されますが、一般的なトラッキングは困難です。 

応用問題として、1次元最近傍ではなく、実際のハードウェア接続を使用してこの挙動を再現してみてください。現在利用可能なアーキテクチャではこのような例を見つけるのは簡単ではありません。それでも、特にマルチコアアーキテクチャを考慮した場合、より複雑なアーキテクチャになればなるほど、その関連性は高まるでしょう。量子ビット数とCXゲート数のトレードオフを示す他の量子ビルディングブロックに、心当たりはありますか?

結論

量子アルゴリズムを設計する際には、ハードウェアの特性を含めて性能を考慮することが重要です。Classiqの合成エンジンを活用することで、開発者は複雑なゲートレベルの最適化に取り組むことなく、モデルのアルゴリズム構造に力を注ぐことができます。Classiqのような自動化ツールの必要性は、量子回路が商用レベルの複雑さに進化し、ハードウェアに依存したトレードオフを示す多くのビルディングブロックを含むようになればなるほど高まるでしょう。Classiqの合成エンジンの概要については、パートIとIIをご覧ください。

最後に、量子ビットの接続性は、パフォーマンス向上のために協調設計を活用するきっかけとなる多くの制約のうちの1つに過ぎません。例えば、回路内のCX層を調整してエラー抑制を行うことができます(こちらを参照)その他の使用例としては、量子ビットに対する古典的制御の制限を考慮することもできるでしょう。

はじめに

古典コンピューティングにおいては、メモリという物理的要素がソフトウェアのパフォーマンスにとって非常に重要です。しかし、多くのアルゴリズム開発者はこうした点を気にせず、プログラミング活動に専念しています。このようなことが可能なのは、業界標準の最適化されたライブラリや自動化ツールが、多くのケースで十分にその負担を肩代わりしてくれるからです。同様に量子アルゴリズムの開発においても、同じような恩恵を受けることが望まれます。量子コンピュータはまだ黎明期にありますが、同じような考え方を取り入れることはできるでしょう。では、一体どのような方法によってでしょうか?それは2つの要素である中間計算を一時的に保存する補助量子(アンシラ)ビットと、メモリの物理的特性である量子ビット間の接続性を考慮することによって可能になります。本ブログ記事では、これらがどのように関係しているかを説明し、Classiqのプラットフォームを使用して最適化を自動化する方法をご紹介します。

概要 

Dmitri Maslovが相対位相トフォリゲートを使用した多重制御量子ゲートの新しい実装を提案した際、彼は論理レベルの指標を他の実装と比較することでその方法の利点を示しました。しかし、その論文では量子ビットの接続パターンは考慮されていないことや、実際に物理空間は3次元にしか広がっておらず、すべての量子ビットが有限次元空間内で他のあらゆる量子ビットにスケーラブルに接続できるわけではないことが述べられています。当然ながら量子アルゴリズム設計の専門家であるMaslovは、ハードウェアが課す要件は明確に認識しています。ここでは、Classiqのプラットフォームを使ってMaslovの発言を検証し、多重制御量子ゲートに対する量子ビット接続性の影響について述べていきます。

まず、多重制御演算について簡単に説明した上で、Classiqライブラリの実装について説明しましょう。次に、量子回路をゲートレベルで設計する際のハードウェアの接続性とその制約について掘り下げます。最後に、Classiqの合成エンジンがハードウェアの接続性に応じて異なる実装を選択する機能について実証します。このような調整は、ハードウェアから得られる低レベル情報が論理レベルでの回路設計を決定する、量子回路の協調設計の一例です。

多重制御演算

多重制御演算は、グローバーのアルゴリズムや算術演算などの標準的な量子アルゴリズムの構成要素です。簡便化のため、多重制御反転演算(MCX)に焦点を当てます。実際のところ、あらゆる多重制御の量子演算は、MCXゲートと1つの制御された量子演算を使って表すことができます(簡単な練習として試してみてください)。

Maslovの実装以外にも、長年にわたって様々なMCXゲートが提案されており、それらは文献やQiskit、TKetのようなオープンソースライブラリで参照できます。これらに共通するパターンは、補助量子ビットの数と回路の深さおよび制御反転(CX)ゲートの数とのトレードオフです。(まれに指数関数的に精密なゲートを必要とする例もありますが、ここでは簡便化のために避けます)。 

では補助量子ビットとは何でしょうか? 補助量子ビットは、量子計算における一時的なメモリストレージとして機能するもので、量子計算の開始時に割り当てられ、終了時に初期状態(未計算状態)に戻ります。補助量子ビットは、他の計算リソースを削減するために必要となることがあります。例えば、回路の深さやCXゲートの数は、特にノイズの多い量子デバイスでは、フィデリティが損なわれ、プログラムの品質に影響を与える可能性があります。

Classiqのライブラリではこれらの異なる実装を組み合わせて(これはまた別のブログ記事でご紹介しましょう)、このトレードオフを利用した一連の回路を構成します。合成エンジンは、ユーザーから与えられた制約に従って実装を選択します。 

ハードウェアの接続性

古典プログラムを設計する際、通常はソフトウェアが動作する物理的なデバイスについては考慮しません。この部分は、中間レベルや低レベルの自動最適化によってバックグラウンドで処理され、専門家によってさらに微調整されます。重要な点として、プロセッサ(CPU)とさまざまなメモリデバイス間の物理的な通信によるオーバーヘッドがあります。オンチップメモリ(キャッシュ)は小さいもののCPUとの距離が近く、メインメモリであるランダムアクセスメモリ(RAM)は離れたところにあります。そのため、キャッシュの利用率はプログラムの性能を決定する上で非常に重要であり、時には計算操作の回数を最小化するよりも重要な意味を持つことがあります。この問題に対処するための具体例として、行列演算のアルゴリズム的実装、ループブロッキングやアンローリングといったコンパイルパス、およびスタック上のメモリとヒープ上のメモリの割り当てに関する検討などがあります。

これに対応できる量子アナログはあるのでしょうか? 量子コンピュータはまだ複雑なメモリアーキテクチャには対応していませんが、補助量子ビットをメモリと見なすことができます。この類似性をさらに説明するためには、コンパイルプロセスの一部としての、ルーティングの概念を理解する必要があります。

多くの量子コンピューティングアーキテクチャ(超伝導量子ビットなど)では、量子ビットは直接接続されていません。例えば、Classiqのプラットフォームから抽出した下記のIBMのEagleプロセッサの接続図をご覧ください。14〜15の量子ビットを垂直に積み重ね、それらを交互の4つの量子ビット層を介して接続することで形成されています。

例えば論理回路ゲート(CXなど)が、青で示した2つのような隣接しない量子ビットの間にあるとしましょう。ゲート演算を行うために、これらの量子ビットを接続する選択された経路に沿ってSWAPゲートを導入し、情報をターゲット量子ビットに伝達します。 

SWAPゲート演算は高コストであり、なんと各SWAPゲートはそれぞれ3つのCXゲートにも相当します! 従って、与えられた論理回路のルーティングステージを最適化することはパフォーマンスにとって非常に重要なのです。残念ながら、ルーティングの最適化はNP困難問題であるため、コンパイルされた回路内のCXゲートの数を事前に計算することはできません。いくつかの発見的なルーティングアルゴリズムは開発されており、文献やオープンソースライブラリで入手可能です。

Classiqによるハードウェアに対応した合成

ここで、次の疑問が浮かんでくることでしょう:ルーティング問題を踏まえると、補助量子ビットを使用することでリターンが減少する可能性はあるのでしょうか?より具体的には、CXゲート数を可能な限り減らすことを目的としたMCXゲートの実装があった場合、この実装は完全に接続されていないハードウェアに対して最適と言えるのでしょうか、それともルーティングのオーバーヘッドによって補助ビットの使用は無駄なものになるのでしょうか?

この疑問に答えるために、Classiqの合成エンジンに30制御キュービットのMCXゲートを構築させてみましょう。基本ゲートをCXとUに調整し、CXゲート数を最適化します。皆さんも試してみてください:

  • まずはAll-to-All接続を合成します。 予想通り、エンジンは最大数の補助量子ビットを使用するMaslov的な実装を選択しました。その結果として得られた回路では、45量子ビット(30制御量子ビットと1ターゲット量子ビットに分割された31機能量子ビットと、14補助量子ビット)を必要とします。 
  • 次に、50量子ビットの1次元最近傍接続パターンを持つ回路に対して同じMCXゲートを生成します。 その結果、今度は論理レベル回路は42量子ビットしか使用しなくなりました。実際のところ、補助量子ビットを多く使いすぎると、量子計算を一時的に保存することで得られる利点よりもルーティングのオーバーヘッドが大きくなってしまいます。

注1:2番目のケースでは、42量子ビットは論理レベル回路を表します。ルーティングアルゴリズムを適用すると、量子ビットの数は増える可能性があります。ここでの重要な違いは、Classiqを使用したことで論理レベルの実装が変更され、結果としてより良い回路が得られたということです。

注2:これは最終的な結論ではなく、将来的にはさらに優れた実装方法が見つかる可能性があります。さらに、プロセス中に適用されるゲートレベルの最適化など、他の要因も最終的な回路に影響を与える可能性があります。とはいえこの例では、補助量子ビットを追加しすぎることによるリターン逓減の挙動を提示しており、これはClassiqの自動合成エンジンを使用して解決されますが、一般的なトラッキングは困難です。 

応用問題として、1次元最近傍ではなく、実際のハードウェア接続を使用してこの挙動を再現してみてください。現在利用可能なアーキテクチャではこのような例を見つけるのは簡単ではありません。それでも、特にマルチコアアーキテクチャを考慮した場合、より複雑なアーキテクチャになればなるほど、その関連性は高まるでしょう。量子ビット数とCXゲート数のトレードオフを示す他の量子ビルディングブロックに、心当たりはありますか?

結論

量子アルゴリズムを設計する際には、ハードウェアの特性を含めて性能を考慮することが重要です。Classiqの合成エンジンを活用することで、開発者は複雑なゲートレベルの最適化に取り組むことなく、モデルのアルゴリズム構造に力を注ぐことができます。Classiqのような自動化ツールの必要性は、量子回路が商用レベルの複雑さに進化し、ハードウェアに依存したトレードオフを示す多くのビルディングブロックを含むようになればなるほど高まるでしょう。Classiqの合成エンジンの概要については、パートIとIIをご覧ください。

最後に、量子ビットの接続性は、パフォーマンス向上のために協調設計を活用するきっかけとなる多くの制約のうちの1つに過ぎません。例えば、回路内のCX層を調整してエラー抑制を行うことができます(こちらを参照)その他の使用例としては、量子ビットに対する古典的制御の制限を考慮することもできるでしょう。

About "The Qubit Guy's Podcast"

Hosted by The Qubit Guy (Yuval Boger, our Chief Marketing Officer), the podcast hosts thought leaders in quantum computing to discuss business and technical questions that impact the quantum computing ecosystem. Our guests provide interesting insights about quantum computer software and algorithm, quantum computer hardware, key applications for quantum computing, market studies of the quantum industry and more.

If you would like to suggest a guest for the podcast, please contact us.

See Also

No items found.

量子ソフトウェア開発を開始

お問い合わせ