雑なツイートをしてしまったばかりにrubyを高速化するはめになった俺たちは！
逆に言うと、Rubyの文字列型の内部実装がropeになれば、freezeしてもしなくても変わらない速度が出るようになって、結局freezeする必要なんてなかったんやーで丸く収まるんじゃないの？と思いました #雑な感想 — Kazuho Oku (@kazuho) October 6, 2015とツイートしたところ、処理系の中の人から @kazuho 文字列を弄る話じゃなくて、文字列の identity の話なので、ちょっと関係ないかなぁ、と — _ko1 (@_ko1) October 6, 2015みたいなツッコミをもらって、うっすみません…ってなってRuby VMのコードを読むことになったわけです。 で、まあ、いくつか気になる点があったので手をつけてしまいました。 1. オブジェクト生成のホットパスの最適化 ホットスポットだとされていたところのコードを読んでると、オブジェクト生成の際に
雨の中、Cを書かずにPythonで並列計算をする人間がいてもいい。自由とはそういうものだ。 - Qiita
「Pythonの遅い部分をCで書き直すと実行速度が100倍になりました！（神奈川県・主婦・30代）」といった広告をよく週刊誌で見かける。しかし、型ゆとり世代にとってCはいささかハードルが高い。一方Python並列化ならば追加の手間はかなり少なくて済み、100倍とは言わないが数倍程度の高速化ができる。 並列化する計算 言うまでもないが、HTTP通信が律速になっているようなPythonでは並列化しても高速化されない。並列計算を要するのは大体、巨大なforループ計算である。例として以下のようなものを考える。 L = 20000 total = 0 for i in range(L): for j in range(L): total += i*j print (total) 手元のマシンでの実行時間は25.663秒。これを並列化によって高速化する。 Thread並列とProcess並列 並列化は
AdaGradが12倍速くなる魔法
AdaGradは学習率を自動調整してくれる勾配法の亜種で、いろんな人が絶賛しています。 勾配を足し込む時に、各次元ごとに今までの勾配の2乗和をとっておいて、その平方根で割ってあげるだけと、恐ろしくシンプルです。 Adaptive Subgradient Methods for Online Learning and Stochastic Optimization John Duchi, Elad Hazan, Yoram Singer. JMLR 2011. 丁度、 @echizen_tm さんがブログを書いてました。 AdaGrad+RDAを実装しました。 通常のSGDなどは学習率をだんだん減衰させながら勾配を足していくわけですが、どの様に減衰させるかという問題にいつも頭を悩ませます。 AdaGradでは最初の学習率こそ外から与えますが、減衰のさせ方や減衰率といったハイパーパラメータから
pt&Goroutines
pt(the_platinum_searcher) を高速化するために Goroutines まわりで試したことを発表しました。 http://connpass.com/event/6370/
Vimの生産性を一撃で高めるシンプルなテクニック | RickyNews
Vim Advent Calendar 2013の168日目の記事です。 Vimプラグインの組み込みなど、日々Vimによる開発速度の向上を研究されている方も 多いかと思います。そんな開発効率を一撃で高められるテクニックがあるので紹介。 それはズバリ、OSのキーリピート速度を高めるです。 非常にシンプルですが、破壊力がすごいです。 普段のwebhjklがこの通り。パラグラフ単位移動コマンド{ }でやるとすごい速度。 単語単位でも超高速で移動できます。 もちろん通常のvimに限らず、tmuxのvisual mode(vi互換)であってもBashのカーソル移動であってもリモート接続先のVimであっても全てが高速になります。なぜならボタンを押し続ける動作はほぼキーリピートによるコマンド送出だからです。 Bashの場合は単語移動では以前はEsc + fを利用しておりましたが、すっかり使わなくなりまし
EXISTSとSQLの高速化について - 猫好きモバイルアプリケーション開発者記録
SQL高速化についてはいろんなサイトで取り上げられているので 今更取り上げる必要はないかと思っていましたが、 ふと最近仕事をしている中でハマっている人が多いポイントであると感じたため 改めて書いてみることにしました。 EXISTSが速いという誤解 EXISTSについて書かれたサイトを見ると、 「速い」というような記述を見かけることが多いかと思います。 しかし、これはあくまでサブクエリを組んだ場合に、INやイコールを使って比較するときと比べて速い場合が多いというだけであり、 EXISTSが速いというわけでは決してありません。 ハッキリ言ってしまうと、EXISTSを使うクエリは基本的に遅いです。 これは正確に言うと、EXISTSを利用するケースにおいて相関サブクエリが使われていることが原因で遅くなっています。 相関サブクエリとはどういうものか、以下にメンバー情報を格納した MEMBER テーブ
[MySQL] 数十万件ともなるとLIMITとORDER BYを使ったSELECTが遅い | りふれっと サンプル メモ帳 - Reflet Sample Note pad -
コメント - Comment - MySQLで150万件のデータを扱ったときに、Order ByとLimitを使った単純なSQLが10件のデータを抽出するのに 120秒近くかかったので、チューニングを検討する。 最初のデータ limit 0, 10 とかlimit10, 10などで抽出すると問題ないのですが、 最後の方のデータ LIMIT 1527120, 10などで取得しようとすると、非常に時間がかかってしまう。 なんとか解決しようと、下記の参考サイトの記述を参考に少しSQLをいじってみる・・・。 mysql> SELECT * FROM testt ORDER BY priority DESC,id DESC LIMIT 10; (略) 10 rows in set (0.20 sec) mysql> SELECT t1.*,t2.data FROM (SELECT id,priori
60 fps を実現する超高速イメージキャッシュ
x-callback-url とはURLスキームを利用したアプリ間連携の仕組み。他アプリを呼び出すだけでなく、その名（コールバック）の通り呼び出し元で結果を受け取るまでの一連の動作を定めている。 x-callback-url 現在は 1.0 DRAFT...
ブロックアルゴリズムとB-Treeアルゴリズム
ファイルサーチを高速化するB-Treeアルゴリズム ext2、ext3がベースとするブロックアルゴリズムは、ブロック数が対応するディスクのジオメトリ数に制限されること、ファイルサーチにO（n）かかる（注）こと、ファイルサイズに関係するパフォーマンス低下など、いくつかの問題があった。 注：「O（n）」とは、実行時間が入力の大きさ「n」に比例するアルゴリズムである。O（n）は「nのオーダー」または「オーダーn」と読む。後述する「O（log n）」は、アルゴリズムの計算量に関する議論の場合logの底は常に2で、O（log n）の方がO（n）よりも効率が良い。例えばn＝8の場合、O（log n）は入力8に対して3回の実行で済むが、O（n）は8回の実行となる。 ReiserFS、JFS、XFSといったファイルシステムでは、こうしたブロックアルゴリズムの限界に対して、早い段階からデータベースの技術をフ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
世界最速の正規表現JITエンジンの実装