もしコンパイラを全世界で同時にうっかり削除してしまったら、元の状態に復旧できるのだろうか？｜Rui Ueyama｜note
思考実験として、全世界の人が同時に、自分の持っているコンパイラやインタープリタなどの実行ファイルをうっかり全部消してしまったとしよう。そうするとそれ以降、ソースコードが残っていても、コンパイラ自身も含めてどのようなプログラムもコンパイルできなくなってしまう。この状況から人類は元のコンピュータ文明を復旧することができるのだろうか？ 僕は結論としては、かなり簡単に復旧できると思う。ここではその手順についてちょっと考えてみよう。 コンパイラのバイナリファイルが全部消えてしまった後、復旧のために目指すべきマイルストーンは、おそらくCコンパイラを元に戻すことになるだろう。Cで書かれたプログラムはOSやコンパイラ自身を含めてたくさんあるので、そこを起点にすれば、たくさんのプログラムを芋づる式に復旧していけるからだ。 ほとんどのCコンパイラはCかC++で書かれている。最近のGCCやClangは巨大かつC
十分大きな乱数をユニークな識別子として使うのがなぜ安全なのか｜Rui Ueyama
いろいろなソフトウェアで、大きいランダムな値をユニークな値とみなすということが行われている。例えばユニークな識別子としてよく使われるUUIDはただの122ビットの乱数だ。gitもSHA-1ハッシュ値が160ビットの乱数のように扱えることを期待して、それをユニークな識別子として使っていた。実際にはランダムな2つの値が同じになる確率はゼロではないのに、なぜこれが安全なやり方だと言えるのだろうか？ それについてちょっと説明してみよう。 あるシステムが、乱数で生成された識別子の衝突のなさに依存しているとして、仮に衝突が発生した場合、相当悪い結果、例えば復旧不可能な形でデータベースが壊れてしまうとしよう。これはどれくらい危険なのだろうか？ 数学の問題で、学校のクラスの中で同じ誕生日の人が1組以上いる可能性は思ったより高いという話を聞いたことがあると思う。あるランダムに生成された値が衝突する確率という
乱数生成器とゲームと諜報活動の話｜Rui Ueyama
ゲームなどを作っているとランダムさが必要になることがあるけど、コンピュータは基本的に毎回全く同じように動くので、乱数を作り出すのはそう簡単なことではない。Wi-FiやHTTPSなどの暗号は乱数のランダムさに本質的に依存しているので、高品質な乱数生成は世の中的にも重要な話題である。ここでは乱数生成について話をしてみよう。 ゲームではイベントがプレイヤーに予測不可能であればよいだけなので、真の乱数列ではなく擬似乱数列というものを使うことが多い。擬似乱数列は人間にはランダムにみえるけど、実際は何らかの数式によって順番に生成されているだけの数の列で、初期値を毎回違うものにしておくと、人間には毎回違う数列が生成されるようにみえる。初期値には現在時刻を使うことが多い。現在時刻は普通の用途では毎回違うからだ。 昔のゲーム機は現在時刻の設定がなかったので、ファミコンなどでは、起動してからの経過時間を疑似乱
スタンフォードのコンピュータサイエンスの授業の感想｜Rui Ueyama
いまのところ25単位分（マスター修了に必要な単位数の約半分）の授業を取ったので感想を時系列でちょっとまとめたい。昔のやつは記憶が曖昧になっているけど。 CS243 プログラムの解析と最適化 (2014Q4)要するにコンパイラの最適化の授業。前半はデータフロー解析とかでかなり実用的な感じがしたが、後半は行列計算の命令の依存関係を抽出してベクトル最適化とか、ItaniumみたいにレジスタのたくさんあるCPUでループアンローリングするみたいな話で、実際に役に立つのかはよくわからなかった。 と、そのときは思ったが、巨大な行列の計算はよくあるので、興味を持てなかった僕がダメだっただけかもしれない。 とにかく難易度が高かった。かなりがんばって夜中までやっていたつもりだけどもっと真剣に取り組むべきだったかもしれない。なにせこれが最初の授業だったのでレベル感がよくわかっていなかった。教授がドラゴンブックの
ソフトウェアの互換性と僕らのUser-Agent文字列問題｜Rui Ueyama
いろいろな環境で動くプログラムでは互換性のためにその場しのぎのことをしないといけないことがよくあるけど、歴史が積み重なってくると、アドホックな技の上にアドホックな技が積み上がる喜劇的な状態になることがある。こういう問題は認識するのは簡単だが直すことは誰にもできない。まさに僕がそのような体験をしたのでちょっと説明したい。 僕は仕事としてオープンソースのlldというリンカを書いている。リンカというのはコンパイラが生成したバイナリファイルをつなぎ合わせて最終的な実行ファイルやDLLを作成するプログラムで、知らない人も多いと思うけど、何をコンパイルしても最後にはリンカが動いている。lldは既存プログラムより何倍も速くてビルドが早くなるというので最近は結構人気が高まっていて、FreeBSDなどのいくつかのOSが全面的にスイッチしようとしたり、あるいは大規模プロジェクト（Chromeや、どうもFire
絵文字がある種のUnicodeバグを世界から一掃しつつある件について｜Rui Ueyama
UnicodeのUTF-16エンコーディングではほとんどの文字（コードポイント）は2バイトで表現されるが、Unicodeに後から追加収録された文字の多くは4バイトで表現される。4バイト文字がうまく扱えないプログラムというのはわりとよくある。しかし世界中で広く使われるようになった絵文字がよりによって4バイト文字であるせいで、そのような文字が扱えない問題がよいペースで解決に向かいつつある。それについて少し説明してみようと思う。 Unicodeが80年代から90年代初頭にかけてデザインされたときの目標の一つは、Unicodeに含まれる文字数を65536個以内に収めることだった。現代の文章を実用的なレベルで表すためには、漢字などを含めてもそれだけの種類の文字があれば十分だと考えられたのだ。当然これは1文字を2バイトで表すことを念頭に置いていた。つまりコンピュータの揺籃期から当時に至るまで単純に英語
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
