「サイボウズ・アドベントカレンダー」の4日目です(これまでの記事一覧)。どうやら三日坊主は免れたようです(笑)。 (0) はじめに こんにちは。サイボウズ・ラボの川合秀実です。私は主にサイボウズ製品の高速化のお手伝いをしています。しかし先日、製品とは関係ないものを高速化したので、今日はそれを発表します。 サイボウズには社内勉強会がいくつかあって、その中にはC++の勉強会もあります。私はサイボウズの勉強会に参加するのが好きなので、このC++の勉強会に参加してみました。この勉強会では、「数独」というパズルを解くプログラムをC++で書いてみよう、というのが最初のテーマでした。参加者各自がプログラムを書き、翌週にお互いにレビューしあうということが行われました。 ここで私はやらかしてしまいました。ええ、そうです、高速化してしまったのです! 言うまでもないですが、誰もこんなことは望んでいません。そもそ
Over the past couple of weeks I've seen a few great resources about optimizing your javascript. One is a wonderful GCD presentation by Lilli Thompson about best practices when writing code for V8 (Chrome's Javascript engine.) Although the presentation uses Chrome for it's concrete examples, much of the information is very practical for any browser. GDC 2012: From Console to Chrome It's a long pres
RLogをいじってて知った__builtin_expectを試してみた。__builtin_expectはある式がほとんどの場合に決まった定数になる、と言う場合に分岐予測のヒントなどを与えて高速化を計るためのgccディレクティブだそうな。 RLogはdormant(休眠)状態のログファシリティに最適化してあって、プロダクションコードにログコードを残しっぱなしでもさほどデグレしないのが売りなんだけど、そのカラクリがこれ。 で、RLog自身についてはあとで書く。 どうかく? 具体的には __builtin_expect(A,B)と書いた場合 Aが定数 Bである事を期待する、というヒント情報になる。 例えば、比較演算子がほとんどの場合成り立たない、と言う場合 __builtin_expect(, 0) となる。 #include <stdio.h> #ifdef EXPECT #define E
In my last note I mentioned that I had been doing a lot of reading of JavaScript implementation code. One point that I didn't mention is that the state of the art is completely undocumented. So to work on rectifying that, here's the first in what might be a series of articles about the internals of JavaScript implementations. tagging Initially, all JavaScript implementations used tagged pointers t
書いておかないと将来自分が意味不明になるので, NaN boxingについて. LuaJITが古くから(wingologさんの素晴らしい記事によると), JSCが前から, SpiderMonkeyはfatvalsで, NaN boxingすることによりJSValを64bitに収めることを行っています. iv / lv5は以前から32bit SystemにおけるNaN boxingは実装していましたが, 64bit SystemにおけるNaN boxingは行っていませんでした. しかし先ほど, 64bit NaN boxing in 64bit Systemが入り, 現在, Solaris以外のOSにおいてはsizeof(JSVal)が常に64bitになりました. というわけでNaN boxing memo. 32bit / 64bitともに. value representation i
追記: typo修正。テストコードに余計な「r」が含まれてたのと、「PICコード」とか間抜けなこと書いてたのを。 Issue #4753 職場でも話題になったので。 このパッチのコメントによると、threaded codeにしたほうが分岐予測が効果的に働き、15%-20%ほど速くなるとのこと。computed goto自体は、threadedにする都合によるものなので、実はあまり本質的ではない。 要は、分岐予測は分岐命令ごとに、特定の呼び出しパターンを検出することで行われるものなので、ディスパッチする箇所が1カ所になっているよりは複数箇所になっている方が有効に利用できるということらしい。 つまり、 int *op = opcodes; for (;;) { static void *table = { &&OP_ADD, &&OP_LOAD, ... }; goto table[*op];
GNU grepの元祖作者がFreeBSDハッカーをschoolしている。 http://lists.freebsd.org/pipermail/freebsd-current/2010-August/019310.html FreeBSD対GNU grepのパフォーマンスを議論していると思われるとことに「俺はgrepの初代作者だ」と名乗って現われた男がいる。 履歴書(http://duckytech.com/resume.pdf)を見ると、GNU coreutilsに貢献した後、インテルやAMDでCPUアーキテクトを勤めている男だ。これは話を聞いた方がよさそうだ。 FreeBSDユーザでもある彼はリストを観閲していたらたまたまGNU対BSDのgrep論争に当ってしまったようだ。BSDのリストにGNU grepの秘密を解く。 技1: 全ての入力バイトを見ないから速い 技2: 見るバイトに関
先日Python 3.1a1 がリリースされました。 Python 3.0 は Python 2.6 に比べてパフォーマンスが悪かったのですが、Python3.1はPython2.6よりも速くなるかもしれません。 Python3.1のパフォーマンス向上は、主に次の2点が影響しています。 ioモジュールがC言語で書き直された computed goto の採用 (--with-computed-gotos というconfigureオプションで有効) computed goto という名前を聞き慣れなかったのですが、調べてみると Ruby 1.9 の VM (YARV) や、 Perl6 の VM として開発されとうとうリリースされた Parrot にも採用されている手法でした。今回は簡単に computed goto の紹介をしてみます。 とりあえず label as value C言語の規
Faster.pm がやってることは、基本的には Perl VM がやってる処理を C のコードにかきくだしただけなのです。生成されてる C のコードは以下のようなかんじだ。 ここからさらに最適化できれば、ぐっと速くできるのだけど。 #define PERL_NO_GET_CONTEXT #define PERL_CORE #include <assert.h> #include "EXTERN.h" #include "perl.h" #include "XSUB.h" #if 1 # define faster_PUSHMARK_PREALLOC(count) while (PL_markstack_ptr + (count) >= PL_ markstack_max) markstack_grow () # define faster_PUSHMARK(p) *++PL_markst
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く