C言語

最近、http://www.open-std.org/jtc1/sc22/wg14/で見つけたC言語の規格書を読んでいます。
Draftと書いてはいますが、ダウンロードできて検索もできるので、正直JISを苦労して見るより、かなり便利だと思います。

ところで、Draftって草案って意味ですよね？
草案だから公開してるのでしょうか？
でもこの草案を参考文献にしている所もあるし・・・いったいどういうことなのでしょう？
ただいずれにしても、個人で使う分には十分だと思います。

この規格書、今までいろいろと疑問に思っていたことが、一瞬で解決されてしまう魔法の書です。
英語で５００ページ程度なので、そんなに大量というわけでもありません。

少しでもプログラミングを経験した今だからこそ読めるのかもしれませんが、最初から読みたかった気もします。

色々と複雑な気がする言語なので、規格書の内容も参照しながら入門させてくれるC言語の入門書があればなぁ、と思います。

しかしC言語ですらほとんど理解出来ていないのに、C++となるとどうしていいのか・・・という気分になってしまいますね・・・。

fortRun更新 ( v2.11 )

fortRunを更新しました。

最新版は以下からダウンロードできます。

「fortRun.lzh」をダウンロード

■ 変更部分

・位置とサイズの保存の復元ができないバグを修正
（僕の環境でしかテストできていないので、もし問題があれば連絡ください）

・まとめてインデント・アンインデント機能追加

・フォートラン固定書式の場合、まとめてコメントアウトと、まとめてコメントアウト解除機能追加

パソコン

最近身近な人たちは就職や進学でパソコンを買ったりしてます．

そんなの見てると欲しくなるけど，学生の身分ですので，動くうちは今のパソコンで我慢します（笑）
派手な計算は研究室のパソコンで出来るし．

あ，でもBuilderのXE2は欲しいです．

６でも全然問題ないけど，そろそろ未来がないかなぁ，なんて思ったりします．

僕は趣味でやってるので，全然問題ないのですが，やっぱり仕事でとかなると，C＃とかJavaとか，そういった技術を使いこなせないと話にならないのかなぁ

マイコンな部分でも，Cコンパイラーと高度なライブラリーが使えるのが普通みたいだし，Arduinoみたいな流行の部分は全然分からないし．
い，い，・・・一応AVRのアセンブリならちょこっとかける・・・よ？・・・

アセンブリで書けなきゃ楽しくないみたいな妙なこだわりが，結局何にもできない原因かもしれません
色々勉強しないと色々やばそうです・・・

Ubuntuどうしよう

今更ながらUbuntu11.10にアップグレードしてみたのです．
でも残念ながら，少なくともUnityは重くて使い物になりませんでした．

Core2Duo1.6GHzでメモリー1GB，Radeon200M搭載のEpsonのノートです．
考えれば５年くらい前のパソコンなので当たり前かもしれません．

Chromeで動画を見ながら，ソフトウェアセンターを起動するという，当たり前レベルの動作で急激に重くなり，なんとウィンドウマネージャー（？）ごと落っこちてしまいました．（ただ，そのあと端末に戻らずログイン画面に戻ってきたのは素晴らしかったです）

全体的にはいろいろ進化してていい感じです．
以前までなら終了がうまく出来ないことが多かったのですが，11.10からは問題なく終了できるようになりました（この辺はカーネルのバージョンの影響かもしれません）
UIも，「これでいいの？」感はあるけれど，工夫している感じがあります．

全体的に明らかにmacのパクリとなっているのも，ここ最近の流行と思えば仕方ない気もします．
ただ設定画面，あれはどうかと思います（笑）

起動してしばらく使った段階でメモリーを400MB以上消費していたので，恐らく想定されているスペックが11.04のgnome2の時より高いのだと思います．

今後もパソコンやスマートフォン，家電の変化は止まるはずもないので，Ubuntuがそれを見据えて進化していこうというのは素晴らしいと思います．

ただ，「友人に気兼ねなく勧められるOS」じゃなくなったかなぁ，という気もします．
僕のPCのスペックは今では「古いパソコン」に分類されるんだと思うのですが，そういうパソコンがやっぱり今でも現役な気がするのです．
そういうパソコンにそのまま入れて動く保証がなくなってしまったと思うと，ちょっと残念な気もするのです．

そういえば，ここ数年パソコン関連はいろんな変化がある気がします．
64bitが当たり前になったり，メモリーは2GB程度が当たり前になったり，MBRがGPTになったり．
スマートフォンが（日本でやっと）使われ始めたり，ネットワークにファイルを置くのが当たり前になったり，携帯のモデム化が当たり前になったり．

今まで少しずつ積み重なった変化が一気に現れ始めたという気もします．

そんなわけで，Ubuntuが変わっていくのも仕方ないのですが，僕の使えるOSがなくなってしまって困っています．
11.04のgnome2のままで行けるのも時間の問題だし．
Xubuntuという選択肢もあるのでしょうが，なんとなく，UbuntuはUbuntuで使えた方が楽な気がします．

Unity2Dも何故かもっさりとしか動いてくれません．
何かスペック以外の問題があるのかなぁ・・・

メモリ不足は確かにあるので，とりあえずメモリを買い足そうかと思います．

CUDA上の定数

CUDAでプログラムを作るときに，double型を使っていないにもかかわらず

ptxas /tmp/tmpxft_000008ef_00000000-8_fdirdet_dev.ptx, line 95; warning : Double is not supported. Demoting to float

という警告が消えませんでした．
nvccに渡したオプションは，macでは

-m64 -O2 -lcutil_x86_64 --compiler-options -fpermissive

という感じです．

しょうがないのでptxを出力させたところ，こんな結果となりました（関連部分を抜粋）

ld.global.f32 %f1, [%r12+0];
cvt.f64.f32 %fd1, %f1;
mov.f64 %fd2, 0dbfe0f5c28f5c28f6; // -0.53
mul.f64 %fd3, %fd1, %fd2;
cvt.rn.f32.f64 %f3, %fd3;

-0.53の部分は，ソースファイルの中で#defineした定数です．
何故か-0.53とかけ算するために，一度doubleに変換し，その後floatに戻しているように見えます（多分）
たったこれだけの計算でいろんなレジスタを使っていて，いかにも遅そうです．

ちなみに95行目のコードは

mul.f64 %fd3, %fd1, %fd2;

です．サポートしてないという割には64bitっぽい命令ですが，恐らくcubinに変換されるときに，float型の計算になるのではないのでしょうか．

問題は，-0.53がdouble型となっていることが推測されるので，ソースコードを

-0.53f

と変更してみました．
すると，警告はなくなり，周辺のコードはすっきりしました．
やってることも一目瞭然でいい感じです．

ld.global.f32 %f1, [%r12+0];
mov.f32 %f3, 0fbf07ae14; // -0.53
mul.f32 %f4, %f1, %f3;

そういえば，Cの実数定数の型はdoubleだった気がします．
意外と律儀に型を守ってくれるみたいですね．その方が嬉しいです．

オプションでアーキテクチャの指定をすると，この警告がなくなるというのは読んだことがあるので，
これでは今まで効率の悪いcubinが出力されていた可能性がありますね．

ただ，速度は全く上がりませんでしたw
computeprofレベルで見れば変わっているかもしれませんね．

ところで，アーキテクチャの指定をしていなくても，64bitからの変換や，64bitレジスタの使用には警告が出ないと言うことは，どんなに古いCUDAの動くGPUでも64bitの値を保持する仕組みはあったということでしょうか？

いずれにしても，警告が０になって一安心です．
これで堂々と論文に貼れますｗ

ちなみに，この警告を直している間にほかのバグを二つ発見しました・・・危なかった・・・

歯が口内炎が

痛い！

CUDAデバッグ

卒業研究でCUDAを使っています。

自分で書いたデバイスコードがまともなのか心配なので、CPUで同じ動作をするコードを書いて比較するのですが、どうにも微妙、非常に微妙に値がずれます。

計算方法をチェックしても間違ってるとは思えないし・・・

で、いろいろ調べてるとやっと見つけることができました。（マニュアル読んでないだけかも）

CUDAのデバッグをCPUと比較して行う場合、次のことに注意するとある程度うまく行くようです。

１．積和演算器による誤差の変化

２．実数の演算順序

１について、GPUには、頻繁に行われる実数の積和演算（ 1.4. * 2.2 + 3.3のような演算 ）を行う装置があり、積和演算器を通す場合と、それぞれ乗算器と加算器を使う場合では結果が異なる。

２について、たくさんの加算を実行する場合、コアレッシングやバンクコンフリクトの影響を考えて加算の順番をCPUと異なる順番で実行すると、結果が異なる。

・・・といった感じです。

１については__fmul_rnと__fadd_rnという関数を使えば最適化を防止し、CPUと同じ動作をさせることができます。

２については多分、なのですが、CPUでGPUの動作と同じになるようにプログラムすると、ちゃんと結果が一致したので多分こういうことだと思います。

いずれにしても、CPUと同じ結果に持って行くには、複雑なプログラムだと結構大変だと思います。

無理に同じにしようと努力するより、浮動小数点の仕様からどの程度までのずれが誤差と言えるのか調べたほうがいいかもしれません。

ただ、ロックの位置やメモリ操作のミスで値がずれたりもするのでチェックしたい誘惑にもかられます（笑）

便利なことには違いないですが、気を付けていないとひょんなところから穴にはまりそうで怖いです。

しかしCUDAは速いな・・・

秋

なんか今日から急に寒くなりましたね。

あと五教科・・・

家が光回線になりました。

無線LANで、１メガバイトも一秒間にダウンロードできるなんてどうかしてます。

Windowsがかなりやばい状況です。
起動に１０分はかかるかなぁ

要するにHDDの容量が無いのが問題なので、お引越しを真剣に検討してます。

ノートパソコンに何個もOS入れてるのが悪い気もするのですが、Linuxは必要だし・・・

Windowsのテキストエディタは秀丸一本でこれからも行くつもりですが、Linuxでのエディターはまださまよい中です。
Ubuntuの場合、標準でgeditレベルのものが入っているので正直、標準でもなんとかなります。

多分エディタって慣れですよね。

gnome2、バグが多いとも聞きますが、結構気に入ってるのでぜひともサポート続行して欲しいです。

とはいっても、Unityの進化にも期待してます。

今のままじゃちょっと困りますが。

いよいよ11.10ですよね？楽しみ〜

いつか開発に参加できるまでになりたいなー。

パソコンパーツ

買うならこんなのかなーと思って適当に見積もってみたら・・・

マザー 17000
CPU 26000
ケース 15000
電源 20000
CPUFAN 7000
メモリ 4000
SSD 17000
HDD 8000
BDR 10000
GTX580 60000
etc 10000

ん〜、やっぱり二十万くらいでしょうか。

高い・・・

正直普段使う分にはオーバースペックですが、どうせ作るなら最強構成・・・なんて欲が出ます。

CUDAと広大なメモリ空間がそもそもの目的なので、そのへんは外せません。

あれ、これOS入れたらとんでもないことに・・・？

ただ、ちょっと派手にメモリを使うプログラム程度を作るのであれば、Ubuntu64bitでなんの問題もないのでOSはいらないかもしれません。

CPUはi72600で行きたいです。
Kは・・・どうなんでしょう、わかりません。

正直ブルーレイなんて持ってないのでドライブは安くなるかな？
ケースももうちょっと安くてもいいのかもしれない。

ファンとか電源は派手に使うのであまり削りたくないし・・・

・・・なんて考えてると飽きてきちゃいます（笑）

PC自作は非常に「趣味な世界」ですね。

同時に、なんとなくハマる気持ちも分かってきました（笑）

パーティションを切りたい

Linuxを使うとなると、パーティションの話やマルチブートの話からは逃れることができません。

パーティションについていろいろ調べてみましたが、やっぱり自分で切るのは難しいですね・・・

今回も、以下のサイト様の情報が非常に役に立ちました。本当にありがとうございます。
http://wikiwiki.jp/disklessfun/?hduse
http://www37.tok2.com/home/nobusan/

以下の内容は僕個人の、思ったこと、分かったことのメモなので不正確な情報である可能性が高いです。
読んでくださる方は、その上で読んでいただけると助かります。

いろんなサイトによる情報をまとめると・・・

CHSはもはや形だけ（？）
これからは物理的には4kセクタのHDDが出てくる。
よってパーティションの先頭は512バイトセクター番号で8の倍数にすべき？
SSDはページと言う単位やブロックという単位で読み書きされるので、パーティションをそれに合わせて切るべき。
fdisk -H 64 -S 32
昔は H255 S63 ( WinXPSP1以前等、古いOSではこれ + 下の２つのルールで切るのが安全？ )
最初のパーティションは第二トラックから。
パーティションはシリンダー境界で切る。
GPTというパーティションテーブルではLBA33まで使われるらしい？
XPSP1以前では48bitLBAに対応していないので128GByte内のパーティションへ？

・・・という感じ？

シリンダー境界などはもうあまり意味が無いのでは、とも思いますが、不安なので揃えたいです。

たぶん-H64 -S32で第二トラックからパーティションを切れば先頭のパーティションの先頭のLBAは8の倍数な気がします。
ただそうすると、GPTというパーティションテーブルに微妙にかかっている気もします。
そもそもMBRでブートするHDDと共存する状況があり得るのかわかりませんが、なんとなく怖いです。
しかし、さらによく見ると、第二シリンダーからパーティションを切る、とあります。これなら確かに余裕ですね。

まとめると、

「H64 S32で第一パーティションを第二シリンダーから、以降、パーティションはシリンダー境界で切る」

・・・と言うのがベストな方法・・・なのかな？

やっぱりパーティションは大変です。

その他メモ：

とりあえずGpartedかfdiskで先頭1MiB開けて、以降1MiB単位で切るのが安全そう？

Ubuntuでgrubのインストール先を間違えたら

sudo dpkg-reconfigure grub-pc

というのが有効そう？