タグ

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

  • オープンソース活動がフルタイムの仕事になる仕組みの話|Rui Ueyama|note

    僕の仕事をひとに説明するときに、「Google仕事をしているけどオープンソースなのでGoogleのプロダクトを作っているわけではないし、むしろアップルとかソニーの人と一緒に仕事している」と言うと、「???」という反応になることが多いので、僕はこういう仕事をしているんだよということをここでちょっと説明してみようと思います。 (2016年の僕のFacebookの投稿の転載です。) 僕のいるチームはLanguage Platform Teamというところで、プログラミング言語や開発ツールの開発をしています。LPTの中にもいろいろ細かいチームが分かれているのですが、僕がいるのはC++チームで、Googleで主要開発言語になっているC++言語の開発環境を担当しています。 C++で開発をするときには、C++ツールチェインと呼ばれる一連のツールを使います。ツールチェインの一番大きなコンポーネントは、人

    オープンソース活動がフルタイムの仕事になる仕組みの話|Rui Ueyama|note
  • 意図的にプログラムの動きをランダムにしてバグを早期発見するテクニックについて|Rui Ueyama

    プログラムを書いていると、素直に実装した結果として毎回特定の条件が満たされているけど、来それは誰も保証してないという場面に出くわすことがよくある。保証されていない偶然の動作に依存することで生じるバグというのはかなり多い。 例えば最近では、ドラゴンボールZ ドッカンバトルというゲームで、2回SQL文を実行した結果が同じ順序で並んでいるという誤った期待をしているコードがあったせいで、ガチャの確率表示がめちゃくちゃになってしまって、運営が確率操作しているのではないかという騒動が発生したことがあった [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