Ruby1.8.5、1.8.6、1.8.7のリリースマネージャを務め、現在は株式会社マネーフォワードでフルタイムのRubyコミッター職として働く卜部昌平（うらべ・しょうへい／@shyouhei）さんは、deoptimizationと呼ばれるアプローチを用いてRubyの高速化に取り組んでいます。 本稿ではその足跡から、いかなる思想のもとでデザインや実装を行っているかを、卜部さん本人が解説します。 Deoptimizationの着想に至るまで デザインとは、やらないことを決めること 「最適化が間違っていたら、戻す」をどう実装するか？ インストラクションを消し、跡地をnopで埋める 「メソッド呼び出しが省略可能であること」を判定するために 省略可能な呼び出され方を増やす 大き過ぎる問題ではなく、実現できる規模の問題に取り組む Deoptimizationの着想に至るまで 言語を高速化するときに、

概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: The Limits of Copy-on-write: How Ruby Allocates Memory 公開日: 2017/08/28 著者: Brandur サイト: https://brandur.org/ Unicorn（またはPumaやEinhorn）を実行していると、誰しもある奇妙な現象に気がつくでしょう。マスタからforkした（複数の）ワーカープロセスのメモリ使用量は開始当初は低いにもかかわらず、しばらくすると親と同じぐらいにまでメモリ量が増加します。大規模な本番インストールだと各ワーカーのサイズが100MB以上まで増加することもあり、やがてメモリはサーバーでもっとも制約の厳しいリソースになってしまい、しかもCPUはアイドル状態のままです。 現代的なOSの仮想メモリ管理システムは、まさにこの状況を防止するために設

Rubiniusをhackしたことは特にないが、中を軽く読んでおこうという気持ちになったので読んだ内容をメモしておく。今日初めて読んだ状態なのであまり参考にならないかもしれない。 歴史 2007あたり開発開始 v1 (2010) 「Rubyで実装されたRuby」 バイトコード仮想マシンはC++/LLVM LLVM JIT 世代別GC JRubyに次ぐ3番目にRailsが走ったRuby処理系 v2 (2013) 当時まだ出ていなかったRuby 2.1互換 GILなし、マルチスレッドサポートの向上 JITにより2-4倍程度まで高速化を達成 v3 (2016) ビルドにclang/clang++しかサポートしなくなった AOTコンパイルによるバイナリ生成もサポート 実行時にRubyを使わないようにした JITはバグが多かったため取り除かれた 特徴 2017/4/12時点ではRuby 2.3.1を

回答: 13年間、Rubyは十分高速でした。Rubyがさらに速くなるなら、私にとっては「おまけ」のようなものです。待ちわびてもいませんし、要求もしていません。また、開発状況にそれほど注意を向けてはいません。ですが、さらに速くなったら「どうもありがとう」という気持ちでいっぱいになるでしょう。これについては、実の所はあまり考えてはいないのです。 コンピューターの計算能力はとても良くなっていますし、私たちがビジネスを始めた時よりもかなり良くなっています。それに、当時からすでに十分な速度でした！ まぁ、これはBasecampのようなビジネスモデルの場合です。何百万ものユーザーの情報やページア...

Shiro Kawai まだ下書き Schemeの特徴をあげるときに、「継続」や「call/cc」が出て来ないことはない。 でも、R5RSのcall/ccの項をいくら読んでも、どうもよくわからない。 call/ccを使えばC言語のbreakみたいなのとか、コルーチンとかいう スレッドもどきとかが書ける、というのはわかったけど、一体そういうのが書けて 何が嬉しいのか、そこんとこがピンと来ないんだ。 今、そこにある継続 プログラミングの世界の概念には、禅の公案のようなものがある。 それを説明する文章はほんの一文なのに、最初に目にする時、 その文は全く意味をなさない、暗号のように感じられる。 だがひとたびその概念を理解すると、 その概念の説明は確かにその一文で説明されているのがわかるのだ。 そんな、「分かれば分かる」という禅問答の中でも 「継続」は最も謎めいたものの一つと言えるだろう。 文献を紐

先日、Emscripten & WebAssembly night !! #7というイベントにて、AsteriusというHaskellをWebAssemblyにコンパイルするツールについて紹介いたしました。 資料はこちら👇です。 AsteriusでHaskellの関数をJSから呼べるようにしてみた（けど失敗） 本日は、スライドの英語で書いていた箇所を和訳しつつ、いろいろ捕捉してブログ記事の形で共有します。 Link to here🔍Asteriusとは何か 冒頭でも触れたとおり、AsteriusはHaskellのソースをWebAssemblyにコンパイルするコンパイラーです。 GHCのHEAD（開発中のバージョン）を都度フォークして、現在活発に開発中です。 Template Haskellと、GHC標準におけるIOを行う関数（の大半）を除いた、すべての機能が利用できるようになっています

流れに便乗して私がソフトウェアエンジニアになるまでにやってきたことを書いてみます。学生を想定読者にしています。進路を考える時の参考になると嬉しいです。 私は修士一年の 2010 年に Google Japan の Chrome OS チームでインターンし、 2012 年に新卒のソフトウェアエンジニアとして入社しました。現在は東京オフィスの Chrome ブラウザの開発チームにいます。インターン中や入社後の仕事については以前「就職して 6 年過ぎた」という記事に書いたのでそちらも是非見てください。 本記事では学生時代に何を学び、それがどのように現在へと繋がっていったのか紹介します。ソフトウェアエンジニアとしての能力や経験をどのように磨いてきたかが中心です。面接を含む Google 固有の話題は他の記事で十分語られているのであまり書きません。 長文です。結論だけ読みたい人は『最後に』を読んでく

The Art of Concurrency和訳書籍への推薦文 訳者まえがき まえがき 1章　速くしたい人、手を挙げて！ 1.1　さまざまな疑問 1.1.1　スレッドモンキー 1.1.2　並列と並行：その違いは？ 1.1.3　そんなことを知る必要があるの？ どんな役に立つの？ 1.1.4　並行プログラミングって難しくないの？ 1.1.5　スレッドって危険じゃないの？ 1.2　スレッド化の4つのステップ 1.2.1　ステップ1. 分析：並行性を持つ部分を見つけ出す 1.2.2　ステップ2. 設計と実装：アルゴリズムをスレッド化する 1.2.3　ステップ3. 正当性の検証：スレッド化の誤りの検出と修正 1.2.4　ステップ4. 性能チューニング：性能ボトルネックの排除 1.2.5　スクラッチ開発 1.3　並列アルゴリズムの背景 1.3.1　理論モデル 1.3.2　分散メモリプログラミング 1.

概要 コレクションの要素の列挙・反復の方法には、 内部イテレータと呼ばれる方式と外部イテレータと呼ばれる2つの方式（デザインパターン）があります。 ちなみに、列挙（enumerate）と反復（iterate）ってのは、 この分野において、 「コレクション内の全要素に対して処理する」って意味ではほぼ同義語です。 ただし、 C++ の iterator が順方向・逆方向・双方向・ランダムアクセス可能なのに対して、 C# の Enumerator が順方向アクセスしかできないので、 そのイメージに引きずられて意味を使い分ける場合もあります。 百聞は一見にしかずということで、具体例を出しつつ内部イテレータと外部イテレータについて説明しましょう。 例ということで、余計な機能は一切省いた以下のような低機能リストを考えます。 public class List { int[] items; public

どうも、バックエンドエンジニアのサトウリョウスケです ✌︎('ω')✌︎ RubyKaigi 2018 から早 3 週間。この記事を読んでいる方でも参加された方が沢山いるのではないかと思います。 個人的な感想ですが、今年は例年以上に充実していたんじゃないかな、と大満足です✨ 感想記事はこちらの記事に詳しくまとめられています。 developer.feedforce.jp さて、今回の RubyKaigi の発表では笹田さんから Guild の進捗についての発表がありました。 この Guild の概要について社内のメンバーに解説したところ中々に好評だったので、今回の記事では Guild とはどういうものなのかを超ざっくりですがご紹介します。 そもそも論。なぜ Guild が必要なのか？ Guild と Thread の関係 Guild 間のデータの受け渡し おわりに そもそも論。なぜ Gui

はじめに 先月の4月4日に，自分が第一著者の原著論文が「Journal of Morphology」という雑誌のウェブサイト上で公開されました．該当論文の解説記事は後日公開するとして，今回の記事では，論文が公開されるまでの過程（原稿執筆・査読受理・原稿修正・採択通知受領）を書き綴っていきます．この記事を書く動機は主に，1年近くかかった作業の思い出を文書として記録したいこと，と，1年前の自分が論文を書くときに知りたかった論文採択までの流れを知見として残したいこと，の2つです．この記事で言う論文は全て原著論文（学術雑誌に掲載される論文）を指します．学会プロシーディングス・講演要旨・講演原稿などは，また別の媒体なので，区別してください．1年前の自分のように論文を出版したい，と思っているけれど何をどう進めていけばいいのか分からないという人のお役に立てば幸いです． はじめに 事前準備：論文に必要な結