Syoyo Fujita's Blog

raytracing monte carlo

Month: February, 2008

USD/JPY 103 円突入…

いや、GPU は終わりだ、CPU だなんて言ってる場合じゃないね。

そんなことよりももっと面白い、
サブプライムショックを発端とする世界経済のリセッションが、本格化してきました

「バーナンキ失言」で市場大荒れ 暴れる投機マネーで不透明感再燃
http://sankei.jp.msn.com/economy/finance/080229/fnc0802291747018-n1.htm

バーナンキFRB議長、リセッションの認識に近づく
http://jp.reuters.com/article/topNews/idJPJAPAN-30573320080229

usd_jpy_103.png

ドル円は、ついに今現在 103 円に一時突入した… あちゃーーー。
こりゃ日本の製造業は死亡だね。

ドル弱すぎ… ユーロはともかく、世界最弱通貨の円に負けるなんて…

まだだ、まだ終わらんよ、
これからが本当の米国経済終わりの始まりです

生存者バイアス

あ、私は (ラスタライザベースの) GPU は終わる、と予測していますが、
まあ当たったところで、「ほれみろオレの言った通りだ」なんて風潮するのは愚かなことです。
そんなのは実のところ、まぐれであり生存者バイアスにすぎないのです。

過去 5 年を振り返れば、もし毎年 「GPU は終わる」とオオカミ少年のように
繰り返し言ったところで、ことごとく外れているわけですから、
逆にまったくお前の予測は当たらない、というふうに解釈もできるわけです。

[1] にもあるように、世の中のほとんどの、
「私が成功した〜の理由」「私は〜を予測していた」「〜がこれから来る」
なんて成功者などが語っているたぐいのものは、
まぐれだったにすぎないのです。

まぐれを自分の(予測の)才能と勘違いするのは、
「100 円を元手に、一日一分の時間で、20 日で 1 億にする方法」
という内容の本を書くくらい、愚かなことです。
(元ねたはもちろんわかりますよね)

大切なのは、

「将来こうなる」と予測することではなくて、
「将来こうなる」と思うなら、その機運に乗っかって自らが変革の源泉になること。

予測するだけなら、オオカミ少年でも出来ますからね。

というわけで、マジでラスタライザベースの GPU は
MUDA とリアルタイムレイトレでツブしにかかります

[1] まぐれ—投資家はなぜ、運を実力と勘違いするのか
http://www.amazon.co.jp/dp/4478001227

MUDA project proposal

OoO, とても急な参加の案内でしたが、ご参加いただいた方ありがとうございました。
特に会場の手配をしていただいた H 氏に多謝。

最初だったのですが、意外とネタが持ち寄られて、
なかなかよい discussion ができたのではないかと思います。

個人的には議論が盛り上がってしまって?もう少し個人作業/コラボレート作業の時間が
とれればよかったかなぁと思いました。

次回は一ヶ月後くらいかな?
次回のネタのひとつは I3D ’08 参加者による I3D ’08 レポートを予定しています。

あ、ついでに OoO で発表した、世界初の MUDA プレゼンを貼付けておきます。

軽くまとめると、GPU(ラスタライズベース)はどう見てももう終わりでしょ
これからは CPU の時代ですよ。でもみんなまだ CPU のパフォーマンスを引き出している
とは思えない。たとえば flash の lowering に MUDA 使ったらぜってー 10 倍は早くなるって。
これからのグリーン IT の時代、効率的で無駄のない CPU パワーの
利用が求められている。そこで MUDA。という感じ。

GPU は私は 6 年前に将来性が無いと判断したのですが、それがやっと実現しようとしています。
(原因の一つがサブプライムショックひいては消費バブル崩壊によるものになるとは思いませんでしたが)

あ、別にレイトレベースの GPU(RPU) なら否定しません。
というか RPU がこれからの本命ですね。
(MUDA とあんま関係なくなってきたので、ここでやめます)

ちなみに、最初のグラフが指数関数でなくて、
その先の予測が 5 秒で出来たひととは、たぶん私とフィーリングが合うかも…

OoO(Offline meeting for Offline renderists)

えっと、突然ですいませんが、
日曜(2/24) に OoO, オフラインレンダラ野郎のためのオフライン勉強会やります。
結局またしばらく日本にいることになりそうなので、
こういう勉強会を今後継続して開いていければな、と考えています。

場所は日本 SGI 社に提供していただきました。ありがとうございます。
東京は恵比寿になります。

13:00 に B1F SGI ホール入り口前に集合です(マックの隣)。
終わりの時間は 18:00 ~ 19:00 を予定しています。

SGI ホール @ 恵比寿ガーデンプレイス B1F
http://www.sgi.co.jp/company_info/map1.html

集合場所は B1F ですが、勉強会の場所は 31F になります。

オフラインレンダラ野郎同士は惹かれ合う、を信じたいと思いますが、
不安な方や、当日遅れて参加することになりそうな方は私宛メールにて参加希望をお伝えください。

たぶん当日は「OoO」という張り紙があるかもしれません。

とりあえずは最初なので、ネタだしのプレオフライン勉強会みたいな感じで、
まあ半分くらいの時間はこんな感じなことがやれたらと。

サタデーコードフィーバー
http://labs.unoh.net/2008/01/post_113.html

無線 LAN は使えるそうですが、基本的にはオフライン作業になることを想定しておいたほうがよいと思います。

いちおう今回のメインテーマはあって、それは OoO をオンラインでフォローするための、
ompf のオフラインレンダラ版フォーラムを RoR で作ろうというものです.
作っていただける方はいるので、それにときどき意見を出すみたいな。

まあでもその一方で、 MLT の実装とか, 論文書くとかしてても OK.

スライド作成が間に合えば、世界初、日本でしか聞けない(<- これ大事)、
MUDA のプレゼンとかするかも.

というわけで、オフラインレンダラ野郎で、オフラインレンダラについて悩んでいること、
これから勉強したいと思っている方、論文の輪講をしてみたいと考えている方、
EG08, I3D08 の論文解説したい方、ぜひともご参加ください。
(リアルタイムレンダラ野郎はダメということはありませんが、肩身の狭い思いをするかも)

Ray-Triangle intersection using Affine arithmetic

Ray-Triangle intersection using Affine arithmetic
Uchimura HAJIME, Kashiwagi MASAHIDE, and Kashiwagi KEIICHIRO
http://nikq.nothing.sh/backlog/junkbox/univ/tecrep.pdf

In these days, rendering algorithms are getting complex, and target models are getting dense.Those dense triangles cause precision trouble.
so I used Affine-arithmetic(AA) as a precision-proving tool for intersection calculation.

Just for those who can read Japanese 🙂
(Or if you are intersted in, let me know. I or the author will try to illustrate it in English)

I am very interested in this problem, i.e. how to do numerically robust ray-trianble intersection computation.
I think many people in production rendering and almost all practical raytracer writer are suffering from this precision problem.

Hmm. I’d like to comment it. I think it’d be much better to use gappa to formally verify their result.

Blender to Renderman, and shader editor SLer

Tenzin, of Blender to Renderman project, let me know this quite interesting open source projects.

Blender to Renderman.

http://blendertorenderman.blogspot.com/

One of these is ribMOSAIC, Blender to Renderman plugin.

http://ribmosaic.wiki.sourceforge.net/

And other is SLer, RenderMan shader GUI editor.

http://ribkit.sourceforge.net/

I love to integrate my lucille renderer to adopt these project.

And more, I’m planning to evolve MUDA as a global illumination language,
thus, if possible, I’d like to use SLer for its development tool.

[Ja]

SLer よさげ。でも昔からあった気がしますが。

MUDA がある程度完成したら、MUDA をベースにして大域照明言語(global illumination language)を作ろうとしているので、そのための開発ツールのひとつとしても SLer が使えたらいいなぁと思っています。

LLVM 2.2 v.s. gcc 4.2

LLVM 2.2 is just released.

http://www.llvm.org/

Benchmark again. Here is my old post: LLVM 2.0 & gcc 4.2

I ran Himeno benchmark with following compilers on my Core2 Intel Mac 2.16 GHz, Leopard 10.5.2

– gcc 4.0.1(from Apple’s Xcode)
– gcc 4.2.1
LLVM 2.2

The graph of observed performance for 3 compilers,

llvm22_bench_01.png

and the graph showing the performance for LLVM2.2 and LLVM2.0
(The value of LLVM 2.0 is taken from my old post)

llvm22_bench_02.png

Here are procedures and outputs

llvm-gcc & LLVM 2.2


Macintosh: $ llvm-gcc -c -emit-llvm -O3 -DSMALL himenoBMTxps.c -o himenoBMTxps.bc
Macintosh: $ lli himenoBMTxps.bc
...
 Gosa : 1.981140e-05
 MFLOPS measured : 1283.698606	cpu : 39.254658
 Score based on Pentium III 600MHz : 15.654861

gcc-4.2.1


Macintosh: $ gcc-4.2.1 -O3 -DSMALL himenoBMTxps.c -o himenoBMTxps.gcc42.out
Macintosh: $ ./himenoBMTxps.gcc42.out
...
 Gosa : 1.966431e-05
 MFLOPS measured : 946.659033	cpu : 53.317495
 Score based on Pentium III 600MHz : 11.544622

gcc4.0


Macintosh: $ gcc -O3 -DSMALL -o himenoBMTxps.gcc40.out
Macintosh: $ ./himenoBMTxps.gcc40.out
...
 Gosa : 8.331492e-05
 MFLOPS measured : 612.135986	cpu : 56.467345
 Score based on Pentium III 600MHz : 7.465073

LLVM2.2(mid-end and x86 back-end) is so nice,
+35% improvement compared to gcc 4.2 and
+10% improvement was observed against LLVM 2.0.

Investigation

Where these performance differences come from?
In Himeno bench, The inner-most loop in jacobi() consumes
99.7% of whole computation time.

I disassembled executables of this part,
and found LLVM 2.2 emits very efficient x86 assembly.
It is composed of move, add/sub and mul instructions.
These 3 instructions can be executed in parallel on Core2 CPU.
(Core2 has independent load/store unit, additive fp ALU and multiply fp ALU)

Here’s a disassembled code of inner-most loop in jacobi(), from 3 compilers.

LLVM2.2 generated code.


1.8%    mulss    +21847984(%ebp), %xmm3
0.1%    movss    +46412(%ebp), %xmm0
0.9%    mulss    +21881008(%ebp), %xmm0
1.8%    addss    %xmm3, %xmm0
0.1%    movss    +4406612(%ebp), %xmm3
0.8%    mulss    +21847472(%ebp), %xmm3
0.0%    addss    %xmm3, %xmm0
1.8%    movss    +21881524(%ebp), %xmm3
1.1%    subss    +21880492(%ebp), %xmm3
0.2%    subss    +21814444(%ebp), %xmm3
0.3%    addss    +21813412(%ebp), %xmm3
1.9%    mulss    +8766828(%ebp), %xmm3
1.6%    addss    %xmm3, %xmm0
0.9%    movss    +21847988(%ebp), %xmm3
0.0%    subss    +21846956(%ebp), %xmm3
1.4%    subss    +21847980(%ebp), %xmm3
0.0%    addss    +21846948(%ebp), %xmm3
0.4%    mulss    +10946928(%ebp), %xmm3
2.0%    addss    %xmm3, %xmm0
3.0%    movss    +21881012(%ebp), %xmm3
0.0%    subss    +21813932(%ebp), %xmm3
0.0%    subss    +21881004(%ebp), %xmm3
0.0%    addss    +21813924(%ebp), %xmm3
1.9%    mulss    +13127028(%ebp), %xmm3
2.1%    addss    %xmm3, %xmm0
2.7%    movss    +15307148(%ebp), %xmm3
0.7%    mulss    +21813928(%ebp), %xmm3
0.8%    addss    %xmm3, %xmm0
3.1%    movss    +17487248(%ebp), %xmm3
0.7%    mulss    +21846952(%ebp), %xmm3
0.1%    addss    %xmm3, %xmm0
4.2%    movss    +19667348(%ebp), %xmm3
0.7%    mulss    +21847464(%ebp), %xmm3
0.0%    addss    %xmm3, %xmm0
4.6%    addss    +24027596(%ebp), %xmm0
6.1%    mulss    +6586712(%ebp), %xmm0
8.5%    movss    +21847468(%ebp), %xmm3
0.0%    subss    %xmm3, %xmm0
5.5%    mulss    +26207724(%ebp), %xmm0
8.0%    movaps   %xmm1, %xmm4
        mulss    %xmm0, %xmm4
7.8%    addss    %xmm4, %xmm3
4.6%    addss    +24027596(%ebp), %xmm0
6.1%    mulss    +6586712(%ebp), %xmm0
8.5%    movss    +21847468(%ebp), %xmm3
0.0%    subss    %xmm3, %xmm0
5.5%    mulss    +26207724(%ebp), %xmm0
8.0%    movaps   %xmm1, %xmm4
        mulss    %xmm0, %xmm4
7.8%    addss    %xmm4, %xmm3
5.2%    movss    %xmm3, +28387852(%ebp)
1.9%    mulss    %xmm0, %xmm0
        addss    %xmm2, %xmm0
0.2%    addl     $4, %ebp
        incl     %ebx
1.6%    cmpl     %ebx, %esi
        movaps   %xmm0, %xmm2
2.1%    jg       0x00002395 

gcc 4.2 genereted code.


        mulss    +2180104(%ecx), %xmm2
1.7%    movss    (%esi, %edx, 4), %xmm0
1.1%    mulss    +4(%ecx), %xmm1
0.5%    movl     -104(%ebp), %esi
0.0%    movss    %xmm0, -20(%ebp)
0.0%    mulss    +4360204(%ecx), %xmm0
1.7%    addss    %xmm2, %xmm1
0.0%    addss    %xmm0, %xmm1
0.1%    movss    -4(%eax, %esi), %xmm0
0.4%    movl     -116(%ebp), %esi
1.1%    subss    -4(%eax, %esi), %xmm0
0.1%    movl     -100(%ebp), %esi
0.0%    subss    -4(%eax, %esi), %xmm0
0.2%    movl     -108(%ebp), %esi
1.1%    addss    -4(%eax, %esi), %xmm0
0.1%    movl     -112(%ebp), %esi
0.1%    mulss    +4(%edi), %xmm0
0.7%    movss    (%esi, %edx, 4), %xmm2
1.1%    movl     -120(%ebp), %esi
0.0%    addss    %xmm0, %xmm1
0.2%    movss    (%esi, %edx, 4), %xmm0
0.0%    movl     -36(%ebp), %esi
1.3%    movss    %xmm0, -16(%ebp)
0.0%    movaps   %xmm2, %xmm0
0.1%    movss    (%esi, %edx, 4), %xmm5
0.0%    movl     -32(%ebp), %esi
1.2%    subss    -16(%ebp), %xmm0
0.1%    movss    (%esi, %edx, 4), %xmm7
0.1%    addl     $1, %edx
0.0%    movl     -112(%ebp), %esi
1.4%    subss    -8(%eax, %esi), %xmm0
4.7%    movl     -120(%ebp), %esi
0.1%    addss    -8(%eax, %esi), %xmm0
5.8%    movl     -36(%ebp), %esi
        mulss    +2180104(%edi), %xmm0
5.3%    addss    %xmm0, %xmm1
4.0%    movaps   %xmm5, %xmm0
        subss    %xmm7, %xmm0
        subss    -8(%eax, %esi), %xmm0
0.0%    movl     -32(%ebp), %esi
1.3%    addss    -8(%eax, %esi), %xmm0
0.1%    movl     -152(%ebp), %esi
        mulss    +4360204(%edi), %xmm0
2.6%    addl     $4, %edi
0.2%    mulss    +4(%esi), %xmm4
0.7%    mulss    +2180104(%esi), %xmm3
0.7%    addss    %xmm0, %xmm1
3.2%    movss    +4360204(%esi), %xmm0
0.6%    movl     -44(%ebp), %esi
0.0%    addss    %xmm4, %xmm1
3.4%    mulss    -8(%eax, %esi), %xmm0
0.1%    addss    %xmm3, %xmm1
3.8%    movl     -132(%ebp), %esi
0.0%    addss    %xmm0, %xmm1
3.8%    addss    -4(%eax, %esi), %xmm1
5.4%    movl     -136(%ebp), %esi
        mulss    +6540304(%ecx), %xmm1
5.1%    addl     $4, %ecx
        subss    %xmm6, %xmm1
3.9%    mulss    -4(%eax, %esi), %xmm1
5.6%    movaps   %xmm1, %xmm0
2.6%    mulss    %xmm1, %xmm0
6.1%    addss    -64(%ebp), %xmm0
4.0%    movss    %xmm0, -64(%ebp)
1.3%    movl     -140(%ebp), %esi
        mulss    -96(%ebp), %xmm1
        addb     $4, -152(%ebp)
1.3%    cmpl     -92(%ebp), %edx
        addss    %xmm6, %xmm1
        movss    %xmm1, -4(%eax, %esi)
0.0%    jnz

gcc4.0 genereated code.


0.8%    movl     -60(%ebp), %eax
        inc      -56(%ebp)
0.8%    movl     -56(%ebp), %esi
0.0%    movl     -56(%ebp), %edi
0.0%    shll     $7, %eax
        addl     -60(%ebp), %eax
0.8%    addl     $2, %esi
        movl     %esi, -32(%ebp)
0.0%    movl     -136(%ebp), %esi
0.0%    incl     %edi
0.9%    movl     %eax, -80(%ebp)
0.0%    movl     -80(%ebp), %edx
0.0%    imull    $8385, -64(%ebp), %eax
0.0%    movl     %edi, -28(%ebp)
0.8%    leal     -8(%esi), %ecx
        imull    $8385, -144(%ebp), %esi
0.0%    addl     %eax, %edx
        movl     %eax, -84(%ebp)
0.7%    movl     -80(%ebp), %eax
        movl     %edx, -88(%ebp)
0.0%    addl     %edi, %edx
        movl     %edx, -92(%ebp)
0.8%    movl     -92(%ebp), %edi
0.0%    movl     -136(%ebp), %esi
0.0%    incl     %edi
0.9%    movl     %eax, -80(%ebp)
0.0%    movl     -80(%ebp), %edx
0.0%    imull    $8385, -64(%ebp), %eax
0.0%    movl     %edi, -28(%ebp)
0.8%    leal     -8(%esi), %ecx
        movl     %eax, -104(%ebp)
0.1%    leal     -4(%edx), %eax
        movl     -104(%ebp), %edx
0.8%    movss    +4(%edi), %xmm1
0.3%    movl     -84(%ebp), %edi
0.0%    mulss    (%eax, %edx, 4), %xmm1
0.7%    movl     -20(%ebp), %edx
0.7%    shll     $7, %edx
        addl     -20(%ebp), %edx
0.0%    addl     %edx, %edi
0.2%    movl     %edi, -108(%ebp)
	movl     %edi, -112(%ebp)
0.0%	movl     -36(%ebp), %edi
0.3%	movss    +2180104(%edi), %xmm0
1.3%	movl     -112(%ebp), %edi
0.0%	mulss    (%eax, %edi, 4), %xmm0
2.1%	movl     -36(%ebp), %edi
0.1%	movl     -88(%ebp), %eax
0.1%	addl     -32(%ebp), %eax
0.0%	addss    %xmm0, %xmm1
2.1%	movss    +4360204(%edi), %xmm0
0.4%	movl     -48(%ebp), %edi
0.1%	mulss    (%ecx, %eax, 4), %xmm0
1.2%	movl     -128(%ebp), %eax
0.4%	shll     $7, %edi
0.0%	addl     -48(%ebp), %edi
	addss    %xmm0, %xmm1
2.0%	subl     $8, %eax
0.0%	movl     %eax, -116(%ebp)
	leal     (%edx, %esi), %eax
	addl     -28(%ebp), %eax
0.8%	leal     (%edi, %esi), %esi
	addl     -28(%ebp), %esi
0.0%	movss    (%ecx, %eax, 4), %xmm0
0.3%	subss    (%ecx, %esi, 4), %xmm0
2.6%	imull    $8385, -44(%ebp), %esi
0.0%	addl     %esi, %edx
	addl     -28(%ebp), %edx
0.0%	leal     (%edi, %esi), %eax
0.8%	addl     -28(%ebp), %eax
0.0%	subss    (%ecx, %edx, 4), %xmm0
3.5%	movl     -92(%ebp), %edx
0.0%	addl     -84(%ebp), %edi
0.0%	addss    (%ecx, %eax, 4), %xmm0
2.5%	movl     -116(%ebp), %eax
	mulss    (%eax, %edx, 4), %xmm0
3.7%	movl     -32(%ebp), %eax
0.0%	movl     -108(%ebp), %edx
	addl     -32(%ebp), %edx
0.0%	addss    %xmm0, %xmm1
2.7%	addl     %edi, %eax
0.0%	movl     %eax, -160(%ebp)
	movss    (%ecx, %edx, 4), %xmm0
0.0%	movl     -112(%ebp), %edx
0.9%	subss    (%ecx, %eax, 4), %xmm0
0.2%	subss    (%ecx, %edx, 4), %xmm0
0.9%	movl     -56(%ebp), %edx
	leal     (%edi, %edx), %eax
0.4%	movl     -116(%ebp), %edx
0.0%	addss    (%ecx, %eax, 4), %xmm0
1.8%	movl     -96(%ebp), %eax
	mulss    +2180100(%eax, %edx), %xmm0
3.5%	movl     -100(%ebp), %eax
0.0%	addl     -32(%ebp), %eax
	addss    %xmm0, %xmm1
2.4%	movl     %eax, -120(%ebp)
0.0%	movl     -80(%ebp), %edx
	addl     -28(%ebp), %edi
	addl     %esi, %edx
0.7%	movl     -32(%ebp), %esi
0.0%	leal     (%edx, %esi), %eax
0.0%	movl     -120(%ebp), %esi
0.0%	movss    (%ecx, %esi, 4), %xmm0
0.7%	movl     -56(%ebp), %esi
0.0%	subss    (%ecx, %eax, 4), %xmm0
0.3%	movl     -104(%ebp), %eax
	subss    (%ecx, %eax, 4), %xmm0
2.2%	leal     (%edx, %esi), %eax
0.0%	movl     -116(%ebp), %esi
	addl     -28(%ebp), %edx
0.0%	addss    (%ecx, %eax, 4), %xmm0
2.3%	movl     -96(%ebp), %eax
	mulss    +4360200(%eax, %esi), %xmm0
3.8%	movl     -132(%ebp), %esi
	addss    %xmm0, %xmm1
2.5%	leal     -8(%esi), %eax
	movl     -92(%ebp), %esi
	movss    (%eax, %esi, 4), %xmm0
0.2%	movl     -96(%ebp), %esi
0.7%	mulss    (%ecx, %edx, 4), %xmm0
0.1%	movl     -96(%ebp), %edx
	addss    %xmm0, %xmm1
1.5%	movss    +2180100(%edx, %eax), %xmm0
0.3%	movl     -88(%ebp), %edx
	addl     -56(%ebp), %edx
	mulss    (%ecx, %edi, 4), %xmm0
1.0%	movl     -92(%ebp), %edi
0.0%	addss    %xmm0, %xmm1
2.0%	movss    +4360200(%esi, %eax), %xmm0
0.3%	movl     -148(%ebp), %eax
	movl     -152(%ebp), %esi
0.0%	mulss    (%ecx, %edx, 4), %xmm0
2.3%	movl     -36(%ebp), %edx
0.0%	movl     -140(%ebp), %ecx
1.0%	addss    %xmm0, %xmm1
1.5%	addss    -8(%eax, %edi, 4), %xmm1
2.8%	mulss    +6540304(%edx), %xmm1
3.5%	addl     $4, %edx
	subss    %xmm2, %xmm1
2.4%	mulss    -8(%ecx, %edi, 4), %xmm1
3.5%	movaps   %xmm1, %xmm0
1.7%	mulss    %xmm1, %xmm0
4.1%	mulss    %xmm4, %xmm1
	addss    %xmm0, %xmm3
2.4%	addss    %xmm1, %xmm2
	movss    %xmm2, -8(%esi, %edi, 4)
0.0%	movl     -76(%ebp), %edi
0.0%	cmpl     %edi, -56(%ebp)
1.0%	movl     %edx, -36(%ebp)
	jnz

Definitely, gcc4.0 generated code is redundant.
This is why gcc4.0 is slow.

gcc4.2 genereated code contains some redundant instructions, e.g. movl and addl.

x86 Core2 is OoO(Out-of-Order) architecture, thus less instructions does not mean faster execution in general.
But in this case(gcc4.2 v.s. LLVM2.2), I think the exection time scales well with the number of instructions.

For more accurate investigation, we need instruction pipeline simulator for Core2 architecture,
but Intel does not provide it! , whereas ATI did.
So I cannot investigate more on the performance.

Warren Buffett to CNBC: I Will Reinsure $800B in Municipal Bonds

Warren Buffett to CNBC: I Will Reinsure $800B in Municipal Bonds
http://www.cnbc.com/id/23125353

うおおおおおおおおおおおお
おおおおおおおおおおおおお
おおおおおおおおおおおおお
おおおおおおおおおおお!!

Buffet, モノライン各社の地方債債務保証 80 兆円を引き受ける意思がある、
と救済計画を申し出ていたことを TV インタビューで語った!!

スケールが違う…

Y! が 20 個くらい買える ^^)

さすが Buffet, 俺たちにできないことを平然とやってのける!
そこにシビれる憧れるゥ!

いやー、やっぱ今の金融状況は面白ろ.

WIP: MUDA -> LLVM backend

I’ve started to code MUDA -> LLVM IR backend.
For more details, see MUDA development blog.

Work in progress | MUDA -> LLVM backend
http://mudadev.blogspot.com/2008/02/work-in-progress-muda-llvm-backend.html

自分にとって本当にコワイ奴は下から来るんだ

某レンダラ野郎達と会話をしました。
人数も私を合わせ 3 人であり、いずれも真のレンダラ野郎(大域照明レンダラ野郎)だったので、
deep な discussion となりました。

技術的な話題についてはさておき、
やはり、思うことは、

「自分にとって本当にコワイ奴は下から来るんだ」

という倉田先生のお言葉を身を持って感じること。
まさにリアル 「ヒ○ルの○」の世界。

もうね、上だけを見てレンダラの巨塔を登り詰める、じゃダメなのですよ。

どんどん下から登ってくるヤツらが、自分をすっ飛ばして上に挑戦しているわけです。
私の存在?もちそんなの認識されてないよ。皆私をスルー。

明らかに、レンダラ野郎は、新参者が圧倒的に有利である。
レンダラを作るということは、IT 分野における真の知識労働であるから。

– 先駆者による知識の積み重ね。
– IT の発展による、機能的なコミュニティ(レンダラ野郎のコミュニティ)と情報への
アクセスコストが年々激的に低下し、容易にアクセスできるようになっていく。

この両者を常に享受できる分野である。

知識は加速する…

ドラッカーというオッサンが、マネジメントやら知能生産の向上やらで、
数百年前は 10 年かかっていた教育(技術の伝達)が、今は 90 日でできるようになったぴょん、
ということを言っていた気がしますが、まあそれが加速したような世界です。

私の時代は、大域照明を学ぼうと思ったら、3 年くらいかかったわけですが、
今の時代であれば 3 ヶ月でできると思います。
(インド人はもっとすごくて、3 日で MLT まで実装しちゃいますが)

まさにリアル メ○ド・イン・へ○ン ス○○ドが発動した世界。

Weired network

伊藤清先生は、戦時中に海外の論文を取り寄せることに苦労したらしい。
ドイツの潜水艦に論文を積んでもらってでも取り寄せたそうです。

いまや、論文は(公開されていれば) web ですぐに読むことができる。
数年前(google が出てくるまで)は、論文タイトルをキーワードにしても見つからないことが多かったが、
今は検索でもかなり正確にヒットするようになり、
また google scholar や citeseer というサービスも出て来た。

機能的なコミュニティも、いまや、BBS, blog や、facebook などの SNS で構築されている。
必要になれば、論文の作者に e-mail で問い合わせて議論も出来る。

わざわざ SIGGRAPH へ赴くまでもなく、
世界中のレンダラ野郎に気軽にアクセスできる世の中になったのである。
(もちろん、real world での活動も必要ではある)

まさにリアル l○○n の Weired ネットワークの世界。
# そう思うと、l○○n は当時としてはかなり先見性があってすばらしかったなぁと思います。

では古参レンダラ野郎ができることは?

常に自分も時代に乗り遅れないように keep up しておく?

No, 知的労働の生産性は圧倒的に若い方が高い。
古参者がいくら頑張って keep up しようとしても、それを遥かにしのぐスピードで新参者は
情報を吸収、知的生産活動を行う。

あと 5 年後くらいには、古参者は幼稚園児にも抜かれることだろう。

保守的、つまり既得権益を守るようにする?

No, 斜陽産業や政治と違い、レンダラの世界では、守りに入ることすらできない。
レンダラは真の知的生産であるから、物理的に壁を作って参入を阻むことはできないからだ。

結局のところ、古参者にできることはなにも無い。
せいぜい新参者の彼らに、さらに飛躍的に活動してもらい、
成功のおこぼれをもらうためにパトロンになるくらいである。

そういうわけで、せめて我々が出来ることとして、
レンダラ財団を設立せねば、という考えに行き着くわけです。
(集まった一人からも、レンダラ財団の出資に同意してもらいました)

あ、ちなみになぜインド人が脅威かについて書いておきます。
というかもう日本人はインド人に越されているわけですが。

インドは人口が日本の 10 倍なわけです。日本人が 1 年で 10 を行うとしたら、
インド人は人口のパワーで 100 できているということになるわけです。

しかも日本の高齢化、人口減少の最悪な人口ピラミッド構成とは違い、
インドは理想的な人口ピラミッド構成です(若者が多く、人口も増加)。
勝てるわけがない

しかも、2008 年米国経済減衰で、だぶついたマネーが流れる先となると、
いまならインドなどの新興国。その中でインドは外需依存度が一番低い。
(今回の金融危機の影響度が小さい)
インドの発展が今回の米国経済減衰で予想以上に加速することは目に見えている。

しかも、彼らにとっては、IT こそがカーストから抜け出すための唯一の手段
という考えがあるそうで、どんなに家が貧しくても PC だけは良いものが置いてあるそうな。
IT への参入者が人口にスケールし、日本人の 10 倍というのも、嘘ではないと思う。
もしかしたら日印の人口比率以上にインドの方が IT 参入者が多いかもしれない。

しかも肉体労働ではどんなに生産性を上げようとしても、肉体の限界があるわけですが、
知能労働の生産性向上は上限が無い訳です。
日本人の 10 倍の生産性を生み出すというのはまったくもって不可能ではないのです。

ただ、それだけのポテンシャルがありながら、インド人のレンダラ野郎って
実はあまりいないんですよね、なんでだろ?…