その手の平は尻もつかめるさ

ギジュツ的な事をメーンで書く予定です

Goでforkしたいとかgoroutine IDが欲しいとか言わない

golang















結論

欲しがらない

補足






CUDAのエラーチェックを楽にする

CUDA

CUDAの組み込み関数はほとんどcudaError_tというエラーコードのenumの値を返してくるので，これを適宜見てエラー処理をする必要があります．最近ではそこまででもないですが，CUDAの組み込み関数はカジュアルにエラーを吐くのでちゃんと見てやらなければならない．
見てやると言っても，CUDAの組み込み関数がエラーを吐いてきたらほとんどの場合そのまま潔く死んで欲しいので (個人の意見)，以下の様に戻り値をチェックしてexit()するというコードを大量に書くことになります．

int *foo;
cudaError_t err;
err = cudaMalloc((void **)&foo, sizeof(int) * 42);
if (err != cudaSuccess) {
    exit(err);
}
...

まあ，素直に書けばええやん！　という意見は尤もなのですが，いかんせんこういうエラーチェックが大量に入ると本質的なコードが追いにくくなってつらい．
あとカジュアルにエラーチェックを忘れてしまって，バグッた時にハマる (しかしまあ，これはもうどうしようもない気がしている)．golangとかだと，返ってきたerrが使われてないと「err使われてないよ！ (つまりエラー処理してないんじゃねえの！)」と処理系が叱ってくれるからナイスですね．羨ましい．あとgolangは「エラーを受け取っても受け取らなくても良いよ」みたいなものが無いから，そこら辺のコードを規約化出来て良いという印象があります．


さて，そうしたリッチな機構が無い上でどうするかというと，僕は以下の様なマクロを書いてしのいでいます．

でもって，こう書く

int *foo;
CUDA_SAFE_CALL( cudaMalloc((void **)&foo, sizeof(int) * 42) );

こうしておくと，CUDA組み込み関数からエラーが吐かれた時にエラーメッセージ・ファイル名・行番号と共に，エラーコードでexit()してくれるのでまあまあ便利．
ちなみにcudaGetErrorString()っていう関数はcudaError_tの値をもとにエラーメッセージを引っ張ってきてくれる君です．


しかし，これも野蛮な方法であることには違いないし (なにより，CUDAの組み込み関数がCUDA_SAFE_CALLに渡される事が保証されない)，エラーチェックが忘れがちになってしまうという問題については何一つ解決されていません．
現段階では，ちょっとだけコードが見やすくなって便利，くらいの感覚です．


もっと良い方法知ってる人いたら是非教えて下さい．

テンプレートエンジンNightやります

ページャNightなるイベントが開催されてからはや2ヶ月，
あの「なんとかNight」が帰ってきた！！！！



テンプレートエンジンNight on Zusaar


今回はテンプレートエンジンNightです．その名の通りテンプレートエンジンとその周辺技術専門の勉強会です．
テンプレートエンジン尽くしの2時間となる予定ですので，テンプレートエンジンに興味のある方は是非ふるってご参加下さい．

予定ですと，

といった，たくさんの言語のテンプレートエンジンエンジンの話が聞ける予定です．
めちゃめちゃ楽しみです！！！


よろしくお願いします．

CUDAで特定の条件に合致したGPUのIDを持ってきたい

CUDA

CUDAで，特にマルチGPUプログラミングなどをやっておりますと，特定の条件に合致したGPUのIDを持ってきたいという要求に高確率でぶち当たる事となると存じます．俺はぶち当たる．


GPUがマザーボードに5枚刺さっていて，そのうち4枚は映像のアウトプット端子がないGPGPU専用の板で，残る1枚は映像を出力するためだけの貧弱なボード，という構成のサーバはこの世の中少なくありません *1．
そうした構成の時に，不慮の事故によりcudaSetDevice()によってGPGPU専用のグラボではなく映像出力専用の貧弱な板がアサインされてしまったばかりにパフォーマンスが死ぬほど落ちて死ぬ，というのは割とよくある事例であります．そうした事故は未然に防がなくてはなりません．


原因を考えてみましょう．
なぜこういう悲しい事故が起こるかと言うと，cudaSetDevice()に食べさせるGPU IDをハードコードしているからこういう事が起こるわけです．
GPUのIDはハードウェアの構成が変わるとそれと共に変化します (あと良くわからんけどこの前マシンをリブートしたらIDが変わってハマった，ふざけんな)．
つまり，書いたプログラムを違う環境に持って行くと動かなくなったりパフォーマンスが下がる可能性が出てくるわけですね．
GPU IDをハードコードしてはならない．


で，どうするかと言うと，

こういう感じのプログラムを書くことで解決を試みています．
cudaGetDeviceCount()でGPUボードの数を持ってきて，それをもとに全部のGPUボードを舐めつつcudaGetDeviceProperties()でGPUのプロパティを引き出し，そのプロパティのデータを使って条件と一致するボードかどうか (今回はボードの名前) を見てやるという感じですね．
基本的にcudaGetDeviceProperties()で取れるcudaDeviceProp構造体はボードのほとんどの情報を持ってるので，これを使えば大体なんとかなります．


こういう感じで持ってきたIDをcudaSetDevice()に渡してやると事故が起きなくて便利．

追記

つらい

*1:とは言え，「GPUなのに映像出力できないとはけしからん！！」と怒る怖い人がいるので，最近ではGPGPU専用の板でも映像を出力できたりします

YAPC::Asia Tokyo 2014に参加致しました

perl

YAPC::Asia Tokyo 2014に参加致しました．

例年はgihyo.jpのリポータという事で参加していたのですが，今年は僕の怠慢でリポータではなく，初の一般参加でした．

とはいえ，
YAPC::Asia Tokyo 2014でPerl::Lintについて喋りました - その手の平は尻もつかめるさ
に書いたように発表はしたのですが，各方面から「慢談だ，慢談だ」などと揶揄され非常に厳しい状況です．慢談じゃねえっつってんだろ！！！
汚名をすすぐ為に後ほど詳しい解説記事を書く予定です．乞うご期待．


ああ，そうそう，@さんのライブコーディングの茶々入れ係もやりました．
トラブルはありながらも適切に説明を入れながら，時間通りに成果物を完成させてしまうsongmuさんは完全にバケモノだと思いました．
ところで，まじめにライブコーディングやってる人に茶々を入れるの，実は皆さんが思っているより200倍は難しくて，「ここで変なこと言って邪魔したら殺されるんじゃねえか……」という葛藤が常に頭にあったことを述懐します．しかし常に会場がシーンとしているのも怖い……喋らねば！　みたいな感じでおっかなびっくりしゃべっていたというのが舞台裏です！！


さて，はじめて一般目線でYAPCに参加しましたが，好きなときに好きなトークを見て，おしゃべりしたい人とおしゃべりできる，というのは本当に良いですね．今年のトークの方はPerl関連のトークと非Perlのトークが半々くらいで，バラエティに富んでて非常に面白かったように感じます．

特に@cho45さんのトークは今年見たトークの中で最高のトークでした．これが本物のハッカーなのだ，と実感しました．ローレイヤーでブログツールを書くという発想がすさまじい．本当に格好いい．

@lestrratさんのSubroutine Signaturesのトークもめちゃめちゃ面白かった．現実はドラマよりもドラマだったし，OSSは人間そのものだという事を改めて実感できました．人間としてのパワーを高めたい．

そして静的解析友達でもある@hitode909さんのトークは，今回の僕のトークと同じ感じのテーマ性を有していたので非常に楽しみにしていて，果たしてそのトークは本当に良かったです．頑張って静的解析するぞ！！！！！


さてさて，今回のYAPCで特筆すべきは今年から導入された同時通訳で，これがとにかく凄い．
こういうカンファレンスで提供される同時通訳と言えば，あまりクオリティが高くなくて，聞いてるうちにその通訳音声がノイズになってきて「だったら自分の耳で聞くわい！！！」ってなってインカムを外す，というのがお決まりのパターンだったわけで．
そんな感じで本当に失礼なことに，YAPCの同時通訳に関しても最初は全く期待していませんでした．
そして蓋をあけるとびっくり仰天，なんと快適な同時通訳！　今まで体験した同時通訳の中で最高の通訳でした．本当にありがとうございます．

例年は海外からのスピーカーのトークは聞きに来る人が少なくてなんだか寂しい思いをしていたのですが，今回は同時通訳のパワーのお陰か聴講者の数が多くて良い感じでした．やはりなんだかんだ言っても言語が違うというハードルは確かにそこに存在するので，このような障壁を少しでも取り除こうとする取り組みは本当に素晴らしいですね．最高です．
かなりのコストがかかっている事と存じますが，来年以降も同時通訳はぜひとも続けていただきたく思います．


そしてインターネット！
我々はインターネットが無いと窒息して死んでしまう民族なわけですが，今回の会場内のWi-Fiは何一つ不自由すること無く，快適なインターネットライフを送ることが出来ました．これが有志の皆さんの力で成り立ってるというのだからすさまじい．マジ最高！！　ありがとうございます．


後，無限コーヒーや無限かき氷といった炊き出し制度もかなり良かったです．
ああいう食物や飲料が存在しているとどこからともなく自然と人がわらわらと集まってくるので，そこで自然とコミュニケーションが生まれて色々おもしろ体験が出来て良い．僕はといえばその無限コーヒーの傍らでBooking.comの人事の人と適当な英語で魂のコミュニケーションを行い，Booking.comのロゴが入ったスクィーズボトルを貰うにまでこぎつけました．「そのボトルあげたんだから雇うぞ」とか言われた気がするけど多分気のせいだ．
そういった場所でおもしろイベントを催すっていうのも，「これぞ祭りじゃ！！」という気分が盛り上がって非常に良かった．


会場内にHUBがあるというのは非常に考えものですね！！　僕みたいに自制心の無い人間はホイホイおびき寄せられてしまう！
とは言えこういう社交場というか，コミュニケーションの場があるのは本当に素晴らしい．普段話せないような色々な人と楽しく話せて本当に良かった．
酔っ払った勢いでBooking.comの皆さんと喋ってたら「雇うぞ」とか言われた気がするけど多分気のせいだ．


とにかく今年のYAPC，楽しみ倒しました．ありがとうございます．
来年も是非参加したいと思います！！


最後にひと言
適当な英語でも通じる！！！！！！！！！！！！！


YAPC::Asia Tokyo 2014でPerl::Lintについて喋りました

perl

タイトルのとおりです．
スライドは以下です．



もうちょい詳しく話す予定だったんですが，冒頭のライブリリースに失敗するなどして出鼻をくじかれテンパってしまいました……
ちょっと詳しい話をすると，

  • ポリシー周り
    • 各ポリシーがトークンを受け取って，それを各々独自に走査して処理する
    • ポリシーはevaluate()というメソッドを持っていて，そこで解析処理をする．各ポリシーのevaluate()はそれぞれ同じ引数を受け取り，violationsを含むarray referenceを返す．ゆるふわなインターフェイス的思想．
  • フィルターもゆるふわなインターフェイス的思想になってて，filter()というメソッドを持ち，filterしたいポリシー名を含んだarray referenceを返す．
  • こんな感じで，新しいポリシーやフィルターを作りやすい！！　と思ってたんだけどそうでもない気がする，後述．
  • とりあえず，開発のモチベーションとして，処理が高速でないと話にならんと思ったのでパフォーマンスの為にあえてダーティなコードを書いている部分がある
  • 一方でパフォーマンスとは関係の無いダーティなコードも書いている
  • あとまあ，Perl::Lintが速い場合と遅い場合があるのはわかっていて，スライドには割と恣意的なベンチの結果を載せている


あと，現状だと独自のポリシーとか独自のフィルターを書く為の敷居が高過ぎる (例えば，作法とかが一切わからん) という意見をもらったので，そこら辺を上手くサポート（チュートリアルとかスケルトンジェネレータとかで）したいなあというモチベーションになりました．何か良い意見あれば是非教えて下さい！


質疑応答は（覚えている限り）以下のとおりです．

Q. なんでAST使わないの？
A. Compiler::Parserがまだ不安定で，解釈できないコードが多かったため諦めた

Q. ASTじゃなくてToken使うことによるメリットってあるの？
A. よくわからない，無いのでは．手でToken走査して頑張るの本当に大変．ASTあるなら本当に使いたいケースは確かにある．

Q. Compiler::Lexer，SEGVとか多いイメージあるけど最近どう？
A. 最近では少なくなっているとは思います．でもまあ起きるには起きるんで……

Q. コントリビュータ募集って言ってたけど，どのへんに協力して欲しいの？
A. ぶっちゃけ僕が実装したくないポリシーを実装して欲しいんですけど，まあ無理な話なんでドキュメントとかで協力していただきたく存じます．

Q. Perl::LintにPerl::LintかけるとたくさんPerl::Lintのviolation出るけどこれって直るの？
A. 無理では……（ほんとうに難しい）

Q. C-Style forやめたら？
A. C-Style forの方が楽なんで許して欲しい (これは発表中にも喋ったんですけど，トークンの先読みとか後戻りとかを結構するので自在にインデックスをいじれたほうが良い)



YAPC会期中は常に会場のどこかしらにいますんで，何かPerl::Lint周りに興味がある方いらっしゃいましたらお話しましょう！

YAPC::Asia Tokyo 2014でPerl::Lintについて喋ったりします

perl

おわび

Perl::Lint出来てません

本題

明日8月28日(木)から3日間に渡ってアジア最大のPerlのカンファレンスであるところのYAPC::Asia Tokyo 2014が開催されますね！　楽しみですね！　夜も眠れないですね！


さて，そのYAPC::AsiaでわたくしPerl::Lintという開発中のツールについて一席打たせて頂きます．
Perl::Lint - Yet Another Perl Source Code Linter - YAPC::Asia Tokyo 2014

  • そもそも静的解析とは何か
  • 静的解析して何が嬉しいのか
  • Perlにおける静的解析ってぶっちゃけどーなのか
  • Perl::Lintの構造とかポリシーとか実装とかってどうなってんのか
  • Perl::Lintにたっぷり詰まってるバッドノウハウについて
  • 理想の社会とは何か

みたいな話をする予定です．「Perl::Lintの話」と銘打ちましたが，コードの静的解析技術やその応用について言及する予定です．
どっこいあくまで予定です．まだ資料できてません．
資料できてませんが，必ず良い発表にするので皆さん是非足を運んでいただけたらと存じます．


資料できてないしPerl::Lintもできてないしで，別の意味で夜も眠れませんが，俺のこの熱量は本物です．
それではみなさん会場でお会いしましょう！！！！！！！