デザイン・ソリューション：お客様の成功事例 OpenCL を使用したストリーミング・データのマップ／リデュース解析のためのハードウェア・アクセラレーション Syncopated Engineering 社 CEO/Founder, Jim Costabile プロジェクト一般的に、データ解析担当者やアルゴリズム解析開発者は、演算解析として展開する前にデータ解析を検討、精緻化、および最適化するたデザイン・チーム：め、スタティック・データの演算を行って複雑な問題の解を求めます。 Syncopated Engineering 社は、ワイヤレス通信、して発見するプロセスでは、多くの場合、リアルタイムなストリーミ信号処理、およびデータ解析用のソフトウェア・アプリケーションおよびエンベデッド・システムこれは、しばしば、静止データ・アプローチと呼ばれます。この開発ング形式でのダイナミック・データ、つまり移動データ実装では大きのクリエイティブなソリューション・プロバイダーな意味を持つソリューションが生まれます。課題：デザインの課題です。膨大なスタティック・データセットを細かく分割して独立したプロセッサにマッピングし、各プロセッサでデータを解析するマップ／リデュース・アプリケーションは、Hadoop などの業界標準フレームワークによってサポートされています。しかし、スタティック・マップ／リデュース環境から、アプリケーションをデータが流れる環境へのコードの移行は非常に困難です。この変更では、デザインにおける課題は、これらのスタティック・データ解析アーキテクチャからダイナミック・ストリーミング・アーキテクチャへの移行です。スタティック・アーキテクチャとダイナミック・アーキテクチャの基本的なコンピューティング・インフラストラクチャ、解析フレームワーク、およびプログラミング言語は、現在のところ異なっており、データ・ストリームに追従するため、多くの場合、互換性がありません。アクセラレータを使用する必要がありました。アルゴリズム解析開発者は、スタティック・データ解析を開発およびアプリケーション全体を記録し、ハードウェア・ソリューション：マップ／リデュース機能を OpenCL ™ カーネルとしてコーディングすると、基本の OpenCL プラットフォームへの新しいストリーミング・エクステンションを活用し、アプリケーション・コードをほぼ変更せずにハードウェア・アクセラレーションを使用して、CPU 上のスタティック・データ・モデルからストリーミング・モデルに移行できます。検証し、単純で容易な方法によってこの解析をストリーミング解析アーキテクチャに移行できる機能を必要としています。理想的には、ストリーミング・データのスピードに遅れないように高スループット低レイテンシで動作できる、機能的に同等の解析をこの移行プロセスで作成できることです。デザイン・ソリューション現在のスタティック・データ解析向け最先端技術は、Hadoop Map/Reduce ソフトウェア・フレームワークです。 Hadoop Map/Reduce は、汎用コンピュータによる大規模クラスタで、マップ／リデュース並列処理モデルを実装します。一般的に、マップ／リデュース処理には、キー／値の中間ペアを生成するキー／値の入力ペアに対する演算を行うユーザー定義のマッピング機能と、特定の中間キーに関連付けられたすべての中間値をマージして演算を行い、リデュース ( 縮小 ) した出力結果を生成するユーザー定義のリデュース機能が含まれます。入力データを分割し、多数の同一マッピング機能の同時実行で並列処理し、続いて、少数の同一リデュース機能の同時実行で処理を行うデータ並列処理において、このフレームワークは役立ちます。 Hadoop は、Java で記述され、汎用マシンの大規模クラスタにまたがって展開されるスタティック・データ解析フレームワークです。このクラスタのサイズ、重量、および消費電力 (SWAP) フットプリントは、必然的に大きくなります。より高い性能が必要な場合は、SWAP フットプリントが増加しても、汎用マシンをさらに追加する必要があります。ストリーミング・データで同じ解析手法を使用する場合は、まずデータを保存する、つまり、事実上、移動データ・シナリオを静止データ・シナリオに変更するか、ストリーミング解析フレームワークで解析を書き換えるかの 2 つの選択肢があります。デザイン・ソリューション Syncopated Engineering 社のソリューションは、OpenCL ヘテロジニアス並列プログラミング・フレームワークを使用したマップ／リデュース並列処理モデルの実装です。データ解析開発者は、カスタム・マッピングおよびリデュース機能を OpenCL カーネルとして記述し、Syncopated Engineering 社のマップ／リデュース実装を利用して、汎用 CPU アーキテクチャおよび FPGA によるハードウェアで高速化されたヘテロジニアス・コンピューティング・アーキテクチャ上で、スタティックまたはストリーミング・データ解析として、マップ／リデュース・アプリケーションを迅速に実施できます。OpenCL マップ／リデュース・フレームワークのデモのために、 Syncopated Engineering 社は、文書の集合を入力とし、文書ごとに用語または単語の出現頻度を特定し、トピック・プロファイルを使用して文書にスコアを付け、トピックへの関連性の高い文書を特定する文書フィルタリング・アプリケーションを開発しました。技術論文の集合を入力文書セットとして使用し、特定のトピック・プロファイルの作成には文書の要約を使用しました。 2 デザイン・ソリューション動作原理この文書フィルタリング・アプリケーションは、入力文書セットを文書ごとの <term, frequency> ペアの集合に変換する初期化プロセスを含んでいます。ここで、term は文書内のある 1 つの単語、frequency はその文書におけるその単語の出現頻度です。トピック・プロファイラは、文書セットの要約の 1 つについても同じ変換を行います。トピック・プロファイルは <term, weight> ペアとして保存されます。weight は、その用語のプロファイルとの関連性を表します。このアプリケーションでは、文書内の用語がプロファイル内の用語と比較され、文書のトピック・プロファイルとの関連性を示す重み付けがなされたスコアが文書ごとに計算されます。また、メモリ・アクセスのパフォーマンスを向上させるため、文書の用語がトピック・プロファイルに含まれるかどうかがブルーム・フィルタで効率的に判断されます。ブルーム・フィルタは、トピック・プロファイル内のすべての用語についてハッシュ関数を計算し、ハッシュ結果を使用してブルーム・フィルタにビットを設定することで初期化されます。また、文書内の各用語についても同じハッシュ関数が計算され、ブルーム・フィルタと比較されます。ブルーム・フィルタから 0 が返ってきた場合は、トピック・プロファイルにその用語がないことが保証されるので、メモリ・アクセスは必要ありません。ブルーム・フィルタから 1 が返ってきた場合は、そのトピック・プロファイルにおける用語の重みが取得されます。誤った判定により余分なメモリ・アクセスが生じる場合もありますが、結果の全体的な精度に対する影響はありません。この文書フィルタリング・アプリケーションは、マッパおよびリデューサ・カーネルを OpenCL で実装し、 FPGA で実行するマップ／リデュース並列処理アプローチを使用して実装しました。マッパ・カーネルは入力された文書データセットの各用語についてハッシュ関数を計算し、ブルーム・フィルタと比較して、グローバル・メモリに保存されているプロファイルの重みにアクセスします。リデューサ・カーネルは、文書での用語の出現頻度とプロファイルの重みを使用して、文書のスコアを計算します。このマップ／リデュース文書フィルタリング・アプリケーションは、NDRange アプローチを使用したスタティック解析、チャネル化アプローチを使用したスタティック解析、およびチャネル化アプローチを使用したストリーミング解析として、実装しました。 3 デザイン・ソリューション NDRange 実装は、同じ演算を並列実行する多数の動作項目で構成される独立した非同期動作グループに、 OpenCL カーネルを分割します。このアプローチでは、ホストがデバイスのグローバル・メモリにデータセットをロードします。マッパ・カーネルはメモリからデータを読み取り、データを処理してホストに中間結果を返します。ホストは、リデューサ・カーネルが中間結果を処理できるように、デバイスのグローバル・メモリに中間結果を送り返します。次に、リデューサ・カーネルによって処理された最終結果がグローバル・メモリに書き込まれ、ホストに返送されます。これは OpenCL カーネルの標準的な記述アプローチであり、現在の GPU において一般的な超並列 SIMD (Single Instruction Multiple Data) 計算単位アーキテクチャへのマッピングに適しています。 FPGA アーキテクチャはこの SIMD プログラミング・アプローチにも対応していますが、これを使用することが必須ではないため、並列処理実装の柔軟性が高まります。スタティック・データ解析 (NDRange アプローチ) ホスト保存されているデータセットデータセット最終結果中間結果グローバル・メモリ (DIMM1、DIMM2) マッパリデューサ FPGA 4 デザイン・ソリューションチャネル化アプローチでは、カーネル間でデータを直接受け渡し、コストのかかるホストとデバイス・メモリ間の転送を不要にするアルテラのチャネルの概念を利用します。チャネルは、最新の OpenCL 仕様に書き加えられたパイプの概念の上位集合です。アルテラのチャネルは FIFO として実装されるため、カーネル間およびカーネルと外部 I/O 間でデータを直接転送することができます。チャネル化実装では、コードを単純なシングル・スレッド・アプリケーションとして記述します。並列性は、開発者が実装するベクトル・データ型の使用 ( データの並列性 ) や、主にコンパイラにより提供されるループのアンロール ( プログラミングの並列性 ) で利用されます。つまり、チャネル化アプローチは、開発者にとって NDRange アプローチよりも簡明な実装です。外部メモリの読み書きには、追加のヘルパー機能 ( プロデューサおよびコンシューマ・カーネル ) が使用されます。スタティック・データ解析 (チャネル化アプローチ) ホスト保存されているデータセットデータセット最終結果グローバル・メモリ (DIMM1、DIMM2) プロデューサマッパリデューサコンシューマ FPGA 5 デザイン・ソリューション最後にこの文書フィルタリング・アプリケーションを、チャネル化アプローチを使用してデータを直接 FPGA にストリーミングするストリーミング・マップ／リデュース解析としても実装しました。この FPGA には、外部のネットワーク接続経由で文書データセットを受信して処理し、残りの処理カーネルに文書の <term, frequency> ペアを提供する UDP オフロード・エンジンが含まれています。FPGA 内に UDP オフロード・エンジンを含めることで、ユーザー定義のカーネルに使用できるリソースが減るので、このアプローチで達成できる並列性は、前述のアプローチより低くなります。しかし、ホストでのデータセットの収集と保存、およびそれに続く処理のためのデバイスへのデータセットの転送が不要になります。最終結果はホストに返送されて保存されるので、データを大幅に削減でき、データ転送時間とホストで必要なストレージ容量の両方を改善できます。ストリーミング・データ解析 (チャネル化) FPGA データセット UDP オフロード・エンジンプロデューサマッパリデューサコンシューマグローバル・メモリ (DIMM1、DIMM2) 最終結果ホスト保存されているデータセット 6 デザイン・ソリューション結果 NDRange およびチャネル化実装の両方を使用したスタティック・データ解析文書フィルタリング・アプリケーションのパフォーマンス ( 実行時間 ) および消費電力のベンチマーク・テストを実施しました。各実装は、Nallatech PCI385N および Bittware S5PH-Q FPGA プラットフォームの両方で、それぞれの高性能コンピュータ (HPC) ボード・サポート・プラットフォーム (BSP) を使用して実行しました。ホストは、Atom C2850 プロセッサを搭載した 1U マイクロサーバーを使用しました。このベンチマーク・テストは、2 つの方法で実行しました。1 つ目では、各イタレーションの最初にカーネルをデバイスに再展開しながら、比較的小さいデータセットでイタレーションを複数回実行しました。他の方法では、1 つ目の方法よりかなり大きいデータセットを使用し、テストの最初に一度だけカーネルをデバイスに展開しました。このパフォーマンスを 1U Atom サーバーと i7 3930K 12 コア・プロセッサの両方で実行したシングル・スレッド実装および AMD の OpenCL SDK を使用して i7 プロセッサで実行した NDRange OpenCL 実装を使用した、CPU のみでの実行と比較しました。スループット性能イタレーション 3,000 回、330,000 語イタレーション 1 回、21,000,000 語 1 秒あたりの処理用語数 1.8E+09 1.6E+09 1.4E+09 1.2E+09 1.0E+09 8.0E+08 6.0E+08 4.0E+08 2.0E+08 0.0E+00 Intel I7 12 Intel I7 12 Core (シングル・ Core スレッド) (NDRange) Atom、 Nallatech (NDRange) Atom、 Nallatech (チャネル) Atom、 Bittware (NDRange) Atom、 Bittware (チャネル) 7 1 ジュールあたりの処理用語数デザイン・ソリューション 4.50E+07 消費電力で正規化したスループット性能イタレーション 3,000 回、330,000 語イタレーション 1 回、21,000,000 語 4.00E+07 3.50E+07 3.00E+07 2.50E+07 2.00E+07 1.50E+07 1.00E+07 5.00E+06 0.00E+00 Intel I7 12 Intel I7 12 Core (シングル・ Core スレッド) (NDRange) Atom、 Nallatech (NDRange) Atom、 Nallatech (チャネル) Atom、 Bittware (NDRange) Atom、 Bittware (チャネル) 今回の調査では、計算を多用するアルゴリズムを実装する際に、OpenCL フレームワークにて FPGA を使用することの利点が明らかになりました。この OpenCL FPGA 実装により、シングル・スレッド CPU 実装と 1 つの CPU のみで実行した OpenCL 実装で、パフォーマンスが大幅に向上しました。コストのかかるホストとデバイス・メモリ間の転送への依存度を軽減できるチャネル化アプローチの使用により、非常に大きいデータセットに対して最大のパフォーマンスを実現できました。そのままで達成可能なパフォーマンス向上に加え、この技術の真の潜在能力は、消費電力の大幅な削減が関係します。1 ジュールあたりのスループットでパフォーマンスを解析すると、FPGA は桁違いの性能向上を実現できます。今回は、マップ／リデュース並列処理モデルを使用した文書フィルタリング・アプリケーションの実装に集中して調査を行いました。このアプローチはこの技術によく整合していますが、パフォーマンス上の利点がこの種のコンピューティング・メソッドに限定されると結論付ける理由は見当たりません。実際には、 FPGA および OpenCL の活用は、ほとんどの並列アルゴリズムに利益をもたらすことになると考えられます。〒163-1332 東京都新宿区西新宿6-5-1 新宿アイランドタワー32F 私書箱1594号 TEL. 03-3340-9480 FAX. 03-3340-9487 www.altera.co.jp E-mail: [email protected] Altera Corporation 101 Innovation Drive, San Jose, CA 95134 USA www.altera.com 本資料に掲載されている内容は、製品の仕様の変更等により予告なく変更される可能性があります。最新の情報はアルテラ・ウェブサイトをご参照ください。 © 2015 Altera Corporation. All rights reserved. ALTERA, ARRIA, CYCLONE, ENPIRION, MAX, MEGACORE, NIOS, QUARTUS and STRATIX words and logos are trademarks of Altera Corporation and registered in the U.S. Patent and Trademark Office and are trademarks or registered trademarks in other countries. All other words and logos identified as trademarks or service marks are the property of their respective holders as described at www.altera.com/legal. March 2015. DS-1001/JP