はじめに
いろんな量子コンピュータが出過ぎてて、選ぶのが大変なので、１つ書いたらいろんなのに対応したり、自動的に割り振ってもらいたいです。参考になる論文があるのでみてみます。
オークリッジ国立研究所
オークリッジ国立研究所（オークリッジこくりつけんきゅうじょ、英：Oak Ridge National Laboratory、ORNL）は、アメリカ合衆国エネルギー省の管轄下でテネシー大学とバテル記念研究所が運営する科学技術に関する国立研究所。テネシー州オークリッジ（ノックスビル近郊）にある。基礎研究から応用の研究開発まで、多方面にわたって活動している。クリーンで豊富なエネルギーの研究、自然環境の保全の研究、安全保障に関する研究などである。
エネルギー省以外からの業務も請け負っており、同位体の生成、情報管理、技術的プログラムマネジメントなどの研究や、他の研究組織への研究や技術的な援助を提供している。
XACC
こちらの論文を見てみます。
A Language and Hardware Independent Approach to Quantum-Classical
Computing
A. J. McCaskey1,2
, E. F. Dumitrescu1,3
, D. Liakh1,4
, M. Chen5,6
, W. Feng6
, T. S. Humble1,3,7
1Quantum Computing Institute, Oak Ridge National Laboratory, Oak Ridge, Tennessee, USA
2Computer Science and Mathematics Division, Oak Ridge National Laboratory, Oak Ridge, TN 37831, USA
3Computational Sciences and Engineering Division, Oak Ridge National Laboratory, Oak Ridge, TN 37831, USA
4Oak Ridge Leadership Computing Facility, Scientific Computing, Oak Ridge National Laboratory, Oak Ridge,
Tennessee, USA
5Department of Physics, Virginia Tech, Blacksburg, VA, USA
6Department of Computer Science, Virginia Tech, Blacksburg, VA, USA
7Bredesen Center for Interdisciplinary Research, University of Tennessee, Knoxville, Tennessee, USA
概要
google翻訳
ヘテロジニアスハイパフォーマンスコンピューティング（HPC）システムは、特殊なコプロセッサを慎重に使用することで特定のワークロードを高速化する新しいアーキテクチャを提供します。将来の科学計算のための有望なアーキテクチャアプローチは、量子処理ユニット（QPU）を統合する異種HPCシステムによって提供されます。この目的のために、我々はXACC（eXtreme-scale ACCelerator） - 標準またはHPCソフトウェアワークフロー内で量子加速を可能にするプログラミングモデルおよびソフトウェアフレームワーク - を提示する。 XACCは、基盤となる量子コンピューティングハードウェアから独立したコプロセッサマシンモデルに従うため、統一されたアプリケーションプログラミングインターフェイスを介してさまざまなQPUタイプで量子プログラムを定義および実行できます。さらに、XACCは、多相低レベルの中間表現、および言語に依存しない量子プログラミングを可能にする拡張可能なコンパイラフロントエンドを定義しているため、量子プログラミングランドスケープ全体での統合と相互運用性を促進します。この研究では、ハードウェアと言語に依存しないアプローチを可能にするソフトウェアアーキテクチャを定義し、ゲートとアニーリングベースの量子プログラムのコンパイルと実行を含む例示的な例を通して、量子計算モデルの範囲にわたってその有用性を示します。
基本的には量子コンピュータが多彩にあるので、それらを使いこなすのに統一されたプログラミングインターフェイスから意識しないで使いこなすためのアプローチを研究しています。もちろんゲートとアニーリングベースの量子プログラミングを網羅します。
コプロセッサあるいはコ・プロセッサ（英: coprocessor / co-processor, 副処理装置あるいは補助プロセッサ）とは、CPU（中央演算処理装置）などの計算機システム内で主要な役割を果たす汎用プロセッサに対して、一部の処理の補助や代行をする集積回路のことである。通例、CPUの負荷を軽減し、システム全体の性能を向上することを目的とする。CPUとソフトウェアによる実装・実行形態では時間がかかりすぎるような処理を、専用ハードウェア上で高速に実行する「ハードウェアアクセラレーション」が可能となる。
"co-"は「共同の」「共通の」あるいは「副」「補助の」といった意味を持つ英語の接頭辞であり、他にもco-worker（同僚）、co-pilot（副操縦士）やco-factor（補因子）などの多数の用例がある。
https://ja.wikipedia.org/wiki/%E3%82%B3%E3%83%97%E3%83%AD%E3%82%BB%E3%83%83%E3%82%B5
はじめに
HPCと量子コンピュータを統合することは科学計算においても量子シミュレーションをはじめとした種々の計算において意味を持つ一方で、多くの方式が出てきているので、それらを統合する必要がある。
堅牢なアプリケーションベンチマークおよびプログラムの検証と検証を促進するために、量子ハードウェアの可変性を処理するための柔軟な古典+量子プログラミングモデルと統合ソフトウェアフレームワークを提供することが必要となっている。
ORNLは量子計算装置をアクセラレータベースの実行モデルに統合するプログラミングモデルと拡張可能なコンパイラフレームワークを提示します。 eXtreme-scale ACCelerator（XACC）フレームワークは、量子言語とハードウェアの相互運用性を可能にすることによって、堅牢で移植性の高いQPU高速化アプリケーションプログラミング用に設計されています。 XACCは、従来のプログラミング言語と量子プログラミング言語の両方で構成されるハイブリッドプログラムのコンパイルを可能にするインターフェイスと抽象化を定義します。
量子古典ハイブリッド
将来的な量子汎用計算の一方で、近年主流として考えられているのが量子古典ハイブリッドの量子シミュレーションなどの比較的エラーがあっても計算ができるような部類の計算です。
これまで考えられてきたような量子汎用計算に特化した量子コンパイラの他に、量子古典ハイブリッドに特化し、ハードウェアを選ばないようなコンパイラが必要とされいる。
ORNLは近い将来の量子ハードウェア実行とプログラミングモデルに関連した欠点に対処しようとしているので、古典的コプロセッサ計算モデルの拡張を通して量子と古典的計算の統合を可能にする。多種多様な重要で実用的な量子プログラミングワークフローステップに拡張可能なモデルフレームワークを提供を通じて、量子コンピューティングモデル、言語、そして物理的（仮想）ハードウェアタイプにわたって機能する、真に統合された量子コンパイラと実行フレームワークを提供することができます。ORNLの努力は、量子コードの移植性を高めることを目的としています
プラットフォーム＆メモリモデル
google翻訳
XACCは、シリアルアクセラレーション-量子コンピューティングと、量子加速を用いた超並列分散型高性能コンピューティングの両方を容易にするように設計されているため、ホストCPUコンポーネントの濃度は1対多（1 .. *）です。 ＨＰＣアプリケーションで利用可能な多数のコアに対応する所与のハイブリッド実行の一部として、１つまたは複数のホストＣＰＵを有することができる。同様に、複数の量子コプロセッサを含む計算を検討することができる。近い将来、これはQPUインフラストラクチャ要件のためにありそうもないですが、適度なハードウェアの進歩を考えると、古典的な異種コンピューティングのGPUの場合のように、適度なサイズのQPUのコレクションが複数の計算ノードで利用可能になるでしょう。したがって、アクセラレータシステムの基数も1対多（1 .. *）です。
このプラットフォームモデルでは、複数のアクセラレータにアクセスできる複数の古典的なスレッドを含めることができます。 XACCメモリモデルにより、クライアント側のアプリケーションは、ビットレジスタをモデル化し、測定結果のアンサンブルを格納するAcceleratorBufferの概念を通じて、量子実行結果を確実に取得できます。クライアント（ホストCPU）は、実行時にアクセラレータシステムに渡されるAcceleratorBufferのインスタンスを作成します。すべての測定結果を追跡し、それらをAcceleratorBufferに保存するのはアクセラレータシステムの責任です。クライアントは実行プロセスを通して作成されたAcceleratorBufferハンドルを参照し続けるので、実行後に含まれるデータは、期待値やその他の統計的な関心量を計算するために後処理することができ、ハイブリッド計算の残りに影響を与えます。
AcceleratorBufferっていいですね。
全体の構成は、
・HostCPU
・Accelerator
・AcceleratorBuffer
で構成されます。
ホストCPU（クライアント）
メインとなるのはHostCPUです。HostのCPUは主となります。これが全ての起点です。
アクセラレータ（サーバー）
HostCPUから直近に設置されたチップに直接ローカルでアクセスするか、リモート経由でアクセスするかでアクセラレータに命令を投げます。アクセラレータに投げる命令は基本的に現在のNear Termの量子コンピュータではハイブリッド計算のためある程度の予想がつきますので、その形式で作ることになりそうです。
アクセラレータは通常はQPUと記述され、IBMの場合は、
```
auto qpu = xacc::getAccelerator("ibm");
```
D-Waveの場合には、
```
auto qpu = xacc::getAccelerator("dwave");
```
のように記述されます。
QPUはQuantum Processor Unitの略で、演算を司り、
QCUはQuantum Control Unitの略で、QPUと外部とのやりとりを司ります。
QREGはQuantum Registerで、量子ビットの値を格納しているということになりそうです。
参考論文
参考（Q言語）
Q言語（Q Language）とは2番目に実装された命令型量子プログラミング言語である。Q言語はC++の拡張として実装された。Q言語は基礎クラスQopから派生したQHadamard、QFourier、QNot、QSwapのような基本的な量子オペレーションのためのクラスを提供する。新たなオペレータはC++のクラスメカニズムを用いて定義される。
量子メモリはQregクラスを用いて表現される。
```
Qreg x1; // 初期値0の1キュービット quantum register。
Qreg x2(2,0); // 初期値0の2キュービット quantum register。
```
アクセラレータバッファ
プロジェクトが始まる際には、HostCPUはアクセラレータバッファを作成し、これを共有します。
HostCPUからおもにQPUであるアクセラレータへ命令が飛ぶと主にQPUはコヒーレンスタイム内で計算を行います。
計算結果は01のバイナリの値で量子ビット数だけ得られますので、これを測定結果としてアクセラレータバッファに格納します。
HostCPUは演算の内容によってはアクセラレータバッファを読み込み参照し、計算結果をもとに次の計算を指令するか、計算をやめるかなどします。
VQE
VQEは量子変分アルゴリズムで、エルミート行列からなるハミルトニアンを持ちますが、そのハミルトニアンの固有値を求めます。エルミート行列は項ごとにユニタリ行列に分解されパラメータ付きでそれぞれがアクセラレータで都度計算され、計算が終わるごとにアクセラレータバッファに格納されます。パラメータによってアクセラレータの結果は異なりますので、その計算結果を持って、HostCPUで計算が実行され、再度パラメータ変更をしてアクセラレータに投げるか、一定の条件を満たして計算が終了するかという感じになるかと思います。
量子計算部分は複数台あれば並列化できますし、その中にGPUのような別のアクセラレータがシミュレータで含まれていたりしても大丈夫かと思います。
プログラミングモデル
google翻訳
XACCは6つの主要な概念を定義します：
（1）アクセラレータ中間表現、（2）量子カーネル、（3）中間表現上の変換 （4）コンパイラ、（5）アクセラレータ、および（6）プログラム。
これらの概念は、計算タスクを付加された量子加速器にオフロードするための表現的APIを可能にします。クライアントは、GPU用のOpenCLまたはCUDAと同様の方法で、量子カーネルソースコード表現を介して量子アルゴリズムを表現します。これらのカーネルは、有効なコンパイラ実装が存在する任意の量子プログラミング言語で量子アルゴリズムを表現することができ、それによって多種多様なプログラミング手法および技法（高レベルおよび低レベルのプログラムによる抽象化）を可能にする。コンパイラは、ソースカーネルを、ハードウェアに依存するプログラム解析と独立したプログラム解析、変換、および最適化を可能にするコア中間表現にマッピングします。この一般的に変換または最適化された表現は、次にハードウェア固有のアセンブリコードにマッピングされ、利用可能な物理または仮想ハードウェアインスタンスで実行されます。
知らないなりにがんばってみます。上部のモデルで重要なのは、「中間表現」、「関数」、「命令」がメインでそれらの相互関係が重要とのこと。（文言があってるかはわかりません。。。）コンパイラが中間表現のインスタンスを作成し、アクセラレータは中間表現を含む関数を実行します。
データを中間表現で表現することで複数フォーマットへの変換処理を効率化することを手助けできるので、多数の種類のマシンがあっても中間表現に落とし込むことによりその後のマシンに処理を割り振ることができそうです。
XACCの中間用言は、次の4つの主な要件に準拠するように設計されているようです。
(1)IRは操作可能なメモリ内表現とAPIを提供するべき
(2)IRはディスク上のファイル表現に対して持続可能であるべき
(3)読み取り可能なアセンブリのような表現
(4)IRはグラフ表現を提供するべき
命令インターフェイス
XACC IRの基礎となる命令インターフェイス。
命令は一意の名前を持ち、操作されたアクセラレータキュービットを参照します。
命令は1つまたは複数の量子ビットで動作。
命令はパラメータ化することもできます - 各命令はオプションでfloat、double、complex、int、またはstring型の1つ以上のInstructionParameterを追跡できます。
関数インターフェイス
関数インターフェイスはそれ自体が命令を含む命令インターフェースの派生物です。この命令/関数の組み合わせは部分と全体の階層をモデル化する一般的なソフトウェアデザインの実装のようです。
この辺りはもっと既存の計算機の仕組みを理解するべきのようです。。。
XACCモデルは、コンパイルされたプログラムをノードとしての関数インスタンスとリーフとしての命令インスタンスを持つツリーとしてモデル化するようです。この辺りは比較的一般的な方法みたいで、既存のLLVMのアーキテクチャとかを参照すると理解しやすいようですので、勉強会などでも取り上げてみたいなと思います。
XACCは関数のコンテナとして機能するIRインタフェースを定義しています。 IRは、それらの関数をアセンブリのような人間が読める形式の文字列とグラフデータ構造の両方にマッピングすることを可能にする公開されたAPIと共に、関数インスタンスのリストを含みます。デジタル化計算の場合、グラフは量子回路をモデル化し、プログラムの変換と解析に便利なデータ構造を提供します。
量子アニーリングの場合、グラフ構造は、量子計算のための機械レベルの命令を形成するイジングハミルトニアンおよびスケジューリングパラメータをモデル化することができる。ディスク上の表現を提供するために、IRインタフェースは、読み込みと書き込みにそれぞれファイルパスを使用するloadメソッドとpersistメソッドを公開します。このようにして、特定のカーネルのセットから生成されたIRインスタンスを永続化して再利用することができ、早い時間またはジャストインタイムでのコンパイルが可能になります。
中間表現（IR）
中間表現（ちゅうかんひょうげん、英: Intermediate Representation、IR）は、コンピュータがデータをクロスプラットフォームで扱うために使用されるデータ構造の表現である。クロスプラットフォームで扱うため以外にも、さまざまな目的のために使用される。
中間表現を用いたデータの抽象化はコンピューティング分野では一般的な手法である。異なるプラットフォームで同等の情報を保持するデータを異なるフォーマットで扱う場合に、データを中間表現で表現することで複数フォーマットへの変換処理を効率化することを手助けできる、というのは、この手法の利点（あるいは応用）のひとつである。
https://ja.wikipedia.org/wiki/%E4%B8%AD%E9%96%93%E8%A1%A8%E7%8F%BE
Google翻訳
利用可能な幅広いアクセラレータとプログラミング言語（組み込み型またはスタンドアロン型）にわたって相互運用性とプログラム可能性を促進するには、理解しやすく操作しやすい低レベルのプログラム表現が必要です。実例は、さまざまな高級古典的プログラミング言語（C、C ++、Objective-C、Fortranなど）を共通の中間表現（IR）にマッピングするLLVMコンパイラー・インフラストラクチャーにあります。IRは、効率的なハードウェア固有の実行可能コードを生成するために、ハードウェア（依存および独立）分析および最適化を実行するために使用されます。
量子計算のための標準的なIRは広範囲のプログラミングツールを可能にし、彼らの研究と応用に最も適した方法で彼らのドメイン特有のアルゴリズムをプログラムすることの利益を初期のユーザに提供するべきです。今日まで、多くの異なる量子計算モデル（例えば、断熱的、ゲート）にわたることができる量子計算用の統一された中間表現の開発に関する努力はなかった。現在利用可能なコンパイラツールは、回路レベルのプログラム式を取り、それらをハードウェア固有の量子アセンブリ（ＱＡＳＭ）言語にマッピングし、フォーマットおよび文法が異なるＱＡＳＭ表現を提供することによって様々な努力をする。
さまざまな量子アクセラレータの種類にまたがってサポートする多相の拡張可能なインタフェースのセットが強く求められているため、計算モデルやハードウェアの種類にわたる量子コンピューティングのためのリターゲット可能なコンパイラインフラストラクチャが可能になります。このようなインフラストラクチャは、一般的なアセンブリ表現よりもわずかに高い抽象レベルにあるため、複数の高級言語と複数のハードウェアアーキテクチャを統合する統一されたAPIが可能になります。この量子中間表現の目的は、量子プログラムの分析、変換、および最適化のためのアセンブリレベルの言語とAPIを提供することです。
XACCは、プログラミング言語とテクニックを具体的な（物理的または仮想的な）ハードウェア実現と統合した多態IRアーキテクチャを定義します。 XACC IRは、次の4つの主な要件に準拠するように設計されています。
（1）IRは操作可能なメモリ内表現とAPIを提供するべきです。
（2）IRはディスク上のファイル表現に対して持続可能であるべきです
（3）読み取り可能なアセンブリのような表現
（4）IRはグラフ表現を提供するべきです。
IRインターフェースを管理するアーキテクチャーは、UML（Unified Modeling Language）を使用して図2（前述）に示されています。ＸＡＣＣ ＩＲの基礎は命令インターフェースであり、それは実行可能命令（例えば、量子ゲートまたはプログラム）の概念を抽象化する。命令は一意の名前を持ち、操作されたアクセラレータキュービットを参照します。命令は1つまたは複数のキュビットで動作し、古典的な条件付き分岐で使用するために有効または無効にできます。命令はパラメータ化することもできます - 各命令はオプションでfloat、double、complex、int、またはstring型のバリアントデータ構造として表現される1つ以上のInstructionParameterを追跡できます。
重要なことに、InstructionParameterの概念は変分量子アルゴリズムにおける命令の自然な表現を可能にします。それは近い将来のスピードアップのための最も有望な候補のうちの1つです。
次に、XACCは、ソースコードを命令の構成として表現するためのFunctionインターフェイスを定義します。機能インターフェースは、それ自体が命令を含む命令インターフェースの派生物です。この命令/機能の組み合わせは、コンポジットデザインパターン、すなわち部分全体の階層をモデル化する一般的なソフトウェアデザインの実装です。
このパターンを介して、XACCモデルは、コンパイルされたプログラムを、ノードとしてのFunctionインスタンスとリーフとしてのInstructionインスタンスを持つn進ツリーとしてモデル化します（カーネルソースコードとFunction / Instructionツリー間のマッピングを示す図3を参照）。これらのＦｕｎｃｔｉｏｎインスタンスの実行、変換、および最適化は、事前順序木探索によって処理され、それによって各ノードを歩くことは、最初に各子ノードを左から右に歩くことを含む。図3のIRツリーの場合、これはノードが次の順序でアクセスされることを意味します。f→g→i1→j→i2→i3→h→i4ここで、f、g、j、hは関数インスタンス、i1、i2、i3、i4は一般的な命令インスタンスである。
最後に、XACCは関数のコンテナとして機能するIRインタフェースを定義しています。 IRは、それらの関数をアセンブリのような人間が読める形式の文字列とグラフデータ構造の両方にマッピングすることを可能にする公開されたAPIと共に、関数インスタンスのリストを含みます。デジタル化計算の場合、グラフは量子回路をモデル化し、プログラムの変換と解析に便利なデータ構造を提供します。
量子アニーリングの場合、グラフ構造は、量子計算のための機械レベルの命令を形成するイジングハミルトニアンおよびスケジューリングパラメータをモデル化することができる。ディスク上の表現を提供するために、IRインタフェースは、読み込みと書き込みにそれぞれファイルパスを使用するloadメソッドとpersistメソッドを公開します。このようにして、特定のカーネルのセットから生成されたIRインスタンスを永続化して再利用することができ、早い時間またはジャストインタイムでのコンパイルが可能になります。
IRTransformationインターフェイス
コンパイルワークフローの重要な点は、最適化と変換を実装できることです。これは、一般的なものでもハードウェアにも依存する可能性があります。量子プログラムのための量子プログラム変換、最適化、および最適命令スケジューリング技術の開発はここ数年で大きく進歩しており、そのような6つの最適化をその中に組み込むようにXACCを設計しました。
全体的なコンパイルワークフロープログラム操作の目的は、コンパイルされたすべての命令が、最適または最適に近い方法で目的のアクセラレータ上で実行されるようにすることです。最適化と変換を処理するために、XACCはIRTransformationインターフェイスを定義します。このインタフェースは、IRインスタンスを取得し、修正、最適化、またはより一般的に変換されたIRインスタンスを生成するための拡張ポイントを提供します。変換されたＩＲは論理的に等価であり、すなわち理想化されたノイズのない設定で等価な結果を生み出す。
より一般的なＩＲ修正は、Neartermの量子計算に不可欠であるエラー軽減タスクを処理するのに特によく適している。基本的な考え方は、エラーの発生源を減らすために必要に応じて追加情報を収集する新しいIR、または変換されたIRのセットを生成できるということです。この場合、ユーザーが期待した結果を確実に取得できるようにするために、適切な実行後処理メカニズムを用意する必要があります。この状況に対処するために、XACCはIRインスタンスを取り込んで非同型的に変更するIRPreprocessorインスタンスを定義しますが、この変更の詳細を知っているアクセラレータ結果を適宜調整できるAcceleratorBufferPostprocessorインスタンスを返します。このメカニズムの有用性の例は、キュビット測定誤差緩和にあります。それによって、IRインスタンスに測定カーネルを追加するIRPreprocessorを実装することができます。
これらの追加カーネルの実行は、読み出しエラー率を特徴付けるものであり、アクセラレータの結果を修正するために、IRPreprocessorインスタンスによって提供される、対応するAcceleratorBufferPostprocessor実装によって使用されることができます。ノイズのない外挿法および準確率法などの他の緩和手法も、IRの前処理および変換の構成内で処理できます。カーネルソースコードをIRインスタンスにマッピングした後、XACCモデルはIRTransformationsがアクセラレータ実行前にIRインスタンスを変換することを指定します。これらの変換に続いて、すべての要求されたまたはデフォルトのIRPreprocessorsが実行され、実行後に結果のAcceleratorBufferPostprocessorsが結果のAcceleratorBuffersに格納され実行されます。
なんか本格的にいい話になってきました。
アクセラレータ
量子ハードウェア型における避けられない短期間の変動性は、それが相互作用するハードウェアにおいていかなる異種量子古典的プログラミングモデルも拡張可能であることを強いる。 ＸＡＣＣもこれに例外ではなく、したがって物理的および仮想的（すなわちシミュレータ）ＱＰＵバックエンドを注入するためのアクセラレータインターフェースを定義する。
Acceleratorインターフェースは、サブタイプがデバイス上で実行される前に必要な起動手順またはロード手順を処理するための初期化演算子を提供します。これには、カーネルのコンパイルやIR変換に影響を与える可能性がある、接続情報などのハードウェア仕様の検索が含まれます。
アクセラレータは、AcceleratorBufferインスタンスを作成するためのメカニズムを公開します。これは、プログラマにAccelerator測定結果のハンドルを提供するものです。さらに、アクセラレータの実現はgetIRTransformations操作の実装を提供して、論理的にコンパイルされたIRインスタンスに必要な低レベルのハードウェア依存の変換を提供します。最も重要なのは、アクセラレータは、操作対象のAcceleratorBufferと実行対象のカーネルを表すFunctionインスタンスを入力として受け取る実行操作を公開することです。
Acceleratorインタフェースの実現は、これらの入力データ構造を利用して、それらのターゲットハードウェアまたはシミュレータでの実行に影響を与える責任があります。 Acceleratorの実装では、この実行を実行するためにベンダーまたはライブラリが提供するAPIを利用することを目的としています。すべてのexecute実装は、測定結果でAcceleratorBufferを更新する責任があります。このAcceleratorインターフェースの一般性に注意してください。サブクラスは、物理ハードウェアまたは仮想ハードウェアを対象とした実行実装を提供できます。このようにして、我々は、利用可能な量子プログラミング言語が、ハイブリッド量子古典アルゴリズム実行に関する高速フィードバックのためのメカニズムを提供する模擬ハードウェアをターゲットにすることを可能にする。たとえば、アクセラレータ開発者は、さまざまな高性能および特殊なシミュレータの実行実装を提供できます。好ましいシミュレーション方法論がないので、テンソルネットワーク理論によるゲートモデル量子コンピュータシミュレーション、特に行列積状態仮説を利用した波動関数分解を通じて、アクセラレータのデフォルト実装を提供した（Tensor Network Quantum Virtual Machine、TNQVM）。 ）。これにより、ゲートモデルの量子計算をターゲットとするXACCのユーザーは、物理ハードウェア上で実行する前に大きなシステムの量子ビットを調べることができます（上限はシステム内のエンタングルメントのレベルによって異なります）。
カーネル、コンパイラ、プログラミング
XACCは、アクセラレータを対象としたコードが、CUDAまたはOpenCL内のGPUアクセラレーションを対象としたコードと同様の方法で提供されることを要求しています。つまり、コードはスタンドアローンのカーネルだけで表現する必要があります。カーネルは、ビットレジスタに適用されるアクセラレータ操作のプログラム表現です。基本的には、XACCカーネルはCのような関数で表されますが、この関数は最初の引数として、このカーネルが動作するアクセラレータビットレジスタ（qubits）を表すAcceleratorBufferインスタンスをとる必要があります。このようにして、カーネルは従来のコードをアクセラレータ測定結果へのハンドルと結び付けます。
XACCカーネルは戻り型を指定しません。カーネルの操作結果に関するすべての情報は、AcceleratorBufferのビット測定のアンサンブルから収集されます。 XACCのカーネルは、qpuキーワードを使用した従来のライブラリ関数呼び出しと区別する必要があります。このアノテーションは、抽象構文ツリー検索メカニズムを提供することによって、XACCカーネルの静的な事前コンパイルを可能にします。この静的な先取りコンパイラは将来の作業として残します。現在、すべてのXACCコンパイラは実行時に実行されるため、ジャストインタイムコンパイルのみが有効になっています。最後に、カーネルは量子コードの全体的な実行を駆動するカーネル引数をいくつでも取ることができます。これらのパラメータは、前述のInstructionParameterバリアント型としてモデル化されています。これにより、実行時に評価できるパラメータ化されたコンパイル済みIRインスタンスが有効になります。
XACCカーネルの関数本体は、利用可能な任意の言語で表現できます。利用可能な言語は、その言語に対して有効なコンパイラ実装が存在するものです。 Compilerインタフェースアーキテクチャを図2に、その拡張性とXACC IRへの接続を図3に示します。このインタフェースは、カーネルソースコードを入力として受け取り、XACC IRの有効なインスタンスを生成するコンパイルメソッドを提供します。派生コンパイラは、有効なIRインスタンスを返す限り、自由にコンパイルできます。さらに、コンパイル操作ではオプションでターゲットアクセラレータを入力として使用できます。これにより、コンパイル時にハードウェア固有の詳細が表示され、コンパイルの実行方法に影響を与えることができます。このコンパイル拡張ポイントは、高レベルの構成要素を低レベルの量子アセンブリにマッピングするためのメカニズムを提供するため、ドメイン固有のプログラム式をXACC IRにマッピングする量子プログラム分解方法を容易にします。この例としては、分子ハミルトニアンを表現するドメイン固有の言語、およびこのハミルトニアンをJordan-Wigner変換またはBravyi-Kitaev変換を介して量子アセンブリにマッピングする、関連するCompilerの実現があります。
この設計では、コンパイル方法の全体的な拡張性を通じて一般的なゲート分解手法も容易になります。 XACCカーネルとして表現され、ユニタリーをネイティブの低レベルゲートセットに分解するCompiler実装に渡される一般的なユニタリーの表現のためのドメイン固有言語を想像することができます。 XACCコンパイルの概念では、カーネルソースコードのプリプロセッサ拡張ポイントも定義されています。プリプロセッサはコンパイルの前に実行され、入力として解析と処理のためのソースコード、カーネル言語のためのコンパイラリファレンス、そしてターゲットアクセラレータを取ります。このデータを使用して、プリプロセッサはカーネルソース文字列に対して操作を実行し、計算を強化または単純化する修正されたソースコードを生成できます。
プリプロセッサの効用の一例は、量子言語マクロ展開、あるいは所望のアルゴリズムを記述し、そのコード行をそのアルゴリズムのソースコード表現で置き換える特定のキーワードのためのカーネルソースコードの検索でしょう。このように、プリプロセッサは面倒なプログラミング作業を軽減するために使用できます。 XACCコンパイルインフラストラクチャと対話するための第一歩は、プログラムの概念です。プログラムは、カーネルのコンパイルプロセス全体を調整し、コンパイル済みカーネルを目的のアクセラレータ上で実行するための実行可能ファンクタをユーザーに提供します。プログラムは、カーネルのソースコードと対象となるAcceleratorを参照してインスタンス化され、要求されたカーネルプリプロセッサを適用し、正しいCompilerを選択して実行してIRインスタンスを生成し、そしてすべての（またはデフォルト）を実行するbuild（）操作をプログラマに提供します。 IRTransformationsとIRPreprocessor。
最後に、プログラムはターゲットのアクセラレータ上でコンパイルされた関数を実行する実行可能ファンクタを返すgetKernelオペレーションを公開します。 従来のプログラムと量子プログラムの相互作用をリスト1に示します。ユーザーは自分のソースコードをXACCカーネルとして記述し（このカーネルはdoubleパラメーターでパラメーター化されていることに注意）、目的のAcceleratorへの参照またはハンドルを要求し、バッファーを割り当てます。量子ビット。次に、Programオブジェクトがインスタンス化され、ビルド呼び出しを通じてXACCコンパイルワークフローが開始されます。この時点で、適切なコンパイラがソースコードをXACC IRにマッピングし、すべての変換、最適化、およびプリプロセッサが呼び出されて、目的のアクセラレータ上でのユーザ実行を可能にする実行可能ファンクタまたはラムダが提供されます。この実行可能なカーネル参照は、その後、いくつかのパラメータ化されたループの一部として使用され、ハイブリッド量子古典変分アルゴリズムを可能にします。
```:list1
auto src = R"src(__qpu__ foo(AcceleratorBuffer qreg, double theta) {...})src";
auto qpu = xacc::getAccelerator("ibm");
auto buffer = qpu->createBuffer("qreg", 2);
xacc::Program program(qpu, c
program.build();
auto kernel = program.getKernel<double>("foo");
for (auto& theta : {-3.14...3.14}) kernel(buffer, theta);
```
XACCをつかった例
原子の結合エネルギーをXACCをつかって計算する過程をみてみます。結合エネルギーを示すハミルトニアンと呼ばれる式は下記の通りです。これをVQEと呼ばれるアルゴリズムで最小化します。
下記が上記の重水素のカーネル
```
__qpu__ ansatz(AcceleratorBuffer b, double t0) {
X 0
RY(t0) 1
CNOT 1 0
}
__qpu__ z0(AcceleratorBuffer b, double t0) {
ansatz(b,t0)
MEASURE 0 [0]
}
__qpu__ z1(AcceleratorBuffer b, double t0) {
ansatz(b,t0)
MEASURE 1 [1]
}
__qpu__ x0x1(AcceleratorBuffer b, double t0) {
ansatz(b,t0)
H 0
H 1
MEASURE 0 [0]
MEASURE 1 [1]
}
__qpu__ y0y1(AcceleratorBuffer b, double
t0) {
ansatz(b,t0)
RX(1.57079) 0
RX(1.57079) 1
MEASURE 0 [0]
MEASURE 1 [1]
}
```
Google翻訳
ＶＱＥアルゴリズムは、加速器ＱＰＵのキュビットレジスタに符号化されたパラメータ化量子波動関数に関してハミルトニアンの期待値を最適化することによって所与のハミルトニアンの基底状態エネルギーを探索する。システムサイズが大きい場合、波動関数は量子ビットレジスタで簡単に表現できますが、格納するために指数関数的な古典的なリソースを必要とします。この最適化が繰り返されるたびに、QPUは現在の反復パラメータによってパラメータ化された量子回路によって展開され、複数の測定がハミルトニアン項の非通勤集合に対して実行されます。
次いで、期待値が測定サンプルの集合に関して評価され、これらすべての期待値の加重合計が所与のパラメータ化におけるシステムエネルギーを決定する。この最適化は収束するまで続きます。
XACCフレームワークを使用して、QPUに依存しない方法でこのアルゴリズムをプログラムする方法を説明します。まず、QPU上でansatzとして知られる試行波動関数を初期化するカーネルソースコードを定義します。このansatzは、リスト2でqpu ansatz（···）{・・・・}カーネルを使って定義されています。このカーネルは3つの論理演算を実装しています。 ansatzカーネルをビルディングブロックとして使用し、必要に応じて追加のゲートと測定命令を追加して、式1からハミルトニアン項の期待値を評価します。式1のZ0、Z1項はQPU状態に関して評価できます。初期化ansatzの後に、測定命令だけが追加されます。 ＸおよびＹ演算子を含む他の項を評価するために、基底回転の局所的変化、すなわちすべてのＸ演算子についてのアダマールゲートおよびすべてのＹ演算子についてのＸ（π2）回転が適用される。リスト2のXACC量子カーネルのソースコードは、Quilで書かれています。ただし、カーネルはフレームワークでサポートされている任意のゲートモデルの量子言語（OpenQASM、Scaffoldなど）で記述できます。XACC IRは命令インスタンスのn進ツリーとして動作するため、以前に定義されたカーネルは他のカーネルの命令として再利用できます。量子フーリエ変換などの再帰的回路は、このようにして容易に定義することができる。
これらのカーネルをコンパイルして実行するために、図4（a）に示すようにXACC APIを利用します。フレームワークからAcceleratorを要求するユーザーは、目的のAcceleratorに対応する文字列名を指定するだけです。これは、望ましい実装を指す多態性アクセラレータ参照を返します。 TNQVMアクセラレータ上でこのコードを実行すると、単にgetAccelerator文字列引数をtnqvmに変更するだけです。このコードをTNQVM AcceleratorとIBMQX5 16量子ビットQPUで実行した結果を図4（b）に示します。
この実行の生のタイミング情報は、IBM Quantum Experienceのジョブキューで待機したり、リモートHTTPS呼び出しが原因でネットワークが遅延したりする可能性があるため、あまり明快ではありません。ただし、このサンプルプログラムの実行時間の下限は、回路長、測定、およびリフレッシュタイムスケールを考慮することで見積もることができます。並列に実装することができる（この例ではｎ１ ＝ ２、ｎｅ ＝ １）ローカル（エンタングラ）量子ゲートのｎ１（ｅ）層からなる量子プログラムを考える。 ｔｍ ＝ ２μｓの測定時間尺度と共にｔｌ ＝ ２０ｎｓ、ｔｅ ＝ ２００ｎｓの典型的な超伝導ゲート時間スケール、および自然緩和機構によってキュビットレジスタを再初期化するために必要なリフレッシュ時間ｔＲ≒１０ ＊ Ｔ１≒５００μｓを考える。
リスト2の4つのカーネルすべてを評価するのに必要な最小デバイス時間は、1項あたり104サンプルのアンサンブルサイズであると仮定すると、与えられたパラメータθでの各関数評価に対して20秒になります。サンプルレートは並列化によって部分的に軽減することができることに注意してください（将来の10の作業で詳述されるトピック）が、かなりの数のサンプルを必要とするプログラムに対して全体の時間リソースが法外なものになるかもしれません。ノイズの多いコスト関数評価を最適化するために。したがって、量子最適化の大幅なコストを削減するために、量子最適化アルゴリズムのスケーラビリティを向上させることが必要です。
D-Wave素因数分解
XACC IRの多形性を実証するために、ここではD-Wave QPUをターゲットにした簡単な問題のプログラミング例を示します。この例では、リスト1とまったく同じAPI呼び出しと重陽子のデモを利用します（図5（b）を参照）。
具体的には、D-Wave QPUを使用して15を5および3に因数分解することにより、XACC量子アニーリングIR実装（量子アニーリング用の対応する機能および命令サブタイプを使用）の使用法を示します。
QPU、およびXACC APIを使用してQPUをコンパイルして実行するために必要な関連コードを図5に示します（カーネルコードは簡潔にするためにトリミングされています）。 D-Wave量子マシン命令の改行区切りリスト（Ising Hamiltonian係数）として構造化されたカーネルを入力として受け取る、コンパイラ実装、DWQMICompilerを実装しました。コンパイルと実行のワークフローは、リモートでホストされているすべてのD-Waveソルバー（物理リソースと仮想リソース）へのアクセスをユーザーに許可するD-Wave Acceleratorを参照することから始まります。次に、ユーザーはAcceleratorBufferの割り当てを要求します。これにより、D-Wave QPU量子ビット、および実行後に得られたすべてのデータへの参照が与えられます。
次に、アクセラレータとソースコードを参照してプログラムを作成し、ビルド（コンパイル）します。これは、DWQMICompilerワークフローの一部として、マイナーグラフの埋め込みとパラメータ設定のステップを開始します。ユーザーは、得られたデータ（エネルギー、測定ビット列など）をAcceleratorBufferインスタンスに追加するカーネルラムダを実行します。次に、最小エネルギーに対応するビット列を使用して、15の因数の2進表現を再構築できます。
参考
github