マルチコアコンピュータへのアップグレードでLabVIEWプログラムの実行が高速化するか？

LabVIEWプログラムのパフォーマンスを評価する際は、実行時間とメモリ使用率が主な測定基準となります。実行時間とは、一連の命令の処理に要する時間のことで、通常秒で表します。メモリ使用量とは、一連の命令の処理に要するメモリスペースのことで、通常バイトで表します。これらの測定値は、個々のプログラムの性能を示す適切な指標となりますが、特に実行時間が重要です。マルチコアシステムでもう1つ改善されたのが、応答性です。応答性とは、プログラムまたはシステムの入力に対する応答の速さを意味し、必要な動作を実行するために必要な時間の長さを表すものではありません。マルチコアシステムは、複数のコアを利用したマルチタスクにより、応答性が向上します。ただしこの性能の向上が必ずしもプログラムの実行時間の短縮につながるわけではありません。

LabVIEWは、利用可能なコア数を判別し、より多くのスレッドを作成できるよう支援することで、高性能コンピューティングシステムで複数プロセッサを活用するためにプログラムを自動的にスケーリングします。例えば、LabVIEWはオクタルコアコンピュータ上で実行する際、プログラム実行のために8つのスレッドを作成します。

プロセッサ数が増加してクロック速度が同一の場合

シングルコアシステムを、クロック速度が同等のプロセッサユニットを持つマルチコアシステムに置き換えることで、LabVIEWプログラムの実行時間が短縮されます。プログラムの実行速度は、マルチコアコンピュータシステムのコア数に比例して増加 (クアッドコアシステムで4倍の速度など) することが理想的ですが、実際にはスレッドとコアの間での通信オーバーヘッドによってそれよりも多少速度が低下します。対象のLabVIEWプログラムが完全に逐次型であり、単一プロセッサ上で実行されている場合、他のソフトウェアとのプロセッサ共有時間が少なくなるため、プログラム実行時間が改善されます。対象のプログラムが完全に並列的でデータ依存性のない同一規模のタスクで構成されている場合は、ほぼ理想に近い実行時間の向上を実現することができます。

プロセッサ数が増加してクロック速度が低下する場合

シングルコアコンピューティングシステムをクロック速度が遅いプロセッサを使用するマルチコアシステムに置き換えると、LabVIEWプログラムの実行時間の変化を判断する際に曖昧な状況を生み出します。LabVIEWプログラムが完全に逐次的でマルチコアシステムの1つのシングルコアに独占的なアクセスがある場合は、システムの相対するクロック速度とタスクスケジュールによって実行時間が決定され可能性があります。LabVIEWプログラムが完全に並列でデータ依存性のない同一規模のタスクで構成されており、マルチコアマシンのあらゆる使用可能なコアにアクセスできる場合にも、実行時間はシステムの相対するクロック速度とタスクスケジュールに依存します。

メモリスキーム

マルチコアコンピュータシステムのメモリ構成は、通信オーバーヘッドとLabVIEWプログラムの実行速度に影響を与えます。一般的なメモリアーキテクチャには、共有メモリ、分散メモリ、分散共有ハイブリッドメモリがあります。共有メモリシステムでは、すべてのプロセッサからアクセスできる1つのグローバルメモリスペースを使用することで、高速な通信が実現されます。ただし、同じメモリに多くのプロセッサが接続されると、プロセッサとメモリの間の通信に障害が発生します。分散メモリシステムは、各プロセッサ用にローカルメモリスペースを使用し、通信ネットワーク経由でプロセッサ間の通信を行うため、共有メモリシステムに比べプロセッサ間通信の速度は遅くなります。また、両アーキテクチャの利点を活かすため、共有/分散メモリアーキテクチャを採用するシステムもあります。メモリスキームは通信オーバーヘッドに影響を与え、その結果としてあらゆる言語 (LabVIEW、C、Visual Basicなど) で記述されたプログラムの実行速度にも影響を与えます。

プロセッサ間通信

プロセッサの物理的な距離とプロセッサ間接続の品質は、通信オーバーヘッドを介してLabVIEWプログラムの実行速度に影響します。複数のプロセッサが別々のICに搭載されていると、1つのICに搭載されている場合に比べプロセッサ通信の遅延時間が長くなります。その結果通信オーバーヘッドが大きくなるので、LabVIEWプログラムの実行速度も遅くなります。たとえば図1では、左側のデュアルプロセッサシステム (2ソケット) のレイテンシは右側のシングルチップデュアルコアプロセッサよりも増加します。

コードの構成

マルチコアコンピュータでのLabVIEWプログラムの実行時間は、プログラム自体だけでなくそれを実行するコンピュータにも同様に左右されます。プログラムは、マルチコアシステムがもたらす特有の環境のメリットを活用できるよう作成する必要があります。プログラムの並列性の度合いにより、プログラムの実行時間や粒度 (通信に対する演算の比率）、負荷バランスが大きく変わります。既存のGコードの多くは逐次実行向けに作成されています。ただしこのタイプのコードは、データフロープログラミングの性質上並列性を備えています。前述のとおり、一般的なLabVIEWプログラムのストラクチャをシングルコアシステムからマルチコアシステムに移行してテストすると、実行時間が平均で25～35%向上します。ただし、その値は個々のプログラムの性質によって大きく変わります。マルチコアの環境に合わせてLabVIEWプログラムを作成しておくことで、マルチコアシステムにアップグレードした際に大幅な実行時間の短縮を実現することができます。

ハードウェア特有の調整

プログラムを実行するハードウェアを知らない状態では、Gコードを整理して実行速度を上げるのは困難です。マルチコアプログラムを実行するシステムについて知ることで、最高の実行速度を実現することができます。マルチコアシステムでは、システムのコア数がわからない場合、より汎用的なプログラミングテクニックを用いることが必要になります。一般的アプローチを取る場合、多くのマルチコアマシンで実行時間を短縮できますが、特定のシステムでは最大限の実行速度を得られない可能性があります。LabVIEWプログラムをハードウェアごとに調整することは、時間がかかり、常に必要であるとは限りませんが、特定のハードウェアで最大実行速度を得るためには、必要になる場合があります。たとえば、オクタルコアコンピュータシステムを最大限に活用するために、データ並列化やパイプラインのような高度な並列プログラミング手法を使用できます。また、システムのコア数、コアレイアウト (2つのデュアルコア、1つのクアッドコアなど)、接続スキーム、メモリスキーム、既知のバグ情報などから、マルチコアシステムでのプログラムにおける実行時間の最短化を図ることができます。

並列プログラミング手法については、以下を参照してください。

• マルチコア処理の並列プログラミング戦略:データの並列処理
• マルチコア処理の並列プログラミング戦略:タスクの並列処理
• マルチコア処理の並列プログラミング戦略:パイプライン処理

ソフトウェアスタックの準備

ソフトウェアスタックの複数レベルにおいて、並列処理のボトルネックが発生する場合がありますが、C言語など従来型の言語ではこの問題の回避は難しいものがあります。LabVIEWプログラミングの利点の1つとして、これらのボトルネックをあらかじめ排除する「マルチコア対応」ソフトウェアスタックが挙げられます。マルチコアハードウェアでパフォーマンスの向上を実現するために、ソフトウェアスタックがマルチコア対応かどうかを判断するためには、4つの層、すなわち開発ツール、ライブラリ、デバイスドライバ、オペレーティングシステムを評価します。これらの層がマルチコアに対応していない場合、性能の向上を期待することはできません。表1は、LabVIEWのマルチコア対応ソフトウェアスタックを示しています。

マルチコア対応ではないライブラリとドライバ、または複数コア間でタスクの負荷調整を行えないオペレーティングシステムを使用するマルチコアシステムでは、並列LabVIEWプログラムは高速に実行されません。

マルチコアシステムにおけるLabVIEWプログラムの実行速度を予測するためには、いくつかの要素を考慮に入れる必要があります。構成が適切ではないマルチコアシステムにアップグレードしても、LabVIEW外部のハードウェアとソフトウェアの問題により、実行時間が改善されない可能性があります。また、LabVIEWプログラムでストラクチャの問題によって、マルチコアでのパフォーマンスが改善しない場合もあります。LabVIEWは基本的にマルチコア対応であり、直感的なマルチコアプログラミングの機能とサンプルを利用できるため、マルチコアコンピュータシステムへのアップグレード時に考慮するべき要素が最小限に抑えられています。

• LabVIEW関数およびドライバのマルチスレッド機能
  
• LabVIEWでマルチコアプロセッサ用に自動テストアプリケーションを最適化する
• NI LabVIEWの詳細

Linux®は、Linus Torvalds氏の米国およびその他の国における登録商標です。