マルチコア時代の高並列性IOアーキテクチャ Wavy - Blog by Sadayuki Furuhashi
シングルスレッドではもう遅い。 以前にマルチコア時代の高速サーバーの実装で、「ネットワークIOはマルチスレッドで動かすが、その他の部分はシングルスレッドで動かす」というIOアーキテクチャの実装（mp::iothreads）を紹介しました。iothreadsはロジック部分をシングルスレッドで書けるため実装の手間を抑えることができ、ネットワークIOがボトルネックになるプログラムには特に適していると思われます。 しかし実際にiothreadsを使ってプログラムを書いてみると、非常に負荷が高い状況でシングルスレッドの部分の処理速度がボトルネックになってしまうことがありました。 そこでマルチコアCPUの性能を引き出すために、徹頭徹尾マルチスレッドで動かすIOアーキテクチャを実装してみました。 1つのスレッドが、ある時はepoll_wait()し、ある時はread(2)を行い、ある時はイベントを処理す
スレッド間通信のオーバーヘッドを比較する - Blog by Sadayuki Furuhashi
pthread_系の関数は mutex か cond しか待てないが、select/poll/epoll はファイルディスクリプタしか待てないので、両方待ちたいときに困る。 解決方法はいろいろあると思いますが、私の思いつく範囲では以下の４つ。 selectで待ち、シグナルで割り込む ファイルディスクリプタはselectで待つ。他のイベントはいったんキューに入れておき、シグナルを発生させてselectを中断させる。たしかlighttpdはこの方式だったはず。ただlighttpdはシングルスレッドなのでキューは使っていなかったような（うろ覚え） selectで待ち、パイプで割り込む selectで待つのだが、その中にpipe(2)で作ったパイプを１つ食わせておく。ファイルディスクリプタ以外のイベントはいったんキューに入れておき、パイプに1バイト書き込んでselectを中断させる。 select
MessagePack 0.2.0 リリース！ - Blog by Sadayuki Furuhashi
バイナリシリアライズ形式 MessagePack の２回目のリリースです。 フォーマットの仕様はそのままで、C++用のAPIを大幅に強化しました。詳しくは：サンプルコード msgpack-0.2.0.tar.gz MessagePackとは MessagePackは効率を重視したデータ交換用のフォーマットで、言うなれば「速いJSON」です。 データ型を持つシリアライズ形式（JSONやYAMLと同じ。整形式XML文章とは異なる） フォーマット定義（IDL）が不要 シリアライズ/デシリアライズがとても高速 シリアライズされたデータのサイズが小さい ストリーム処理できる いまのところ Ruby、C、C++ で使える 作りかけのActionScript版（lp:~frsyuki/msgpack/as3） プロトコルを実装する手間を省ける ネットワークで通信を行うプログラムを書くときは、ぜひ高速なバ
memstored 0.1 = memcached + mpio + Tokyo Cabinet - Blog by Sadayuki Furuhashi
memstored は memcached のバイナリプロトコルをサポートしたハッシュストレージサーバーです。IO戦略ライブラリmpio の信頼性と性能をテストするために開発しました。 IOに mp::iothreads を使用し、バックエンドには Tokyo Cabinet の抽象データベースAPIを利用しているため、高速でスケーラビリティが高く、かつ柔軟性の高いアーキテクチャになっています。プログラムの大部分はライブラリによって実現されているため、プログラム全体の見通しが良く、行数で見ても非常に小さく収まっています。 SVN (memstored): http://svn.coderepos.org/share/lang/c/memstored/trunk SVN (mpio): http://svn.coderepos.org/share/lang/c/mpio/trunk パッケー
Protocol Buffersは遅い - Blog by Sadayuki Furuhashi
Google の Protocol Buffers は、同技術と競合するバイナリシリアライズ形式である MessagePack と比べて、場合によっては 19倍 以上遅く、シリアライズ後のデータサイズは 7倍 以上になることがあります。平均的に見ると MessagePack の方が高速であり、高い性能が必要とされるなら Protocol Buffers より MessagePack を選択するべきです。 …とはいえどちらも非常に高速なので、実際にはそのAPIの違いで選んだ方が良い。Protocol Buffers と MessagePack は重視している点が異なり、使い勝手は大きく異なる。 Protocol Buffers とは何か Protocol BuffersはGoogleが開発したバイナリエンコード手法で、以下のような要素が提供されます： データフォーマットを記述するための言語（
バイナリシリアライズ形式「MessagePack」 - Blog by Sadayuki Furuhashi
Googleが公開したバイナリエンコード手法であるProtocol Buffersは、クライアントとサーバーの両方でシリアライズ形式を取り決めておき（IDL）、双方がそれに従ってデータをやりとりするようにします。 この方法では高速なデータのやりとりができる反面、IDLを書かなければならない、仕様を変えるたびにIDLを書き直さなければならない（あらかじめしっかりとIDLを設計しておかないとプログラミングを始められない）という面倒さがあります。 ※追記：Protocol BuffersのデシリアライザはIDLに記述されていないデータが来ても無視するので（Updating A Message Type - Protocol Buffers Language Guide）、仕様を拡張していっても問題ないようです。 一方JSONやYAMLなどのシリアライズ形式では、何も考えずにシリアライズしたデータ
「Metal」 based on Parsing Expression Grammar - 古橋貞之の日記
Parsing Expression Grammar (PEG)をベースとした構文解析器を生成するパーサジェネレータMetalを作りました。Rubyで書かれており、Rubyのコードを生成します。 Metalの多くはOMeta: an Object-Oriented Language for Pattern MatchingをRubyに移植したものです。 Metalの特徴： Rubyでアクションが書ける オブジェクト指向（継承、Mix-in、委譲、オーバーライド、super） PEGの特徴はそのまま 曖昧さが無い 左再帰が書けない（いまのところ） メモ化する ソースコードはCodeRepos:/lang/ruby/metalにあるので、ガツガツいじれます。 使い方 Ruby gemsでインストールできます。 $ gem install metal 文法定義ファイルを書いて、metalコマンド
Blog by Sadayuki Furuhashi
MessagePackフォーマット仕様のPull Request #209をマージし、MessagePackにTimestamp型を追加しました。 ※この記事の英語版は XXX にあります（翻訳中） Extension型の型コード -1 として定義されているため、後方互換性が維持されています。つまり、既にExtension型に対応しているデシリアライザであれば、Timestamp型を使用して作成されたデータを、Timestamp型に対応していない古いデシリアライズで読み出すことができます。 新しいTimestamp型には timestamp 32、timestamp 64、timestamp 96 の3つのフォーマットがあり、よく使う値をより少ないバイト数で保存できるようになっています。例えば、1970年〜2106年までの時刻で、秒までの精度しか持たない時刻であれば、合計6バイトで保存でき
Aerial（エアリアル） - Ajax/Cometの次を行く リアルタイム双方向RPC - Blog by Sadayuki Furuhashi
JavaScript - サーバー間で双方向のRPC通信を行う技術は「Aerial」（エアリアル）という名前になりました*1。アイディアを出していただいた皆様、ありがとうございましたm(_ _)m Aerialは、通信にFlashを使い、JavaScriptとサーバープログラムとの間で双方向のRPC呼び出しを行う技術です。つまり、サーバー側からJavaScriptのメソッドを呼び出したり、逆にJavaScriptからサーバー側のプログラムを呼び出したりします。 サーバーから直接JavaScriptのコードを呼び出したり、逆にJavaScriptからサーバー側のメソッドを呼び出したりできるので、通信の内容を意識する必要がなく、バグの混入を抑えます。RPC成分入り！ ライブラリを開発するときも、HTTPやブラウザ間の実装の違いを意識する必要も無く、ごく普通のTCP接続で通信を行うので、Come
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
