Syoyo Fujita's Blog

raytracing monte carlo

Month: March, 2008

レンダラコンサル: 続き

過去の記事 の続き.

相変わらずレンダラコンサル(?)みたいなことを続けています.

が、うーん、だんだんと首が回らなくなってきた…
常時 5,6 件くらいが平行して動いているので、
誰に何時, 何を返信したかどうかあやふやになってきた…
なんか返信し忘れしているひとがいる気がする.

そろそろ本格的にマネジメント & 知のアウトソースが必要です.

とはいえ、バジェットを軽減するために案件(?)を無下にあしらうのもためらわれる。
思いもかけず得られることもいろいろあるわけで。
あのプロダクションではほうほうそうなのか、
このプロダクションではおやまあそうなのか、
などが分かったりと、いろいろマル秘?情報を得ることができます。

だいたいみんな悩みが同じだったりするのも面白い
(そういう人たちとしかやりとりしてないだけかもしれませんが)

いずれにせよ、(レンダラ野郎の)世界はどんどん縮まっているのは確か!
6 年前(私が GI を本格的に始めたころ)には雲の上の存在だったひと達と、
いまや繋がり、横並びで discuss しているという現実!
URYYYYY!!!

こんなこと、6 年前には想像もできなかった.
(そして、下からどんどんやってくるヤツらのほうが上にいるヤツらよりももっと脅威であることも!)

Advertisements

世界 7 大不思議のひとつ: 人はなぜ C++ をまだ使っているのか?

(from steps to phantasien)

もう C++ なんて好きでもないし使いもしない理由。
http://www.hyuki.com/yukiwiki/wiki.cgi?WhyINoLongerLikeOrUseCPlusPlus

世の中やはり同じ境遇に陥っているひとはいるのですね.

何が起きたのか? 嫌気が差したんだ。C++ のどの面をとっても、その設計は性能と引き換えに私の生産性をうばった。もう一つうんざりなのは, リンカのエラー診断だ。ただライブラリをダウンロードして使うなんてことが決してできない。新しいライブラリを使うのに、自分でソースからビルドしないといけない。C++ にはコンパイル済コードをさっと使うための ABI がないからだ。コンパイラがアップグレードするたびに、私はアプリケーションとライブラリ全体を再コンパイルして、その中でいつも不可解なエラーを診断して数時間つぶした。ライブラリひとつのアップグレードでも更なるコンパイルと暗号的エラーに見舞われた。「より高い性能」という誓いが、私を冒しはじめた。誓い(コードの可読性は低いが)は守られ、C++ ABI 不在による保守の地獄には一切注意が払われなかった。私は気がついた。C++ の連中は性能に取り憑かれている。他の全てをなげうって。そして、私はもうそこで仕事をしないと決めたのだ。

個人的な経験から言わせてもらうと、C++ は性能も奪うし、生産性も奪う
生産性を奪うのは確かで、遥か昔私がまだ C++ のプログラムでグラフィックスのコードを書いていたとき、
今振り返ってみると, その 95% はベクトルクラスなどのどーでもいいのだけど、
無いと次に進めることができない基本クラスの作成と、
リンカエラーの対処(特に他ライブラリとの)に費やされ、
アルゴリズムのコード化はその残りの 5% くらいだったと思う。
それに C++ はデバッグもしずらしい。

「C++ は早い」というのはもはや幻想になりつつあると思う。
C++ で性能を引き出すには、よほどこう書くとこんなアセンブラコードが生成されると分かっていないといけない。
何も考えずにコーディングすると、ボトルネックな部分は仮想関数テーブル引きでした、ということもなきにしもあらず。
しかもどんなアセンブラコードになるかは、コンパイラ依存、ひえぇ〜〜〜。

大切なのはどうコードを書くか、ではなくて、いかに効率的にアルゴリズムをコードに変換して生産性を
向上させるか?だと思います。

そのような意味で、FFTW や Spiral などのアルゴリズム記述からの自動最適化コード生成や,
DSL などの生産性を上げるようなやり方が、これからは注目されてしかるべきじゃないかなぁと思っています。

BSR

米JPモルガン:ベアーS買収額を1株10ドルに上げ、新株取得へ
http://www.bloomberg.com/apps/news?
pid=90003017&sid=aFj4X93dT1uw&refer=jp_news_index

うーん、なんだかもうよくわかりませんなぁ…

米ベアー不良資産を分離、10年で処理・JPモルガンとNY連銀
http://www.nikkei.co.jp/kaigai/us/20080325D2M2500X25.html

10 年って… 狩猟民族のアングロサクソンがそんなに長い期間耐えられるのだろうか?

おまけ.

いやー、ジム•クレーマー、いいなぁ. いい仕事してるなぁ.
彼こそまぐれで生き残っているのではなくて、
なんだかんだで成功(?)に成功を重ねて今がある “accumulator”[1] と呼んでいいかもしれない。
というかそうであってほしい(いずれにせよ、今の所はそのようだ)。

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

Visual Python

randunitvec.png

I found a good visualization tool powerd by Python, vpython
(See quite nice application of vpython for teaching physics)

The above image shows random unit vectors and is generate by following python script.
It’s quite simple to code, and you can drag/zoom the scene without describing anything about mouse handling & screen drawing.

Wouldn’t it be nice to use vpython for visually validate graphics algorithms(e.g. path muatation for MLT)?


from visual import *

import math
import random

# Generate 100 random unit vector on upper hem-sphere
for n in range(100):
    theta = math.sqrt(random.random())
    phi   = 2.0 * math.pi * random.random()

    x     = math.cos(phi) * theta
    z     = math.sin(phi) * theta
    y     = math.sqrt(1.0 - theta * theta)

    pointer = arrow(pos=(0.0, 0.0, 0.0), axis=(x, y, z), shaftwidth=0.01)

Unit-testing C code with Python & swig & nose

nosetest.png

I’m finding a way how to test code of lucille.

There are some testing methods

– Unit test
– Use case(functional test)
– Behaviour driven development
– Formal verification(good for testing algorithm itself)
– Model checking for monte carlo algorithm( e.g. prism )
– etc.

In this article, I’d like to talk to about how to do unit testing for C function.

There’s already good unit testing framework for C, CUnit.
But writing fixture(setup, teardown) code also in C is harder & redundant & time-consuming,
so I tried to seek a way to test C code from scripting language.

An answer I’ve convinced so far is to use Python to write fixture and swig to call C function from Python.
And more, nose enables writing python-side test code much more simpler.

Here’s my trial of C, swig, Python and nose combination for unit testing.

C code to be tested

First, let we assume unit-test functions is defined in list.h(code grabbed from lucille source).


/*
 * simple list routine.
 *
 * $Id: list.h,v 1.1.1.1 2004/01/06 13:57:09 syoyo Exp $
 */

#ifndef LIST_H
#define LIST_H

#ifdef __cplusplus
extern "C" {
#endif

typedef struct _ri_list_t
{
	void		  *data;
	struct _ri_list_t *next;
	struct _ri_list_t *prev;
} ri_list_t;

extern ri_list_t *ri_list_new();
/* add data to last */
extern void	  ri_list_append(ri_list_t *list, void *data);
...

 
 
Swig

Then, write swig interface file test.i so that C functions can be callable from Python.


%module base_list
%{
#include "memory.h"
#include "list.h"
%}

%include "../../../../src/base/memory.h"
%include "../../../../src/base/list.h"


 
 
Provide setup.py to ease compile/link C code to make a module.


# setup.py
import distutils
from distutils.core import setup, Extension

import os

srcPath = "../../../../src/base"

srcList = [ "list.i"
          , os.path.join(srcPath, "list.c")
          , os.path.join(srcPath, "memory.c")
          ]

setup(name = "base_list",
      version = "1.0",
      ext_modules = [Extension("_base_list", sources=srcList, include_dirs = [srcPath])])

 
 

With setup.py, compiling module can be done by just typing


$ python setup.py build_ext --inplace

 
 

Python test code

Finally, write unit test code in python(test.py)
Thanks to nose, classes whose name having “test” is considered as a test,
so we don’t need to write unit test related things explicitly.


from base_list import *

import os, sys

class TestListNewIsNotNull():

    def setup(self):
        pass

    def teardown(self):
        pass

    def testListNew(self):
        l = ri_list_new()

        assert l != None

class TestListNextAfterListNewIsNull():

    def setup(self):
        self.lst = ri_list_new()

    def teardown(self):
        ri_list_free(self.lst)

    def test(self):
        l = ri_list_next(self.lst)

        assert l == None


 
 

Run test with nose

Functions/Classes/Directories with name having “test” is automatically executed by nose.


 $ nosetests -v
test.TestListNewIsNotNull.testListNew ... ok
test.TestListNextAfterListNewIsNull.test ... ok

----------------------------------------------------------------------
Ran 2 tests in 0.008s

OK


Sounds nice?

All codes explained above are located at,

https://lucille.svn.sourceforge.net/svnroot/lucille/trunk/tests/unit/testBase/testList

N と A

しばらくウォッチしていなかったのですが、

http://finance.google.com/finance?q=nvda

http://finance.google.com/finance?q=NYSE:AMD

あらら、、、まあハイテク系は現在軒並み半額セール中が多いので、妥当なところでしょうか?
(これからもっと叩き値になる可能性もあります)

AMD は赤字だからとりあえず置いておいて、NVDA は GX2 発表にも関わらず大きな反応なし.
市場も、消費バブル崩壊でハイエンド製品が売れなくなることを折り込みつつあるのかもしれません.

Larrabee, accelerated for ray tracing, double x 4 SIMD.

http://www.dailytech.com/article.aspx?newsid=11088

> Smith said Larrabee will support OpenGL, DirectX and ray-tracing instructions.

インテル、新しいグラフィックチップ「Larrabee」の追加情報を公開
http://japan.cnet.com/news/ent/story/0,2000056022,20369631,00.htm
> 現在のGPGPUに対する一部のアプローチでは、そのチップにしか通用しない特化されたプログラミング技法を学習する必要があり

【IDFプレビュー】Intel社がグラフィックスLSIで本腰,「Larrabee」は単体製品で提供
http://techon.nikkeibp.co.jp/article/NEWS/20080318/149166/
> AVXでは256ビットのベクトル演算を可能にする。

Larrabee では、レイトレ用インストラクションを提供するみたいですね。
うーん、どんな感じだろう。レイトレ用に何かしらの HW 回路が付かないのであれば、
外積計算や、 AABB との交差判定くらいでしょうか?
レイと三角形の交差判定は、1 インストラクションで表現するには大きいし、レジスタも足りなさそうだからなさそう。
# I 社のサイダーにでも聞くのが早いか。
# でもサイダーをやると日記とかに書けなくなるので気をつけないといけなくなる.

256 bit の SIMD 演算はよさそうですね。double x 4 が実用的になると、
レンダラにも大きな恩恵があると思います。

まあでもホント言うと、SIMD はもうやめてスカラ + メニーコアのほうが、
コードを書くほうからすると楽でいいと思います。
(CUDA などのなんちゃってスカラ(=SPMD) は論外ですが)

MUDA も今は演算は fp32 x 4 がメインですが、
fp64 x 4 が扱えるようにするのもそんなに難しくないでしょうし、
Larrabee 向けのバックエンドを書くのもそんなに難しくなさそう。
そんなわけで Larrabee 向けのバックエンドも書いてみたいところ。

リスクが世界を駆け巡る : 2008 年 3 月 17 日時点

うはー!
うおー!
がおー!

いやー、この毎日が祭りは何時まで続くのでしょうかね.

USD/JPY の下落がすごい.

ドル3円超の急落、9年ぶりパニック売りでも下値めど見えず
http://jp.reuters.com/article/topNews/idJPJAPAN-30868220080317

ベアスタは、JPM にわずか 一株 $2(総額たったの 270 億円程度!) で買収された…

J.P. Morgan Buys Bear in Fire Sale, As Fed Widens Credit to Avert Crisis
http://online.wsj.com/article/SB120569598608739825.html

先週末の株価は $30, 少し前は $70 近くあったのに…
それでも $2 値がついたと見た方がいいのかもしれない.

Vertex Culling illustration at SBR07

Oh, I’ve forgotten to upload my presentation of Vertex Culling illustration at SBR07(Held on Nov, 2007).

Here’s the side.

FYI: Vertex Culling is one of the acceleration technique for realtime raytracing, possibly simplest but fastest at this time.

リスクが世界を駆け巡る : 2008 年 3 月 14 日時点

ベアスタが、JPM と FED から緊急融資(?)を受けることになった。
サブプライムで最初につぶれる大手金融機関は、ベアスタになりそうだ。

http://www.reuters.com/article/innovationNews/idUSN1438968020080314

FED は、市場に、”なあに、最後は FED(公的資金) が救ってくれるさ”、
とモラルハザードを引き起こすようなシグナルを発していいのだろうか?

ベアスタの株価はこのニュースを受けて 40% ほど低下した。
ボロクソに売られてますな。

http://finance.google.com/finance?q=NYSE:BSC

来週の金融機関の 1Q 決算、 FOMC ではもっと阿鼻叫喚になりそうだ。

そして、金はついに 1,000 ドルを突破した!
http://www.kitco.com/charts/livegold.html

金融•経済の世界はもう毎日がお祭りです。