Agile Cat — in the cloud

スループット指向のアーキテクチャ- Amazon EC2 で GPU を正しく使うために

Posted in Amazon, Big Data, Parallel by Agile Cat on December 6, 2010

GPU Vs CPU Smackdown : The Rise Of Throughput-Oriented Architectures
FRIDAY, DECEMBER 3, 2010 AT 9:20AM
http://highscalability.com/blog/2010/12/3/gpu-vs-cpu-smackdown-the-rise-of-throughput-oriented-archite.html

_highscalability

In some ways the original Amazon cloud, the one most of us still live in, was like that really cool house that when you stepped inside and saw the old green shag carpet in the living room, you knew the house hadn’t been updated in a while. The network is a little slow, the processors are a bit dated, and virtualization made the house just feel smaller. It has been difficult to run high bandwidth or low latency workloads in the cloud. Bottlenecks everywhere. Not a big deal for most applications, but for many high performance applications (HPC) it was a killer.

ドアを開けてリビング・ルームに入り、緑色の古臭いシャギー・カーペットを眺め、その家が改築されていないと理解したとき、私たちの大半がいまだに住んでいる元々の Amazon クラウドは、いろいろな意味において寒々としている。 そのネットワークは少し遅くて、プロセッサも時代遅れであり、仮想化が家を狭く感じがさせた。 そのクラウドでは、広帯域および低レイテンシーのワークロードを動かすことが難しい。そこらじゅうに、ボトルネックがある。 大半のアプリケーションとっては重要な事柄ではないが、それは HPC(high performance applications )を殺してしまうものだった。

In a typical house you might just do a remodel. Upgrade a few rooms. Swap out builder quality appliances with gleaming stainless steel monsters. But Amazon has a big lot, instead of remodeling they simply keep adding on entire new wings, kind of like the Winchester Mystery House of computing.

そんなありふれた家は、リニューアルすべきかもしれない。 いくつかの部屋をアップグレードしよう。 輝きの薄れてきたステンレス・スチールの怪物を、ビルダー・クォリティのアプライアンスに入れ替えよう。 しかし、Amazon が抱えている資産は膨大であるため、大改造を行う代わりに、その全体を覆う新しいツバサが取り付けられた。それは、まるで、コンピューティングにおける Winchester Mystery House のようなものだ。

image

The first new wing added was a CPU based HPC system featuring blazingly fast Nehalem chips, virtualization replaced by a close to metal Hardware Virtual Machine (HVM) architecture, and the network is a monster 10 gigabits with the ability to specify placement groups to carve out a low-latency, high bandwidth cluster. Bottlenecks removed. Most people still probably don’t even know this part of the house exists.

最初に付け加えられたツバサは、きわめて高速な Nehalem チップを前面に押し出した、CPU ベースの HPC システムであり、金属性の Hardware Virtual Machine(HVM)アーキテクチャに取って代わる仮想化と、低レイテンシーと広帯域が保証されるクラスタ・グループを、指定する能力を持った 10ギガビット・モンスターのネットワークを実現する。 これで、ボトルネックが解消される。しかし、ほとんどの人々は、この家に、こんな部分が存在することを知る由もない。

The newest addition is a beauty, it’s a graphics processing unit (GPU) cluster as described by Werner Vogels in Expanding the Cloud – Adding the Incredible Power of the Amazon EC2 Cluster GPU Instances . It’s completely modern and contemporary. The shag carpet is out. In are Nvidia M2050 GPU based clusters which make short work of applications in the sciences, finance, oil & gas, movie studios and graphics.

そして、最新のツバサは美しい。 それは、Expanding the Cloud – Adding the Incredible Power of the Amazon EC2 Cluster GPU Instances において Werner Vogels が記述している GPU(graphics processing unit)クラスタである。 それは、きわめてモダンでコンテンポラリなものである。 もう、シャギーのカーペットはいらない。Nvidia M2050 GPU ベースのクラスタにより、科学/金融/石油/動画/グラフィックスなどの、アプリケーション処理の時間が大幅に短縮される。

To get a feeling of the speed involved read BillMcColl’s comment:

Cloudscale is now able to ANALYZE a SINGLE STREAM of entity events at a rate of TWO MILLION EVENTS PER SECOND (150MB/sec) on an 8-node 10-GigE Amazon cloud cluster. That’s well over ONE TRILLION EVENTS per week.

そのスピード感については、 BillMcColl のコメントを読むと良い:

いまや、クラウド・スケールは、Amazon クラウド・クラスタの 8-node 10-GigE を用いることで、全体的なイベントの SINGLE STREAM を、TWO MILLION EVENTS PER SECOND(150MB/sec)のレートで解析するに至った。それは、ONE TRILLION EVENTS / week を遥かに上回るものだ。

Having both CPU and GPU clusters seems a bit strange. Why have two? Mr. Vogels does a good job explaining the reasoning:

しかし、CPU と GPU の双方でクラスタを持つことは、少し奇妙に思える。 なぜ、2を持つのか? その理由を説明するために、Mr. Vogels は Good Job を提供している:

  • GPUs work best on problem sets that are ideally solved using massive fine-grained parallelism, using for example at least 5,000 – 10,000 threads. To be able build applications that exploit this level of parallelism one needs to enter a very specific mindset of kernels, kernel functions, threads-blocks, grids of threads-blocks, mapping to hierarchical memory, etc. Configuring kernel execution is not a trivial exercise and requires GPU device specific knowledge. There are a number of techniques that every programmer has grown up with, such as branching, that are not available, or should be avoided on GPUs if one wants to truly exploit its power.

  • GPU に適した問題のセットは、たとえば最低でも 5,000-10,000 のスレットを活用し、膨大でキメの細かなパラレルを用いて解決するものが理想的である。 このレベルのパラレルを用いたアプリケーションを構築するためには、カーネルと機能および、スレッド・ブロック、スレッド・ブロック・グリッド、階層メモリ・マップなどの、特定のマインドセットの入力が必要になる。カーネルを実行するためのコンフィグレーションは、些細な処理ではなく、また、GPU デバイス固有の知識を必要とする。たとえば、バランシングのような、すべてのプログラマが育ててきた数多くのテクニックが、そこでは利用できない。 また、GPU の真のパワーを活用するのであれば、それらは排除されてしまう。

  • Modern CPUs strongly favor lower latency of operations with clock cycles in the nanoseconds and we have built general purpose software architectures that can exploit these low latencies very well.  Now that our ability to generate higher and higher clock rates has stalled and CPU architectural improvements have shifted focus towards multiple cores, we see that it is becoming harder to efficiently use these computer systems. One trade-off area where our general purpose CPUs were not performing well was that of massive fine grain parallelism. Graphics processing is one such area with huge computational requirements, but where each of the tasks is relatively small and often a set of operations are performed on data in the form of a pipeline. The throughput of this pipeline is more important than the latency of the individual operations. Because of its focus on latency, the generic CPU yielded rather inefficient system for graphics processing. This lead to the birth of the Graphics Processing Unit (GPU) which was focused on providing a very fine grained parallel model, with processing organized in multiple stages, where the data would flow through.  The model of a GPU is that of task parallelism describing the different stages in the pipeline, as well as data parallelism within each stage, resulting in a highly efficient, high throughput computation architecture.

  • 近代的な CPU により、ナノ秒クロック・サイクルを用いた、低レイテンシー・オペレーションの恩恵が得られる。 そして、この低レイテンシーを活用した、汎用的ソフトウェア・アーキテクチャを構築できる。  しかし、これ以上のクロック・サイクルに関する追求は停滞しているため、CPU アーキテクチャの改善はマルチ・コアへとシフトし、それらのコンピュータ・システムを効率よく使用することが、難しくなり始めている。こうした汎用的 CPU が、効率を高められないトレードオフ領域の 1つは、膨大でキメの細かいパラレル処理であった。 グラフィクス処理は、そのような領域の1つであり、また、膨大なコンピュータ要件を伴う。 しかし、その個々のタスクは比較的に小さいものであり、また、大半のケースにおいて、パイプラインの形態で、オペレーション・セットがデータを処理していく。 このパイプラインのスループットは、個々のオペレーションにおけるレイテンシーより重要なものとなる。レイテンシーにフォーカスしたことで、一般的な CPU は、グラフィックス処理にとって非能率的なシステムとなる傾向にある。Graphics Processing Unit(GPU)の生い立ちをたどると、きわめて粒度の細かいパラレル・モデルへと行き着く。 そこでは、マルチ・ステージで構成された、データのフローを構成した行くための処理が用いられる。 この GPU のモデルは、パイプラインの個々のステージを記述するパラレル・タスクであるだけではなく、きわめて効率的で高スループットな、コンピューティング・アーキテクチャをもたらすものとなる。

The ACM has a timely article about using GPUs for high performance computing ACM:Understanding Throughput-Oriented Architecture by Michael Garland and David Kirk:

ハイパフォーマンス・コンピューティングのための GPU 使用法に関して、ACM Michael Garland と David Kirk が Understanding Throughput-Oriented Architecture というタイムリーな記事を提供している。

Scalability is the programmer’s central concern in designing efficient algorithms for throughput-oriented machines. Today’s architectural trends clearly favor increasing parallelism, and effective algorithmic techniques must scale with hardware parallelism. Some techniques suitable for four parallel threads may be entirely unsuitable for 4,000 parallel threads. Running thousands of threads at a time, GPUs are a powerful platform for exploring scalable algorithms and a leading indicator for algorithm design on future throughput-oriented architectures. GPUs are specifically designed to execute literally billions of small user-written programs per second.

スループット指向マシンのための、効率的なアルゴリズムを設計において、プログラマーたちの主たる関心事はスケーラビリティとなる。 今日におけるアーキテクチャ傾向は、パラレルの促進に対して明らかに有利にはたらき、また、有効なアルゴリズム技法は、並列ハードウェアを用いてスケールを達成するはずだ。 ただし、4 スレッドに適したテクニックは、4,000 のパラレル・スレッドに対して不適切かもしれない。 数千スレッドを同時に実行することで、 GPU はスケーラブルなアルゴリズムの探究において、パワフルなプラットフォームになる。 また、未来のスループット指向アーキテクチャにおける、アルゴリズム設計のための先行指標にもなるだろう。 とりわけ GPU は、ユーザー記述の何十億という小さなプログラムを、毎秒ごとに実行するようデザインされている。

What matters here are two things: tools and jobs.

そして、重要な事柄として、ツールとジョブがある。

First, there’s another exotic tool in the toolbox to solve difficult problems in ways very different than what we are used to. This along side the original recipe cloud, MapReduce, and the CPU Cloud, offers enormous flexibility when architecting systems.

第一に、私たちが慣れ親しんでいるもとは大きく異なる方式で、対象となる問題を解決するためのエキゾチックな別のツールが存在する。 その前方には、本来のクラウド・レシピ/MapReduce/CPU Cloud などがあり、システムを設計する際の、広大な柔軟性を提供していく。

Second, for a surprisingly large number of problems there is now a ready supply of GPU supercomputeryness. With supply there can be demand and not that many people know how to program GPUs. Programming GPUs is a specialized skill. It’s nothing like using your typical threading library, eventing infrastructure, and message passing library. Now that GPU processors are so readily available we’ll need GPU programmers to make use of all that power. Something to think about as a potential career direction.

第二に、驚くほど膨大な問題のための、GPU のスーパーコンピュータ的な用法が、まさにいま、準備できたことになる。 その供給に対する需要が生じるだろうが、多くの人々が GPU プログラミング知っていると言うわけではない。 GPU のプログラミングは、専門的なスキルである。 それは、一般的なスレッディング・ライブラリや、イベント・インフラストラクチャ、メッセージ・パス・ライブラリを使うようなものではない。現時点において、GPU プロセッサが容易に利用できるようになり、そのすべてのパワーを活用するために、私たちは GPU プログラマーを必要とするだろう。 経験に関する潜在的な方向性として、何を考えるべきか。

Related Articles

ーーーーー

High Scalability の Todd Hoff さんは、とても詩的な文章を書くので好きなのですが、写真の選び方もユーモアがあります。 おそらく、GPU 的な空中戦とでも、言いたいのだろうと思います。 原題の Smackdown って、プロレス技の名前なんでしょうかね?

コンテンツの訳は、もう、、、四苦八苦だったのですが、大まかなところは理解できたように思えます。 プログラミングの発想からツールまで、これから大変革が起こるのでしょう。 いやはや、たいへんな時代になってきたものです。

それにしても、この文章と写真のギャップがスゴイ :)ーーー A.C.

%d bloggers like this: