分散ワークフローエンジン『Digdag』の実装 at Tokyo RubyKaigi #11 - Download as a PDF or view online for free
Ruby で String オブジェクトを複製しても、文字列データは複製されません。 data = "a"*10*1024*1024 system "grep ^VmSize /proc/#$$/status" t1 = Time.now a = [] 100.times do |i| a.push data.dup end t2 = Time.now system "grep ^VmSize /proc/#$$/status" printf "%.6f\n", t2-t1 実際に10MBの文字列を作って、100回dupする前後でプロセスのメモリサイズを比較してみても変わってません。 % ruby hoge.rb VmSize: 56140 kB VmSize: 56140 kB 0.000164 複製後に文字列を変更すると、そこで文字列データも複製されます。 data = "a"*10*
regional.rubykaigi.org 東京Ruby会議11で「Rubyに型があると便利か」という発表をしてきました。 speakerdeck.com 何百人もの人に30分も時間をとってもらって話を聞いてもらうのは物凄く贅沢な時間だと思います。 トークを聞いていただいた皆様。声をかけていただいた皆様本当にありがとうございました。 発表内容についてはるびま記事としてまとめる予定ですのでお楽しみに。 みんなちがって、みんないい 今回の東京Ruby会議11は本当にそれぞれが非常に濃い内容だったと思う。 正直発表の7割ぐらいはよくわからなかった。 しかしそれでいいんだと思う。 東京Ruby会議11の目的にはこうある 技術的好奇心を改めて呼び起こし、プログラミングの難しさ、そして楽しさを再発見する場を目指します。 例えば火星がポンとあってもわけがわからない。 でも、「もっと知りたい」という好奇
(5/29 追記:Deep Learning のGoogleグループコミュニティを追加) (6/8 追記:松尾研究室の勉強会ページを追加) (6/13 追記:neural language notesを追加) はじめまして。@aonotas(あおのたす)です。 Deep Learningと自然言語処理に興味があります。 好きなフレームワークはChainerです。 さて、Deep Learningが自然言語処理のタスクでも応用されています。 ACLやEMNLPなど国際会議でもタイトルに「Neural」が入ったものが多いですが、arxivにも査読前の論文がよくアップロードされています。 (スピードが早くて追いつくの大変ですよねorz) そこで最新のDeep Learningの論文の集め方を紹介したいと思います。(あくまで私個人の方法です。皆さんどうしてるか教えてもらえると嬉しいです。) 面白い
移転しました。 https://chezo.uno/post/2016-05-29-sonomoderu-guo-xue-xi-siteruno-wei-xue-xi-nano-tokun-tutara/
qiita.com これの話。ブコメに書こうとしたら4000字は入らなかった。 Microsoft Java VM かつての WIndows には MS 製の Java VM が搭載されていました。 古代の Java は「Write once, run anywhere」を掲げていた通り、クライアントサイドで Java アプレットとして利用されるのが主流でした(サーバーサイドで動くようになって、真価を発揮した感じがあります)。 しかし Java VM の仕様は、パフォーマンスについての記述は曖昧になっており、OS ごとの実装の違いによって、実行速度に顕著な差がありました。 Windows の Sun 純正の Java VM は性能が悪かったため、MS は独自の Java VM を開発し、Internet Explorer にバンドルしました。調子に乗った MS は Windows GUI
チーフエンジニアの id:Songmu です。 4月に 新人エンジニア研修を行なった のですが、その際に、「インフラを意識したアプリケーションの書き方」という講義を担当しました。そこでおこなった講義の内容について整理しながら書き起こしていきたいと思います。 インフラを意識すると何が良いか 業務でWebアプリケーションを扱うと、個人ではなかなか扱えないトラフィックであったりデータ量を扱うことになります。小規模サービスでは考えなくてよかった多くのことを考慮する必要がでてきます。なかなか体験できないことでもあるので、楽しく、やりがいもあります。 また、そういった経験を通して、インフラを意識しコードをかけるスキルを身につけることは、Webエンジニアとしては大きな強みとなります。ISUCONで優勝できるかもしれません*1。 インフラを意識すると何が良いか 〜 中規模ベンチャーの場合 そもそも、はてな
アプリケーションのパフォーマンス問題の解決やチューニングで大切なのは問題のコアやボトルネックに最短パスで到達することである. 基本的なパフォーマンス分析の入り口はアプリケーションのスレッドがon-CPUで時間を消費しているかoff-CPUで時間を消費しているかを理解するところから始まる.on-CPUの場合はそれがuserモードかkernelモードかを特定し,さらにCPUプロファイリングによってどのcode pathがCPUを消費しているのかの分析に向かう.off-CPUの場合はI/OやLock,pagingといった問題の分析に向かう. Flame Graphはon-CPUでのパフォーマンスの問題が発覚した時に行うCPUプロファイリングを助ける.どのcode pathがボトルネックになっているのかを1つのグラフ上で理解できる.本記事ではFlame Graphとは何か? なぜ必要なのか? を解
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く