JP Morgan Chaseがデリバティブ専用スパコンをFPGAで作った話 #fpgax - スティルハウスの書庫の書庫
金融系でFPGAというとHFTへの応用が知られてるけど、この事例はリアルタイムトレードの話ではない。金融業務で必要とされるバッチ処理やHPC（High Performance Computing）でもFPGAが本格的に使われ始めてるという話だ。 元ネタは、2011年にJP Morgan Chaseの人がスタンフォード大学で講演した内容。このビデオを見ていたらとっっっても面白かったので、 #fpgax 第3回で使う資料として要点を訳し、俺のコメントや補足を追加してみた。 http://www.youtube.com/watch?v=9NqX1ETADn0 （スライドはこちら） なお、FPGAも金融も素人なので、勘違いや誤訳があるかもしれない。FPGAとは何かよく知らない人はこちらをどうぞ。 リーマン・ショック対策のスパコン開発 JP Morgan Chaseは、社債やモーゲージ（不動産を担保
ハード素人が32bit CPUをFPGAで自作して動かすまで読んだ本のまとめ - スティルハウスの書庫の書庫
男子たるもの一度は自分でCPUを作ってみたいものだけど、ICでLEDをピカピカさせた程度の経験しかないハード素人な俺だったので、CPUを自作してる東大生などを遠くから見て憧れてるだけだった。しかしおよそ一年前のこと、「MIPSなんて簡単に作れますよ！」とKさん（←FPGAでLispマシンを自作するような人）に言われて、お、おぅ。。そりゃKさんはそうでしょうよ。。あれ、もしかして俺にもできるかな。。？ と思った。この一言がなければ32bitのCPUを自作しようなんて考えなかっただろう。 それから一年ちょい、とくに今年の正月休みやFPGA温泉でがっつりがんばって、なんとかMIPS Iサブセットの自作CPUが動いた。これはフィボナッチを計算してるところ。 ちなみに、これはこんな感じのフィボナッチのコードをCで書いて、 void main() { int i, *r = (int *)0x7f00
FPGAでジョインやソート - スティルハウスの書庫の書庫
ストリームやデータベースにおけるジョインやマージやソートのFPGA実装って、いまどこまで研究が進んでいるんだろう…と気になってて、その道の専門家である筑波大の川島さんに参考になるpaperをいくつか教えてもらった。これからゆっくり読む。 How Soccer Players Would do Stream Joins ストリームデータ同士を高速にwindow joinするhandshake joinという手法。これをベースに、三好さん＋オゲさん＋川島さんが世界最速のFPGA実装を作成されたとのこと。 Sorting Networks on FPGAs ハードウェアでソート！ FPGAs: A New Point in the Database Design Space FPGAでデータベースまわりの処理、あまり本文がないのでリンク集って感じ。 FPGA: What’s in it for
文字通り「ネットワークがコンピューター」な金融HFTでのFPGAの使われ方 - スティルハウスの書庫の書庫
ここのところ重度のFPGA中二病にかかってしまい、冬休み中もDE0ざんまいな日々。気になっていた金融のHFT（high frequency trading：大手投資銀行等がμ秒単位の超高速で株式等を売り買いしてる恐ろしい市場）におけるFPGA利用状況について、HFT Reviewにこってりしたレポート（HFT業界のベンダー各社にインタビューしたもの）が載っていたので、勢い余って面白かった部分を超訳してしまった。 元ネタはこちら： FPGA & Hardware Accelerated Trading, Part One - Who, What, Where and Why? FPGA & Hardware Accelerated Trading, Part Two - Alternative Approaches FPGA & Hardware Accelerated Trading, P
佐藤先生がErlang、Scala、Javaなどの並行処理を斬る！ - スティルハウスの書庫の書庫
ここ数日の佐藤先生のエントリが熱い！ Erlang、Scala、Go、Javaなどの現代の言語（Erlangは古いか）における並行処理の扱い方について、それぞれの歴史的背景や意義、得手不得手などがわかりやすく紹介されてます。80年代から並行処理やオブジェクト指向を研究されてきた佐藤先生ならではの視点ですね。ちょっと長くなりますが特に私が興味深かった部分を引用します（強調は私）： 佐藤一郎: Web日記 (2010年) 最近、興味深いのはオブジェクト指向言語のScalaやErlangが話題を集めていることでしょうか。どちらもActor Modelをベースにしているそうですが、オブジェクト指向言語の歴史でいうと、Actor Modelなどの並行処理用オブジェクト指向言語の研究が盛んになったのは1985年からの6,7年ぐらいだと思います(Actor Model自身はもっと古いですが)。そして19
#appengine MapReduceで毎秒2000件×8日間＝15億件を処理！ - スティルハウスの書庫の書庫
まだMapper APIのみの提供でReducer APIがないappengine-mapreduceライブラリについては、10万件のデータを対象としたテストでは1000件／秒程度で処理できたよというレビューをお届けしました。しかしApp Engineの中の人であるBrettさんは15億件のデータを対象としてmapper APIを試したところ、毎秒2000件以上のスループットを達成したそうです。以下におもな点を要約します： Brett Slatkin - One Big Fluke - Biggest Map() of my own. I recently ran the biggest Map() job of my life on my own data using the new App Engine Mapper framework: 1.5 Billion rows. The d
#appengine うそっ、私のMapReduce、遅すぎ？ - スティルハウスの書庫の書庫
Fredさんへの別件メール中で「Mapper API遅いなぁ〜」とちょっとグチをこぼしたら、「そんなはずはない」的なリアクションだったので、先日のテスト結果をお知らせしたところ、こんな返事が来ました： You can adjust the processing_rate to be higher. The default of 100 is to prevent you from eating through quota too quickly. In mapreduce.yaml (Python) you add: - name: processing_rate default: {some large number} We missed this in the documentation. Thanks for point this out. We'll fix that. Fredな
#devfest_jp 「Task QueueはMapReduceの夢を見るか？」の資料です - スティルハウスの書庫の書庫
DevFestの私のセッション 「Task QueueはMapReduceの夢を見るか？」の資料です。 Do Task Queues Dream of MapReduce? Tips and tricks about Google App Engine's Task Queue service and parallel processing with it. (by @kazunori_279) 1. What is Task Queue 2. Parallel Query Demo 3. The App Engine Parallelism 4. Concurrency Control on TQ まあ要するに「MapReduceほど大規模な並列処理にはならないけど、順次処理より数倍は速くなるよ」という趣旨です。 また、このセッションで使用する並列検索デモのコードはこちらで公開しています
BigtableとSmalltable - スティルハウスの書庫の書庫
App Engineによる設計手法でひとつ私が実案件で試してなかなかうまくいったと思ったのは、「Smalltable」って私が勝手に呼んでいるアーキテクチャです。簡単にいうと、「複数クライアントのローカルのSQLite間をDatastoreを介して同期する」仕組みです（こういうの一般に何パターンと言うのでしょう…教えてください！）。 クライアントはHTML5やAIR、iPhone、Android等のリッチクライアントで（実際に実装したのはAIRとiPhoneです）、SQLite等の小規模RDB（以下、Smalltable）をローカルに持つことが前提 Smalltableは、Datastoreが保持するすべてのデータのうち、そのユーザーが常時使用するデータのみ保持するサブセット アプリケーションの大半のロジックをリッチクライアント内のSmalltableだけで実装する すべてのレコードにはク
スティルハウスの書庫の書庫
スティルハウスの書庫というブログを2009年から2015年まで書いてたのだけど、はてなダイアリーからはてなブログにお引越しした。昔の記事を読んでたら懐かしかったので、思い出深いものをまとめてみた。 書き始めたきっかけがApp Engineだったので、前半は appengine ja night やApp Engineにまつわる記事がとっても多い。でも後半は #fpgax やハード系の記事が増えてる。あと、ちょこっとポエム系。 FPGA系の記事 FPGAをがんばって勉強してたころの記事。ちっちゃい32 bit MIPSを作って、フィボナッチのコードが動いたのですごく嬉しかった。 これも勉強になったな。Maxelerすごい。 株の売り買いっていうアプリ層のロジックを物理層でやっちゃう発想は大いに刺激を受けた。 App Engine系の記事 松尾さんがスター付けまくってくれたおかげでバズって、こ
App Engineと使うXMPPサーバーを探す - スティルハウスの書庫の書庫
今朝のtwitterはSDK 1.2.5のリリースで賑やかでした。Task Queueはもちろん、さっそく使ってみたいのはXMPPです。ちょうどぴったりな要件があったのですごく嬉しい。。 ただひとつ勘違いしてました。。App EngineのXMPPサポートってXMPPクライアント機能のサポートなのですね。。XMPPサーバーを用意するには、 Google Talkを使う すでにどこかで動いているXMPPサーバーを使う 自分でXMPPサーバーを立てる のいずれかが必要。まずGoogle Talkですが、 クライアントはGmailアカウントでログインする必要がある（事前にアカウントたくさん作っておいてプールして、クライアントにその都度配布するって方法もあるかな） そもそもGoogle TalkをSaaSとして利用して商用サービスを展開できるのか？（→Googleに問い合わせ中） といった課題あり
Bigtableと分散KVS・その2 - スティルハウスの書庫の書庫
ありがたいことに古橋さんに前回のエントリをご覧いただいたようで、大変ためになるつぶやきをされてたので、ここで引用させていただきます。 @frsyukiさん： 「分散KVS」という名前は何も考えていなくて、別に分散KVSにBigTableを含めても良くて、効率の話を問題にしていたけど、分かりにくかっただろうか…：http://bit.ly/IMFUs それはそれとして、効率について。概念的には、データモデルがmultidimentionalであることで、BigTableはアプリケーションに依存した情報をより多く知ることができる。これによって最適化をしやすくなり、効率が上がる。 例えば、Every read or write of data under a single row key is atomic を効率的に保証する、reads of short row ranges are effi
Bigtableと分散KVS - スティルハウスの書庫の書庫
首藤さんがUNIX managineに「key-valueストアという名前には、キーと値のペア（key-value pair）を格納するデータ格納ソフトウェアというくらいの意味しかない」と書かれていたように、KVSにはRDBのようなベースとなるデータモデルとか定義があるわけじゃありません。むしろRDBへのアンチテーゼとして登場している様々な非リレーショナルなデータストアを象徴するキーワードとして使われるケースが多いと思います（そういった意味でNoSQLっていう表現は的を射てますね）。 なので「Bigtableが分散KVSなのかどうか」という問いは、KVSの定義が曖昧な以上あまり意味のある問いではありませんが、しかし様々なKVS実装とBigtableは何が違うのかを知るきっかけとして気になりました。 古橋さんの分散KVSの使い方より： ここで言うところの分散KVSには、BigTableやCa
KVSやMapReduceはクラウドの真価ではない - スティルハウスの書庫の書庫
ちょっと逆説的に書きました。key-value store (KVS)やMapReduceは、クラウドにはなくてはならない重要な技術ではありますが、それらの技術単体では一般のエンジニアにとってそれほど価値はありません。もともと分散ストレージや分散処理技術は昔から学術研究の恰好のネタでしたし、最近になって技術的ブレークスルーがあったわけでもありません。 クラウドの真価は、「すでに巨大なクラウドがそこにあり、きちんと運用され、ビジネスモデルがある」ということです。学術研究や、まだ実績の少ないOSSフレームワークなどのレベルから、Google並の商用サービスに至るまでには、超えられない壁があります。例えばBigtable論文では、クラウドを構築して実運用することがいかに大変かが記されています。 One lesson we learned is that large distributed sys
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
