cusp

何度かダウンロードに挑戦しているが、未だEclipseがマーケットに繋がらない。
SpMVのコードもcusp以外に生きているプロジェクトはなさそうで、
cuspの結構長いコードをcuda-gdbで追うとすると結構骨が折れそうな作業であるため、
どうにかならないものか考えている途中です。

Eclipseのプラグイン導入がうまくいかない

AMDのOpenCLソフトウェア環境が不完全であるため、
TSUBAME上でCUDAを用いた実験で代替する予定なのだが、
CUDAコードをLinux環境上で楽に行う環境構築を行いたい。

そこで、Fixstars社が開発し、オープンソースで公開している
Eclipse用のCUDAプラグインを用いることを画策していた。
しかしながら、Eclipse Marketから当該のプラグインを落とそうとしても、
そもそもマーケット自体に接続できない。

何が起きているのかよくわからないので、一度Windows環境上で追試してみる予定だ。

AMD Radeon HD7970 & APP SDK v2.6

待望の新アーキテクチャのGPUが登場。
より汎用計算向きの構成が取られており、非常に楽しみ。
特にSM単位で命令発行でき、L1などの容量も大幅に改善されているのが気になる。
あとは性能とソフトウェア環境の整備次第なのか。
http://pc.watch.impress.co.jp/docs/column/kaigai/20111222_501138.html

APP SDK 2.6ではOpenCL 1.2の仕様の一部が利用可能になっており、
特にカーネルコードでC++98の一部が記述可能になったそうだ。
具体的には、ホストで作ったクラスをカーネルに転送し、
カーネル関数でアクセスするなどかなり自由度が上がっている。
また、カーネル関数のオーバーロードやテンプレートも作成できる。

そのほかの改善としては、APUでのAtomicカウンタの対応と、
非同期メモリコピーの実現が挙げられる。
もちろんRadeon HD79xx対応も行われている。
http://developer.amd.com/sdks/AMDAPPSDK/assets/AMD_APP_SDK_Release_Notes_Developer.pdf

ただし、未だにLinuxでのZero Copyには対応できていない。
現状、自分の研究にはOpenCL + AMD APUは利用できなさそうだ。

CUDA to OpenCL

AMDのページにもっと詳細な移植用のメモがあった。
しかし今後移植を行う可能性は低い。
http://developer.amd.com/zones/OpenCLZone/programming/pages/portingcudatoopencl.aspx

Tesla C1060でOpenCLを実行できるよう環境整備したが、
何かNVIDIA環境でもOpenCLだとメモリコピーなどが非常に遅い気がする。
面白いデータが取れそうなので、間に合えば論文にも載せる予定。

OpenCL C++ bindingでException

#define __CL_ENABLE_EXCEPTIONS

これがないとコンパイラにぐだぐだ言われます。注意！

こんな感じのよくわからないエラーが出て凹みます。
mem.cpp:40: error: expected type-specifier
mem.cpp:40: error: expected unqualified-id before ‘status’
mem.cpp:40: error: expected ‘)’ before ‘status’
mem.cpp:40: error: expected ‘{’ before ‘status’
mem.cpp:40: error: expected ‘;’ before ‘)’ token

キャッシュミス測定

いいコマンドを知った

% valgrind --tool=cachegrind ./test

さよならMars

Marsから離れることができた。よかった。

修士論文に向けて、ようやく全体の構成がまとまってきたので一安心だ。
新しいアプリケーションの実装は必要だが、研究室の他の学生も似た処理を実装しているのでどうにかなるのではないかと思っている。

Marsの移植が終わらない

Mars自体の処理の流れは掴めており、後はOpenCLとCUDAで差異がある部分だけを書き直せばいいのだが、
どのようなやり方で書き直すのが最適な手法なのか判断が付かず、そのたびに作業が迷走してしまう。

OpenCLではコンテキストやキュー、カーネルなどのオブジェクトを明示的に作成し、
メモリの転送やカーネルの実行時にそれらを指定してやる必要がある。

CUDAではこうした要素がプログラム実行時に暗に設定されるため、
ユーザはこれらを意識することなくプログラムを書いて実行することができる。

現在のMarsの実装だと、OpenCLではこうしたオブジェクトを利用する場面が
ソース内で関数を跨いで不規則に離散して存在しており、移植が非常に大変になっている。
特に関数呼出部分が辛く、OpenCLではカーネル関数ごとにクラスやオブジェクトを作って保持する必要があるため、
Marsで使われる多くのカーネル関数をどうにかしなければならない。

今までは何とかグローバル変数を使わずに済ませる方法を考えていたが、
このままではどうしようもなさそうなのでグローバル変数でオブジェクトを宣言するしかないのだろうか。

C++を使いだしてOpenCL関連のコードはかなり綺麗になったのだが、
またごちゃごちゃしてきそうで憂鬱だ。

OpenCL C++ bindingで複数の.clファイルを扱う

C++を使い慣れている人には常識的なことなのかもしれないが、
OpenCLをC++で使うときにやり方が見つからなかったのでメモ。

OpenCLをC++から叩くとソースが非常に短くなって生産性、可読性がかなり高まり便利。
しかしながら、使用者が少ないので情報があまりなく、その点では面倒。

標題の件だが、C++からは以下のようにしてソースをコンパイルする。
（srcに.clファイルのソースが含まれているとする。）
cl::Program::Sources source(1, std::make_pair(src, strlen(src) ));
cl::Program program_ = cl::Program(context, source);
program_.build(devices);

単一のソースのみをコンパイルする場合はこれでいいのだが、
複数のソースを扱う場合の情報は検索しても見つけられず、四苦八苦した。
しかし、あるサイトで先にsourceを宣言し、コンストラクタを使わずにpush_backを使うものを発見。
cl::Program::Sources source(1, std::make_pair(src, strlen(src) ));
↓
cl::Program::Sources source;
source.push_back(std::make_pair(src, strlen(src));

これと同じように、複数のファイルをpush_backしてやればそのままコンパイルが通る。

学会参加時の注意事項（特に海外）

今回SCに参加させていただき、色々注意すべき点があったのでメモとして残しておくことにします。


・清算
立替払いで予算を使う場合、各種手続きを行う必要がある。
URLを送ると秘書さんに支払い手続きからやってもらえる場合も。

学会参加費：カード明細を提出
宿泊費：国内はカード明細や領収書を提出、海外は一律で一人一泊1万円支給
　　　　学会発表の場合は発表者氏名がわかるURLの送付と印刷物を提出
　　　　それ以外の場合は開催日時などのページか交通費の日付で照会する
交通費：新幹線等国内交通費は開催地に応じて支給、飛行機は領収書を提出
食費：　学会中の食事回数毎に1000円を参加費から減額
報告書：五行程度の文章で、学会での活動、予算との関連性を出張報告として記述

以上のものを秘書さんに提出する。

・飛行機
なるべく余裕をもって行動する
飛行場から滞在地までの移動手段も事前に調査するべき
日中かどうかで機内温度が著しく変動するので着替え（上着）は必須
機内は大変乾燥するためマスクやのど飴で自衛すること
スリッパは普通支給されないが、足の疲れに大きく関わる
金属探知機対策としてPC等は速やかに出せるように
液体持込は100mlまでなので透明な袋を忘れないように

旅行サイトを2箇所くらい見て予習すれば問題ない

・海外滞在中
携帯電話は複数人で購入しないと効果は薄い
端末込みのプリペイドはスーパーやデパートのほうが機種は豊富
1週間程度なら2千円弱で稼動できるので導入する価値は高い

・論文
特定領域のアプリケーションの発表は外れが多いので事前にチェックが必要
実装したこと自体に意味があるものが多く、システム屋には全く無意味な発表も
評価が曖昧、最適化手法が領域特化しすぎ、ドメイン自体の紹介発表・・・など

背景知識の薄い発表は事前に論文を読まないと英語で理解するのは困難
そもそも重要な単語の意味がわからず発表全体が理解できない恐れもある
→事前に読むなら発表を聞きに行く必要は薄れる
特別な事情がない限り、自分の研究領域に近いものを選ぶべき

チュートリアルはあくまで基礎、実践がメインなので既知の技術なら参加する意義は薄い
有料のものだと資料は完成度の高いものもあるので最悪一人だけ参加すればよい


#追記
アプリケーションの発表を否定するような文になってしまったが、
あくまでもシステムの研究の参考にはなりにくいという意味です。
システムの研究においても本当の目的はアプリケーションの高速実行なので、
常にアプリケーションとの連携を考える必要はもちろんあります。
ただ、自らが対象としていないドメインのアプリケーションの論文発表を
聞くことが研究に直結するかどうかは非常に怪しい、ということです。

11/9 CUDAからOpenCLへの移植

簡潔にまとめられている記事があったので。

OpenCLLink プログラミング
http://reference.wolfram.com/mathematica/OpenCLLink/tutorial/Programming.ja.html

11/1 CUDA on Linux

フィックスターズ、Eclipse CUDA プラグインをオープンソース化
http://www.fixstars.com/ja/company/press/20110221.html

便利そう。
しかし最近はOpenCLばっかりなので使う機会がなさそう。

10/25 原因

前回うまくいかなかった原因がわかった。
Brazosの設定時と違い、yumで拾ってこれるkernel sourceのバージョンが変わっていたからだ。
カーネルのバージョンが関わるものは、yumを信用せず直接rpmを取得すべきと学習した。

自分のインストールしたkernelと一致するバージョンのものを拾ってくれば解決する。

# uname -r
カーネルのバージョンを確認。

# yum install http://ftp1.scientificlinux.org/linux/scientific/6x/x86_64/os/Packages/kernel-devel-2.6.32-131.0.15.el6.x86_64.rpm
適切なカーネルソースをインストール。

以下の手順は前回までに試した方法でOK。

vendorsも忘れずに作る。
これを忘れるとOpenCLデバイスを認識できない。
# mkdir /etc/OpenCL
# mkdir /etc/OpenCL/vendors
# echo "libamdocl32.so" > /etc/OpenCL/vendors/amdocl32.icd
# echo "libamdocl64.so" > /etc/OpenCL/vendors/amdocl64.icd


AMDドライバの生成とインストールだが、gccやrpm-buildがなかったり、
カーネルソースのバージョンが違う場合でも見た目は生成が成功してしまうことに注意。
今まで何度もこのせいでハマってしまっている。

/usr/share/ati/fglrx-install.logにログが残されるのだが、
ドライバ生成時には生成成功みたいなメッセージしか絶対に残されない。

いざドライバをインストールすると、そのときになって初めてエラーがわかるというダメな仕様。
ログを見て失敗していた場合、同ディレクトリ以下にアンインストールスクリプトがあるのでこれを実効。

失敗時の例（カーネルソースのバージョンミスマッチ）
[Message] Kernel Module : Trying to install a precompiled kernel module.
[Message] Kernel Module : Precompiled kernel module version mismatched.
[Error] Kernel Module : Kernel module build environment not found - please consult readme.
[Reboot] Kernel Module : dracut
[Message] Driver : End of installation

アンインストールが成功したら、エラーが出ていた部分を修正して再生成・再インストールする。
あとは今まで書いたような内容に注意してやればきっとうまくいくはず。

ssh経由でGPUを叩く場合、runlevel 3にしてローカルでログイン・startxして、
sshからログイン後は$ export DISPLAY=:0とする必要がある。
ローカルでstartxしていないとGPUに繋げられないようだ。
このうち一つでも設定していないと強制的にCPU実行になってしまうので注意。

10/20 まだうまくいかない

先ほどの設定を経てもまだうまくいかない。

/etc/modprobe.d/以下のblacklistが悪いとかいうのを見たので、
radeonとかfglrxとか書かれているのをコメントアウトする。

具体的には、blacklist-fglrx.confとblacklist.conf。


うまくいかない。
よく見るとfglrxと衝突するから止めるとか書いてある。逆だったのか。
blacklist-fglrx.confのほうは再び有効に。

llano 環境整備

作業まとめ

・Oprofile
sudoがあると便利なので一緒にyumしておく。
vmlinuzを含めたプロファイルにはkernel-debuginfoも必要。
oprofileをyumすれば終わり。

yumではkernel-debuginfoが落とせないときがあるので、
その場合はkernelとかOSのバージョンとdebuginfoで適当にググると出てくる。
依存関係でkernel-debuginfo-commonもいる。
今回は山形大学のお世話になった。
http://ftp.yz.yamagata-u.ac.jp/pub/linux/scientific/6.1/archive/debuginfo/kernel-debuginfo-2.6.32-131.0.15.el6.x86_64.rpm
http://ftp.yz.yamagata-u.ac.jp/pub/linux/scientific/6.1/archive/debuginfo/kernel-debuginfo-common-x86_64-2.6.32-131.0.15.el6.x86_64.rpm

・ATI driver
runlevelが5だとドライバ生成が失敗する。
Xが起きているとまずいみたい。

/etc/inittabを編集。
id:5:initdefault:
上のような行があるので、5を3にする。
id:3:initdefault:

また、rpm-buildとkernel-develも必要なのでyumしておく。

ドライバを生成するスクリプトをAMDから落として起動。
# wget http://www2.ati.com/drivers/linux/ati-driver-installer-11-9-x86.x86_64.run
# ./ati-driver-installer-11-9-x86.x86_64.run
色々聞かれるが、自分のOSとbit数を当てればいいだけ。
ディレクトリはそのまま/のままでよい。

こうするとrpmが生成されるので、これをインストール。
/usr/share/ati以下や/root以下のlogに変なことが書かれていなければOK。
成功するとamdcccleなどが使えるようになる。

OpenCLを使うのはだいぶ前に書いた/etc/OpenCL/vendorsもいるので注意。
前回からの転載。

/etc/OpenCL/vendors/amdocl32.icd
中身↓
libamdocl32.so

/etc/OpenCL/vendors/amdocl64.icd
中身↓
libamdocl64.so

これでデバイスが認識できてOpenCLのコードが動く。
ただし、このままではCPUしか利用できない。
SSH経由でGPUを叩くには、ホストマシンでXにログインが必要。
rootでなくとも自分のユーザ名で可。(login後、startxすればよい)

その後、
$ export DISPLAY=:0
としてローカルのXに繋ぐ。
こうしないとGPUを認識してくれない模様。

以上でOpenCLが使えるようになる。


＜10/20 17:49 追記＞
APUの内蔵GPUをOpenCLデバイスとして正しく認識するには、
runlevelをもう一度5に戻して再起動する必要がある。注意。


（以前設定したままなのでSDKの導入、パスの設定は省略した）

10/19 vs Atheros

とうとううまくいった。
方法は先ほどの投稿でほとんど間違いないが、
/etc/modprobe.d/以下に適当な名前のファイル(atheros.confなど)を作り、
「alias eth0 atl1e」と書くだけでよい。
あとは再起動すると普通に/etc/sysconfig/network-script/ifcfg-eth0が出来ている。
面倒なのでsystem-config-network-tuiで一括設定すれば完了。

elrepoのkmod-atl1e-1.0.1.14-1.el6.elrepo.x86_64.rpmを拾ってくるまでは正しかった。

一応手順を再記述する。

# cp SOMEWHERE/kmod-atl1e-1.0.1.14-1.el6.elrepo.x86_64.rpm .
# rpm -Uvh kmod-atl1e-1.0.1.14-1.el6.elrepo.x86_64.rpm
# modprobe atl1e
# echo "alias eth0 atl1e" > /etc/modprobe.d/atheros.conf
# reboot

たぶんこれでうまくいく。
CentOS 6.xやScientific Linux 6.xの利用者で、Atheros L1Eに苦しめられている方は是非。


今日中にOpenCL環境を作るつもりだったが、疲れたし空腹なので今日はもう退散する。
明日は本気出す。


＜＜＜10/22 追記＞＞＞
他にも書くべき項目があった。
/etc/sysconfig/network-scripts/ifcfg-eth0に、
> DEVICE=eth0
> ONBOOT=yes
の追記が必要。

もしかしたら/etc/sysconfig/networkにもいるかも。
> NETWORKING=yes

これでrebootすればeth0が動く。

10/19 Llano

LlanoノードにScientific LinuxやOpenCL環境を昨日からインストールしている。
Windows環境はM/B付属のCDを使えば簡単に終わるのだが、
Linuxのほうは一筋縄ではいかない。
原因は全てAtherosのGbEにある。

elrepoから対応するrpm(kmod-atl1e)を拾ってきてmodprobeしたまではいいが、
（http://elrepo.org/linux/elrepo/el6/x86_64/RPMS/）
そこからの操作がよくわからない。

どうすればよいのだろうか。

10\12 今後の仕事

研究会での発表が無事終わった。

今後の作業
・Llanoでの再測定
FELIX SST, VWAP, Microbenchmarks
・白幡君の実装の移植
・APUの予測
・ポスターの作成


現状のAPUのスペックは悪いが、今後はこちらが主流になるので調査が必要
しかし、今日のBulldozarアーキテクチャのベンチマークは驚いた。
AMDは滅んだ。

10/12 XwindowをWindows上で表示する

・Putty + Xming
Cygwinを使うのが一般的だが、リモートでXを表示するだけならXmingのほうが軽くて楽で環境を汚さない

XmingとXming-fontsは自分のWindowsに対応するものをインストールすればよい
Puttyでの設定は、「接続->SSH->X11」の「X11フォワーディングを有効にする」をONにし、「Xディスプレイの場所」に「localhost:0」を入力

あとはXmingを起動し、いつも通りPuttyで接続すればXのアプリケーションがWindows上で表示できる！便利！

9/30

2週間も更新しないままだった。反省。

とりあえず次の発表資料の第一稿が完成した。
実験結果がうまくいってないのでそれに比例してスライドのクオリティも下がってしまった気がする。

来週はイベントが多いので大変だ。

9/16 工作

研究室での作業中に回路系でいいアイデアを思いつき、
夕飯後作業していたらいつの間にかこんな時間になっていた。

シリアルポートからの電源引き込みは成功したので、
あとはトランジスタの擬似レベルコンバータを試すのみ。

PICからPCへの信号送信は成功したので、
PC側での受信・電圧→温度変換部分を組まなくては。

Linuxでの/dev/ttyS0の扱いが未だにわかっていないが、
これも色々触っているうちにどうにかなりそうとは思う。

これがうまくいけばサーバルームの温度を常時観測可能になる。

9/9 svnが動かない

Scientific Linux 6.1 AMD64のノードでsvnを叩くがうまくいかない。
libssl.so.6とlibcrypto.so.6がないとか言われるが、
rootでyumするとすでに入っていることになっている。
実際に確めてみる。
$ ldd `which svn`
たしかにnot foundと言われる。

仕方がないので/usr/lib, /usr/lib64を見てみるが、
libには上記のファイルがあるが、lib64には*.so.1.0.0しかない。
勝手にやるのも少し怖いが、とりあえずシンボリックリンクを作ってみる。
そうするとうまくファイルの読み書きもできたので、これでよしとする。

最良の解決策ではなさそうだが、とりあえず動いたので気にしない。

9/8

論文は何とか間に合いそうだ。
夜遅くまで必死にやったかいがあった。

これからの作業
・定式化にむけて考える
・他のAPUでの作業
・NVIDIAのOpenCL環境を試す
・M研究室のS幡君の研究をOpenCLにポーティング

特に後半2つは今からでも着手できるので、
9月中はそちらをやってみる予定。

9/6 締切寸前

もうすぐ投稿締切だが、追加実験が必要になった。
スケジュール確認のためにリストを残しておく。

・今日やる
実験部分以外の文章を完成
追加実験を完遂
　マイクロベンチのプロファイル（メモリ送受信、カーネル起動、行列積）
　IKA-SSTのvmstatの時系列データを測定（OpenCL APU & CPU, CPU naive）

・明日やる
校正、推敲
実験結果を文章に追加
　各種プロファイル、実行時間データ


いつもながらギリギリすぎて驚き。

8/26 OpenCL IKA-SST

U君に監修してもらったお陰でIKA-SSTのOpenCL移植版がコンパイルまでは通った。
一通りコードは移植したのだが、最後の行列演算でエラーが出る。
今後はこれがうまく動くようデバッグを行う。
OpenCLに移植した際に幾つか怪しい部分があるので、まずはそこをチェックする。
締切も迫っているので急がなくては。

8/24 AMD APP SDK v2.5

いつの間にか2.5が出ているようだが全然気づかなかった。

何が新しくなったのか見てみたのだが・・・

・Kernel launch times have been further reduced.
信じていいのだろうか。今更インストールする時間があるか微妙だが。

・For APUs, zero copy buffers created as CL_MEM_ALLOC_HOST_PTR | CL_MEM_READ_ONLY offer improved GPU read performance.
そもそもLinuxでzero copyは対応していない。残念。

8/23 苦戦中

IKA-SST GPU版をCUDAからOpenCLへ移植中。
OpenCLデバイスの初期設定やメモリ確保、CPU計算部分はたぶんうまく移植できた。
あとは本丸のGPUでの計算部分が動ければよい。

GPUカーネルコード部分が問題なのだが、初っ端から躓いてしまった。
OpenCLのデバイス側の制約などがまだちゃんと頭に入っておらず、
検索に時間を取られすぎてしまって全然進展しない。

締切も迫っているのでこのままではまずい。

8/22 gcc

IKA-SSTの実装で使っているライブラリはcblasとlapackだが、
ライブラリをリンクする場合には依存関係による順番に注意が必要らしい。

cblasはatlasとf77blasに依存しており、f77blasはgfortranに依存、
lapackはatlasに依存している。

これを踏まえてgcc(g++)に渡すオプションを整理すると、
-lcblas -lapack -latlas -lg77blas -lg77fortran
のような感じになる。
ダイナミックリンクライブラリだと関係ないらしい。

難しい。

8/22 IKA-SST on CPU

U君に手伝ってもらい、IKA-SSTのCPU版のコンパイルが通った。
一応コンパイル時のオプションを記述しておく。
g++ Main.cpp sst.cpp -I/usr/global/boost/include -I"/usr/global/cuda/include" -I"/nfs/home/matsuura/ikaSST/sst_CPU/inc" -O3 -fno-strict-aliasing -msse -msse2 -Wall -L/usr/global/boost/stage/lib -L/usr/global/centos5.4/lib64 -L/nfs/home/ueno/lib -lboost_thread -lgfortran -llapack -lf77blas -lcblas -latlas
環境依存なので他所では役に立たないし、そもそもIKA-SST自体がローカルのコードだが。

CentOS環境下ではうまく動作するが、Scientific Linuxではうまくいかない。
Fortran関連のライブラリがうまくいってない模様。
./a.out: error while loading shared libraries: libgfortran.so.1: cannot open shared object file: No such file or directory


＃＃＃追記

共有領域にlibが置いてあったようなので、それを/etc/ld/so.confに追加し、
ldconfigしたら無事に動いた。

Phenom 2.5GHzとE-350 1.6GHzなので実行時間は4倍くらいかかってしまうが、
APUとの比較なのでまあ大丈夫だろう。

ようやくAPUへのポーティングにとりかかれるが、困難を極めると予想される。

8/12

実験データをNFSから写し忘れてしまい、作業が全くできない。
図書館のサイトは復活したので停電は終わったはずだが、
なぜか研究室のSSHは全く無反応のままだ。
15日まで作業できないのだろうか。

8/9 OpenCL VWAP on Linux

だいぶ前に作成したVWAPをLinuxで実行。
ソースは時間測定部分が変わるだけで全て同じ。
10回実行の上下特異点を抜いて8回の平均値を算出。
10000回実行時のメモリ送信、カーネル実行、メモリ受信のそれぞれの時間を測定。

現在VOIDとVWAPをCPU、APUそれぞれで実行中。
結果が出たらWindows版と比較する。

ちらっと結果を見たところ、メモリ送信は10倍近く時間がかかっている。
初回起動時のオーバーヘッドかと思ったが、10000回のそれぞれがj10倍程度遅い。
実はWindows版はゼロコピーらしきものが効いていたのだろうか？

カーネル実行時間は数%程度は下がっている。
しかし大勢には影響ない・・・。

詳しい集計や考察はまた明日以降に。

8/8 Scientific Linux

インストールはCentOS 6.0とほぼ同様。
パッケージはDesktopのみを選択。
リポジトリはAMD64とセキュリティも追加。

・System S
必要なパッケージを適当にyum。
おととい書いたものは重複やエラーも混じっていたので修正。

# yum install -y gcc libstdc++-devel gcc-c++ boost-devel libicu-devel zlib-devel libxml2-devel binutils-devel libsepol-devel keyutils-libs-devel e2fsprogs-devel krb5-devel openssl-devel libidn-devel perl-Digest-SHA1 perl-XML-Parser perl-XML-Simple curl-devel libstdc++.so.5 perl-libwww-perl.noarch compat-libstdc++-33 perl-XML-SAX libicu-devel libxml2-devel binutils-devel libXaw compat-expat1 libperl.so

しかしこれでもgraphvizはインストールできないし、
スクリプト起動時のエラーも消えない。
具体的にはlibltdl.so.3とlibperl.soが解決できない。
yumではインストールできているようだが、System Sが要求しているものと微妙に違うようだ。
これに対処している暇は今はないので、System SはRedhat/CentOSの5.xで使うしかなさそうだ。


・OpenCL
今までと同様。
# wget http://www2.ati.com/drivers/linux/ati-driver-installer-11-7-x86.x86_64.run
# yum install kernel-devel rpm-build

runlevelを3にしてスクリプトを起動してRHEL6 AMD64のドライバを生成。
生成が成功したらyumでインストール。
rpmのインストールでもyumを使うほうがいいらしい。

# aticonfig --initial -f
してからまたrunlevelを5に戻して再起動。

このままではうまくいかなかったが、/etc/OpenCL/vendors/以下を追加したら成功した。
追加するファイルの詳細はこの前このブログにも書いたので省略。

ここまでやると、OpenCLデバイスでGPUも認識され、
サンプルコードを動かしてもGPUで実行されることが確認できた。
atigetsystemlog.shでも以前うまくいっていなかった部分が更新されている。

System Sは残念だったが、OpenCLは無事動いた。
これで安心して帰省することができそうだ。


・おまけ
サンプルコードのGlobalMemoryBandwidthの実行結果

実行環境
[OS] Scientific Linux 6.1
[APU] AMD E-350
[RAM] DDR3 2GB (512MB for Graphics)
[M/B] E35M1-I
[Software] AMD APP SDK v2.4, Catalyst 11.7, gcc 4.4.5


Selected Platform Vendor : Advanced Micro Devices, Inc.
Device 0 : Loveland
Build Options are : -D DATATYPE=float4

Global Memory Read
AccessType : single
VectorElements : 4
Bandwidth : 31.4677 GB/s

Global Memory Read
AccessType : linear
VectorElements : 4
Bandwidth : 17.9922 GB/s

Global Memory Read
AccessType : linear(uncached)
VectorElements : 4
Bandwidth : 15.332 GB/s

Global Memory Write
AccessType : linear
VectorElements : 4
Bandwidth : 21.1874 GB/s


色々CPUとの性能差があって面白い。

8/6 CentOS 6.0許すべからず

6だとインストーラが色々変わっていてややこしかった。
テキストインストーラの指定方法を調べるのが面倒でGUIでやったが失敗だった。
やはりGUIインストーラはいらない。

・CentOS 6.0でSystem S
デスクトップのパッケージのみを選択した場合、yumするやつが余分に必要。
yum install -y boost gcc libstdc++-devel gcc-c++ boost-devel libicu-devel zlib-devel libxml2-devel binutils-devel libsepol-devel keyutils-libs-devel e2fsprogs-devel krb5-devel openssl-devel libidn-devel perl-Digest-SHA1 perl-XML-Parser perl-XML-Simple curl-devel libstdc++.so.5 perl-libwww-perl.noarch compat-libstdc++-33 libltdl.so.3
yum install -y libtool-ltdl perl-Digest-SHA1 perl-XML-Simple perl-XML-SAX gcc-c++ boost-devel libicu-devel libxml2-devel binutils-devel curl-devel libltdl.so.3
yum install libXaw
yum install compat-expat1
yum install libstdc++.so.5
yum install libperl.so
（複数のスクリプトからのコピペなので重複があります）

しかしlibltdl.so.3はlibtool-ltdlがあるにも関わらず解決しない。
graphvizがインストールできないが、無視した。

libperl.soがないとか怒られてデーモンが起動できない。
さすがに眠いので今日はここまで。


・atiのドライバ
# yum install kernel-devel rpm-build
して前のドライバをDLして実行。
GenerationでRHEL6のAMD64を選んで生成。
これで後は生成されたRPMをインストールするだけ。

しかしインストールされているはずのライブラリがないとか言い出す。
さすがにキれた。System Sも動かんし。
CentOS6はRHクローンを名乗るに値しないのではないか。
許し難いのでScientific Linuxに鞍替えすることを決定。

もうダメだ。9月初旬に間に合う気がしない。
眠すぎるしやる気がゼロ。明日の晩また頑張る。

8/6

Forumに別のポストがあったので試してみる。

/etc/inittabでRunlevelを3から5に変えるといいようだ。
あと、
# aticonfig --adapter=all --initial
も必要？
これはマルチカードのときのみかもしれない。


しかしダメだった。
atigetlogみたいな感じのコマンドでログを見てみると、
どうやらカーネルソースが古すぎてカーネルモジュールの作成に失敗している。
これが原因か。

CentOS 6をまずは試してみるか・・・。

8/5

色々手を尽くしたつもりだが、結果は散々だ。
Linuxの管理運営はここ数年でかなり習得できたつもりだっだが、
Xには手も足も出ず、認識の甘さを思い知らされた。

このままCentOSに固執するのは愚行のような気がしてきた。
フォーラムなどを見ても他のOSの例しかない。
CentOSも5.6ではなく6にするか、debian, ubuntu,
RHEL, Scientific Linux, Gentooあたりに逃げるかもしれない。

とりあえずisoは落としたので、色々検討してみる予定。

8/3 実はまだ動いていなかった

昨日からの続き。
どうも標準のXorgのやつだとうまくいかない。
もう一度ドライバを生成してみる。

最初に前のドライバを消すのも大事。
# /usr/share/ati/amd-uninstall.sh

カーネルソースがなかったのが原因の一つのようなので、
# yum install kernel-devel
そりゃ失敗するわけだ。

前と同じようにやると、fglrx64_p_i_c-8.872-1.x86_64.rpmや
fglrx_p_i_c-8.872-1.i386.rpmやicd-registration.tgzが生成される。
icd-registration.tgzはここで生成されるのか・・・。

普通に
# rpm -ivh fglrx64_p_i_c-8.872-1.x86_64.rpm
してやる。

初期化。
# aticonfig --initial -f

実機でstartxしてドライバをfglrxにする。


しかしやっぱりうまくいかない・・・。
このままではヤバイ。

8/1 Linux + OpenCLの続き 作業ログ

うまくいったような気がしたが、それは嘘だった。
サンプルプログラムのコンパイルは成功しているが、実行ができない。

例）
# cd /usr/global/AMD-APP-SDK-v2.4-lnx64/samples/opencl/bin/x86_64/
# ./HelloCL
HelloCL!
Getting Platform Information
Platform::get() failed (-1001)

エラーです。お疲れ様です。


色々原因を探ってみる。
aticonfigとかamdcccleなど、AMDのドライバ系のツールがある。

# aticonfig --lsa
* 0. 00:01.0 AMD Radeon HD 6300 series Graphics

* - Default adapter

と、なるのでとりあえずAPUは認識されている。
VNC経由で、
# aticonfig --initial
として初期化もやってみる。

しかしうまくいかない。

# amdcccle
は壮大なエラーを吐いて停止する。
何か、AMDのGPUドライバが入ってないとか言われる。マジか。
もう一度インストールしてみた。
その前にrpm-buildもyum installしておく。
（一回これがないためにドライバのビルドが失敗しているよう）

# ./ati-driver-installer-11-7-x86.x86_64.run
今度は「Generate Distribution Specific Driver Package」してみた。
CentOS 5.6 AMD64なので、「RedHat/RHEL5_64a」と「RedHat/RHEL5」を選択。

インストールは成功したが、うまくいかない。
さらに調べたが、/etc/OpenCL/vendorsが悪いみたい。
これがATI系の名前のままだと失敗する。

中身を見るとただのテキストファイルなので、自分で書いたほうがよさそう。

/etc/OpenCL/vendors/amdocl32.icd
中身↓
libamdocl32.so

/etc/OpenCL/vendors/amdocl64.icd
中身↓
libamdocl64.so

こんなやつを作ればOK。
パーミッションはリードオンリーでOK。

ようやく動いた。
たぶんドライバは関係ない。
vendorsが悪い。


ここまで到着するのに3時間くらい消費した。
疲れた。肉食いたい。


成功パターンも一応記載してみる。
# ./HelloCL
HelloCL!
Getting Platform Information
Creating a context AMD platform
Getting device info
Loading and compiling CL source
Running CL program
Done
Passed!

8/1 中間発表終了 & Linux + OpenCL

中間発表が完了。
スライドをしっかり見ていただいていたお陰で、特にハプニングもなく坦々と終わった。
観客が他の研究室の先生お一人と学生一人だったのもあるが・・・。
一箇所、APUがCPUとGPUのギャップを埋めるデバイスであることを述べ忘れたが、
先生にフォローしていただいたので一応大丈夫だった。


次の実装に向けて環境をLinuxに移行する。
既存のコードがLinux + System S用だと
M研究室のNさんにアドバイスをいただいたのもある。

CnetOS 5.6にAMD APUドライバとAMD APP SDK(OepnCL 1.1)を導入する。


以下作業ログ。
・ドライバインストール
# wget http://www2.ati.com/drivers/linux/ati-driver-installer-11-7-x86.x86_64.run
# ./ati-driver-installer-11-7-x86.x86_64.run
（Xは提示されたX.ORG6.9を普通に選択。全部一番の選択肢でOK）

・SDKインストール
# yum install mesa-libGLU-devel.x86_64
（/usr\include/GL以下のglu.hやgl.hのために必要。もしかしたら他のでもいいかも。）

・icd-registration.tgz
これも必要な模様。AMD APP SDKの過去のアーカイブからゲット。
リンクが深いので注意。

# wget http://download2-developer.amd.com/amd/Stream20GA/icd-registration.tgz
# tar zxvf icd-registration.tgz -C /

インクルードパスなどを.bashrcに追加してsourceする。
export AMDAPPSDKROOT=/root/AMD-APP-SDK-v2.4-lnx64
export AMDAPPSDKSAMPLESROOT=/root/AMD-APP-SDK-v2.4-lnx64/samples
export ATISTREAMSDKROOT=$AMDAPPSDKROOT
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$AMDAPPSDKROOT/lib/x86_64
export LIBRARY_PATH=$LIBRARY_PATH:$AMDAPPSDKROOT/lib/x86_64
export C_INCLUDE_PATH=$C_INCLUDE_PATH:$AMDAPPSDKROOT/include/

# wget http://download2-developer.amd.com/amd/APPSDK/AMD-APP-SDK-v2.4-lnx64.tgz
# tar zxvf AMD-APP-SDK-v2.4-lnx64.tgz
# cd AMD-APP-SDK-v2.4-lnx64
# make

最後にディレクトリ全体を/usr/globalに移動させ、パスなどを書き換えて終了。
これでOpenCL実行・開発環境が完成。

最終的な.bashrcの追加内容は以下の通り。
export AMDAPPSDKROOT=/usr/global/AMD-APP-SDK-v2.4-lnx64
export AMDAPPSDKSAMPLESROOT=$AMDAPPSDKROOT/samples
export ATISTREAMSDKROOT=$AMDAPPSDKROOT

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$AMDAPPSDKROOT/lib/x86_64
export LIBRARY_PATH=$LIBRARY_PATH:$AMDAPPSDKROOT/lib/x86_64
export C_INCLUDE_PATH=$C_INCLUDE_PATH:$AMDAPPSDKROOT/include/



## 環境 ##
CentOS 5.6 AMD64
Catalyst 11.7
AMD APP SDK 2.4

7/27 LlanoはZacateよりマシな模様

APU + OpenCLのレイテンシなどを計測している方のページ。
Llanoではだいぶ改善されている模様。

http://d.hatena.ne.jp/w_o/201107

7/15 map/unmap

メモリアクセスのAPIを変えて実験しているのだが、ヒープメモリ関係のバグが発生している。
原因はよくわかっていないが、最後にメモリをfreeしている場所でエラーが起きる。
大事な部分は全部mallocで確保しているので、ヒープは関係ない気がするのだが何なんだろう。

そもそもmap/unmapのAPIが正しく使えているのかが怪しいが、
検索してもそれらしい記述にたどりつくことができない。


先日まで取り組んでいたWindowサイズを変える実験も、
Windowサイズが大きくなると実行時間が減ってしまう部分があり、
実験結果の信憑性が疑われるのだが色々探しても原因やバグは突き止められなかった。
こちらもよくわからないが、とりあえず進捗が芳しくなく中間発表が恐ろしい。

7/11 実験の謎

ウィンドウサイズを4から1024まで2倍刻みで実験したのだが、
CPU/APUともほとんど実行速度に影響がなかった。
ウィンドウサイズを増やすと浮動小数計算量もメモリ転送量も2倍ずつ増えるので、
現在のデータ量では少なすぎるのだろうか。

ウィンドウサイズ1024、Ticker数640では、単純にウィンドウが占めるメモリ領域だけで、
配列長1024 x 2本 x 4Byte(float) x 640種類 = 5MBになる。到底L2キャッシュに収まる容量ではない。
シーケンシャルアクセスしか行われないので、CPU側への影響は薄いのかもしれない。
APU側のデータ転送時間にも全く影響のないところをみると、
ほとんどが呼出コストで、送受信自体はゴミのような時間しか食わないのか。
もしくはゼロコピーなるものがこっそり仕事しているのかも。

計算量もウィンドウサイズ4でTicker数1ならば掛け算と足し算が配列長分ずつ必要なので、
8回の浮動小数計算だが、ウィンドウサイズ1024でTicker数640ならば2 * 1024 * 640 = 1310720回になる。

CPUが1.6GHzなので、1サイクルは0.625ns。
浮動小数命令が今何サイクルかかるかよく知らないが、1サイクル以下はありえないので、
1で考えると1310720 x 0.625ns = 0.8192s。意外と短い。
計算量が少なすぎて、大した違いにならないのかもしれない。

もっと大規模データで実験しないといけないのだろうか。
実験の方向性がよくわからなくなってきた。

6/26 時間測定

今まで何も考えていなかったが、Windows環境での時間測定のやり方がわからない。
gettimeofdayが使えないだけでこれだけ苦労するとは・・・。

QueryPerformanceCounterやtimeGetTimeを使おうとしたのだが、
ぜんぜんうまくいかない・・・。

何が起こっているのかよくわからないが、今日中に終わらせるのは無理ということだけは確実だ。
諦めて明日誰かに聞く。

6/26

今までのバグの原因が判明した。
OpenCLカーネル内で、片方のスレッドがもう片方のスレッドの結果を上書きしていた模様。
これにより、実行の順番によって結果が変動していたようだ。
GPUのときに失敗しなかったのは、単純に運がよかっただけのようだ。

とにかく、これでバグは全部ないはずなのでベンチマークができる状態に仕上げなければ。

6/24 謎の挙動

スレッドの同期か何かの問題と思うのだが、CPU実行すると計算結果が2パターン現れる。
APUのほうでは十数回実行しても全く変化がなかった。何故だろう。

APU実行　正しい結果（計算の誤差は大きい模様）


CPU実行　正しい結果


CPU実行　誤った結果


この問題さえどうにかなれば、後は数十～数百スレッドで実行時間を測定すればよい。
先はまだまだが、どうにかなりそうにはなってきた。


bi(bargain index)に-0と-expがあるが、これはvwapとask_priceの関係によって式が2種類あるため。
どちらの分岐に入ったかを検知するために付与している。


APU(GPU)は演算器の実装が違うのか誤差が出やすい模様。
今後、この点にも注意する必要がありそう。

6/24 OpenCL Debug

とうとうOpenCLでVWAP計算が動作した。
しかしながら、まだシングルスレッドで一周のみの動作しかさせていないので、
複数スレッドで連続計算できるように改修が必要だ。
カーネル関数自体の動作は確認できたので、作業はだいぶ楽になった。

OpenCLのDebugではFermi以降のCUDAと同様kernel関数内部でのprintfが使える。
書式はC/C++と同様で、文字列なども難なく扱える。
表示が実際に行われるタイミングは非同期のようだが、同期を行えば確実に表示できる。
clWaitForEvents関数がそれで、第一引数に待ちイベント数、第二引数にイベント配列を渡す。
イベント配列はカーネル関数実行時やメモリ読み書き時に指定できるので、
カーネル関数実行時に設定したイベントをこの関数に渡してやればよい。

・OpenCL 1.1のKhronos公式のリファレンス
知りたい関数などを一発で検索できるため大変便利
http://www.khronos.org/registry/cl/sdk/1.1/docs/man/xhtml/

6/17

OpenCLのカーネルビルド時のエラーの詳細を見るための関数があるようだ。

　clGetProgramBuildInfo(program, device_id, CL_PROGRAM_BUILD_LOG, sizeof(buffer), buffer, &len);

これで作業が少しは楽になりそう。

しかし、これを知ったのがBuild Errorを解決してからだった。ショック。
しかも、今度はNDRangeKernelの起動でエラーが。

先は長そうだ。

6/17 OpenCL kernel関数の罠

＊今回の教訓
ドキュメントは隅々までちゃんと読むべし


OpenCLでは実行時にカーネルソースを読み込み、JITコンパイルする。
このカーネルソースのファイルへの思い込みのせいで1週間以上を無為に過ごしてしまった。


１．カーネルソース内では#includeできない
＃PROGRAM_BUILD_FAILURE(-11)で盛大にこけます

２．カーネルソース内のカーネル関数には二重ポインタは渡せない
＃同上でこけます
＃そもそも今考えるとどうして二重ポインタを渡そうとしていたのかが謎

３．カーネルソース内ではC++のように好きなところで変数宣言はできない
＃同上
＃ちゃんと先頭で全て定義しましょう


以上を踏まえて書き直したところ、あっさりコンパイルが通って虚脱した。
心が折れそうだ。

6/16 Fusion

AMDもAシリーズ（Llano世代）からようやく本気を出すらしい。
APUによるGPGPUを後押しするためのソフトウェア層の再定義を行うらしい。
中間言語レイヤでCPUやGPUとOpenCLやC++ AMPとの隙間を抽象化する。
これらはすぐに出てくるのかどうかは微妙。

APUのアーキテクチャ自体も、CPUとの協調を重視した設計のようだ。
GPUからメモリへのバスが、メモリコントローラへの直結側と、
CPUとのコヒーレンシを保てるバスの二つになっている。
これにより、グラフィックス性能とGPGPU性能を両立できるようだ。
名前がGarlicバスとOnionバスのようだが、もう少しまともな名前にできなかったのだろうか。

OpenCLのデバッグ環境も、OpenCLのカーネルコードをC++のプロシージャとして扱えるものが出た。
今ドキュメントを読んでいる途中なので詳しいことはわからないが、使えるかもしれない。

6/14

昨日先生にミーティングをしていただき、研究の方針を定めることができた。
後は実装結果を元に知見をまとめればよいのだが、OpenCL＋APUは未知の領域が多く、
OpenCL関連の実装経験も情報も乏しいためなかなか作業が思うように進まない。

今日は家で作業を進めるはずが、自室の照明が突然死して大いに困った。
回路を調べてみると、インバータのコンデンサが自壊し穴が開いていた。
ヒューズは飛んでいないので、どこかのトランジスタが悪さをした模様。
一昨日も浴室の電球が切れたばかりで、不思議とこういうことは重なるものだと思った。

6/10

clEnqueue[Read|Write]BufferとclEnqueue[Map|Unmap]Bufferは最初の理解でよかった模様。
細かい値を引くなら前者、行列のようにランダムアクセスなどが発生する巨大な配列は後者を使えばよさそう。
昨日修正した部分はむちゃくちゃになっていたので再修正が入りそう。

6/9

今まで勘違いしていたが、OpenCLのNDRangeは1-3次元構造が3重に入れ子になった構造だった。
各階層の識別子は外側からワークグループID、ワークアイテムID、ローカルIDとなっている。
グローバルIDが知りたい場合、プログラム内で各IDから求める必要がある。面倒。

clEnqueueMapBufferとclEnqueueReadBufferも謎。
排他的に使うものなのかどうかよくわからなくなってきた。
今まで細かい部分を無視して適当にやってきたツケが回ってきたようだ。

6/9 OpenCLのコードをVC++で色つきに

Visual C++ 2010でOpenCLの開発をしているのだが、ソースが無色で非常に見づらい。
これを解決するには、
[ツール]→[オプション]→[テキストエディタ]→[ファイル拡張子]の項目に「cl」という拡張子を追加する。
このとき、デフォルトではVBになってる部分をちゃんとVC++にするように。

これだけではC++的な部分しか反映を受けないので、OpenCL特有の情報を教えてやる必要がある。
C:\Users\＜ユーザ名＞\Documents\AMD APP\samples\opencl\SyntaxHighlightingに、
usertype.datというファイルがあるので、これを
C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE
に放り込む。

Windows 7 AMD64 + Visual C++ 2010 + AMD APP SDK 2.4の組み合わせだが、
他の環境の組み合わせでもだいたい同じような作業を行えばうまくいくはず。
これもCUDA向けの情報から類推した結果なので。

参考URL：http://wiki.livedoor.jp/mikk_ni3_92/d/CUDA%CA%D400

6/2

ニートの危機を脱することができた。

研究室のノードの生存状況を1時間ごとに告知するShell Scriptを作成。
estherの/home/share/live.txtが出力ファイル。

本当はこのファイルからさらに見やすいHTMLを作成し、
世界中どこからでも研究室の状況がわかるようにしたかったのだが、
Webサーバを立ち上げるのは怖いし、クラウドで使えそうなサービスもなかったので断念。

GoogleサイトやGoogle Docsは機能が制限されているし、
Google App Engineに登録する気にはならないし悩ましい。

5/30

Hadoopの象だけでもダサイと思っていたが、世の中、上には上がいることを再認識。
http://d.hatena.ne.jp/kkawamura/20100130/1264864342

5/20

さるファイルから、各行の先頭三文字を抜き出し、カンマとシャープを消し去り、
ソートし、重複を削除し、語数を数えるコマンド列。
sedの使い方とsort, uniqの組み合わせがいる点に注意。

$ cat TradesAndQuotes.csv | cut -c 1-3 | sed -e s/[,#]//g | sort | uniq | wc -l


現在新図書館2階の学習スペースで作業しているのだが、研究室より涼しく静かで集中できそう。
3階にはミーティングスペースもあるので、今後研究室で利用してもよいかもしれない。
ミーティングスペースとして利用できるのは7月以降のようだ。

5/14

最近面接や面接関連の書類の締切に追われて、
研究もそちらも二兎追う者になりつつる。

うまく気を入れ換えて対応しなければならない。

特に研究は、本題以外に注力しすぎていたので
早く切り上げて先に進めなくては。

4/22 Error Message

OpenCLのエラーは種類が多々あるが非常にわかりにくい。
数字とエラーの対応付けも面倒。

先人が残してくれたコードがあるので活用すべき。


今回遭遇したエラー：-55
コンパイルしたコードで実行してみると、
CL_INVALID_WORK_ITEM_SIZEというエラーらしい。
（利用したコード：http://opencl-percipere.blogspot.com/）

エラーの定義名さえわかれば、リファレンスからググれば一発。
（KhronosのPDF：http://www.khronos.org/registry/cl/specs/opencl-1.x-latest.pdf）

数字との対応関係を見たいならこのようなページも存在。
（http://blog.s21g.com/articles/1647）


こうしてエラーの詳細はわかったが、どういうエラーで何が原因なのかはまだ不明。
明日以降にどうにかする予定。

4/22 実験

レイテンシとスループットを測定
それぞれ順番に、
CL_MEM_ALLOC_HOST_PTR
CL_MEM_USE_HOST_PTR
CL_MEM_USE_PERSISTENT_MEM_AMD
でメモリオブジェクトを確保した場合の実行結果。
他の条件は全く同じ。

使い方が間違っている可能性もあるが、
CL_MEM_USE_PERSISTENT_MEM_AMDが微妙。

CL_MEM_ALLOC_HOST_PTRはZero Copyの恩恵なのか、
Map/Unmapが速く、いい感じだと思う。

ただ、全体的にCPUと比べて高レイテンシすぎて心配になる。

4/22 Zero Copy

＊最近OpenCL関係で検索すると自分のページがよく出てきますが、
＊このブログはあくまでもただの学生の作業メモ日記なので、
＊勘違いや嘘が多々含まれているかもしれません　ご注意を

＊致命的なミスなどがあったらご一報をお願いします



・AMD APUでZero Copyを使うには
AMDの4月発表の最新のAMD APP OpenCLプログラミングガイドの4.4を見るとよいそうだ。


・OpenCLのメモリオブジェクト
5種類に分けられるようだ。
１．Host Memory
２．Pinned Host Memory
３．Device-Visible Host Memory
４．Device Memory
５．Host-Visible Device Memory

詳細はAMDのガイドを参照すべきだが、簡単にまとめると、
Host/Device Memoryは名を冠するデバイス以外は直接参照不可能で、
一度Pinned Memory領域かホストのBufferにコピーしないと参照できない。

Pinned Host Memoryは物理メモリと直接対応付けされているので、
デバイスとのDMA通信が可能。領域サイズにより挙動は多少異なる。

Device-Visible Host MemoryはCPUのキャッシュを無効にした領域。
デバイスからのアクセスは早いが、CPUからのアクセス速度は低下。

Device Memoryはデバイス側のメモリ。アクセスはHostメモリの逆。
要はCUDAのGlobal Memory。
APUではDevice-Visible Host Memoryをこれとして扱うらしい。

Host-Visible Device MemoryはGlobal Memoryの一部で割り当て可能。
CPUからはPCIeを通したキャッシュ不可能なメモリ領域としてアクセス。速度は遅い。


・メモリオブジェクトの確保・アクセス
clCreateBufferで確保、clEnqueueReadBuffer / clEnqueueWriteBufferでアクセス。
clCreateImageなんてやつもあるらしい。

確保したオブジェクトを実際に配置するにはMappingを行う。
これはclEnqueueMapBufferで行う。
消す前にはclEnqueueUnmapMemObjectが必要で、clReleaseMemObjectで消し去れる。

オブジェクトの確保の際に、定数を引き渡すことでオブジェクトの性質？を決める。
これも色々あって複雑。WindowsかLinuxかでも動作が変わる。
１．Default(no flags)
２．CL_MEM_ALLOC_HOST_PTR
３．CL_MEM_USE_HOST_PTR
４．CL_MEM_USE_PERSISTENT_MEM_AMD

OpenCLプログラムの実行元がGPUか、APUのGPUか、CPUかで配置が変わるが、
CPUの場合は今回は無視。Windows以外の場合も無視。

デフォルトだとAPUではDevice-Visible Host Memory、
GPUではHostかDeviceのメモリを文脈に応じて選択。

CL_MEM_ALLOC_HOST_PTRではPinned Host MemoryでZero Copy。

CL_MEM_USE_HOST_PTRではデフォルトと同様になり、Copyされる。

CL_MEM_USE_PERSISTENT_MEM_AMDとCL_MEM_ALLOC_HOST_PTRの挙動の違いが謎だが、
Map Locationの説明が異なっている。
前者では異なるメモリエリアの割り当てがなされるが、
後者ではそれぞれのメモリマップに同一のメモリエリアが割り当てられるらしい。
どういった差異が発生するかはわからない。。。
4.4.3.1に書かれているようだがよくわからなかった。
どちらもWindows Vista/7環境ならZero Copyは可能なようだ。


・速度計測
clEnqueue系の命令にはイベント情報の格納先を指定することができるので、
そのイベント情報をclWaitForEventに引き渡せば実行を待つことが可能。
この時間を計測すれば各イベントの実行時間がわかる。便利。
使ったイベント情報はclReleaseEventで開放してあげよう。


・リモートデスクトップ
VNCなら大丈夫らしい。NVIDIA GPUでも同様の事例はあるらしく、
Windowsのリモートデスクトップの実装に起因しているらしい。MS頑張れ。

4/21 リモートデスクトップの功罪

測定結果が意味不明だったので色々調べてみると、
リモートデスクトップ利用時にはGPUがうまく利用できないらしい。

あと、SDK 2.4にはCatalyst 11.4が必要らしい。
これも正しくインストールされていなかった。愚かだ。

両方直して測定してみると、非常に空しい結果だった。
前回の異常な結果はさすがにブログから削除した。
正しい結果についての考察と対処が必要だが、
今日は完全に心が折れてしまったので明日頑張る。



デバイスの確認に使ったソースはこちら。
[参考文献] Percipereさん, clGetDeviceInfo でデバイス固有情報の取得
[URL] http://opencl-percipere.blogspot.com/2009/09/clgetdeviceinfo.html

これはGPU非依存なので、一度コンパイルしておくとすぐにチェックできて便利。

4/21 APUとGPU

ある程度OpenCLにも慣れてきたので、今度はGPUとの比較を行うための環境構築に手を出す。
シームレスにAPUとGPUを切り替えて実行できればよいのだが、
現状ハードウェア構成やBIOSの設定まで変更しないとうまく動かすことができなかった。

[APU実行時]
GPUは物理的に取り外す
BIOSでIGPXをAuto or Force（共有メモリ量も手動設定）
M/B側にDisplayを接続

[GPU実行時]
GPUは物理的に接続する
BIOSでIGPXをOFF
GPU側にDisplayを接続

ドライバ関連はCatalystが自動で設定してくれるようだが、
今の状態だと手元にマシンがないと構成変更ができない。

何かいい方法はないのだろうか。



実験の自動化のためにバッチファイルを覚えた。
・変数の設定
set VAL_NAME=VALUE

・変数の参照
echo %VAL_NAME%
（VALUEが表示される）

・リダイレクトによるファイル書き込み
SOME_EXEC >> FILE
（FILEに表示内容が格納される）

・日付、時間を表示
echo %date%
echo %time%

Linuxのシェルと似た部分もあるが違いもあるので注意が必要だ。
また、Windows同士でもバージョンが違うと微妙に差異がある模様。

4/19 OpenCL雑感

CUDAと比べるとやはり面倒。
これはマルチデバイスへの対応と動的コンパイルのため仕方がないのだろう。

CUDAだと、
１．デバイスのメモリ確保
２．デバイスへのメモリ転送
３．デバイス関数の実行
４．デバイスからのメモリ転送
で済むのだが、

OpenCLだと、
１．デバイスの情報取得
２．デバイスコンテキストなどの設定
３．デバイス関数のコンパイル（もしくはロード）
４．デバイスのメモリ確保と転送
５．デバイス関数のキューの確保とエンキュー（実行）
６．デバイスからのメモリ転送
となり非常に面倒。

文章だけではわからないだろうが、コンテキストやIDあたりが非常に煩雑だ。
メモリの確保と転送も、CUDAと比べると記述が多い。
デバッグが大変だった。


慣れの問題もあると思うが、早く使いこなせるようになりたい。
このままだとマイクロベンチを書くのも危うい。


Visual StudioはI君、U君や隣の研究室のS君の助けもあり何とか使えるようになった。
次はOpenCLとCALをどうにかしなければ。

4/19

「OpenCL入門」という秀和システムの本を読み、サンプルプログラムを書いて学習している。


OpenCL自体は本を読めばある程度はわかるが、Visual Studioまわりで色々苦戦中。

・ソリューションの追加
Visual Studio 2010ではプロジェクトを作成するときにソリューションを選ぶか
追加できるので、ソリューションの追加みたいなメニューがないようだ。

・ソリューション内での構成のプラットフォームの選択
64bit用のデバイスドライバが入っているのでx64でコンパイルしたいのだが、
複数のプロジェクトで同じプラットフォーム（x64）を追加したい場合は
「新規作成」したときに「新しいソリューションプラットフォームを作成する」の
チェックボックスをはずさないとエラーが出る。

・実行結果のDOS窓（コマンドプロンプト）がすぐ閉じて悲しいことに
Ctrl+F5でコンパイル＋実行すれば結果の窓が残る

など、VSを使い慣れている人からすると衝撃的なのかもしれない内容で戸惑ってしまった。


Visual Studio 2010でのOpenCLのコンパイル自体は、
１．ソリューションプラットフォームをx64にし、
２．VC++ディレクトリのインクルードディレクトリに「C:\Program Files (x86)\AMD APP\include」を追加、
３．同所のライブラリディレクトリに「C:\Program Files (x86)\AMD APP\lib\x86_64」を追加、
４．「リンカ」の「入力」の「追加の依存ファイル」に「OpenCL.lib」を追加すればOK。

Visual Studio 2010とAMD APP SDK 2.4さえちゃんと入っていればこれで全て動く。
これは64bit Windows 7とAMD GPUの組み合わせのみに当てはまると思うが、
32bitの場合でも(x86)の部分とソリューションプラットフォームの変更を除けばだいたいいけると思う。

4/18

隣の研究室からOpenCLの本を貸していただけた。
入門用の情報が少ないので渡りに舟だ。

就活関係の書類も一段落ついたので、
ようやく落ち着いて取り組むことができそうだ。

4/15

OpenCLのコンパイルがとうとう通った。
環境構築のアドバイスをしてくれたI君、ありがとう。

歓迎会がはじまるので、詳細は後ほど。

4/14

咄嗟のときに欲しい英単語が出てこず、もどかしいことが多い。
契約書を丸々翻訳（超訳？）する必要があったのだが、かなり体力を消費した。

日本人が外国のサイトを見るのは簡単だが、外国人が日本のサイトを見る場合、
特に文字列の入力が必要な場合は多くの困難があることを思い知った。
全角英数字を強要するのはさすがにやめるべきだと思う。

Windows上でOpenCL開発環境を構築したいのだが、
64bitのコンパイルの部分で大きく躓いてしまった。
Visual Studio 2010でもWindows SDK 7.1を指定しないと
うまくいかないことに気づくまで多くの時間を費やしてしまった。

4/13

今日はお隣さんと合同で歓送迎会を行った。
久々に会う人や新顔とも話せて色々楽しかった。


・OpenCL関係
VC++ Express版では64bitのコンパイルがうまく通らず、
DreamSparkのlicenseを見つけたので昨日の作業ログから多少変更が。

１．Windows 7インストール、LANなどの設定
２．AMD APP SDK 2.4をインストール（AMD-APP-SDK-v2.4-Windows-64.exe ）
３．Visual Studio C++ 2010をインストール

Visual Studioはダウンロードに数時間かかり、インストールもまだ終わらない。
ISOイメージを展開しても何もファイルが現れずに焦ったが、
DVDに書き込めばちゃんとファイルを読み取れるようだった。不親切な設計だ。

終わりが見えず今日はもう眠いので、続きは明日やることに。

4/12 OpenCL作業ログ

Windows 7上に開発環境を構築。
APP SDK 2.4でAPU上でCPU-GPU間ゼロコピーがサポートされたため、
急遽CentOSからWindows 7へ鞍替えすることに。

１．Windows 7インストール、LANなどの設定
２．Visual C++ Expressをインストール
３．Windows SDK for Windows 7 and .NET Framework 4をインストール（AMD64対応のため）
４．AMD APP SDK 2.4をインストール（AMD-APP-SDK-v2.4-Windows-64.exe ）

SDKをインストールすると、自動でドライバのインストールも開始する。



参考URL
http://www.02.246.ne.jp/~torutk/cxx/opencl/windows7_vc2010express_atistreamsdk.html

環境
[OS] Windows 7

4/10

APUノードだが、CentOS 5.6にしたところ、無事にインストールできた。
次はOpenCLプログラミング環境をセットアップする。
嵌らないことを願いたい。

[OS] CnetOS 5.6
[MB] E35M1-I DELUXE

4/8

Kernel Panic
新しく買っていただいたノードにCentOS5.4のインストールを試みたが、
Kernel Panicが多発してインストーラの起動すらできなかった。
衝撃。

PCI関連の読み込み時のようなので、APUが悪さを働いているかもしれない。
System Sは諦めて、うまくいくディストリビューションを探すしかないのか。

4/8

今日はB4が研究室にやってくる。

会津大学の研究室のAMD GPUに関する情報が得られるページ。
http://galaxy.u-aizu.ac.jp/trac/note/

3/31

AMDのOpenCL最適化関連
http://developer.amd.com/samples/Pages/default.aspx
http://developer.amd.com/documentation/articles/pages/OpenCLOptimizationCaseStudySupportVectorMachineTraining.aspx
http://developer.amd.com/documentation/casestudies/Pages/default.aspx
http://developer.amd.com/documentation/articles/Pages/default.aspx

3/30

AMD E-350でOpenCL
ドライバのインストール方法などが掲載されたスレッド
http://forums.amd.com/devforum/messageview.cfm?catid=390&threadid=145785

3/28

見積もりは現在確認中

・OpenCLを勉強する→本がほしい
（OpenCL入門　- マルチコアCPU・GPUのための並列プログラミング - ）
・AMDのGPUアーキテクチャや最適化手法を調べる
・研究の対象アプリケーションを探す

3/26 三行でまとめます

疎開していたが最近復帰
研究テーマが変わりそうだがSandy BridgeはOpenCL使えなさそう
Stream Noodleは華麗に復活しました

3/3

単位がそろいました！

際どい点数が頻発でしたが、ギリギリ全ての講義を乗り切れました。
これであとは就活だけです。

Hadoopを久しぶりに使ったら色々忘れていたので覚書。
・HDFSが動かない→/tmp以下のHadoop関連を削除、ログ削除、killallでデーモン抹殺
・自前のjarは実行時に特殊な操作が必要
$ ./bin/hadoop jar li.jar LineIndexer input output

2/21

Marsを動作させようと奮闘。
結果的に、Marsをダウンロードする場所を間違えて、古いのを使っていたのが失敗要因だった。
原因究明を手伝ってくれたI君とU君、ありがとう。

新しいCUDA SDKを拾ってコンパイルし直すと、今度はうまく動作。
最後に一応結果を掲載します。

今後Marsを拡張するなら、他のSDKなどへの依存がないよう作り直すべきだろうか。

計算結果　Fermi GTX460

running test suite...
==========Similarity Score=========
PCI-E I/O: 8.954000ms
Map: 34.964000ms
Group: 85.582000ms
all-test: 164.454000ms
==========StringMatch=========
io-test: 555.225000ms
PCI-E I/O: 0.107000ms
Map: 5.742000ms
all-test: 561.273000ms
==========MatrixMul=========
generate two 1024x1024 matrice...
rotate matrix2: 575.593000ms
PCI-E I/O: 20.445000ms
Map: 325.586000ms
all-test: 421.117000ms
==========InvertdIndex=========
generating 28 MB data...
io-test: 591.807000ms
PCI-E I/O: 0.736000ms
Map: 59.946000ms
Group: 145.929000ms
all: 799.424000ms
==========PageViewCount=========
rm Gen
gcc -o Gen main.c
generating data...
preprocess: 696.710000ms
PCI-E I/O: 16.061000ms
Map: 24.795000ms
Group: 251.808000ms
Reduce: 8.789000ms
PCI-E I/O: 15.979000ms
Map: 99.858000ms
Group: 2026.143000ms
all: 3159.068000ms
==========PageViewRank=========
rm Gen
gcc -o Gen main.c
generating data...
io-test: 736.345000ms
PCI-E I/O: 10.029000ms
Map: 6.983000ms
Group: 191.776000ms
count: 2147482603, offset: 25070899
count: 2147480853, offset: 30364534
count: 2147478632, offset: 14685990
count: 2147474733, offset: 34364671
count: 2147473550, offset: 36486720
count: 2147470289, offset: 30271619
count: 2147465831, offset: 9384424
count: 2147460496, offset: 8174314
count: 2147459207, offset: 21390190
count: 2147456172, offset: 23958395
all-test: 983.356000ms
==========WordCount=========
preprocess: 549.211000ms
PCI-E I/O: 0.087000ms
Map: 10.612000ms
Group: 2.005000ms
all: 562.383000ms
# of words:373
ACCESS - size: 7 - count: 12
ACHIEVE - size: 8 - count: 4
ADDITION - size: 9 - count: 16
ADDITIONAL - size: 11 - count: 8
ADVANCEMENT - size: 12 - count: 20
ADVANCES - size: 9 - count: 4
AFFORD - size: 7 - count: 4
AGAINST - size: 8 - count: 20
ALASKA - size: 7 - count: 16
ALWAYS - size: 7 - count: 4
==========Kmeans=========
preprocess: 2.273000ms
PCI-E I/O: 0.988000ms
Map: 1.180000ms
Group: 8.722000ms
Reduce: 9.396000ms
PCI-E I/O: 0.980000ms
Map: 1.106000ms
Group: 8.911000ms
Reduce: 8.368000ms
PCI-E I/O: 0.973000ms
Map: 1.161000ms
Group: 9.208000ms
Reduce: 7.768000ms
PCI-E I/O: 0.969000ms
Map: 1.118000ms
Group: 9.031000ms
Reduce: 7.416000ms
PCI-E I/O: 0.974000ms
Map: 1.175000ms
Group: 8.886000ms
Reduce: 7.159000ms
PCI-E I/O: 0.973000ms
Map: 1.111000ms
Group: 9.001000ms
Reduce: 6.870000ms
PCI-E I/O: 0.977000ms
Map: 1.179000ms
Group: 9.287000ms
Reduce: 6.752000ms
PCI-E I/O: 0.969000ms
Map: 1.116000ms
Group: 9.064000ms
Reduce: 6.587000ms
PCI-E I/O: 0.995000ms
Map: 1.162000ms
Group: 8.911000ms
Reduce: 6.611000ms
PCI-E I/O: 0.982000ms
Map: 1.121000ms
Group: 9.026000ms
Reduce: 6.548000ms
PCI-E I/O: 0.990000ms
Map: 1.182000ms
Group: 9.318000ms
Reduce: 6.556000ms
PCI-E I/O: 0.991000ms
Map: 1.133000ms
Group: 9.066000ms
Reduce: 6.478000ms
PCI-E I/O: 0.986000ms
Map: 1.189000ms
Group: 8.887000ms
Reduce: 6.458000ms
PCI-E I/O: 0.995000ms
Map: 1.141000ms
Group: 9.006000ms
Reduce: 6.486000ms
PCI-E I/O: 0.999000ms
Map: 1.217000ms
Group: 9.309000ms
Reduce: 6.483000ms
PCI-E I/O: 0.997000ms
Map: 1.137000ms
Group: 9.084000ms
Reduce: 6.455000ms
PCI-E I/O: 0.989000ms
Map: 1.184000ms
Group: 8.941000ms
Reduce: 6.402000ms
PCI-E I/O: 0.984000ms
Map: 1.143000ms
Group: 9.072000ms
Reduce: 6.452000ms
PCI-E I/O: 0.987000ms
Map: 1.237000ms
Group: 9.370000ms
Reduce: 6.481000ms
PCI-E I/O: 0.998000ms
Map: 1.161000ms
Group: 9.152000ms
Reduce: 6.492000ms
PCI-E I/O: 1.008000ms
Map: 1.192000ms
Group: 8.946000ms
Reduce: 6.423000ms
PCI-E I/O: 0.979000ms
Map: 1.151000ms
Group: 9.053000ms
Reduce: 6.439000ms
PCI-E I/O: 1.022000ms
Map: 1.224000ms
Group: 9.358000ms
Reduce: 6.478000ms
PCI-E I/O: 1.028000ms
Map: 1.179000ms
Group: 9.129000ms
Reduce: 6.468000ms
PCI-E I/O: 1.005000ms
Map: 1.209000ms
Group: 8.985000ms
Reduce: 6.529000ms
PCI-E I/O: 1.013000ms
Map: 1.184000ms
Group: 9.105000ms
Reduce: 6.489000ms
PCI-E I/O: 0.998000ms
Map: 1.233000ms
Group: 9.440000ms
Reduce: 6.477000ms
PCI-E I/O: 1.006000ms
Map: 1.161000ms
Group: 9.142000ms
Reduce: 6.553000ms
PCI-E I/O: 1.016000ms
Map: 1.228000ms
Group: 8.938000ms
Reduce: 6.560000ms
PCI-E I/O: 1.171000ms
Map: 1.273000ms
Group: 9.129000ms
Reduce: 6.491000ms
PCI-E I/O: 1.053000ms
Map: 1.279000ms
Group: 9.391000ms
Reduce: 6.543000ms
PCI-E I/O: 1.039000ms
Map: 1.210000ms
Group: 9.146000ms
Reduce: 6.536000ms
PCI-E I/O: 1.039000ms
Map: 1.249000ms
Group: 8.966000ms
Reduce: 6.595000ms
PCI-E I/O: 1.042000ms
Map: 1.212000ms
Group: 9.062000ms
Reduce: 6.576000ms
PCI-E I/O: 1.047000ms
Map: 1.292000ms
Group: 9.435000ms
Reduce: 6.504000ms
PCI-E I/O: 1.044000ms
Map: 1.213000ms
Group: 9.207000ms
Reduce: 6.544000ms
PCI-E I/O: 1.051000ms
Map: 1.267000ms
Group: 8.976000ms
Reduce: 6.546000ms
PCI-E I/O: 1.054000ms
Map: 1.218000ms
Group: 9.125000ms
Reduce: 6.600000ms
PCI-E I/O: 1.063000ms
Map: 1.289000ms
Group: 9.451000ms
Reduce: 6.581000ms
PCI-E I/O: 1.058000ms
Map: 1.212000ms
Group: 9.241000ms
Reduce: 6.581000ms
PCI-E I/O: 1.051000ms
Map: 1.263000ms
Group: 8.957000ms
Reduce: 6.583000ms
all: 746.297000ms


tesla C1060
running test suite...
==========Similarity Score=========
PCI-E I/O: 8.715000ms
Map: 56.532000ms
Cuda error in file 'MarsSort.cu' in line 978 : unspecified launch failure.
==========StringMatch=========
io-test: 50.755000ms
PCI-E I/O: 0.171000ms
Map: 1051.171000ms
all-test: 1102.357000ms
==========MatrixMul=========
generate two 1024x1024 matrice...
rotate matrix2: 57.361000ms
PCI-E I/O: 19.936000ms
Map: 294.171000ms
all-test: 389.633000ms
==========InvertdIndex=========
generating 28 MB data...
io-test: 95.979000ms
PCI-E I/O: 0.813000ms
Map: 48.929000ms
Cuda error in file 'MarsSort.cu' in line 1047 : unspecified launch failure.
==========PageViewCount=========
rm Gen
gcc -o Gen main.c
generating data...
preprocess: 190.078000ms
PCI-E I/O: 15.911000ms
Map: 38.648000ms
Cuda error in file 'MarsSort.cu' in line 978 : unspecified launch failure.
==========PageViewRank=========
rm Gen
gcc -o Gen main.c
generating data...
io-test: 220.167000ms
PCI-E I/O: 9.934000ms
Map: 7.805000ms
Cuda error in file 'MarsSort.cu' in line 1047 : unspecified launch failure.
==========WordCount=========
preprocess: 47.811000ms
PCI-E I/O: 0.134000ms
Map: 12.250000ms
Group: 3.541000ms
all: 64.294000ms
# of words:373
ACCESS - size: 7 - count: 12
ACHIEVE - size: 8 - count: 4
ADDITION - size: 9 - count: 16
ADDITIONAL - size: 11 - count: 8
ADVANCEMENT - size: 12 - count: 20
ADVANCES - size: 9 - count: 4
AFFORD - size: 7 - count: 4
AGAINST - size: 8 - count: 20
ALASKA - size: 7 - count: 16
ALWAYS - size: 7 - count: 4
==========Kmeans=========
preprocess: 2.085000ms
PCI-E I/O: 1.151000ms
Map: 2.921000ms
Group: 10.451000ms
Reduce: 8.029000ms
PCI-E I/O: 1.081000ms
Map: 2.926000ms
Group: 10.566000ms
Reduce: 6.691000ms
PCI-E I/O: 1.094000ms
Map: 2.973000ms
Group: 10.842000ms
Reduce: 6.225000ms
PCI-E I/O: 1.080000ms
Map: 2.946000ms
Group: 10.577000ms
Reduce: 5.944000ms
PCI-E I/O: 1.102000ms
Map: 2.985000ms
Group: 10.468000ms
Reduce: 5.989000ms
PCI-E I/O: 1.092000ms
Map: 2.953000ms
Group: 10.586000ms
Reduce: 5.926000ms
PCI-E I/O: 1.099000ms
Map: 3.031000ms
Group: 10.865000ms
Reduce: 5.898000ms
PCI-E I/O: 1.100000ms
Map: 2.960000ms
Group: 10.574000ms
Reduce: 5.740000ms
PCI-E I/O: 1.115000ms
Map: 2.994000ms
Group: 10.458000ms
Reduce: 5.673000ms
PCI-E I/O: 1.114000ms
Map: 2.959000ms
Group: 10.624000ms
Reduce: 5.615000ms
PCI-E I/O: 1.112000ms
Map: 3.027000ms
Group: 10.904000ms
Reduce: 5.677000ms
PCI-E I/O: 1.119000ms
Map: 2.957000ms
Cuda error in file 'MarsSort.cu' in line 1047 : unspecified launch failure.


teslaでは何かErrorが出ているようだが、水曜以降に確認します。

2/7 今後の予定

現在のテーマは高速化できるか怪しいので、ある程度のものでまとめて終わらせる。

3月までにやること
・XSLTの実装
・文字列比較・文字列コピーの32スレッド化
・Xerces、Xalanの速度計測（C++版）

3月中旬までによること
・上記の内容をまとめた文章の作成

文章は実装・評価と並列して書き上げる。
グラフ関連のGPUのアイデアや論文読みも行う。

1/31

今後の目標
・現在のテーマでSACSISのポスターに出す

そのためのステップ
・今月中旬にはXSLTを実装
・評価も近いうちに行う
・GPUによるAES暗号化のライブラリを探す

・ちゃんと単位を集める

1/26

某企業の見学会に参加したが、前回の数倍疲れた。
そろそろ期末テストと期末課題のラッシュなのだが、
勉強する体力がなくなってしまった。

就職活動と講義と研究で、二兎追うものどころか
三つも並列なので全て失敗しそうで恐ろしい。

一番興味も実用性も低いのは講義だが、
卒業単位の縛りがあるためどうしようもない。
講義は余裕がある人だけ受ければよいようにしてほしい。
某専攻はやることなすこと意味がわからない。

1/17

最近更新が停滞していたので改めます。

某OB会からの就活の連絡が微妙だったり、
学校推薦の流れがよくわからなかったり、
就活に纏わる不安定要素が多い。

XMLの実装は、ようやく速度が出てきたので安心した。
しかし、XSLTMarkの詳細を探してもうまく出てこないのが悩ましい。
IBM Data Powerのページまではたどりつけるのだが、
その先がどうなっているのか全くわからない。