投稿
昨日の latexdraw であるが、これを取り込むと xdvi の -fg が効かないことがわかり、それに対応するのにかなりの時間を取られてしまった。
問題点は pstricks を取り込むことで、これを取り込むと本文が xdvi -fg で変更できなくなる。
自分の場合、長時間 xdvi を見ることもあるため、
$ xdvi -fg white -bg \#333366
としているが、黒になってしまって 333366 の背景に埋もれてしまう。
いろいろと試した結果、
\begin{document}
の前に
\color{white}
とすると、文章全体を白くできることがわかった。
とりあえず xdvi を見るときには、この状態で見ることにして、pdf に変換するときになったら、これを外すことにする。
今日の作業内容：xdvi の色 3h + 航空券関係 3h
今日のランチ：らく ハンバーグとカキフライ \850
明日の予測作業時間：5h
2011年2月17日木曜日
2011年2月16日水曜日
latexdraw
今まで TeX の図は tgif で作っていたが、TeX には picture 環境があって tgif のように eps にしなくても簡単な図であれば書くことができる。
ただ、picture 環境をそのまま座標とかの数字をいじるのはきついので、latexdraw を使うことにした。
これだと、eps と違って tex ファイル（文字ファイル）で生成されるので、git などでの管理も容易になるはず、というメリットもある。
latexdraw は Debian, Ubuntu ならパッケージになっているので、簡単に導入することができる。
ただし、latexdraw は dvipdfmx を通せないので、\documentclass などで dvipdf などを設定しているときには dvips にする必要がある。また、pdf にするなら ps2pdf である。
また、Ubuntu の dvips はそのままでは日本語が通らないので、
$ sudo add-apt-repository ppa:cosmos-door/dvipsk-ja
$ sudo apt-get update
$ sudo apt-get install dvipsk-ja
$ sudo apt-get install ptex-jisfonts cmap-adobe-japan1 gs-cjk-resources ghostscript
$ sudo jisftconfig add
とすると、dvips で日本語を通すことができる。
ただし、Debian ではこの方法は通じない。Debian では cidfmap に Ryumin-Light (Ryumin-Light-Hではなく、Ryumin-Lightを書くのがポイント）の行を書き足す必要があるのだが、他にもいろいろと作業をしてしまったため、どれが本当に必要なのかよくわからなくなってしまった。(Debian では dvipsk-ja は更新されていたので、ppa を追加しなくても大丈夫であった）
なお、latexdraw で生成したソースは、そのまま tex ソースにコピーペーストできるが、これはpstricks としてエクスポートしておくと、あとで latexdraw にインポートしなおせるので便利である。tex では \input があるので、これを利用するのがスマートでもある。
ちなみに、Ubuntu の LXDE では、いまは emacs が Arithmetic Error というエラーで起動できない。すでにバグ報告がされているので、そのうち修正されると思われる。
また、LANG=C をつけたまま日本語ファイルを扱うと、読み込んだときに文字化けを起こす。通常 ssh でログインするときには LANG=C のほうが便利なのでそうしていたが、意外な盲点であった。
今日の作業内容：dvips 文字化け対応 4h + 海外出張準備 2h
今日のランチ：四川 鶏白菜春雨うまみ煮
明日の予測作業時間：5h
ただ、picture 環境をそのまま座標とかの数字をいじるのはきついので、latexdraw を使うことにした。
これだと、eps と違って tex ファイル（文字ファイル）で生成されるので、git などでの管理も容易になるはず、というメリットもある。
latexdraw は Debian, Ubuntu ならパッケージになっているので、簡単に導入することができる。
ただし、latexdraw は dvipdfmx を通せないので、\documentclass などで dvipdf などを設定しているときには dvips にする必要がある。また、pdf にするなら ps2pdf である。
また、Ubuntu の dvips はそのままでは日本語が通らないので、
$ sudo add-apt-repository ppa:cosmos-door/dvipsk-ja
$ sudo apt-get update
$ sudo apt-get install dvipsk-ja
$ sudo apt-get install ptex-jisfonts cmap-adobe-japan1 gs-cjk-resources ghostscript
$ sudo jisftconfig add
とすると、dvips で日本語を通すことができる。
ただし、Debian ではこの方法は通じない。Debian では cidfmap に Ryumin-Light (Ryumin-Light-Hではなく、Ryumin-Lightを書くのがポイント）の行を書き足す必要があるのだが、他にもいろいろと作業をしてしまったため、どれが本当に必要なのかよくわからなくなってしまった。(Debian では dvipsk-ja は更新されていたので、ppa を追加しなくても大丈夫であった）
なお、latexdraw で生成したソースは、そのまま tex ソースにコピーペーストできるが、これはpstricks としてエクスポートしておくと、あとで latexdraw にインポートしなおせるので便利である。tex では \input があるので、これを利用するのがスマートでもある。
ちなみに、Ubuntu の LXDE では、いまは emacs が Arithmetic Error というエラーで起動できない。すでにバグ報告がされているので、そのうち修正されると思われる。
また、LANG=C をつけたまま日本語ファイルを扱うと、読み込んだときに文字化けを起こす。通常 ssh でログインするときには LANG=C のほうが便利なのでそうしていたが、意外な盲点であった。
今日の作業内容：dvips 文字化け対応 4h + 海外出張準備 2h
今日のランチ：四川 鶏白菜春雨うまみ煮
明日の予測作業時間：5h
2011年2月15日火曜日
C/C++によるプログラミングスタイルブック
ここのところ時間がまとまって取れていないので、今日は
「C/C++によるプログラミングスタイルブック」
を細切れの時間に読んだ。
この本はだいぶ古い本ではあるが、SDPA のソースを書く際に参考にしている。
例えば、SDPA の callalbe library で k,l,i,j の変数については、できるだけ
「入力行列 F_k の l 番目のブロックの (i,j) 要素」
となるように統一してある。
SDPA のソースの中でも、できるだけこのルールに従っている。
（ただし、Schur complement のところは少しルールが違い、
i,j は Schur complemet の (i,j) 要素を指すようになっている。）
このように変数の意味をできるだけ固定するとデバッグが行ないやすい。
たとえば、k は0から入力行列の個数 (mDIM) の範囲になるので、
行列のサイズ(nBLOCK, blockStruct)と比較していたらバグの可能性が高い。
10年近く前の書籍ではあるが、「バグの少ないプログラムを書く」という点では
今でも十分に参考になる。
今日の作業内容：本読み 2h
今日のランチ：つかさ カンパチのから揚げ
明日の予測作業時間: 2h
「C/C++によるプログラミングスタイルブック」
を細切れの時間に読んだ。
この本はだいぶ古い本ではあるが、SDPA のソースを書く際に参考にしている。
例えば、SDPA の callalbe library で k,l,i,j の変数については、できるだけ
「入力行列 F_k の l 番目のブロックの (i,j) 要素」
となるように統一してある。
SDPA のソースの中でも、できるだけこのルールに従っている。
（ただし、Schur complement のところは少しルールが違い、
i,j は Schur complemet の (i,j) 要素を指すようになっている。）
このように変数の意味をできるだけ固定するとデバッグが行ないやすい。
たとえば、k は0から入力行列の個数 (mDIM) の範囲になるので、
行列のサイズ(nBLOCK, blockStruct)と比較していたらバグの可能性が高い。
10年近く前の書籍ではあるが、「バグの少ないプログラムを書く」という点では
今でも十分に参考になる。
今日の作業内容：本読み 2h
今日のランチ：つかさ カンパチのから揚げ
明日の予測作業時間: 2h
2011年2月14日月曜日
GotoBLAS2 の Windows 版を Debian の mingw32 でコンパイル
GotoBLAS2 の Windows 版を Debian 上の mingw32 でコンパイルできるようになったので、そのメモを残しておく。
[1] download
GotoBLAS2 は以下のところからダウンロードする。
http://www.tacc.utexas.edu/tacc-projects/gotoblas2/downloads/
[2] mingw32 の環境整理
sudo apt-get install mingw32-binutils mingw32-runtime wine
[3] ファイルを展開
tar xzf GotoBLAS2-1.13_bsd.tar.gz
cd GotoBLAS2
[4] ファイルを修正
以下のように修正する。
（先頭に - があるところを + の行に書き換える。ただし、Makefile.getarch は Makefile なので各行の最初がTabになるようにしなければならない）
Makefile.getarch では、
all: getarch_2nd
- ./getarch_2nd 0 >> $(TARGET_MAKE)
- ./getarch_2nd 1 >> $(TARGET_CONF)
+ cp getarch_2nd getarch_2nd.exe
+ wine ./getarch_2nd.exe 0 >> $(TARGET_MAKE)
+ wine ./getarch_2nd.exe 1 >> $(TARGET_CONF)
config.h : c_check f_check getarch
perl ./c_check $(TARGET_MAKE) $(TARGET_CONF) $(CC)
perl ./f_check $(TARGET_MAKE) $(TARGET_CONF) $(FC)
- ./getarch 0 >> $(TARGET_MAKE)
- ./getarch 1 >> $(TARGET_CONF)
+ cp getarch getarch.exe
+ wine ./getarch.exe 0 >> $(TARGET_MAKE)
+ wine ./getarch.exe 1 >> $(TARGET_CONF)
GotoBLAS2/driver/others/blas_server_omp.c では、
#include<sys/mmap>
をコメントアウトする。
GotoBLAS2.org/driver/others/dynamic.cでは、
#ifdef ARCH_X86
- if (gotoblas == NULL) gotoblas = gotoblas_KATMAI;
+ if (gotoblas == NULL) gotoblas = & gotoblas_KATMAI;
#else
- if (gotoblas == NULL) gotoblas = gotoblas_PRESCOTT;
+ if (gotoblas == NULL) gotoblas = & gotoblas_PRESCOTT;
#endif
と修正する。
[5] コンパイル
make \
DYNAMIC_ARCH=1 \
USE_THREAD=1 \
USE_OPENMP=0 \
CC=i586-mingw32msvc-gcc \
FC=i586-mingw32msvc-gfortran \
BINARY=32 \
libs netlib
なお、USE_OPENMP=1 は mingw32 に libgomp がないので失敗するため、USE_OPENMP は必ず 0 にする。
NO_WARMUP=1 にするのもありだと思うが、SDPA の場合には Warm up が効かなかった。
また、今回は 32 bit 版で作成している（pthread-win32 が 64bit でコンパイルできていないため）。
基本的にどの CPU にも対応できるように DYNAMIC_ARCH=1 であるが、これはすべての CPU の分を持つので、コンパイルに時間がかかるのとできるファイルが大きくなる。
[5]ranlib でライブラリにする。
i586-mingw32msvc-ranlib libgoto2.lib
これで mingw32 用に使える GotoBLAS2 がコンパイルできる。
今日の作業内容：SNL のデータ変換 2h
今日のランチ： らく 焼魚定食
明日の予測作業時間： 3h
[1] download
GotoBLAS2 は以下のところからダウンロードする。
http://www.tacc.utexas.edu/tacc-projects/gotoblas2/downloads/
[2] mingw32 の環境整理
sudo apt-get install mingw32-binutils mingw32-runtime wine
[3] ファイルを展開
tar xzf GotoBLAS2-1.13_bsd.tar.gz
cd GotoBLAS2
[4] ファイルを修正
以下のように修正する。
（先頭に - があるところを + の行に書き換える。ただし、Makefile.getarch は Makefile なので各行の最初がTabになるようにしなければならない）
Makefile.getarch では、
all: getarch_2nd
- ./getarch_2nd 0 >> $(TARGET_MAKE)
- ./getarch_2nd 1 >> $(TARGET_CONF)
+ cp getarch_2nd getarch_2nd.exe
+ wine ./getarch_2nd.exe 0 >> $(TARGET_MAKE)
+ wine ./getarch_2nd.exe 1 >> $(TARGET_CONF)
config.h : c_check f_check getarch
perl ./c_check $(TARGET_MAKE) $(TARGET_CONF) $(CC)
perl ./f_check $(TARGET_MAKE) $(TARGET_CONF) $(FC)
- ./getarch 0 >> $(TARGET_MAKE)
- ./getarch 1 >> $(TARGET_CONF)
+ cp getarch getarch.exe
+ wine ./getarch.exe 0 >> $(TARGET_MAKE)
+ wine ./getarch.exe 1 >> $(TARGET_CONF)
GotoBLAS2/driver/others/blas_server_omp.c では、
#include
をコメントアウトする。
GotoBLAS2.org/driver/others/dynamic.cでは、
#ifdef ARCH_X86
- if (gotoblas == NULL) gotoblas = gotoblas_KATMAI;
+ if (gotoblas == NULL) gotoblas = & gotoblas_KATMAI;
#else
- if (gotoblas == NULL) gotoblas = gotoblas_PRESCOTT;
+ if (gotoblas == NULL) gotoblas = & gotoblas_PRESCOTT;
#endif
と修正する。
[5] コンパイル
make \
DYNAMIC_ARCH=1 \
USE_THREAD=1 \
USE_OPENMP=0 \
CC=i586-mingw32msvc-gcc \
FC=i586-mingw32msvc-gfortran \
BINARY=32 \
libs netlib
なお、USE_OPENMP=1 は mingw32 に libgomp がないので失敗するため、USE_OPENMP は必ず 0 にする。
NO_WARMUP=1 にするのもありだと思うが、SDPA の場合には Warm up が効かなかった。
また、今回は 32 bit 版で作成している（pthread-win32 が 64bit でコンパイルできていないため）。
基本的にどの CPU にも対応できるように DYNAMIC_ARCH=1 であるが、これはすべての CPU の分を持つので、コンパイルに時間がかかるのとできるファイルが大きくなる。
[5]ranlib でライブラリにする。
i586-mingw32msvc-ranlib libgoto2.lib
これで mingw32 用に使える GotoBLAS2 がコンパイルできる。
今日の作業内容：SNL のデータ変換 2h
今日のランチ： らく 焼魚定食
明日の予測作業時間： 3h
2011年2月12日土曜日
GotoBLAS のマルチスレッドで SDPA が遅くなる理由
一日かけて、GotoBLAS のマルチスレッドで SDPA が遅くなる理由を探ってみた。
まず、シングルスレッドに比較してどの問題について遅くなるかを特定したところ、
量子化学の問題やtheta6.dat-s はマルチスレッドのほうが高速で、
control11.dat-s だけマルチスレッドにすると極端に遅くなる。
control11.dat-s は Schur complement 作成のときに F1 の式にかかる負担が大きいのが特徴で、マルチスレッドの場合もここが遅くなることがわかった。さらに F1 の式を詳しく見てみると、
X*Ai (Xは密行列、Ai は疎行列）の計算が99% 近い計算時間を占めている。
この中は daxpy を呼び出しているか、dgemm を呼び出しているのであるが、control11.dat-s の場合は、dgemm を F1 では呼び出していない。
結局のところ、問題が起きているのは daxpy のようである。
１回１回は 1 milli second 程度であるが、これが200万回程度呼ばれており、全体として 1300 秒程度（SDPA合計の95%以上）を占めていた。
今使っている GotoBLAS は DYNAMIC_ARCH なので、おそらく daxpy に入るたびにスレッド数などをチェックしているものと推測され、これが計算時間の負荷になっているのだと考えられる。
今はWARMUP を切っているので、WARMUP をつければ改善するのかもしれない。
これは、またチェックしよう。
今日の作業内容：GotoBLAS チェック 6h
明日の予測作業時間: 3h
まず、シングルスレッドに比較してどの問題について遅くなるかを特定したところ、
量子化学の問題やtheta6.dat-s はマルチスレッドのほうが高速で、
control11.dat-s だけマルチスレッドにすると極端に遅くなる。
control11.dat-s は Schur complement 作成のときに F1 の式にかかる負担が大きいのが特徴で、マルチスレッドの場合もここが遅くなることがわかった。さらに F1 の式を詳しく見てみると、
X*Ai (Xは密行列、Ai は疎行列）の計算が99% 近い計算時間を占めている。
この中は daxpy を呼び出しているか、dgemm を呼び出しているのであるが、control11.dat-s の場合は、dgemm を F1 では呼び出していない。
結局のところ、問題が起きているのは daxpy のようである。
１回１回は 1 milli second 程度であるが、これが200万回程度呼ばれており、全体として 1300 秒程度（SDPA合計の95%以上）を占めていた。
今使っている GotoBLAS は DYNAMIC_ARCH なので、おそらく daxpy に入るたびにスレッド数などをチェックしているものと推測され、これが計算時間の負荷になっているのだと考えられる。
今はWARMUP を切っているので、WARMUP をつければ改善するのかもしれない。
これは、またチェックしよう。
今日の作業内容：GotoBLAS チェック 6h
明日の予測作業時間: 3h
2011年2月11日金曜日
2011年2月10日木曜日
航空券だけで終わった
今日は航空券を探すのだけで終わってしまった。
インターネットのあるサイトで航空券を検索しているのだが、「空席わずか」のところで VISA カードの支払いまで進むと「座席なし」に切り替わってしまう。
一度「座席なし」になっても何時間か経つと急に「空席わずか」に戻り、また VISA カードの支払いでダメになる。
結局、１時間に何回もリロードして、実際に座席が取れるのかを確認してみたが、かなりの時間を取られてしまった。
今日の作業内容：航空券の確保 5h
今日のランチ：味庵 鶏とたまねぎの炒め物
明日の予測作業時間：5h
インターネットのあるサイトで航空券を検索しているのだが、「空席わずか」のところで VISA カードの支払いまで進むと「座席なし」に切り替わってしまう。
一度「座席なし」になっても何時間か経つと急に「空席わずか」に戻り、また VISA カードの支払いでダメになる。
結局、１時間に何回もリロードして、実際に座席が取れるのかを確認してみたが、かなりの時間を取られてしまった。
今日の作業内容：航空券の確保 5h
今日のランチ：味庵 鶏とたまねぎの炒め物
明日の予測作業時間：5h
登録:
投稿 (Atom)