CPUのAFFINITY的なものでちょっと悩んだ

この記事は外部の日記(ひびろぐ)からマルチポストしています。見た目がおかしいときは本家を参照してやってください。
本家→http://exth.net/~tgbt/wordpress/2011/07/21/3838/

      • -


ので、メモしておく。


ちょいとWestmereEPなCPUを搭載した計算機をいじる機会が巡ってきた。このCPUさん、6コアでHTを使うと12コア。そしてこの計算機には、そのCPUが2つ搭載されているのです。つまり、物理12コア論理24コアのちょっとでかいワークステーション

さて、ちょっと困ったのが、OpenMPの性能確認をしようと思ったのだが、HTなコアに割り当たらないように保証する方法とか、逆にHTなコアにぶつけちゃうようにする方法がよくわからない。MPIだったらnumactlで色々いじれることを把握していたのだが、OpenMPはどうするのだろうかという問題にぶつかった。

webで調べてみたところ、どうやらGNUOpenMPならGOMP_CPU_AFFINITYで設定できるようだという情報を得た。今回は、本当はIntel Compilerで測定したいのだが、とりあえずGCC(g++/gfortran)で測定しているので渡りに船。ちょっと試してみることにした。


まず/proc/cpuinfoを確認。なんとなく使えそうな値としては、processorとphysical idとcore id。ざっと順番に抽出してみるとこんな感じ。

processor	:	0	physical id	:	0	core id	:	0
processor	:	1	physical id	:	0	core id	:	1
processor	:	2	physical id	:	0	core id	:	2
processor	:	3	physical id	:	0	core id	:	8
processor	:	4	physical id	:	0	core id	:	9
processor	:	5	physical id	:	0	core id	:	10
processor	:	6	physical id	:	1	core id	:	0
processor	:	7	physical id	:	1	core id	:	1
processor	:	8	physical id	:	1	core id	:	2
processor	:	9	physical id	:	1	core id	:	8
processor	:	10	physical id	:	1	core id	:	9
processor	:	11	physical id	:	1	core id	:	10
processor	:	12	physical id	:	0	core id	:	0
processor	:	13	physical id	:	0	core id	:	1
processor	:	14	physical id	:	0	core id	:	2
processor	:	15	physical id	:	0	core id	:	8
processor	:	16	physical id	:	0	core id	:	9
processor	:	17	physical id	:	0	core id	:	10
processor	:	18	physical id	:	1	core id	:	0
processor	:	19	physical id	:	1	core id	:	1
processor	:	20	physical id	:	1	core id	:	2
processor	:	21	physical id	:	1	core id	:	8
processor	:	22	physical id	:	1	core id	:	9
processor	:	23	physical id	:	1	core id	:	10

processorは通し番号で決定として、physical idは0と1だからソケット番号と見て間違いないだろう。core idはなんで番号が飛んでいるんだろうってのは置いとくとして、6種類の値があるから物理コア番号だろう。番号が飛んでいる理由はおそらくIDをビットで表現しているから、かな?(0:0000, 1:0001, 2: 0010, 8:1000, 9:1001, 10:1010、なんとなくそれっぽいよね。)


というわけで、まずphysical idでソケットがわかれていて、core idで物理コアもわかれている。あとはphysical idもcore idも同じ2つずつのprocessorが同一論理コア上の2コアということで確定でしょう。


確定的な予想はついたところで、実際に測定してみることにする。
試しにシンプルな三重ループの行列積を作成して、最外ループをOpenMP並列化してみることにした。
並列度を1,2,4,6,8,10,12,14,16,18,20,22,24と設定してみたところ、こんな感じになった:

12並列まで性能が向上した後はむしろ性能が落ちている感じ。余っている計算資源を有効活用するHTのコンセプトからして今回みたいなひたすら同じ演算器ばかり使う計算では性能は上がらないわけで。どうやら、ちゃんと並列度が物理コア数に到達するまでは順番に適当なコアを使ってくれているようだ。(きっと/proc/cpuinfoのprocessorを頭から使っているんだろうけど、そこまでは確実性がない。)


それでは、ということで、GOMP_CPU_AFFINITYを適当にいじりつつ並列度12で実行してみた。
順番に、

export GOMP_CPU_AFFINITY="0-11"
export GOMP_CPU_AFFINITY="6-17"
export GOMP_CPU_AFFINITY="12-23"
export GOMP_CPU_AFFINITY="0-5 12-17"
export GOMP_CPU_AFFINITY="6-11 18-23"
export GOMP_CPU_AFFINITY="0-2 6-8 15-17 21-23"
export GOMP_CPU_AFFINITY="0-2 9-11 15-17 18-20"

と設定してみた。結果はこの通り:

まずABCはphysical idが違う6つずつ、各6つはcore idが違うものを選択。思った通りに前の実験の最速性能と同じくらいになった。
次にDEは意図的に同じphysical idのものばかり使ってみた。結果として前の実験の6コアと同じ性能のようなので、各物理コアに2スレッドずつ割り当たったように見える。
最後にFGは、physical id毎に6つずつ、physical id内ではcore idが重複しない範囲で適当に選んだ。最速性能と同じだった。


まぁこの実験結果で確実に網羅できたわけではないのだが、大体わかったと言って良さそうだ。前の方から使えば変にHTのお世話になることはないだろう。
あと気になるのはこのIDの並び方はどのレベルで決まっているのかと言うこと。再起動しても一緒なのか?とか、OS入れ直したら変わっちゃうのかな?とか、そういうところが気にはなるのだが、まぁまたやってみればわかるよね。



さて、確認ができた気がするところで、時間が時間だしもう寝ようかね。

劇場版はがれんネタバレ感想的な何か

この記事は外部の日記(ひびろぐ)からマルチポストしています。見た目がおかしいときは本家を参照してやってください。
本家→http://exth.net/~tgbt/wordpress/2011/07/04/3819/


初日朝一で友人と見てきたのだ。
せっかくだから、見て思ったことをテキトウに並べておくことにする。ネタバレ注意。

  • 固有名詞記憶能力の欠乏により、中盤まで勢力図が良くわかっていなかった。入れ替わりトリックがあったので余計に、か?ネタが明らかになるに従って理解が進んだのでヨシとする。
  • おまけ小冊子のスタッフコメント?にもあったけど、全体的に錬金術強すぎである。エンターテイメントとしては正解か。
  • 鉄道ェ……
  • 物理法則無視と言わざるを得ないアクションがたくさんで素敵。エド、君はジャンプ力いくつあるんだい?
  • コウモリどうやってとんでるんだよってのは聞いちゃいけないんだろうね。でも序盤の鉄道とりつきはどう考えても橋にぶつかると思うんだ。
  • ジュリア可愛いなあ。ハガレンの女衆はかっこかわいいから困る。覚醒後、なんだかデジャヴとは言わないけどなんか何かのキャラに通じるものを感じるなと思ったが、中の人が坂本真綾だから式とリンクしてたのかな……
  • レールガン(違)がなんで決め手になったのかわかっていない件について
  • 大佐出番なさ過ぎ可哀想に……
  • 正直言って、兄妹生存エンドは想定外だった。生きていて良かった良かった。
  • しかしこのあとまた戦乱になるのだろうか……
  • 中盤までのハガレンは賢者の石を探し求めることが主題だった。だから賢者の石を本当に見つけちゃうお話は作りにくい。でも後半のハガレンは、賢者の石はなんたるかを理解した上で、それを使わないことを誓った上で話が進んでいる。だから、逆に賢者の石を出しちゃうというお話の作り方ができたのかなー。とか思った。
  • ディスク化されたら購入して再度じっくり見たいなぁ。実は旧劇場版も持ってないのだが……
  • 私の裏の席に座っていた青年よ、3度くらい私の席を蹴った罪は重いぞ。赤い石の原料になるがよい!

svnからgitへ移行するためのメモ

この記事は外部の日記(ひびろぐ)からマルチポストしています。見た目がおかしいときは本家を参照してやってください。
本家→http://exth.net/~tgbt/wordpress/2011/04/28/3731/

      • -


中央集権リポジトリ(単一リポジトリ)だと夏の停電時にハマることになるんじゃないかという不安を解決するために分散リポジトリに手を出してみるテスト。……移行できるのか?


とりあえず、すごく良く使う基本的な作業のマッピングを考えてみることにする。
コミット時のコメント付加とかはとりあえず省略で……。

リポジトリ作成、作業開始(ローカルにリポジトリを置く想定)

cd
mkdir repos
cd repos
svnadmin create repo

~/repos/repoという名前のディレクトリが作られて、中に管理情報が格納される

cd
svn checkout file:///home/USERNAME/repos/repo ./svnwork

svnworkというディレクトリにリポジトリがチェックアウトされるので、中で作業をする。
svnworkの中には.svnディレクトリが作られる。.svnに格納されているのはリポジトリを参照するための情報。

  • git
cd
mkdir gitproj
cd gitproj
git init

いきなりinitして、その場で作業をすれば良い。.gitディレクトリが作られる。
.gitディレクトリはリポジトリその物の情報も持つようで、svnでいうと.svn+repoディレクトリそのものな感じ?

ファイル追加、変更、復旧

cd svnwork
echo "hoge" > test.txt
svn add test.txt
svn commit test.txt # test.txtを明示しなくても良い
echo "fuga" > test.txt
svn commit test.txt # test.txtを明示しなくても良い
echo "huga" > test.txt
svn revert test.txt # test.txtを明示しなくても良い

最終的にtest.txtの中身はfugaになる。

  • git
cd gitproj
echo "hoge" > test.txt
git add test.txt
git commit
echo "fuga" > test.txt
git add test.txt
git commit
echo "huga" > test.txt
git checkout test.txt

毎回addしなおすそうな。
revertに対応するのはcheckoutっぽい。

作業コピーを作成する

cd
mkdir svnwork2
cd svnwork2
svn checkout file:///home/USERNAME/repos/repo ./

指定するのはsvnadminで作成したディレクトリ。カレントディレクトリに.svnとtest.txtが出現。作られるのはあくまで作業コピー。

  • git
cd
mkdir gitwork2
cd gitwork2
git clone ../gitproj ./

cloneで指定するのは.gitがあるディレクトリ。もしくは.gitそのもの。カレントディレクトリに.svnとtest.txtが出現。作られるのはリポジトリのコピーなのでさらにこいつをcloneすることも可能。

作業コピー間の同期

そもそもrepos/repoが「大元」なので、こいつをcheckout/update/commitすれば衝突に気がつくし同期もとれる。逆に言えば、repos/repoにアクセスできなくなったらゲームオーバー。だから中央集権。

  • git

.gitが「大元」を兼ねているのでこいつらの同期をとる必要がある。そこが分散。

cd
mkdir gitbp.git
cd gitbp.git
git init --bare

「--bare」のオプションでベアプロジェクトを作る。gitbp.git以下には.gitだけが作られる。

cd
cd gitproj
git push /home/USERNAME/gitbp.git master

gitbp.gitにgitprojの情報が格納される。

cd
mkdir gitworkA
cd gitworkA
git clone /home/USERNAME/gitbp.git .

gitbp.gitのcloneを作成。test.txtも.gitも手に入った。

(gitworkAにいる)
echo "hogehoge" > test.txt
git add test.txt
git commit
git push

こちらでファイルを書き換えてadd/commitすればローカルDB(ローカルの.git内)が更新される。
その後、pushするとgitbp.gitへ更新情報が伝搬する。

cd
mkdir gitworkB
cd gitworkB
git clone /home/USERNAME/gitbp.git .

改めて別ディレクトリにcloneしてみるとtest.txtの中身はhogehogeに更新されている。
後はgitworkAとgitworkBでお互いにpull, add, commit, pushを繰り返せば良い。
衝突すれば例によってdiffられるので、修正してcommit。



うーん、とりあえずここまで理解すれば……いや、あっていれば作業に使えるかな。
あとはssh越しでやるのの確認か。今日はここまで!

GalaxyTab工場初期化についてのメモ

この記事は外部の日記(ひびろぐ)からマルチポストしています。見た目がおかしいときは本家を参照してやってください。
本家→http://exth.net/~tgbt/wordpress/2011/04/28/3728/

      • -


帰国後数日、どうにもこうにも動作が重すぎて使い物にならないという残念な状況に陥った。
症状としては、とにかく重い。マーケットを用いたアプリの更新もできない。ブラウザ開いてwebを閲覧するのも必死。これはもうダメかもわからんね。


というわけで(久々に)初期化してみた。

  • メニューから初期化的なものを選んだはずだがうまくいかず(それらしい反応がない)
  • 電源OFF
  • Home押しながら電源投入(他にもなんか押すんだっけ?)
  • メニューを選んで初期化

途中で画面になんか絵が出た状態で止まったのでヤベエと思ったけど、適当にキーを触ってたらうまくいった。ちょっとあせった。


初期化したのは良いのだが、アプリの復旧でちょっとハマった。
一応サードパーティーのバックアップアプリを使った記憶はあったのだが、いつ使ったっけ?とか思ったのと、新しくなったマーケットアプリはwebと連動したよなあということでアップデート待ち。2、3日待ってようやく更新された。されたのは良いのだが、どう見てもwebのクライアントからインストール済みアプリの一覧が見えない。それらしいメニューはあるのだが、明らかに数が足りない。使えない。


ダメだこれ……というわけでフォーラム内を検索してみたがやはりダメっぽいという結論に。おすすめのアプリとしてアプブレイン(appbrain)というのが紹介されていたので使用開始。本家マーケットのようにPCで処理したらそのまま端末にも反映というわけにはいかないが、webでアプリを管理するのに良いアプリだ。


そんなこんなで初期化後はクソ快適になりましたとさ。しばらくはこの端末で色々やっていけそうだ。NicoRoというニコニコ動画を見るアプリが便利過ぎてヤバい。やっぱりこのサイズのタブレットは良い。3インチ程度の軽量スマホ+7インチ程度の高機能タブレット+12〜13インチ程度のモバイルノートが最強コンボだな。あまり電話をしない自分的には前者2つを4〜5インチのスマホにまとめることも不可能ではないかも?


……それにしても、工場初期化のはずなのにr**t化が引き継がれた気がするのは気のせいだろうか……。

GalaxyTabで簡単Blu-ray動画再生 その2

マルチポスト元→http://exth.net/~tgbt/wordpress/2010/12/23/3506/


NANOHA 1stの再生ができるようになった!というか、適当にエンコードした!
楽をするために無駄な苦労を重ねたが、とりあえず簡単にやれるようになった気がする!


さて、NANOHAはUBWと違って音声トラックが複数有るため、mkvを適当にエンコすると音声が死んでしまう。悔しい!というわけで……
(音声トラック複数のMP4をギャラタブで(任意の音声トラックについて)再生できるとは思うんだけど、まぁ、わかんねーので諦め状態。)

mkvを映像と音声に分離する

tsMuxeRを使うと分離できる。NANOHAは2トラックあるので2つのdtsファイルが生成される。このファイルはVLCなんかで再生が可能。

音声と映像を合成し直す

何も考えずにaviutlに喰わせれば(映像を読み込んでから音声の追加読み込み)エンコードできる。
例によってdivxやらxvidやらを使えばギャラタブで快適に再生可能なファイルが作成可能……のはずだったが?

4GB?の壁

再合成し終わってギャラタブに転送……と思ったら、ファイルサイズが大きくて書き込めないと怒られる。もちろん、容量不足ではない。ディスクフォーマットの都合?

容量削減方法1

1トラック目の音声dtsファイル、よく見たら1GB越えてるんだぜ……というわけでdtsを変換しよう。(まぁ、6トラック分の音声があるんだからそりゃでかいわなー。)
NANOHAは1トラック目のみ5.1ch、2トラック目は2ch。1トラック目はともかくとして、2トラック目は普通のmp3あたりに変換してやれば、容量が削減される。1トラック目も、5.1chが維持できるかは別にしてmp3化しちゃえば楽々。

容量削減方法2

解決方法1では、5.1ch音声を再生してどんなもんか味わってみたい!という場合に困る。たぶん5.1ch音声をちゃんと圧縮する方法もあるとは思うんだけど、残念ながら私はよくわからない。
色々と悩んだんだけど、もうめんどくさい(うまく音声を5.1ch状態で圧縮できない)のでおとなしく映像のサイズを小さくした。いわゆる720なサイズにリサイズエンコード。3GBちょいに収まってくれたので、転送。あとは再生するだけ。

結果

結局解像度を落としちゃったけど、ギャラタブで垂れ流すにはまったく問題なし。xvidのデフォルト設定というていたらくだが、モバイル端末で垂れ流すには十分すぎる画質。何も問題を感じない。マジ幸せ。
というわけで、UBW共々、毎晩のように作業のお供になったのでした。まる。

GalaxyTabで簡単Blu-ray動画再生の巻

マルチポスト元→http://exth.net/~tgbt/wordpress/2010/12/10/3475/


なんか珍しくTwitterで☆が付いたりRTが付いたりしたっぽいので、簡単にまとめておくことにする。細かいことは書かないので、適当にぐぐれ。
微妙に間違っていることを書くかもしれないけど、ご容赦を。
あと、当然だけど自分が持っている映画でやろうね!ちゃんと買ってやろうね!!やくそくだよ!!!

はじめに

本家?webサイトを見ればわかるけど、この端末は結構多くの音声・動画形式に対応している。多分ハードウェアアクセラレータ……というか対応したチップが載っている(はず)。なので、ちっこいデバイスのくせに色々なモノが快適に再生できる……能力を持っている……は……ず……。

やってみよう

というわけで、試してみることにした。
手元にBlu-ray判のUnlimitedBladeWorksがあったので試してみた。
ランサーの「歳取って出直してこい」と終盤の斬り合い*2が燃えポイント!


Blu-rayリッピングの巻

まずはBlu-rayリッピング。makemkvってのを使うとmkv形式で吸い出せる。詳しくはググれ。
本編が26GBくらいになった。

適当にエンコードの巻

動画エンコ職人御用達?のaviutlでやってみた。詳しくはググれ……というか、適当にメジャーどころの入力フィルタを入れておけば良い。すると、aviutlでmkvファイルが読めるようになる。
mkvが読めるようになったら、いよいよエンコードエンコードは色々と高度なノウハウのある難しい作業だけど、今回はスーパー適当にやってみた。
色々なコーデックパックを適当に入れておいたらxvidが使えるようになっていたので、設定デフォルトでエンコードしてみた。多分中身はh263だと思う。1pass。流石に2時間くらい時間がかかったけど、放置しておいたらエンコ完了。26GBが3.7GBになった!

ぶっこんで再生の巻

USBでつないで、本体に転送してみた。microSDは1GBのを指していたので無理。
デフォルトの動画プレイヤで再生してみると……なんと、1920x1080のでかい動画のはずなのに、何の問題もなく再生できてしまった!(デフォルトの動画プレイヤが後から入れた何らかのアプリの影響を受けて拡張されている可能性についてはよくわからないので考えないことにする。)
なんかたまーにカクカクするっぽいけど、視聴に耐えないほどではないので無問題!!!(ガベコレの都合?システム的なプログラムの動作のタイミングの問題???)
流石にスピーカーがアレなのでちょっとアレだけど、まさか普通に再生できるとは……驚かざるを得ない。

NANOHA The MOVIE 1stでも試してみたよ!

NANOHAは音声チャンネルが複数あるので、tsMuxeRで吸い出してvlcとかで適当な形式に変換してからaviutlに喰わせる必要があるので注意が必要。
とかやってみたら、4GBオーバーになったので書き込めなかったよ!!! orz
ちと、後で音声圧縮かxvid設定変更か解像度下げで再チャレンジしてみるわ……。

結論

GalaxyTab神。

NAS不調

マルチポスト元→http://exth.net/~tgbt/wordpress/2010/10/02/3421/


「そんなNASで大丈夫か?」「一番いいのを……いや、やめておく(値段とか電力的な意味で)」


ここ数日、NASが不調である。具体的に言うと、「気がついたら死んでいる」。


ふと気がついたらVM上にあるWindowsの反応がおかしくなっていた。アプリケーションを切り替えると反応がない。あれー? とか思っていたら、メインPCからのNASへのアクセス(samba共有ディレクトリ)も途絶えてしまった。FreeNASを使っているのだが、webのGUIにもアクセスできない。PINGも通らない。
実機をいじってみようとしたら、キーボードに反応がない。何を押しても何も起きない。フリーズ状態。


再起動すると完全に復帰。特に問題は起きない。謎である。


2,3度繰り返していたら、なんかRAIDカードの反応が消えてしまった。と思ったら、次はBIOS画面すらでなかった。その後、時間がたってから電源を入れたら普通に電源が入ったのだが、その前にRAIDカードごと旧鯖に引っ越し、とりあえず運用中。
うーん、意味がわからない。ちとmemtestなどのテストをぶんまわしてみるかのう。NASが止まると色々と困る生活をしている……というか、忙しいときに限って止まるとか勘弁な。


とりあえず、写真とリポジトリはバックアップした。こいつらが死んだらマジ自殺モノだぜふーはははー!