MPACK 0.6.5には__attribute__をサポートするコンパイラが必要になる

MPACK 0.6.5のリリース準備を行っているが、Cコンパイラの__attribute__サポートを要求するようにした。嗚呼ポータビリティ...といいつつメジャーどころであるgcc, iccなどがサポートしているので問題ないだろう。PGIなどはサポートしていないらしい(さくっと無視するとのこと)仕方ないのでconfigureで調べることにした。これで./configureが落ちたらあなたのC++コンパイラは腐っている。速やかにgccかよいコンパイラにとりかえるべし。以下の私が作ったpublic domainのコードを参考のこと。

AC_MSG_CHECKING([whether gcc __attribute__ ((constructor)) extension works])
AC_TRY_RUN([
#if STDC_HEADERS
#include <stdio.h>
#include <stdlib.h>
#endif
int isexistattribute = 1;
void init() __attribute__((constructor));
void init() { isexistattribute = 0; }
int main() { exit(isexistattribute);}
],[AC_MSG_RESULT([yes])], [AC_MSG_ERROR([your compiler doesn't support gcc __attribute__((constructor)) ]) ]) 

FreeBSD 8.0のdgemmが遅い、これを再現する方法

FreeBSD 8.0のdgemmが遅い、これを再現する方法を紹介する。
すでにFreeBSD-stable MLに投稿したが...

1. ソースコードをダウンロードする。
Makefile
dgemm.cpp
check md5.
% md5 Makefile dgemm.cpp
MD5 (Makefile) = b408ab1e1f5bf8b923cae5ec9f9f0f07
MD5 (dgemm.cpp) = 0d774a456a665429c67c2b07fd24c64c

2. ports/math/gotoblas をインストール; 登録と手動ダウンロード必要。
cd /usr/ports/math/gotoblas; sudo make; sudo make instal

3. dgemmを走らせる。

% ./dgemm
n: 3000
time : 134.648208 or 16.910525
Mflops : 31943.419695
n: 3100
time : 148.122279 or 18.615284
Mflops : 32017.357408
n: 3200
time : 162.488885 or 20.430651
Mflops : 32087.318295
n: 3300
time : 178.497079 or 22.446093
Mflops : 32030.420499
n: 3400
time : 195.550715 or 24.586152
Mflops : 31981.873273
n: 3500
time : 213.403379 or 26.825058
Mflops : 31975.513363
n: 3600
...
おそいっすね。

縮約密度行列の方法のレジュメ、てっとりばやく知るには

縮約密度行列の方法のレジュメ。これは2009年に首都大学東京でおこなった講義の資料である。なお、これに関しては資料が少なく、しかし興味も持たれているようで縮約密度行列でGoogleをかけると二番目にでてくる。一番目は2008年の私の理論化学討論会のスライド。これはあまりこなれていないので、概略をつかむには2010年のSanibel Symposiumのplenary lectureでのスライドが良いだろう。

明かに我々の2001年の論文が先行している。一旦気づけばあとは誰でもできる。研究とはそういう性格が有る。指導教官だった中辻先生もよくそうおっしゃっていた。

縮約密度行列を使った量子化学の方法で、半正定値計画法を使うものは1999年に始まった

縮約密度行列(2-RDM)を使った量子化学の方法で、半正定値計画法を用いるということは1999年に始まった。fj.sci.mathに投稿して、答えをいただいた。密度方程式(contracted schrodinger equation)が解けないし数値的な振る舞いが悪いため、いくつかのポイントに絞って考えたのが発端だ。

1. 最小値の存在の問題...量子化学の理論
2. 計算可能性の問題...最適化の理論
3. 実際のパフォーマンス...数理計画の実装面

幸い、上の2. 3.は当時東工大の、小島政和研究室で、藤澤先生、中田和秀先生、小島先生らで作られていたSDPAを使うと、既に解決されていた。小島先生のチュートリアル的な文書がいくつもご自身の手でwebにアップされていましたが、なんとなく定式化できるだろうなと思って、(なぜか)当時D1の学生だった福田さんにメールして、一緒に定式化してもらった。そして、量子化学の問題を無事定式化できて、さらに実装も素敵で思った精度がでた。この成果は2001年に ``variational calculations of fermion second-order reduced density matrices by semidefinite programming algorithm.''として出版された。現在引用回数はweb of scienceで100回を越える。それにしてもいま思えば、タイトルがちょっとへんだよな、とかなぜ小島先生の名前が入ってないのかとか、小野孝男さんにもアクノリッジしてない、とか、残念な部分が色々ある。あの時は何も分かってなかったんだよね。

FreeBSD 8.0でdgemmがなぜLinuxより25%も遅いか検証中

この前のエントリFreeBSD 8.0 dgemm:理論性能値のたった70% Ubuntu 95%を英訳してメーリングリストに投げたら結構反響が有って色々な人からメールをもらった。

FreeBSD 8.0でなぜ遅いか、いい機会だからバグなりなんなりを叩き潰してもらおうと思う。色々協力中。検証用コードも送った。現段階では遅いが、その原因は必ずしもクリアではない。後藤さんの指摘はAlan Cox, Andrew Snowは間違っているという。もうすこし見る必要はある。

後藤さんの
> BSD 系列はメモリ管理の
> 粒度が小さすぎて、物理アドレスでの連続性があまり得られません。
は、もうすでに改善されている旨Alan Coxからメールをいただいた。論文も入手できる。

> These statements about FreeBSD's memory management are wrong, or at least
> outdated. FreeBSD is very likely to allocate physical memory in contiguous
> chunks to your memory-hungry application even if automatic superpage
> promotion does not occur.
>
> You should refer your friend to my paper at
> http://www.usenix.org/events/osdi02/tech/full_papers/navarro/navarro_html/and
> tell him that FreeBSD >= 7.2 implements a variation on what that paper
> describes.

次に、
〉プロセスのスケジューリングでも同一のコアに固定した
> スケジューリングではなくて、コロコロと移動させてしまいます。
でもないことが
Andrew Snowによって指摘された。
> The statements about the scheduler flipping between cores is also
> somewhat false, ULE does the right thing now for long-running
> computational threads.
同メールでスケジューラの問題かといってます。
ぼちぼち追記してゆきます。