C++ のヘッダファイルを #include するだけで使える GC 書いてみた - kazuhoのメモ置き場
そういえば C++ のヘッダファイルを #include するだけで使える GC を書きました。使い方は下のサンプルコードを見てもらえばいいとして、特徴としては、 ヘッダファイルを #include するだけで使える C++ の標準機能だけを使っているのでポータブル*1 mark-and-sweep, precise GC ってなあたりでしょうか。コードは GitHub - kazuho/picogc: a tiny, portable, precise, mark-and-sweep GC in C++ にあります。 C++ のプロジェクトで、ちょっとここだけは GC がほしいんだけど、ってなケースで使いやすいと思います。速度も、そこそこでるんじゃないかな*2。 というわけで、以下、サンプルコード。軽く説明しておくと、 GC を使うクラスは picogc::gc_object を継承する
2010年代には Apache の mpm_prefork とか流行らない (もしくは HTTP keep-alive のメリットとデメリット) - kazuhoのメモ置き場
HTTP の持続的接続の功罪について はじめに、HTTP の持続的接続 (keep-alive) のメリットについて。持続的接続を使うメリットは、以下の２点。 TCP 接続の確立にかかる時間の節約*1 TCP の接続と切断に必要な資源 (CPUとネットワーク) の節約 ウェブブラウザ〜データセンタ間の通信で、持続的接続を使う理由は、このうちの前者。特に太平洋を超えるようなケースだと、TCP 接続に0.2秒とかかかるので、メリットが大きい。 一方、持続的接続のデメリットは、 接続が切断されるまでの間、その接続を維持するためにコストがかかる (主としてメモリが無駄になる) という点になる。特に、１プロセス１コネクションを前提とするアーキテクチャ (例: mod_perl) だと、メモリの無駄使いが、とてもひどいことになる。 そこで、ブラウザからの接続を受ける HTTP サーバとアプリケーション
死んだプロセスのスタックトレースを自動収集するデーモンを書いた (そして、その出力を開発者に送ってあげると喜ばれるよという話) - kazuhoのメモ置き場
死んだプロセス (あるいは kill したプロセス) の core イメージから自動的にスタックトレースを収集するデーモンを書いたので、これをセットアップしてサーバにインストールしとくといいかもです (kaztools/bt_cores at master · kazuho/kaztools · GitHub)。Linux のみ対応*1。使い方は bt_cores --help とするか、perl Makefile.PL && make install して man bt_cores。 具体的にいうと、Q4M とか Incline とか kazuho product が落ちたり固まったりしたらスタックトレース送ってくれると、私がうれしいです (古いバージョンのスタックトレースだととても悲しいです)。コアファイルは内部データがいろいろ入ってるから外部の人には見せられないけど、スタックトレース
はやいTCPサーバを書く際に忘れがちなこと - kazuhoのメモ置き場
はやいTCPサーバの書き方 - nyaxtのPC作業ログ で id:nyaxt さんが書いてらっしゃるように、 epoll や kqueue を使う TCP_NODELAY, TCP_DEFER_ACCEPT *1 等を活用する TCP パケットを意識する I/O システムコールの回数を最小にする sendfile といったあたりは、確実にやるべきことだと思います。一方で、TCP 関連以外のオーバーヘッドが実は結構あって、 接続のタイムアウト処理 ログの出力 メモリの確保や解放をやらない あたりにも気を配る必要がある、と思います。 接続のタイムアウト処理については、以前 Kazuho@Cybozu Labs: 高速なCometサーバを書いてみた件 に書いたように、ビットアレイのリングバッファを使うのがベストだと思います。 ログの出力について、複数行を１回のシステムコールにまとめてもいいかど
エッジトリガ (epoll) の話 - id:kazuhookuのメモ置き場
エッジトリガのメリットとしては、「データが貯まった状態で処理を後回ししても起こされない」というのもあるみたいだけど、これはEPOLLONESHOTというオプションを使うとレベルトリガでも実現可能。 epollであえてエッジトリガを使うとすれば、「ノンブロッキングI/Oでいつも最後までデータを読んでるから、レベルトリガはただの無駄だよねー」とかいうときの気持ちの問題ではなかろうか。 http://d.hatena.ne.jp/nishidakeisuke/20080703/p1 エッジトリガとレベルトリガで、コーディングの差が大きくなるのは、むしろデータを書く場合なんじゃないのかなぁ。レベルトリガだと、 send(2) が EAGAIN を返したら epoll に fd を登録 アプリケーション側のバッファが空になったら、epoll から fd を削除 というコードを書かないといけない (と
memcpy 最適化 - kazuhoのメモ置き場
バイト単位でコピーするアホなコードの方が、勝手にベクトル化される分、gcc 内蔵のヤツより最大３倍高速なんだってwww memcpy() compiled with vectorizing compilers All current compilers for linux should support SSE2 auto-vectorization with #include <string.h> void *(memcpy)(void *restrict b, const void *restrict a, size_t n){ char *s1 = b; const char *s2 = a; for(; 0<n; --n)*s1++ = *s2++; return b; }(中略) x86-64 gcc memcpy() (中略) Linking in a user-compiled
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
