新しいホストはコアが12あるのでさすがに何か工夫したほうがいいだろうという気持ちになって gnu parallel を使ってみた
コマンドの書式がいにしえの黒魔術のかおりがあり,ドキュメントを読んでもよくわからないわけですが(以前はそれで挫折した), 気合で解読した結果,たとえばフォルダにある全データファイルを処理したい,というようなケースは
parallel hoge ::: *
でいいみたいです.たったこんだけで適宜コア数に応じて並列化してくれます.
parallel convert {} -resize 1340x1340 s/{} ::: *
これは convert で多数の画像をサイズ変換しています. この場合はグニャとニャグが無名変数的に引数を保持しています.サイズを変更したファイルを s/ 以下にセーブしているわけです.
おかげでcpuメータが多様な愛の形みたいな色彩になりました(その後モノクロ濃淡のみにしました).
まあI/Oやネットワークが律速になってる場合なども多く,結局そういうケースは当たり前ですが順番待ちになります.
あと,調子にのって多数のjobを生成するとメモリが足りなくなりむしろクソ遅くなります.このへんはコマンドあるいは config でオプションがあります(後述).単にコマンドの尻に & つけとくよりは,ずっとうまいぐあいによきにはからってやってくれます.既定値ではコア数分のジョブを生成するので,搭載メモリをコア数で割った値が,ジョブ一個の空間計算量より小さい場合に注意が必要です.
どうもコマンドの書式がパールぽいなと思ったらパールでした.
そんなわけで,ストレージがnvmeになった事もあり古いホストで一ヶ月とかかかってた処理が今は半日で終わります.すげぇ
メモリ使い切る件は,オプション --memfree というのをつけとけば大丈夫ぽいです. このオプションで指定した値よりも残りメモリが少ない場合は新たなジョブを生成しないでやってくれます.ただし,このオプションの値を選ぶのは難しい場合があり,一個あたりのジョブがどれくらいメモリが必要になるかを読みきる必要があるのです.
たとえば 10G をこのオプションで指定して,残り20Gあいてるから新しいジョブを作って,それが育って50Gになってはみ出す,ということはありえるわけです.アルゴリズムとデータ量から必要な空間計算量とその分布をだいたい評価したり,順番をいれかえてうまく混ぜるなどの工夫が必要な場合もあるかもです.
多分ruby で fft というと今も ruby-fftw3 だと思うのでメモがわりに
gem install narray; gem install ruby-fftw3 で必要なものは全部入ります.先に require 'narray' しないと require 'numru/fftw3' が動きません.
関数解析ウォー
何か生産的な話っていうわけでもないのですが,漠然と最近思ったことをメモ代わりに書いときます.
指数関数って微分(当然積分も)しても同じく指数関数のままじゃないですか.加速度的に単調増加している関数は(たとえばプロットすると)お互い,一見似ているんだけど,こういう性質を持っているのは指数関数だけです.
つまり指数関数の集合というものを考えた場合,微分とか積分とかの操作でこの集合は変化しないわけですよ.こういう関数って当然指数関数だけなんだけど,似た性質の関数なら他にもありますよ.
そうです.三角関数です.こいつは,微分すると \(\sin\) が \(\cos\) に, (あるいは位相が\(\frac{\pi}{2}\) ずれながら)互いに移り変わる関係です.位相がずれたこれら三角関数のクラスを考えると,同じクラスのメンバから出発して微分あるいは積分で同じクラスに戻ってくるので,微分積分でクラス全体は変化しない.つまりこの関数族も不動点です.
そこで俺はこう考えたんだ.いままでは実関数の話だった.そこでもし,話を複素関数に拡張したらどうなるか?
ということで手始めに指数の巾を虚数にしてみた
$$ \frac{d^2e^{ix}}{dx^2}=-e^{ix} $$そしたら2回微分して符号が反転する関数ができるわけじゃよ.でもちょっと待て.それって三角関数族の性質でしたよね?
$$ \frac{d^2\sin(x)}{dx^2}=-\sin(x) $$ほらね.
どういうこと?ひょっとして,これって有名なあの定理そのものなのでは?
$$e^{ix}=\cos(x)+i\sin(x)$$実数関数族で微分作用素の不動点になっているこの一見すると全く関係ない二つの関数クラスは,じつは複素関数の世界では包含関係にあり,そのつながりを表現しているのがこの有名な式だったということです.こうなってくると忘れたくても忘れられない味わいが出てきます.
まぁこの先にもいろいろテクニカルで味わい深い話があるわけですが(たとえばこの記事の方針に沿って定理が証明できます),そういうのは俺よりもっとできる人が居るのでそちらにお任せすることにしましょう.この記事はここで終わりです.
当時,関数空間という考え方が今のように整備されていたわけではないので,これ無しでやっていったレオンハルト・オイラー,さすがの凄腕である. まさにおそるべしというしかない.また,現代数学が備えている抽象化手法の有用さもこれとは違った意味で素晴らしいものですね.