タグ

ブックマーク / hyoshiok.hatenablog.com (19)

  • 9月末で60歳定年退職しました - 未来のいつか/hyoshiokの日記

    当社の規定により満60歳で定年退職をした。長いようで短かった会社員生活も一区切りだ。自分のプログラマとしての会社員生活を振り返ってみる。無駄に長いし結論はないのでお忙しい人は飛ばして欲しい。 9月末なのでブログ界隈では退職エントリーがそこかしこに書かれると思うが、その中で自分の退職エントリーを連ねることにどれほどの意味があろうか。もちろんないのだが、それでも多くの書き手の年齢を考えると満60歳定年退職というところに若干の希少価値を見出せなくもない。 1984年に大学院修了して以来、プログラマとしてのキャリアを重ねてきた。大学時代の同期でプログラマとして就職したものは皆無だ。当時、工学部の同期はメーカーに就職するのがほとんどで、大手家電メーカー、自動車メーカー、電力会社などなど、当時の誰でも名前を知っている人気企業に就職するものが大半だった。 その中で、日ディジタルイクイップメント(DEC

    9月末で60歳定年退職しました - 未来のいつか/hyoshiokの日記
  • データベースでもっとも重要な3つのアイデア。(世界でもっとも強力な9つのアルゴリズム) - 未来のいつか/hyoshiokの日記

    昨日の日記には山のようにブックマークがついた。( 世界でもっとも強力な9のアルゴリズムを読んだ。 http://d.hatena.ne.jp/hyoshiok/20140209/p1 ) データベースはアルゴリズムじゃないだろうというツッコミもあるけど、偉大なアイデアということだろう。それは多分誰も異論はないと思う。そこで紹介されている3つのアイデアは ログ先行書き込み(WAL) 2段階コミット リレーショナルデータベース トランザクションと言う概念が70年代以降発展してきて、その実装にはログ先行書き込みが多大な貢献をした。 2段階コミットによって分散型データベースが信頼性をもって実装できるようになった。 リレーショナルデータベース(というよりもリレーショナルデータモデル)は全ての基盤になっている。 これらの発展は70年代のSystem Rの先駆的な研究開発から始まったといっても過言ではな

    データベースでもっとも重要な3つのアイデア。(世界でもっとも強力な9つのアルゴリズム) - 未来のいつか/hyoshiokの日記
    Wacky
    Wacky 2014/02/12
  • わたしがprintf()デバッグをしない理由 2009-03-22 - 未来のいつか/hyoshiokの日記

    プログラマという職業について、もう25年くらいになるのであるが、その間にコンピュータのコストパフォーマンスは、それこそムーアの法則に従って、10万倍〜100万倍くらい向上した。にもかかわらづ、デバッグの方法というものの劇的な変化はほとんどみられない。 プログラミング入門書では、デバッグについて、ほとんど議論されていないし、仮にふれられていても、おざなりな方法というか、かなり邪険にあつかわれていたりする。プログラマの多くの時間がデバッグについやされていたとしてもだ。 たまたま手元にあった、C実践プログラミング(ISBN4-900900-64-8)という10年くらい前に買った参考書では、450ページのうちデバッガの利用については、4行ほど記述がある。たった4行である。診断用のprintf()を挿入するということは3ページにわたって記述されているのにだ。 流石に21世紀になってprintf()デ

    わたしがprintf()デバッグをしない理由 2009-03-22 - 未来のいつか/hyoshiokの日記
    Wacky
    Wacky 2009/03/23
  • プログラムの動的で巨視的な理解 - 未来のいつか/hyoshiokの日記

    コードを読むな理解しろ。http://blog.miraclelinux.com/yume/2006/10/post_e3d6.html というわけでもないが、どのようにコードを読むかということはプログラマにとって大変重要な関心事の一つだと思う。誰もが良き読み手になりたいと願うが、誰もそのことについて系統的に教えてはくれない。それこそ一子相伝の謎めいた読み方がハッカーコミュニティの中で受けつがれていたりする。昨今でこそコードリーディングだなんだとその重要性を喧伝する人々が出てきたが、かつてはやはり黒魔術の世界であったりした。そもそも、良き読み手になるであろう脂の乗りきったプログラマを使いすてにするような社会では、良き読み手になる前に35歳定年だなんだで継承すべき技術を獲得するまえに一線を退いてしまう。人材の使いすての極みであるが、そのような事をここで嘆いてもしょうがない。 例えば、セキュリ

    プログラムの動的で巨視的な理解 - 未来のいつか/hyoshiokの日記
    Wacky
    Wacky 2009/02/05
    プログラムの理解の観点の二軸として、1) 静的理解、動的理解、2) 微視的理解、巨視的理解、というのをあげている。
  • 50代のお父さんのための自分SWOT分析 - 未来のいつか/hyoshiokの日記

    自分の人生を日記ネタにして生きているhyoshiokです。昨今の不景気風ビュービューふきすさぶ中、皆様いかがお過しでしょう。 ということで、日のお父さんのためのSWOT分析というのを考えてみた。ターゲットとなるのは50代、有名大学を出て大手企業に就職した、勝ち逃げ先行にはいろうとした50代前半。子供はまだ就職していないし、住宅ローンもかかえている、しがないお父さんである。わたしとの違いは、大手企業で安泰な生活と高収入。(わたしは中小零細企業でしょぼい給与←ここは泣くポイント) わたしと同世代の皆様向けに考えてみた。若い人は、10年後、20年後の姿として考えてみてほしい。 S(Strengths、強み) 大手企業で30年近く働いてきた経験、幅広い知識などは強みだろうなあ。やっぱし。大手企業なので、そこそこビッグプロジェクトも経験した。若いころは無茶もした、失敗も重ねた。海外生活も強みかもし

    50代のお父さんのための自分SWOT分析 - 未来のいつか/hyoshiokの日記
    Wacky
    Wacky 2009/01/05
  • grubの話を聞いた。 - 未来のいつか/hyoshiokの日記

    2008年日OSS貢献者賞のokujiさんにgrubの話をカーネル読書会でしてもらった。その時教えてもらった、リンクを貼っておく。(それといくつかの孫引き) ブートローダの作り方。http://enbug.tdiary.net/20050716.html#p03 How To Debug http://grub.enbug.org/HowToDebug GNU GRUB 2 Debugging with GDB HOWTO http://grub.enbug.org/DebuggingWithGDB A20 http://www.win.tue.nl/~aeb/linux/kbd/A20.html Debugging http://www.airs.com/ian/essays/debug/debug.html id:fslashtの参加レポート。第92回カーネル読書会行ってきました h

    grubの話を聞いた。 - 未来のいつか/hyoshiokの日記
    Wacky
    Wacky 2008/11/11
  • gdb豆知識 2008-09-26 - 未来のいつか/hyoshiokの日記

    意外と知っているようでよく知らない自分が日々使う道具。そこで、gdbについて復習がてらいろいろ調べることにする。 gdbemacsから使う gdbをコマンドラインから素で使うのはいかがなものかなと思う。やっぱemacsと固く結合されているわけだからemacsから使うのが正しい姿であろう。 「え〜、だってvi使いだし〜」とか「秀丸からは使えないんすかね」とか言うやつがいるが、秀丸ってなんだよ、とりあえづubuntuでも入れて、emacsいれて、gdb使いなさいとか指導したくなる。いかんいかん、説教くさくなってはいかんいかん。 先日もある会議でデバッガの話が話題になったのだが、「TCPなんちゃらのストール問題のデバッグ方法なんですけどね」、みたいな話題で、「それってカーネルの話?」とわたしが聞くと、「いや、ユーザランドっす」と若いハッカー、「じゃ、gdbでほげほげでいけそーね」、「そーっすね

    gdb豆知識 2008-09-26 - 未来のいつか/hyoshiokの日記
    Wacky
    Wacky 2008/10/22
  • 機械語ではマシンの挙動は理解できない - 未来のいつか/hyoshiokの日記

    実のところ機械語はマシンに対する高レベルな挙動を示す命令であって実行を厳密に写像したものではない。(何を言っているんだわたしは?) 「マシン語ってどんな感じか知りたくなった方へ」という大人気のエントリと、ニコニコ動画を見て、昨今の最新マイクロプロセッサでは機械語がもはや機械の挙動と一対一に対応しなくなっちゃったのである、というツッコミをしたくなった。http://d.hatena.ne.jp/shi3z/20070913 「水野拓宏のTK-80講座」これが素敵すぎる。http://www.nicovideo.jp/watch/sm1048903 最近のプロセッサ(Pentium 4とかXeonとか)は機械語を機械が直接実行するのではなく(じゃあ、なんで機械語というだよというツッコミは諸般の事情で却下(w))、機械語をμOPという機械語と一対Nに対応する命令に変換し実行するのである。Java

    機械語ではマシンの挙動は理解できない - 未来のいつか/hyoshiokの日記
    Wacky
    Wacky 2007/09/19
    μOPがどのくらい同時実行されているかは各プロセッサ(Xeonとか)の実装に依存する。
  • カーネル読書会 - 未来のいつか/hyoshiokの日記

    日、カーネル読書会だった。お題はalternativeマクロのお話。お題提供者のこさきさんは、薄めの話を持ってきました、などと言っていたが、「薄い話」とわざわざ言う奴ほど濃い話をするという法則のとおり濃いお話であった*1。(すばらしい) なんだかよくわからないのだが、IA32にはNOPと同様な機能をする命令が1バイトから7バイトまであるそうだ。通常のNOP命令は1バイト。0を足すみたいな命令も、使い方によっては、プログラム的には無効な作業なので、NOP的な命令と言えなくもない。そのような命令がいろいろあるらしい。 CISC(一つの命令のバイトの長さが異なる命令を持つコンピュータ)では1命令の長さがことなるのでいろいろなバイト長のNOPがありうる。自己書き換えプログラムである部分を書き換えたときの埋め草としてNバイトが必要だったらNバイト長のNOPを埋めればいいという話になる。例えば7バイ

    カーネル読書会 - 未来のいつか/hyoshiokの日記
    Wacky
    Wacky 2006/06/10
  • 2006-04-30

    ムーアの法則というのはIT業界にいるものなら誰でも知っている言葉だが半導体集積のペースは当面落ちそうにない。しかし、先に指摘したように(Google電気代)、無分別にプロセッサの周波数をあげていくとその二乗に比例して消費電力が上がるので、消費電力あたりの性能は下がってしまう。(周波数が2倍になったとして、消費電力が4倍になる、性能が4倍になるというわけではなくよくて2倍弱なので消費電力あたりの性能は下がる。)そうすると単位面積あたり倍になったトランジスタを何に使うかという話になる。 結局、マルチコアあたりになる。集積度をあげ、スーパーパイプラインだ、スーパースカラだ、アウトオブオーダーだ、といろいろ知恵を絞ってプロセッサの性能向上を図ってきたが、これをさらに推し進めるには設計が複雑化しすぎた。というような事かと思う。じゃあ、まあ、とりあえづ、設計をそんなに複雑にしないで、ひとつのコアの上

    2006-04-30
    Wacky
    Wacky 2006/05/03
    メモリが増えればソフトウェアに一切の変更なく自動的に性能が向上するという仕組みを埋め込んでいるのである。
  • 2006-04-17

    パソコンで最もよく利用されているエンコーディングの一つがシフトJISなのだが、その誕生については、なかなかまとまった資料がない。当時の関係者の証言を断片的にまとめたものしかない。 まづ小形さんの以下のBLOGとコメントを読む。当時の当事者が証言をしている。 http://d.hatena.ne.jp/ogwata/20051228/p1 シフトJISを発明したのは誰か? http://d.hatena.ne.jp/ogwata/20051229/p1 シフトJISを発明したのは誰か?(2) http://d.hatena.ne.jp/ogwata/20051230/p1 「BASIC80を漢字化した経理専用マシン」のこと http://d.hatena.ne.jp/ogwata/20060102/p1 たくさんのコメント、ありがとうございます 安岡さんの日記も参考になる。 http://s

    2006-04-17
    Wacky
    Wacky 2006/04/18
    古典的なデータ構造としてTLVというのがある。Tag Length Valueの3つ組。
  • spin-waitの実装とHyperThreading (MySQL) - 未来のいつか/hyoshiokの日記

    このところあるプロジェクトMySQLとPostgreSQLのベンチマークを行っている。OSDL DBT-1というTPC-Wのようなベンチマークを実施している。PostgreSQLは某社の16CPUというとてつもないマシンでの計測で、U社の皆様が計測したデータに対していろいろレビューをしたり考察をしている。MySQLの方はSC社と共同でIntelのDual-CoreマシンでHyperThreadingをONにしたりOFFにしたりしてその挙動を調べている。 IntelのHyperThreading(以下HTと記す)というのは非常に大雑把に言えばCPUチップの中に各種レジスタを2セット用意し、同時に2つの実効ができるという代物である。完璧に2つのCPUがあるのではなく、キャッシュは共有していたり、見えないところでいろいろ制約がある。 HyperThreadingをONにして、ある条件のもとDB

    spin-waitの実装とHyperThreading (MySQL) - 未来のいつか/hyoshiokの日記
    Wacky
    Wacky 2006/04/15
    HyperThreadingをONにして、ある条件のもとDBT-1を実行すると性能が劣化する場合があることを発見した。
  • 2005-12-03

    大盛況である。100名を越す参加者。うーん、すごい。IIJの会場がとってもりっぱでうらやましい。(カーネル読書会でもぜひお借りしたいところだ) ネタはCache Pollution Aware Patch(CPAP)。この日記では再三取り上げているのでお馴染みのネタである。ライトニングトークなので5分で伝えることができたかどうか微妙である。メモリアクセスは非常に遅いのでキャッシュを上手に使いましょうね、というだけの話と言えば話である。時間的局所性がない場合(すぐに再利用されない場合)はキャッシュに載せないようにするほうが圧倒的にキャッシュミスを減らせるので速度向上に繋がる。http://www.ipa.go.jp/software/open/forum/development/download/051115/OS-cpu.pdfを参照のこと。 http://namazu.org/~sato

    2005-12-03
    Wacky
    Wacky 2005/12/03
    Binary 2.0で発表。
  • OProfile - 未来のいつか/hyoshiokの日記

    OProfile http://sourceforge.net/projects/oprofile/ を利用するとキャッシュミスの場所を特定してくれる。非常に簡単に特定してくれるのでそれをヒントにいろいろ性能向上をはかれる。もちろんOProfileの限界もいろいろある。OProfileはキャッシュミスのイベントの「どこ」を特定するが「なぜ」は教えてくれない。それは自分で考えないといけない。write cache missかread cache missかも教えてくれない。(IA-32のイベントマスクをちゃんと設定すると教えてくれるかもしれないと、この日記を書いていて思いついたが、あとで調べることにする) キャッシュミスの時間的局所性についても教えてくれない。あるデータへのアクセスがキャッシュミスをしてその結果そのデータがキャッシュにのったとして、そのデータへのアクセスがキャッシュにのってい

    OProfile - 未来のいつか/hyoshiokの日記
    Wacky
    Wacky 2005/10/16
    OProfile http://sourceforge.net/projects/oprofile/ を利用するとキャッシュミスの場所を特定してくれる
  • 2005-10-13

    Intelのマニュアルの話は幾度となくしたが*1、先日ハードコピーを1セット発注して*2、最近ではIA-32 Intel Architecture Optimization Reference Manual 016版 *3を愛読書としている。昔持っていた版は004版(ぼろぼろだ*4)なので最新版(016版)ではいろいろ記述が追加されている。cache周りのことも随分記述が充実している。004版の厚みは18mmで016版は28mmだ。 付録BのIntel Pentium 4 Processor Performance Metrix、Microarchitecture Notesが必読だ。Bus and Memory Metricsを読む。図B-1 Relationships Between the Cache Hierarchy, IOQ, BSQ and Front Side Busにキャ

    2005-10-13
    Wacky
    Wacky 2005/10/16
    Intelのマニュアルの読み方
  • 2005-09-03

    Computer Architecture, Third Edition: A Quantitative Approach (The Morgan Kaufmann Series in Computer Architecture and Design) 作者: John L. Hennessy,David A. Patterson出版社/メーカー: Morgan Kaufmann発売日: 2002/05/15メディア: ペーパーバック クリック: 30回この商品を含むブログ (11件) を見る Computer Architectureの教科書と言えばこれだ。これをすみからすみまでよむ。いつのまにかに第3版になっている。キャッシュの話はこので学んだと言っても過言ではない。 最新版2.6.13でlmbenchを流してみた。2.6.12.4.ntと2.6.13.ntが今回のパッチをあてたもの

    2005-09-03
    Wacky
    Wacky 2005/09/19
    Computer Architecture: A Quantitative Approach
  • ダンプ解析パターン集 - 未来のいつか/hyoshiokの日記

    大きなマシンを借りてベンチマークプログラムを流す。流す。流す。一回あたりの実行時間はものの数分なのであるが、大きなマシンなのでリブートに非常に時間がかかる。大きなマシンなのでというのは、なにが、「〜なので」なのかはわからないが、ともかくそのマシンはそこらへんにあるPCサーバーを物理的に大きくしたような感じのものだから起動時にはBIOSのようなものが走りそれが起動時間のほとんどをしめているというような構成のマシンである。 CPUは16個もついている。CPUのスケーラビリティをはかるため、CPUの数を変化させ同じベンチマークを流す。CPUが1個、2個、4個、8個、16個の時のそれぞれの実行性能を測定する。Linuxカーネル内のボトルネックを発見するために、おなじみのoprofileやらLKSTを仕込んだりして計測している。 http://www.ipa.go.jp/software/open/

    ダンプ解析パターン集 - 未来のいつか/hyoshiokの日記
    Wacky
    Wacky 2005/09/19
  • 2005-09-11

    Computer Architecture, Third Edition: A Quantitative Approach (The Morgan Kaufmann Series in Computer Architecture and Design) (CA:AQA)によればメモリアクセス性能を上げるには 平均メモリアクセス時間=ヒット時間+キャッシュミス率*ミスペナルティ となるので、ヒット時間(キャッシュにヒットした時のアクセス時間)をさらに短くするか、キャッシュミス率を下げるか、ミスペナルティ(キャッシュミスした時のアクセス時間)を下げるという方法がある。例えばL1ヒット時間が1ns(ナノセカンド、10億分の1秒)でL2ヒット時間が5ns、メインメモリアクセスが150nsで、L1ヒット率が9割、L2ヒット率が9%、とすると、 平均メモリアクセス時間=1 + 0.1*(5 + 0.1

    2005-09-11
    Wacky
    Wacky 2005/09/19
    CPUのキャッシュヒットの計算方法について
  • Cache pollution - 未来のいつか/hyoshiokの日記

    今年の夏は朝から晩までLinux Kernelのチューニングをやっていた。端的に言うとLinux kernelでキャッシュミスが多発しているところを発見してそれを解消するパッチを作ったので、その評価をひたすらやっている今日この頃である。 http://marc.theaimsgroup.com/?l=linux-kernel&m=112489315002172&w=2 cache pollutionという話題は昔からよく知られている話題なのであるがOSのカーネルをそれを防止することによって性能向上を図るという話は、どうなんだろうか、わたしの不勉強かもしれないがあまりないような気がしている。 最近のプロセッサではMMX/SSEみたいなマルチメディアストリーミング対応の命令セットが実装されているが、それとの絡みでcache pollutionの話題が出てくるが、Linuxカーネルではその手の命

    Cache pollution - 未来のいつか/hyoshiokの日記
    Wacky
    Wacky 2005/08/27
    ノンテンポラルMOVE命令で、Cache pollutionを避ける
  • 1