タグ

ブックマーク / note.com/ruiu (6)

  • 「悪い方が良い」原則と僕の体験談|Rui Ueyama

    ソフトウェアの世界には「悪い方が良い」原則という有名なエッセイがある。キレイにレイヤ分けされた一貫性のある良いデザインよりも、一見手抜きっぽい悪いデザインのほうが実は良いときもあるという話だ。この逆説的なデザイン原則を僕は身をもって体験したことがある。それについてちょっと書いてみようと思う。 僕はlldというリンカの現行バージョンのオリジナル作者だ。リンカというのはコンパイラと組み合わせて使うもので、実行ファイルやDLLを作るのに使用される。lldはプロダクトとしてはかなり成功していて、標準のシステムリンカとして採用しているOSがいくつかあったり、GoogleやFacebookなど皆が知っているような大規模サイトの中で広く使われていたりする。 現在のlldは2世代目で、第1世代のlldは僕がプロジェクトに参加する前から存在していたのだけど、数年前にそれを捨てて一から書き直すということになっ

    「悪い方が良い」原則と僕の体験談|Rui Ueyama
  • x + 0.25 - 0.25 = xが成り立たないxとは何か|Rui Ueyama

    スタンフォードのコンピュータサイエンスの授業で、ときどきこれは良問と思う問題がテストで出ることがある。僕の印象に残っているのは「xをfloatとするとき、x + 0.25 - 0.25 = xが成り立たないxを求めよ」というものだ。浮動小数点数を理解していないと、両辺が同じにならないケースがあるほうが不自然に思えるだろうから、この問題は浮動小数点数の奇妙さを結構うまく突いていると思う。この問題を元に浮動小数点数についてちょっと説明してみよう。 まずコンピュータ上での数について少し考えてみよう。コンピュータにおける数と、数学の整数や実数は、よく考えてみると全然違う。コンピュータは有限の記憶領域しか持っていないので、無数にある数を表すことが根的にできない。つまりコンピュータ上の数は「物の数になるべく似せた別の何か」だ。現実的には、例えば32ビットの数なら2^32パターンしか表せないので、そ

    x + 0.25 - 0.25 = xが成り立たないxとは何か|Rui Ueyama
  • エレベータに見るアルゴリズムの性能と公平性のバランス|Rui Ueyama

    現実世界でもコンピュータの中でも、何らかの性能指標だけを追求すると参加者にとって極端に不公平になってしまうことがある。例えばエレベータとHDDは共通点がありそうに思えないが、この2つは性能特性的にとてもよく似ていて、リーズナブルな性能と公平性を両立させるために同じ制御方法が使われている。これについてちょっと説明してみよう。 1基しかない場合のエレベータの動き方は単純だ。一度上に動き出すと、上で待ってる人や降りる人がいる限り上昇し続ける。同じように、一度下に動き出すと、下で待っている人や降りる人がいる限り下降し続ける。これ以外の動き方をするエレベータはまず存在しないので、これが唯一の制御方法のように思えるけど、別にこうしなければいけないというルールはない。 エレベータの平均待ち時間を最適化することを考えてみよう。そうすると、一方向に動き続ける代わりに、エレベータが現在存在する階に一番近い人の

    エレベータに見るアルゴリズムの性能と公平性のバランス|Rui Ueyama
  • メモリのビット反転エラーとセキュリティの話|Rui Ueyama

    ハードウェアのエラーでメモリの内容が化けてしまうことが稀にある。大抵のDRAMエラーはせいぜいプログラムがクラッシュする結果になるだけだが、データ破壊になることもありえるし、悪意のある使い方をすればセキュリティ破りに使うこともできてしまう。ここではメモリエラーとセキュリティの話をしようと思う。 メモリのエラー率は意外なほど高い。データセンターで大規模なマシン群を対象に実際に観測したところ、1年間に1回以上のエラーが発生したDIMMモジュールは全体の8%にのぼったそうだ。DIMM 1枚に数百億個のメモリセルが実装されているといっても、このエラー率はちょっとびっくりするくらい大きな数字ではないだろうか? サーバでは普通はエラー訂正付きのDIMMを使うので1ビットのエラーは問題にならないが、エラー訂正のないコンシューマ機器ではこれは実際的な問題になりえる。 メモリエラーを利用したセキュリティ破り

    メモリのビット反転エラーとセキュリティの話|Rui Ueyama
  • 「プログラミングの常識」を時々見直す必要性について|Rui Ueyama

    自分の中のプログラミングの常識というものは、ときどき現実のハードウェアに合わせて調節しないといけない。ハードウェアが進歩し続けているので、コンピュータで簡単にできることと相対的に難しいことのバランスが変化し続けているからだ。ここでは特にストレージにフォーカスして書こうと思う。 昔はメモリが相対的にとても貴重な資源だったので多くのプログラマがメモリを節約することに血道を上げていた。例えばWindowsの初期の頃に設計されたデータ構造には、メモリをバイト単位ででもいいから節約したいという意図の痕跡がいまでも多く見受けられる。DRAMの次に速い記憶装置はHDDだったので、メモリが足りなくなればHDDにデータを保存せざるを得ないのだが、DRAMとHDDのランダムアクセスの速度差は、机の上のの開いているページを見るのと、そのAmazonで注文して到着するのを待つのと同じくらいのスケールで違うの

    「プログラミングの常識」を時々見直す必要性について|Rui Ueyama
  • スタンフォードのコンピュータサイエンスの授業の感想|Rui Ueyama

    いまのところ25単位分(マスター修了に必要な単位数の約半分)の授業を取ったので感想を時系列でちょっとまとめたい。昔のやつは記憶が曖昧になっているけど。 CS243 プログラムの解析と最適化 (2014Q4)要するにコンパイラの最適化の授業。前半はデータフロー解析とかでかなり実用的な感じがしたが、後半は行列計算の命令の依存関係を抽出してベクトル最適化とか、ItaniumみたいにレジスタのたくさんあるCPUでループアンローリングするみたいな話で、実際に役に立つのかはよくわからなかった。 と、そのときは思ったが、巨大な行列の計算はよくあるので、興味を持てなかった僕がダメだっただけかもしれない。 とにかく難易度が高かった。かなりがんばって夜中までやっていたつもりだけどもっと真剣に取り組むべきだったかもしれない。なにせこれが最初の授業だったのでレベル感がよくわかっていなかった。教授がドラゴンブックの

    スタンフォードのコンピュータサイエンスの授業の感想|Rui Ueyama
  • 1