古いCUDA Project (Visual Studio 2013とか) を動かしたい

新しいCUDA Toolkit環境で、昔のCUDA 6.5とかを使ったVisual Studioのプロジェクトを開こうとすると、エラーが起きて読み込めない。古い環境をピンポイントで指定している部分がProjectファイルに含まれているためらしい。
そこで、vcxprojファイルを直接エディター（emacsとか）で開いてみると、XMLタグのImportタグに、
CUDA 6.5.props
などと書いてある部分がある。そこを、6.5->9.1と書き換えてやる。それだけでちゃんと読み込めるようになる。また、環境変数
CUDA_PATH_6.5
とかバージョンを決めているところを、
CUDA_PATH
と変えてやるとよいようだ。
ちなみに、2017年12月19日現在の最新のVisual Studio 2017 (15.5.2かな)とCUDA Toolkit 9.1は互換性がないので注意。古い2017なら動くらしいが、どうもCUDAのVSのバージョンチェックでエラーが起きるようだ。残念なことに古いVS 2017は手に入れられないようなので、バージョンアップには注意が必要だ。

HPCの未来

昔、スーパーコンピュータと言われていたトップエンドのコンピュータは、特別にあしらえたベクトルプロセッサを搭載し、べらぼうなスピードで計算を実行できた。
ここで培われた技術がコンシューマレベルのパソコン用CPUに下ろされ、ボトムエンドコンピュータが桁上げされていった。
そしてスパコンがスパコンたる牙城だったCPUとメモリのバス速度も速くなって、もはやカスタムＣＰＵの存在意義は無くなり、並列コンピュータへの道が加速していった。
そして、並列の粒度を小さくして、膨大な数のスレッドを大量に処理するGPUが注目され、今度は、GPUではなく同じような能力を持つチップが開発され、注目を集めた。
光速が変わりようが無いので、CPUを小さくすることで計算速度を上げるしか無いのだが、もう限界に近い。GPUやペジーの様に膨大な数のスレッドを処理するコプロセッサが現在の主流と言えるのかもしれないが、メモリーアクセスがいつもボトルネックになる。
バンクコンフリクトなんぞは、昔からN社のSXシリーズでも問題になっていたが、GPUでも残っている。
シリコンコンピューティングの今後はメモリーとコプロセッサの通信の部分しか残っていないのかもしれない。そうだとすれば、あとはハードウェアのネットワーキング技術に掛かっている。3次元的なネットワーク網とか。もしかしたら、星野先生のPAXに戻るのかもしれない。
量子コンピュータとシリコンコンピュータの間をつなぐものが欲しいなあ。光なんだろうけど。シリコンよりも小さくないと意味が無いので、そんな小さいところを粒子として扱うことが必要だと、ものすごいエネルギー（短波長）の光量子を発生させなければならないのは多分大変なんじゃ無いか。

Joomla 3.8 + T3 Framework

Joomlaをサイトに使っている。JA-T3 Frameworkを使っているが、GoogleさんにMobile Friendlyでないと怒られてしまう。確認するとiPhoneだけはやるけど、Androidさんには冷たい。
で、最新のT3 FrameworkのT3 Blankを入れると、昔のJA-T3とはプラグインがかぶるらしくて混在できない。仕方が無いので、昔のテンプレートプラグインは休んで貰うことにした。でも、昔の方がしっくりくるデザインだった。でもモバイルフレンドリにはなったようだ。とりあえずはオーケー。

明るい未来

一次産業は、そのほとんどがロボットによって行われ、安定な供給、たぶん工業のような２次産業的な体制になる。水産業は全自動的な監視システムを用いた国際的な取り決めに基づいて漁獲高が決められる。ただほとんどが養殖によって賄われる。漁もロボット船が行い、生育の度合いとか種類とかをちゃんと選別してくれて今みたいに無駄が無い。
二次産業も、ロボット化が進み、ヒトの介在はほとんど無くなる。車で言えば、デザインを決めるのはヒトが行うだろうが、安全性のチェックから製造までをロボットがやるだろう。
三次産業の内、医者、弁護士、などデータベースをベースに判断するような職種はヒトからAIに多くをサポートされるようになり、国民は無料で２４時間サービスを受けられる。警官や消防士などもロボットだろうな。

と言うことになれば、国民は食の心配が無くなるので、何をしよう。伝統工芸とか、デザインみたいな嗜好性の強いもの、料理、研究、学問。。。

こうして考えると、この未来で、重要なのは、自前の食料の確保と、エネルギーの確保が最重要課題なのかな。でも原子力も核融合力もいらんなぁ。

Kuman 信号発生器買ってみた

ゆっちゃんに貰ったファンクションジェネレータキットがどうしても動作しないので、 Kuman 信号発生器をAmazonでぽちっとやった。中国深圳から１０日以上掛かってとどいたものの、それは「UNO」と基盤に書かれた見慣れたものだった。で、販社に連絡したところ直ぐに送っていただけた。組み上げて、別に買ってあったArduino UNOでプローブしたところ、信号が全く検出できない。どうなってるのかと、色々やっている内に、実はArduinoのAnalog Portがこけていることが判明。信号が出ていることは確認したけれど、ケースに入れようとしたら、雌ねじの一つのねじ山が無い。ありかー。直ぐに送ってくれるらしいけど。。。
担当の方はすごく反応が早いし、誠実だけど、ちょっと、疲れた。
Arduinoの方も代替品を送ってくれるらしい。ちょっと心配だったので二つ買っといて良かった。でも、なぜか１つ増えて、半故障品も一つ。２つかったら４つになった。これってわらしべもどきか。
品質は値段の割には十分だと思うけどね。

Visual Studio for macOS

ゆっちゃんに貰ったC#のコードを、せっかくVS for macOSが出たんだから移植してみようと思い立ち、プロジェクトファイルを読み込んで，ランさせようとしたら、オチタ。
じゃあということで、Hello Worldから始めようと思った。新しいプロジェクトを作成して、Cocoaアプリを指定したが、なにかライブラリが無いという。
Xamarinの何かが足らないのかなと思い、Unitiyがらみから、.NET Coreを入れてみたりしたけど、ダメ。もしかしたらXcodeがらみか、と気がついて、Xcodeを立ち上げたら、コンポーネントをインストールしますってメッセージが出た。ドキドキしながら待ち、Hello Worldをビルドしたら、ちゃんと出来た。よかった。
ゆっちゃんコードは、この次にって事になった。

Integrated Performance Monitoring Library

正式には、Integrated Performance Monitoring ライブラリと言う。プログラムの内部関数の時間などを計測し、パフォーマンスの改善につなげるためのライブラリツール。使い方はプログラムリンク時に、IPMライブラリを指定することによって、利用する。計測結果は、標準出力またはファイルに出力される。MPIの通信時間など広くプログラム実行速度のチェックに使われているらしい。

インストール[編集]

2017年現在、ソースはGitHubから提供されている。

git clone https://github.com/nerscadmin/IPM.git
cd IPM
./configure --with-os=LINUX --with-compiler=gcc --with-arch=LINUX --with-cpu=INTEL --prefix=~/  --with-hpm=PAPI
make
make install

これでUbuntu17.04ではインストールされた。インストールされる場所は、自分のルートディレクトリの~/bin, ~/lib, ~/etcである。

使い方[編集]

プログラムリンク時に、その一番お尻にライブラリを指定する。

mpicc foo1.o foo2.o -lfoo -lboo -L~/lib -lipm -o foo

そして、並列処理を始める。

mpirun -np 120 foo arg1 arg2 ...

実行終了時に標準出力やファイルに結果が出力される。出力されるファイルは、xxx_xxx.xmlというファイルになる。このファイルはxmlファイルで階層データになっていてそのままではよく分からないので、グラフィックに出力させる。そのツールは既に用意されている。

~/bin/ipm_parse -html xxx_xxx.xml

すると、ディレクトリが作られ、内部にHTMLファイルがセーブされているのでそれをウェブブラウザで表示すればよい。