|
．リンカの吐いた map ファイルと、その exe の逆アセンブル結果、 そして drwtsn のログはサポートの三種の神器。 VC++ はいろいろ面白いコードを吐くので興味深い。 ．次回の A の B の記事にも書いたのだけど、 この手のスキルは職業プログラマに必須だと思う。 私自身、年に数回これを使って難を逃れているし。 まあ金にはならんが。 |
|
．どの記事とは言わないが、なんというか香ばしいですな ．順を追って挙げてゆくと、
．私はかねがね「日経シンドローム」というものがあると思っていたのだが、 こっちはさしずめ「/.J シンドローム」かね。 まあマスコミさんは多かれ少なかれこういう病に罹りやすいですわね。 |
|
．スレッド話 。 いずれにしろ問題は、そのベースポインタの算出方法なんですよね。 ．ところで、「log のオーダー」の後に「スレッドがものすごく多くならない」 というのを続けるのは微妙に違和感が。 いずれにしても、pthread_self が比較的ひんぱんに 呼ばれる可能性があることを考慮すると、 どちらかといえば微視的な削りが要求されるため、 オーダーだけで論じられる話でもない気はしますです。 このあたりは、CPU の d-cache の大きさや表のロックなどが絡んでくるので、 どうするのが最適なのかは一概には言いにくいですね。 ．逆に、本当に「多くならない」かというと疑問で、 システムの pthread サポートとしては、 最低でも 1 プロセス 1000 スレッドくらいのオーダーで ちゃんとスケールしてくれないと不満が残りますな。 あー難しい……。 ．一番簡単なのは、やはり専門のレジスタを用意することなんですよねぇ……。 とりあえず i386 など、そういうレジスタが用意できる環境に限定して、 まともに動くようにするのが先なんでしょうな。 それなら多分難しくないでしょう。 ．PEACE に限って言えば、libc などのロックプリミティブの面倒が 簡単に見られるようならば、libpthread を使わずに LWP を 直接使ってもいいのかもしれませんね。 Windows は 1:1 スレッドが基本ですから。 |
|
．4 人で呑み食い。 ．トリビア。某氏の某ひみつデータベースによると、 某くらげの某ラブエスカレーター焼き直し版の発売日変更は、 某店舗の発売予定情報の上で 11 回行われており、 これは観測史上 1 位タイである。 ．履歴: 「2002/04/26 → 2002/06/28 → 2002/夏予定 → 2002/08/予定 → 2002/秋予定 → 2003/06/27 → 2003/07/11 → 2003/08/01 → 2003/08/08 → 2003/08/29 → 2003/09/12 → 2003/09/26」 ．なお、あくまでも某店舗情報の発売日欄の更新が行われた回数なので、 延期回数とは限らない。たとえば、上の履歴では、 「2002/夏予定」が「2002/08/予定」になってるのは延期ではない。 でも 10 回延期。 ．「タイ」なので 11 回変更されてるのは他にもある。2 本もある。 でも、両方とも「未定」と「確定」を 3 回繰り返してるので、8 回延期。 こっちは両方ともすでに発売済み。 未発売のものだと、2 位は 7 回というのが二本。 |
