Agile Cat — in the cloud

プロジェクト Piccolo は、スピードで Hadoop を凌駕する

Posted in Big Data, Hadoop, Parallel by Agile Cat on February 18, 2011

Piccolo Project Tries to Speed Past Hadoop
Derrick Harris Feb. 3, 2011, 11:30am PST

_ Gigaom

Few would argue that Hadoop doesn’t have a bright future as a foundational element of big data stacks, but Piccolo, a new project out of New York University, is moving data storage into machines’ memory in an attempt to improve parallel-processing performance beyond what Hadoop and/or MapReduce can do. Todd Hoff at High Scalability profiles the project, and I’d suggest going there for the details. At a high level, the difference between Hadoop and Piccolo might be explained as the difference between digging for one vegetable at a time and spreading the cleaning and peeling duties to a team of workers, versus having those workers each grab and process their own vegetables simultaneously, from a prearranged pile above the ground.

ビッグ・データ・スタックの基本的な要素として、Hadoop の明るい未来を否定する人は、ほとんどいないだろう。しかし、New York University で生まれた新規のプロジェクトである Piccolo は、マシン・メモリ内へのデータ・ストレージの移行により、並列処理パフォーマンスの改善を試み、Hadoop や MapReduce の能力をしのぐ領域を目指す。 このプロジェクトの概要については、High Scalability の Todd Hoff が記しているため、詳細については、その参照をお勧めする。 高い抽象レベルにおいて、 Hadoop と Piccolo の相違を以下のように例えることができる。 つまり、一度に1つの野菜を掘り出し、洗って、皮を剥く、農夫の仕事が Hadoop に相当するなら、あらかじめ定められた区画から複数の農夫が、それぞれが担当する野菜を同時に収穫し、その後の処理も行うのが Piccole である。

A more technical explanation is that Piccolo uses an in-memory, key-value store and a “global table interface” — as opposed to Hadoop, which utilizes a distributed file system contained within the disk drives of the machines in the cluster — that lets the CPUs access all the data simultaneously, and at high speeds only possible by pulling data straight from RAM. In this fairly long, but genuinely interesting presentation at the OSDI 10 conference, lead developer Russell Power explains how Piccolo works, how it differs from Hadoop and how it has tested far faster than Hadoop on certain workloads. Power compares Piccolo to the Chevy El Camino, which was both efficient and easy to use while also delivering high performance. Here’s a screenshot of Power illustrating Piccolo’s scalability on an Amazon EC2 cluster:

よりテクニカルに説明すると、Piccolo はイン・メモリーと Key-Value ストアだけではなく、Hadoop の対極にある 『 グローバル・テーブル・インターフェイス 』を用いることが、大きな相違点として挙げられる。そこでは、クラスタを構成するマシンに配備されたディスク・ドライブ内に含まれる、分散型のファイル・システムを活用する。 つまり、RAM から直接データを引き出すことで可能となる、きわめて高速のデータ・アクセスを、CPU に提供することになる。OSDI 10 カンファレンスにおける、長時間におよぶが、きわめて興味深いプレゼンテーションで、中心となるデベロッパーである Russell Power が、どのように Piccolo が動くのか説明した。また、特定のワークロードにおいて、Hadoop との差異が状況と、Hadoop を上回るテスト結果について説明した。 Power は、Piccolo と Chevy El Camino と比較し、どちらが使いやすく、また、効率的で、高性能をもたらすかという点を指摘した。Amazon EC2 クラスタ上で、Piccolo のスケーラビリティを証明する、Power のスクリーンショットは以下のとおりである:

クリックで拡大 ⇒

I’m not suggesting Piccolo is going to replace Hadoop, or MapReduce, generally, anytime soon or ever — Hadoop vendor Cloudera today received a strategic investment from U.S. intelligence sector consultant In-Q-Tel, which should hammer home the fact that Hadoop is for real — but Piccolo is worth watching. It certainly wouldn’t be the first academic project in recent memory to make it big; the Marten-Mickos-led cloud-software provider Eucalyptus Systems was a research project from the University of California Santa Barbara when it caught on, and then struck it big with VCs and early adopters.

一般論として、近々あるいは特定の時期に、Hadoop や MapReduce に対して、Piccolo が取って代わると示唆しているわけではない。今日(2/3)のことだが、Hadoop ベンダーである Cloudera は、US 政府情報部門のコンサルタントである In-Q-Tel から戦略的投資を受けた。それは、Hadoop が本物であるという現実を裏付けるものだ。 しかし、Piccolo は注視し続けるだけの価値を持つ。アカデミック・プロジェクトに関する最近の記憶では、この件が最初の成功例というわけでもない。Marten Mickos が率いるクラウド・ソフトウェア・プロバイダーである Eucalyptus Systems は、University of California Santa Barbara の研究プロジェクトとして始まった。そして、広まるにつれてアーリー・アダプタを得て、VC からの資金も調達するようになった

To learn even more about the future of big data processing and analysis, make sure to attend out Structure Big Data conference March 23 in New York City. You won’t likely hear about the seedling Piccolo project, but you’ll hear plenty about cutting-edge use cases and tactics for the current generation of big data tools.

3月23日に NYC で開催される、私たちの Big Data conference に参加して欲しい。 Piccolo については聞くことができないが、最先端のデータベースを含めて、ビッグ・データを取り扱う際の要因について、また、それを解決するための最適化された戦略を学べる。

Related Content From GigaOM Pro (subscription required)


いろいろと出てきて、ほんとうに面白いですね! それと、Chevy El Camino は、Todd Hoff さんサイトにあるように、いわゆるデカいアメ車のことなのでしょう。 なんで黄色いのかという、意味もあるのですね。 この人の茶目っ気が大好きです :) ーーー __AC Stamp 2


Real World NoSQL シリーズ – Openwave における Cassandra
Real World NoSQL シリーズ – 4PB を処理する Trend Micro の HBase
Yahoo!は、独自の Hadoop Distribution を止めて、Apache コミュニティに協力する
Hadoop に似た Dryad は、Microsoft の Big Data スターになれるのか


Hadoop に似た Dryad は、Microsoft の Big Data スターになれるのか

Posted in Big Data, Hadoop, Parallel by Agile Cat on December 24, 2010

Why Hadoop-like ‘Dryad’ Could Be Microsoft’s Big Data Star
Derrick Harris
Dec. 21, 2010, 11:09am PDT

_ Gigaom

Microsoft’s HPC division opened up the company’s Dryad parallel-processing technologies as a Community Technology Preview (CTP) last week, a first step toward giving Windows HPC Server users a production-ready Big Data tool designed specifically for them. The available components — Dryad, DSC and DryadLINQ – appear to be an almost part-for-part comparison with the base Hadoop components (Hadoop MapReduce, Hadoop Distributed File System and the SQL-like Hive programming language) and hint that Microsoft wants to offer Windows/.NET shops their own stack on which to write massively parallel applications. Dryad could be a rousing success, in part because Hadoop – which is written in Java – is not ideally suited to run atop Windows or support .NET applications.

Microsoft の HPC 部門は先週、主として Windows HPC Server ユーザーのために設計された、プロダクションに対応可能な Big Data ツールを提供する、Dryad 並列処理テクノロジーの Community Technology Preview(CTP)を、その第一歩として公開した。 そこで利用する Dryad/DSC/DryadLINQ といったコンポーネントは、大まかなところで Hadoop コンポーネント(Hadoop MapReduce/Hadoop Distributed File System/SQL-like Hive programming language)に対応しているように見える。そして、Windows および .NET の開発者に対して、大規模並列アプリケーションを記述するための、Microsoft プロダクト・スタックを積み上げるというヒントが隠されている。Hadoop は Java で記述されおり、Windows 上での実行や、.NET アプリケーションのサポートにおいて、理想的ではないため、その部分で Dryad は成功するだろう。

When Microsoft broke into the high-performance computing market in 2005 with its Windows Compute Cluster Server, it affirmed the idea that, indeed, HPC was taking place on non-Linux boxes. Certainly, given the prevalence of large data volumes across organizations of all types, there is equal, if not greater, demand for Hadoop-like analytical tools even in Windows environments. Presently, however, Apache only supports Linux as a production Hadoop environment; Windows is development-only.  There are various projects and tools floating around for running Hadoop on Windows, but they exist outside the scope of Apache community support.  A Stack Overflow contributor succinctly summed up the situation in response to a question about running Hadoop on Windows Server:

Windows Compute Cluster Server により Microsoft が 2005年に High-Performance コンピューティングの市場に参入したとき、非 Linux ボックス上の HPC が、本当に成立するという発想を確認した。 確かに、すべての組織のたるところで、大容量データがトレンドになることを前提にすると、Hadoop のような分析ツールへの需要は、Windows環境であっても、それと同じ程度を見込めるだろう。しかしながら、現時点において、Apache は Hadoop の運用環境として Linux だけをサポートしており、Windows は開発環境のみである。  Windows 上で Hadoop を実行させるための、多様なプロジェクトとツールが存在するが、それらは Apache コミュニティ・サポートのスコープから外れている。  Stack Overflow のコントリビュータが、Windows サーバー上で Hadoop を走らせるという質問への回答において、その状況を簡潔にまとめている:

From the Hadoop documentation:
‘Win32 is supported as a development platform. Distributed operation has not been well tested on Win32, so it is not supported as aproduction platform.’
Which I think translates to: ‘You’re on your own.’

Hadoop documentation より:
『 Win32 は、開発プラットフォームとしてサポートされる。 Win 32 上での分散処理は、適切にテストされていないため、運用プラットフォームとしてはサポートされない 』
私が考えだと、それは『 あなたは独り立ちしている 』と翻訳される。

Then there is the Windows Azure angle, where Microsoft appears determined to compete with Amazon Web Services. Not only has it integrated IaaS functionality in Windows Azure, but, seemingly in response to AWS courting the HPC community with Cluster Compute Instances, Microsoft also recently announced free access to Windows Azure for researchers running applications against the NCBI BLAST database, which currently is housed within Azure. Why not counter Elastic MapReduce – AWS’s Hadoop-on-EC2 service – with Dryad applications in Azure?

そして、Microsoft が Amazon Web Services との競合を決意した、Windows Azure の視点がある。それは単に、Windows Azure 内で IaaS 機能を統合するだけではなく、 Cluster Compute Instances を用いた HPC コミュニティ作りに熱心な、AWS への反応とも映る。最近のことだが、さらに Microsoft は、NCBI BLAST データベースに対抗して、研究者たちがアプリケーション実行するWindows Azure への、無料でのアクセスを発表した。 それらは、現時点において、Azure の中にホストされている。 AWS EC2 における Hadoopサービスである Elastic MapReduce に対して、Azure 上の Dryad アプリケーションで立ち向かったらどうだろう?

SD Times actually reported in May that Microsoft was experimenting with supporting Hadoop in Windows Azure, but that capability hasn’t arrived yet. Perhaps  that’s because Microsoft has fast-tracked Dryad for a slated production release in 2011. As the SD Times article explains, Hadoop is written in Java, and any support for Hadoop within Windows Azure likely would be restricted to Hadoop developers. That’s not particularly Microsoft-like, which certainly would prefer to give additional reasons to develop in .NET, not Java. Dryad would be such a reason.

この 5月のことだが、SD Times は Microsoft が Windows Azure 上で Hadoop をサポートするための実験を進めているが、その能力はまだ目標を達成していないとレポートした。 2011年に予定されていた Dryad の製品リリースを、Microsoft が前倒しにした理由は、おそらく、そこになあるのだろう。 SD Times の記事が述べたように、Hadoop は Java で記述されており、Windows Azure における あらゆる Hadoop サポートは、おそらく、Hadoop デベロッパーに対するものに限定されるだろう。 そして、Microsoft にとっては特別というわけではないが、Java ではなく .NET が優先されるという、別の理由もあるはずだ。 Dryad は、こうした背景を持つのだろう。

What might give the Microsoft developer community even more hope is the Dryad roadmap that Microsoft presented in August. ZDNet’s Mary Jo Foley noted a variety of Dryad subcomponentsthat will make Dryad even more complete, including a job scheduler codenamed “Quincy.”

その Microsoft デベロッパー・コミュニティに対して、さらなる希望を何が与えるかといえば、Microsoft が 8月に提供したDryad のロードマップである。 ZDNet の Mary Jo Foley は、Dryad の完成度を高めるサブ・コンポーネント群の存在に気づいた。 そして、「Quincy」というコードネームを付けらた、ジョブ・スケジューラーも含まれることを指摘した。

But there’s no guarantee that the production version of Dryad will resemble the current iteration too closely. As Microsoft notes in the blog post announcing the Dryad CTP, “The DryadLINQ, Dryad and DSC programming interfaces are all in the early phases of development and might change significantly before the final release based on your feedback.” A prime example of this is that Dryad has only been tested on 128 individual nodes. In the Hadoop world, Facebook is running a cluster that spans 3,000 nodes (sub req’d). Dryad has promise as Hadoop for the Microsoft universe, but, clearly, there’s work to be done.

しかし、Dryad のプロダクション・バージョンが、現時点におけるイテレーションと、きわめて類似するものになるという保証はない。 そして Microsoft は自身のブログ・ポストで、『 DryadLINQ/Dryad/DSC プログラミング・インターフェイスの全てが、現時点では初期の開発段階にあるため、最終的なリリースを迎える前に、フィードバックに基づた大幅な変更が加えられるかもしれない 』 と、アナウンスしている。その顕著な例として、Dryad がは 128 ノードだけしかテストされていないという点が挙げられる。 Hadoop 世界では、3,000 ノード(以下で参照)にまたがるクラスタが、Facebook により運用されている。 Dryad は、Microsoft の宇宙における Hadoop だと見込まれているが、完了すべき作業が、まだまだ残っている。

Related content from GigaOM Pro (sub req’d):


う~ん! コメントしにくいので、何も言わない。 ーーー A.C.


Microsoft readying Hadoop for Windows Azure の対訳
Microsoft と Intel には、並列/分散の隠し技があるのか
Dryad が DAG をつかう理由 – Dryad & DryadLINQ Team Blog
Windows Azure チームは、どのような興味を Cassandra に持っているのか?
NoSQL は Microsoft にとって重要だから、Microsoft だけに任せておけない!
実行中にノードを追加できる、新しい Elastic MapReduce とは?
MapReduce と Hadoop の将来について
Facebook の HBase は、毎月 1350億 メッセージを処理する!


GPGPU を用いたソートについて考える – James Hamilton

Posted in Amazon, Big Data, James Hamilton, Parallel by Agile Cat on December 22, 2010

GPGPU Sorting
James Hamilton’s Blog

Years ago I believed that incorrectly believed special purpose hardware was a bad idea. What was a bad idea is high-markup, special purpose devices sold at low volume, through expensive channels. Hardware implementations are often best value measured in work done per dollar and work done per joule. The newest breed of commodity networking parts from Broadcom, Fulcrum, Dune (now Broadcom), and others is a beautiful example of Application Specific Integrated Circuits being the right answer for extremely hot code kernels that change rarely.

何年か前のことだが、特殊な目的のハードウェアは好ましくないという、間違った考え方を持っていた。 何が良くないかといえば、コストのかかるチャネルを介して販売される、特別な用途のための、少量生産の高額なデバイスである。 効率のよいハードウェア実装とは、コストとロットをベースに測定するときに、最も大きな価値をもたらすのが一般である。 Broadcom/Fulcrum/Dune(現在は Broadcom)などから提供される、一般的なネットワーク・パーツといった系譜は、Application Specific Integrated Circuits(ASIC)の美しい事例であり、きわめてホットで変化しにくいコードをカーネルとする際の、正しい回答である。

I’ve long been interested in highly parallel systems and in heterogeneous processing. General Purpose Graphics Processors are firmly hitting the mainstream with 17 of the Top 500 now using GPGPUs (Top 500: Chinese Supercomputer Reigns). You can now rent GPGPU clusters from EC2 $2.10/server/hour where each server has dual NVIDIA Tesla M2050 GPUs delivering a TeraFLOP per node. For more on GPGPUs, see HPC in the Cloud with GPGPUs and GPU Clusters in 10 minutes.

私は長い期間にわたり、パラレル・システムとへトロジニアスな処理に、強い興味を持ち続けてきた。 いまや、スーパーコンピュータ Top 500 において、17 種類のGeneral Purpose Graphics Processors 採用され、主流となるコンセプトに対して着実に打撃を与えている(Top 500: Chinese Supercomputer Reigns)。 そしていま、ノードごとに 1 TeraFLOP を提供する、Dual NVIDIA Tesla M2050 GPUs と搭載した EC2 サーバー($2.10 server/hour)により、GPGPU クラスタを借りることができる。 GPGPU の詳細については、HPC in the Cloud with GPGPUs および GPU Clusters in 10 minutes を参照して欲しい。

注記: 上記の 17の意味がよく分けりませんと、ここにコメントを書いていましたが、@kitayama_t さんと @kame355 さんが調べてくださり、Cell の 6種類 (7, 49, 120, 207, 208, 209) および、NVIDIA の 10種類 (1, 3, 4, 28, 72, 88, 102, 117, 145, 403)、そして ATI Radion の1種類 (22) の合計で、17種類の意味だと判明しました。 有難うございます! (参考 ⇒

Some time ago Zach Hill sent me a paper writing up Radix sort using GPGPUs. The paper shows how to achieve a better than 3x on the NVIDIA GT200-hosted systems. For most of us, sort isn’t the most important software kernel we run, but I did find the detail behind the GPGPU-specific optimizations interesting. The paper is at and the abstract is below.

しばらく前のことだが、GPGPU を用いた Radix ソートに関するドキュメントを、Zach Hill から送ってもらった。 そのペーパーに記されているのは、Nvidia GT200 をホストするシステム上で、3倍の性能を達成する方式である。 大半のケースにおいて、ソートは最重要のソフトウェア・カーネルではないが、GPGPU 固有の最適化した際に、その背景に興味深い事柄が広がるのを見つけた。 そのペーパーの Abstruct を以下に記す。また、URL は である。


This paper presents efficient strategies for sorting large sequences of fixed-length keys (and values) using GPGPU stream processors. Compared to the state-of-the-art, our radix sorting methods exhibit speedup of at least 2x for all generations of NVIDIA GPGPUs, and up to 3.7x for current GT200-based models. Our implementations demonstrate sorting rates of 482 million key-value pairs per second, and 550 million keys per second (32-bit). For this domain of sorting problems, we believe our sorting primitive to be the fastest available for any fully-programmable microarchitecture. These results motivate a different breed of parallel primitives for GPGPU stream architectures that can better exploit the memory and computational resources while maintaining the flexibility of a reusable component. Our sorting performance is derived from a parallel scan stream primitive that has been generalized in two ways: (1) with local interfaces for producer/consumer operations (visiting logic), and (2) with interfaces for performing multiple related, concurrent prefix scans (multi-scan).

このペーパーが記すのは、GPGPU ストリーム・プロセッサを用いて、固定長の Key(および Value)で構成される、膨大なシーケンスを効率よくソートするためのストラテジである。 最先端とされる方式と比較して、私たちの Radix ソートは、すべての世代の NVIDIA GPGPU において、少なくとも 2倍の性能を発揮し、また、現行の GT200 ベース・モデル に対して3.7 倍のスピードアップを果たした。 私たちの実装では、4億 8200万の Key-Value セットおよび、5億 5000万のキー(32 Bit)を、毎秒ソートできることが証明れた。 ソートという問題ドメインに関して、私たちのソーティング・プリミティブは、プログラミングに対応する各種のマイクロ・アーキテクチャにおいて、最速を達成するものと信じている。 これらの結果から、GPGPU ストリーム・アーキテクチャのためのパラレル・プリミティブの、これまでとは異なる系譜が喚起される。そこでは、再利用が可能なコンポーネントの柔軟性を維持しながら、メモリとコンピューティグのリソースを、さらに効率よく利用できる 。 私たちのソートにおけるパフォーマンスは、2つの方式により生成されるパラレル・スキャン・ストリームのプリミティブからもたらされる。(1) producer/consumer オペレーション(visiting logic)のためのローカルなインターフェイスを用いる。(2)関連性を持つ多数のプリフィックス・スキャンを実行するインターフェイスを用いる。

As part of this work, we demonstrate a method for encoding multiple compaction problems into a single, composite parallel scan. This technique yields a 2.5x speedup over bitonic sorting networks for small problem instances, i.e., sequences that can be entirely sorted within the shared memory local to a single GPU core.

この処理の一部として、圧縮における多様な問題を、単一の複合パラレル・スキャンへと、エンコードする方式を実証する。 このテクニックは、小規模なインスタンスのための bitonic ソーティング・ネットワーク上で、2.5倍のスピードアップをもたらす。つまり、ワン GPU コアのローカルな共用メモリ内で、シーケンス全体がソートされる。

James Hamilton

: /


何が何やらの GPGPU ですが、こうして、だんだんとイメージが掴めてくるのでしょうね。 調べなければならないことが、山のように残されていますが。 ーーー A.C.


スループット指向のアーキテクチャ- Amazon EC2 で GPU を正しく使うために
Big Data – だれが、どこで、使うのか?

Big Data – だれが、どこで、使うのか?

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

Big Data: How are People Using it?
By Dick Weisinger, on December 16th, 2010


The ability to analyze “big data” or huge data sets efficiently has led many to predict that we are on the verge on being able to make huge breakthroughs in understanding science, society and business.  At a recent conference on “Big Data” sponsored by Aster Data, attendees were asked what type of “Big Data” plans they were considering.

Big Data あるいは膨大なデータセットを分析する能力が、科学/社会/経済の理解において強烈なブレークスルーをもたらす臨界点へと向けて、私たちを効果的に導いている。  Aster Data が後援する、直近の Bid Data カンファレンスでは、どのようなタイプの Big Data を想定して、計画を立てるべきかという質問が相次いだ。

Responses ranged across the following areas:

  • Investigation of new market opportunities.  Attendees were looking for the next “Big Data insight”
  • Gain an understanding of behavioral purchasing data.
  • Understanding data collected from social media and social networking
  • Trying to understand how the data collected could be monetized.
  • Fraud reduction and risk profiling.   Trying to generate a profile or behavior information that can identify good and bad customers.


  • 新しいビジネス機会の調査。 出席者たちは、次の "Big Data insight” を探している。
  • 購入行動データに関する、より深い理解。
  • ソーシャル・メディアとソーシャル・ネットワークから収集されたデータの理解。
  • 収集されたデータをビジネスにつなげる方式への理解。
  • 不正の防止と、リスクのプロファイル化。 優良/悪質な顧客を見極めるための、プロファイルと行動情報の生成。

So while there is much excitement about what hidden insights might be uncovered by analyzing “Big Data”, everything isn’t rosy just yet.  Many of the attendees expressed frustration.  While technology is barreling forward rapidly, there still are hurdles to be jumped in order to be successful in analyzing Big Data.  Problems that attendees mentioned include:

Big Data の分析により、未知の事柄が明らかになるかもしれない。 しかし、すべてがバラ色ではなく、興奮ばかりしているわけにはいかない。ここでは、多くの出席者から、フラストレーションが表明された。  テクノロジーは猛スピードで突き進むが、Big Data の分析を成功へと導くためには、乗り越えなければならない障害がある。  出席者が言及した問題点には、以下の事柄が含まれる:

  • 20 percent said that complex processing of large data sets can be extremely slow.
  • 30 percent said that being able to scale up their current systems to be able to handle Big Data sets can be complex and difficult.

  • 大規模データセットに関する複雑な処理は、時間がかかりすぎる – 20% の参加者
  • Big Data を取り扱うように、現行のシステムをスケールアップすることは、複雑で困難である – 30% の参加者

Sharmila Mulligan, executive vice president at Aster Data, said that the “need for deep analytical processing that when done right, present new opportunities for businesses is also where most stumble.”

Aster Data 筆頭副社長 である Sharmila Mulligan は、『 適切に行われるときに、深層にまで至る分析処理が達成されるが、新しいビジネス・チャンスへの取り組みは、大部分がつまずくところでもある 』 と発言している。


最後のマトメのところですが、急がば回れみたいなことで良いのでしょうかね? ちょっと自信がありませんので、ご指摘などありましたら、よろしくお願いします。

この Aster Data って、どこかで聞いたことがある名前だったのですが、昨年の Hadoop World と同じ会場でカンファレンスがあり、間違って入り込んでしまったことを思い出しました orz   でも、面白かったので、コーヒーなんぞをご馳走になりながら、しばらく話を聞いてしまいました :)

こんなカンファレンスが、日本でも行われるようになるとイイですよねぇ~~~ A.C.


ついに Apple も、Hadoop ユーザーになるようだ!
Facebook のメッセージング・インフラを、再構築する立役者は HBase だ!
実行中にノードを追加できる、新しい Elastic MapReduce とは?
MapReduce と Hadoop の将来について
Hadoop ベンダーたちは、データに苦しむ銀行から利益を得られるのか?
スループット指向のアーキテクチャ- Amazon EC2 で GPU を正しく使うために
イベンチュアル・コンシステンシーはお好き? by James Hamilton
Microsoft の Modeling the World

スループット指向のアーキテクチャ- 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


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 のようなものだ。


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.

Microsoft と Intel には、並列/分散の隠し技があるのか

Posted in Big Data, Microsoft, MS-MapReduce, Parallel by Agile Cat on September 4, 2010

Microsoft, Intel deliver new distributed/parallel tools
By Mary Jo Foley
September 3, 2010, 8:04am PDT

All About Microsoft

Microsoft execs haven’t been beating the parallel-computing drum as loudly as they were a year or two ago, but that doesn’t mean nothing is happening in this space.

Microsoft の首脳陣たちは、この1~2年間と同じように、パラレル・コンピューティングについて押し黙っている。だからといって、この領域で何も起きていない訳ではない。

Late last month, Microsoft made available for download a new version of the HPC (High Performance Computing) Toolpack, which is a collection of utilities that can be used on Windows Server 2008 R2-based clusters. The latest tool pack includes two tools, one known as “Lizard,” and the other as “ClusterCopy.” Lizard, the Linpack Performance Wizard, calculates peak performance of HPC clusters in billions of floating-point operations per second (GFLOPS) and allows users to save those results and the parameters that helped achieved them. ClusterCopy is a tool for distributing files around a cluster using a tree-based copy system.

先月(8月)のおわりに Microsoft は、Windows Server 2008 R2 ベース・クラスタで利用するユーティリティー・コレクションとして、HPC(High Performance Computing)Toolpack の、新バージョンのダウンロードを開始した。 この最新のツール・パックには、“Lizard” と “ClusterCopy” という 2つのツールがを取り込まれている。Linpack Performance Wizard である Lizard は、HPC クラスタのピークのパフォーマンスを、1秒あたり10億桁の浮動小数点オペレーション(GFLOPS)で 計算する。そして、ユーザーの目的を達成するために、それらの結果やパタメータの保存も実現する。 また、ClusterCopy は、ツリーベースのコピーシステムを用いて、クラスタの周辺にファイルを配置していくためのツールである。


As I noted in a previous blog post, Microsoft is gearing up to make some more noise in the HPC space this fall, when the company is expected to release a first Community Technology Preview (CTP) of its Dryad parallel/distributed computing infrastructure technology. A final commercial version of Dryad is due out some time in 2011. Dryad has been a Microsoft Research project, but is in the process of being commercialized, according to a Microsoft presentation I saw.

前回のブログ・ポストで指摘したように、Microsoft は、並列/分散コンピューティングのインフラストラクチャ・テクノロジーである、Dryad の CTP (Community Technology Preview) のリリースに合わせて、HPC 領域に関する話題を、この秋に盛り上げようとしている。 最終的な Dryad の商用バージョンは、2011年のいずれかで登場する。 ただし、私が Microsoft のプレゼンテーションで見た限りでは、Dryad は依然として Microsoft Research のプロジェクトであり、商用化へ向けたプロセスの途上にある。

“Lizard and ClusterCopy have no direct relationship to Dryad today,” a Microsoft spokesperson said when I asked if there was any connection between the products. “Microsoft periodically releases additional tools for HPC that they developed out of band (between formal releases/updates) of the product.  These provide additional value to our customers, at no additional cost, through online tool packs.”

『 現時点において、Lizard と ClusterCopy は Dryad とのダイレクトな関係を持っていない 』と、私の質問に対して、Microsoft のスポークスマンは答えている。 『 Microsoft は、プロダクトとは関係しない領域(正式なリリースやアップデートの間で)で開発され、HPC に追加されていくツールを、周期的にリリースしている。 それらがもたらす価値は、オンライン・ツールパックを介して、また、追加の費用を求めることもなく、顧客に対して提供されていく 』

In other parallel/distributed computing news this week, Intel rolled out an updated version of its Parallel Studio tool suite for Windows developers. The new Intel Parallel Studio 2011 is designed to help developers increase the performance and reliability of both serial and parallel applications running on multicore processors. The new Studio 2011 adds a set of parallel models, known as Parallel Building Blocks, as well as a new threading assistant, known as Parallel Advisor. The new Intel suite supports Visual Studio 2010.

今週の、その他の並列/分散コンピューティングに関するニュースとして、Intel が Windows デベロッパーに対して、Parallel Studio ツール・スイートの、アップデート・バージョンを提供したことが挙げられる。 新しい Intel Parallel Studio 2011 は、マルチコア・プロセッサ上で実行されるシリアル/パラレルのアプリケーションに関して、デベロッパーがパフォーマンスと信頼性を、高めていくためにデザインされている。 この、新しい Studio 2011 では、Parallel Building Blocks というパラレルモデルのセットに加えて、Parallel Advisor という新規のスレッディング・アシスタントも追加される。 そして、この Intel スイートは、Visual Studio 2010 をサポートする。

Intel has been working with Microsoft on adding and improving support for parallel/multicore systems.

Intel は、パラレル/マルチコア システムを追加し、そのサポートを改善するために、Microsoft と協調している。

Microsoft’s recently formed Technical Computing Group is the part of the company that has the charter these days for parallel, technical and high-performance computing.

最近になって、Microsoft で組織された Technical Computing Group とは、パラレル・テクノロジーでハイパフォーマンス・コンピューティングを実現する役割を与えられた、同社の一部門である。


Mary Jo Foley さんが、冒頭で『 この領域 』と言っていますが、まさにココが、Microsoft のチョイ情けないところなのです。 いいじゃぁないですか、たとえ Bing が 何らかの Map/Reduce を使っていたとしても。。。 また、Map/Reduce でなくても構いませんので、いまはこうだけど、次は Dryad でこうなるとか、将来の展望を説明してみれば良いではないですか。 そうすることで、『 この領域 』 での信頼を勝ち得ていくのです。 今回の Mary さんのブログポストは、『 頑張れ Mictosoft 』の応援団ですよ。 ーーー A.C.


Dryad が DAG をつかう理由 – Dryad & DryadLINQ Team Blog
MapReduce in DryadLINQ
Apache ZooKeeper による分散並列キューの構築
Observers と ZooKeeper

SQL Azure をホリゾンタルにパーティショニングする

Posted in Microsoft, Parallel by Agile Cat on August 23, 2010

SQL Azure Horizontal Partitioning: Part 2


Wayne Walter Berry
24 Jun 2010 9:57 AM



SQL Azure currently supports 1 GB and 10 GB databases, and on June 28th, 2010 there will be 50 GB support. If you want to store larger amounts of data in SQL Azure you can divide your tables across multiple SQL Azure databases. This article will discuss how to use a data access layer to join two tables on different SQL Azure databases using LINQ. This technique horizontal partitions your data in SQL Azure.

現時点において、SQL Azure がサポートするのは 1GB と 10GB データベースであるが、2010年6月28日からは 50GB もサポートされる。そのため、大量のデータを SQL Azure にストアする場合には、多数の SQL Azure データベースに、テーブルを分割することが可能になる。 この記事では、異なる SQL Azure データベース上で、LINQ を用いて 2つのテーブルを join させる、データアクセス・レイヤの使い方について説明していく。このテクニックは、SQL Azure 内のデータを、ホリゾンタルにパーティショニングするものとなる。

In our version of horizontal partitioning, every table exists in all the databases in the partition set. We are using a hash base partitioning schema in this example – hashing on the primary key of the row. The middle layer determines which database to write each row based on the primary key of the data being written. This allows us to evenly divide the data across all the databases, regardless of individual table growth. The data access knows how to find the data based on the primary key, and combines the results to return one result set to the caller.

私たちのホリゾンタル・パーティショニング・バージョンでは、対象となるパーティション・セットにおける全データベース内に、すべてのテーブルが存在することになる。 そして、このサンプルでは、ハッシュ・ベースのパーティショニング・スキーマを用いて、対象となる Row の主キーをハッシュしていく。 ミドル・レイヤは、書き込み中のデータにおける主キーに基づき、個々の Row を write するデータベースを決定する。 それにより、個別のテーブルの増大にかかわらず、すべてのデータベースの至るところに、データを均等に分類することが可能となる。 このデータ・アクセス形式であれば、主キーに基づくデータを探し出す方式が認識され、また、対象となる caller に 1つの result set を return するために、その結果が結合される。

This is considered hash based partitioning. There is another style of horizontal portioning that is range based. If you are using integers as primary keys you can implement your middle layer to fill databases in consecutive order, as the primary key grows. You can read more about the different types of partitioning here.

それを、ハッシュ・ベースのパーティショニングと考えることができる。 ホリゾンタル・パーティショニングにおける別のスタイルは、レンジ・ベースのものとなる。 もし、整数を主要キーとして使用するなら、その主キーが増大するににつれて、連続したオーダーでデータベースを埋めていくように、ミドル・レイヤを実装できる。 それ以外のパーティショニング・タイプについては、ココで参照できる。

Performance Gain

There is also a performance gain to be obtained from partitioning your database. Since SQL Azure spreads your databases across different physical machines, you can get more CPU and RAM resources by partitioning your workload. For example, if you partition your database across 10 – 1 GB SQL Azure databases you get 10X the CPU and memory resources. There is a case study (found here) by TicketDirect, who partitioning their workload across hundreds of SQL Azure databases during peak load.

さらに、データベースのパーティションからは、パフォーマンスのゲインが得られる。 SQL Azure では、物理的に異なる複数のマシン上にデータベースが拡散れれるため、そのワークロードが分割され、さらに潤沢な CPUと RAM のリソースが得られる。 たとえば、全体で 10GB の SQL Azure データベースを、1GBずつにパーティショニングすれば、10 倍の CPUとメモリのリソースが手に入る。TicketDirect のケーススタディでは、ピーク時には数100 の SQL Azure データベースに、そのワークロードが分割される。


When horizontal partitioning your database you lose some of the features of having all the data in a single database. Some considerations when using this technique include:


  • Foreign keys across databases are not supported. In other words, a primary key in a lookup table in one database cannot be referenced by a foreign key in a table on another database. This is a similar restriction to SQL Server’s cross database support for foreign keys.
  • データベース全体にまたがる外部キーが、サポートされない。 言い換えれば、データベースにおける lookup table 内の主キーは、別のデータベースのテーブル内の外部キーから参照できない。 それは、外部キーをサポートする SQL Server クロス・データベースに対する、制約に類似したものとなる。
  • You cannot have transactions that span two databases, even if you are using Microsoft Distributed Transaction Manager on the client side. This means that you cannot rollback an insert on one database, if an insert on another database fails. This restriction can be mitigated through client side coding – you need to catch exceptions and execute “undo” scripts against the successfully completed statements.
  • たとえクライアント側で、Microsoft Distributed Transaction Manager を用いるにしても、2つのデータベースにまたがるトランザクションは不可能である。 つまり、片方のデータベースで insert が失敗しても、もう片方でのロールバックが効かなくなる。 ただし、クライアント・サイドのコーディングを介して、この制約を緩和することもできる。それは、例外をキャッチして、完了したステートメントに対して ”undo” スクリプトを実行すことである。
  • All the primary keys need to be uniqueidentifier. This allows us to guarantee the uniqueness of the primary key in the middle layer.
  • すべての主キーは、uniqueidentifier となる必要がある。 それにより、ミドル・レイヤにおける主キーのユニークさが保証される。
  • The example code shown below doesn’t allow you to dynamically change the number of databases that are in the partition set. The number of databases is hard coded in the SqlAzureHelper class in the ConnectionStringNames property.
  • 以下のサンプル・コードはは、パーティション・セット内のデータベース数を総的に変更することができない。 ここでのデータベース数は、ConnectionStringNames のプロパティの SqlAzureHelper クラスで、ハード・コーディングされている。
  • Importing data from SQL Server to a horizontally partitioned database requires that you move each row one at a time emulating the hashing of the primary keys like the code below.
  • SQL Server からホリゾンタル・パーティション・データベースへ向けたデータのインポートでは、それぞれの Row を 1回に 1つずつ移動して、以下のコードにあるように、主キーのハッシュをエミュレートする必要がある。




The Code
Accounts Table
Partitioning by Primary Key
Fetching A Single Row
Inserting a Single Row



Eventual Consistency と CAP Theorem – by Michael Stonebraker _1
Eventual Consistency と CAP Theorem – by Michael Stonebraker _2
Stonebraker と CAP Theorem と Databases – by James Hamilton
Database Sharding _1
Database Sharding _2
Database Sharding _3
Database Sharding _4
Database Sharding _5

Microsoft の Modeling the World

Posted in Parallel by Agile Cat on June 5, 2010

Modeling the World – Microsoft Blog Admin
Posted by Bill Hilf

16 May 2010 11:01 PM


As part of this initiative we’re also bringing together some of the brightest minds in the technical computing community at ; to discuss the trends, challenges and opportunities we share. Personally, I think this site provides a great interactive experience with fresh, relevant content—I’m incredibly proud of it. Please tune in and join us—we welcome your ideas and feedback.

# Technical computing to the cloud:
# Simplify parallel development:
# Develop powerful new technical computing tools and applications:

そこからたどっていくと、以下のようなステキな Silverlight のページが。。。

modeling the world

Bob Muglia さんをはじめ、おそらく MS Research 系の方々が、興味深いメッセージを発しています。 ひょっとして、Microsoft readying Hadoop for Windows Azure に関連する話も、、、と期待しましたが、さすがに Hadoop は出てきませんでした。 それと、みなさんが Jim Gray さんの名前を引用しているのが印象的でした。 もう、何年になるのだろう。 ーーー A.C.

%d bloggers like this: