Write Great Code (Vol.2) めちゃくちゃ分厚くて高い本．数日前に見かけて勢いで買ってしまった．おかげで今月は貧乏生活，朝はごはんとみそしるとさんまの蒲焼き缶詰に白菜漬け，夜はごはんとキムチと缶詰というほぼ白菜とさんまのみで生きている今日このごろ，みなさまいかがお過ごしでしょうか ? （3 缶で 295 円 ！！ 1 缶で 2 食ぶん…） 実はボクは，Vol.1 すら，IEEE 仕様の浮動小数点数演算をビット演算を使いまくってソフトウェア的に実装するところで疲れて (浮動小数点数とビット演算苦手なんですよ…)，積読の部分が多かったのですが (一応全体に目を通してはいる．最近は読みたい本が多すぎて，最初から最後まで精読する，ってのはあんまりできなくて，ざっと目を通しつつ，面白そうなところはじっくり読んで，的な読み方をすることが多い．あとは，必要になるたびに必要な部分を読

コードを読まないで理解するというと何やら心眼で読めとかテレパシーを使えとか、そーゆー荒唐無稽な方向に走れという事ではなく大局的に理解しましょうという話である。 カーネル読書会のネタで今回はmallocのお話だったのだが、そこでRubyのささださんがいらっしゃっていて、GC(ごみ集め)と記憶域管理の関係について熱い議論が沸騰し、その後いろいろブログなどでフォローされていたりする。 わたしもRubyでmallocやGCがどう実装されているか興味があったのでoprofileで実行プロファイルをとってみたりした。日頃利用しているノートPCでRubyのテストプログラム(test/runner.rb)を実行してoprofileしたのは先日ブログに書いたとおりである。 「それとわたしのノートPCではキャッシュミスを測定できないので、Xeonのマシンでキャッシュミスを測定すると面白いと思った。GCの時ぼろ

So, there are you. Logged into one of your production machines, staring at a rogue Ruby process, and wondering why it has been running away with 90% of the CPU for the last half hour. Sure, you can kill it, but you’d really like to know why it is stuck there. This isn’t the first time you’ve noticed this problem, and you’re getting a little tired of manually patching things up. But how do you figu

７月にLMSで発表したglibc mallocの解説を、ブラッシュアップしてYLUG・カーネル読書会でも発表してきた。 本人の知らない間にビデオ撮影をして、YouTubeにアップするとかいう話になっていたので、「ちょ・・業務用です・・・か？？」とでも言わんばかり、かなり本格的ビデオカメラが会場に設置されていた。 もうダメである。 緊張しまくり、用意しておいた小ネタギャグは一切言えなかった。 熱いトークを期待したいた皆さん（いるのか？）ごめんなさい。 てゆーか、ネクタイに指す、アナウンサー向けっぽげなマイクが用意されているあたりがYLUGスゴス。と思った。 まあ、それはさて置き、当日の感想としてはhyoshiokさんのBlogあたりの感想がよくまとまっていていい感じなのではないかと思う。 結論：　みんなRubyが好きなんだよ。 kernel hackerもLL hackerも交流しようよ と

第67回カーネル読書会のセミナー部分のビデオを公開した。今回はお題： glibc malloc について 発表者：小崎さん malloc関数はlibcの中でもっとも使用頻度が高い関数の一つでありながら、そ の実装の詳細は意外なほど知られていません。 Unix誕生当初のプログラミングスタイルでは、ほとんどのデータはスタックと グローバル変数に格納されており、mallocの使用頻度は低かったようです。し かし、今日ではGUI、スクリプト言語、C++といったmallocを多発するソフトウェ アが極めて一般的になり、mallocの性能の重要度は増しています。 こうした点に注目して、素朴な malloc では何が問題だったのか。また、 glibc malloc がどういった点に注力してチューニングされているのか。といっ た点を説明できれば。と思います。 資料はYLUGのホームページからダウンロードで

のでコンパイルできないコードが出るかもしれないとどっかのMLで出ていたのですが、実際どうなんでしょうね？ 過去のコードの継承性がライブラリレベルで失われる(例えばxmultiとか)だけでも面倒臭いどころかプロジェクト次第では致命傷になるのに、コンパイラレベルで継承性を失うと滅茶苦茶な事になるので不安があるのでおしえてえらいひ キャストに関していえば、最適化をかけると strict-aliasing が 有効になるため、かなり多くのプログラムで思わぬ結果をもたらします。 例えば、 long *v = malloc(sizeof(long)); *v = 0; *(short *)v = -1; printf("%ld\n", *v); printf("%ld\n", *v); を -O2 を付けてコンパイルすると、最初の出力は 0、次のは 65535 になります。 gcc の info にあ

プログラムの状態は変数の値の変化によって変化していくわけだが、変数は、宣言され、値を代入され、参照されるなどして利用される。 ポインタによって字面では変数が登場しなくても参照、変更される事もあるので油断禁物である。 またグローバル変数が嫌われるのは、ソースコードを局所的に調べていてもその代入、参照の範囲がつかめないからである。別のディレクトリに格納されている見た事も聞いた事もないファイルで変更されていて、当該ディレクトリをgrepしただけでは発見できなかったりする。 ローカルな変数ならばソースコードを静的に読解していけば、宣言、代入、参照それぞれが局所化しているので簡単に理解できる。 変更の影響もローカル変数ならば局所化されているがグローバル変数だとどこに影響が発生するかよくわからないのである。 さてブレークポイントを設定し、そこで実行が停止したとする。最初の仕事はその関数がどこから呼ばれ

「大規模ソフトウェアの効率的な理解(その1、2、3、4、5、6)」などという大袈裟なタイトルでブログを書いたが、今回は一気に実践編ということでフリーソフトウェア定番のデバッガ gdb の実践的使い方について記す。 プログラマの日々には、プログラムを書くためのエディタ、プログラムをコンパイル(あるいは実行)するためのコンパイラ(あるいはインタプリタ)、そしてプログラムを理解するためのデバッガという三種の神器が必須である。 この定番はわたしの場合xemacs/gcc/gdbである。前々職(DECという会社に務めていた)の場合、それぞれプロプライアトリな物を使っていたので微妙に異なるがやることは一緒である。 gdbは何のために利用するかというと、プログラムを理解するために利用する。デバッガなんだからデバッグのために利用するというのは、gdbの底力の半分も利用していないと言ってさしつかえない。 g

_ こいうのとか __attribute__((section (".interp"))) char x[] = "/bin/ash.static"; main() { puts("hello world!"); } 考えたけど LD script いじらないとダメなのでボツになった。 あと CTOR_LIST に勝手につけくわえるとかできんかと思ったけど これもできなかった。 (03:12) _ ふと発見みたいな http://gusmachine.blog49.fc2.com/ そう継続継続… いわゆる継続サポートと状態シリアライズは違う。 前者は Scheme でも Rhino でも。後者は Smalltalk でも Io でも。 あるいは JS の toScript() は？ 継続ベースのWebほげほげとかはほげほげ。 undump は結構マジ。 http://d.hatena.n

GCCでインラインアセンブリを使用 する方法と留意点等 for x86  (1999〜2006年10回改訂、2006年1月22日注意を追加、最終更新日2006年5月27日) 文: A. SAITOH <s-akira　at　users.sourceforge.net>　　home ※システム名、CPU名は一般に開発会社の登録商標です。 以下の情報はあまり過度に信用しないで下さい。より正確な情報は、asやgccのinfoから得て下さい。 個々のプロセッサ命令の解説はここでは述べません。そのような技術資料は、インテルやAMDのウェブ サイトのdeveloper向けのページからpdf形式で入手できます。 以下の文及びプログラム例の運用結果に関して、筆者は一切責任を負いません。 参考文献 [0] D. Stancevic, K. Scheibler, J. Leto, Linux Assembly