UbuntuのGNOMEデスクトップの隠し設定が簡単にいじれるUbuntu Tweak(*1)というのを導入してみました。
インストールの仕方はこちら(*2)を参考。あいかわらずインストールしただけで、全然いじってないorz
*1 http://ubuntu-tweak.com/*2 http://linuxpoison.blogspot.com/
ねこさんのぐうたらなにちじょう
UbuntuのGNOMEデスクトップの隠し設定が簡単にいじれるUbuntu Tweak(*1)というのを導入してみました。
インストールの仕方はこちら(*2)を参考。あいかわらずインストールしただけで、全然いじってないorz
*1 http://ubuntu-tweak.com/以前にnumpy.fromfileを使ってファイルをseekしてからデータを読むことができない、などと書いてしまいましたが、できました orz
with open('foo.data','rb') as f:
f.seek(128)
data = numpy.fromfile(file=f, count=1, dtype=dt)
やっぱり勉強不足だ orz
会場内のO'Reillyブースでこの本を眺めていて、ProcessingのAlternativeとして以前から興味はあったけどPython使えなかったので今まで手を出せなかったNodeBoxですが、先週からPython頑張っているので今ならどうにかなるのではないかと思い、インストールしてみました。
と言っても、NodeBoxはOSX専用ですので、現在開発中のNodeBox/Qtを指示通りにインストール。Ubuntuでのインストールはこちらに詳しいです。
問題なく動きますが、持参したAtom Z550な機械ではちょっと厳しいかもしれません。
当日券があると聞いてさらに悩んだ末、夜2時位に就寝、5時過ぎに起きて、新幹線に乗ってはるばる秋葉原へ行きました。お陰で、ここの所溜まっていた寝不足が更に厳しいです。会場ではRed Bull飲み放題で、4本飲んでどうにか眠気をやり過ごしました。今まで飲んだことはなかったのですが、なかなかジャンクな飲み物ですね。
講演者は予想通り凄い人ばかりで、十分に刺激になりました。特に某M社元会長様は自分の夢の実現への意欲がとても漲っていました。自分は既にいい加減いい歳にもかかわらず惰眠を貪る生活に現を抜かして過ごしておりますが、やっぱり頑張らないとと思いました。
予想通り若い人ばかりでしたが、まぁ開き直るしかありません。明日も頑張ります。
RD-Z1で録画したデータの整理をしていたら「HDDの状態が複雑になりました」メッセージが orz
ちまちまとアナログ番組に使用しているから出るべくして出たと思うけど…この忙しいときに orz
f2pyを使ってPythonで使えるモジュールをFortran90で書いていたのですが、例えば、
subroutine foo(a,n) integer,intent(in),dimension(n) :: a integer,intent(in) :: nみたいなサブルーチンからf2pyでモジュールbarを作成して、
import bar a = numpy.array([1,2,3,4]) bar.foo(a,a.size)みたいに呼び出す所を間違えて"bar.foo(a)"としても、サブルーチン側にはちゃんと配列の大きさが渡っているのに気が付いて不思議に思っていました。
こちら(*1)を見てモジュールbarの__doc__を確認すると、
This module 'bar' is auto-generated with f2py (version:2_5972). Functions: foo(a,n=len(a))という風なインターフェースが作られていることが判ったのです。
ちょっと安心。
*1 Writing fast Fortran routines for Python基本的に引き籠り系のねこさんですが、最近は年に1回位は何かしらイベントを覗きに行って、元気な人から刺激を貰うように心掛けていまして、今年は頑張って(主に金銭面で。それと月曜の午前中にプレゼンがあるけど、まだ準備できてない…とか orz)みようかとこちらのイベントに行くか行かないかギリギリまで悩んだ末にポチッた所…クレジットカードの承認が何故か通らなくて、そのまま時間切れ orz
週末どうしようかなー orz
Core Duo 2GHzなPCにはSpazを入れてtwitterしていたのですが、Atom Z550なNote PCにはかなり重すぎです。で、どうしようかと思っていたのですが、試しにGwitter(寝ぼけてました orz)Gwibberを使ってみることにしました。
ちょっと使ってみた所では起動も軽くていい感じです。不安定みたいな事も書かれていますがどうでしょう?
こちら(*1)を見ながらMercurialのcgiインターフェースを用意したのですが、アクセスするURLにcgiファイル名が見えるのが微妙に気になっていました。
たまたまこちら(*2)をお見かけしたので試してみましたが、どうもうまく行きません。やけくそになりして、cgiファイルに追記する内容のうち、
os.environ['SCRIPT_NAME'] = os.getenv('SCRIPT_URL')[:-len(os.getenv('PATH_INFO' , ''))]にしたところうまく行きました(あたりまえ?)。
↓
os.environ['SCRIPT_NAME'] = 'cgiファイルのあるURL直書き'
前エントリでndarray使いながらPsyco使うと微妙…なんて書きましたが、良く良く見ると、ちゃんと処理速度上がってる!
…あれって思って、一番最初に書いた全然工夫してないコードにPsyco付けたらめちゃめちゃ処理速度高い! → さすがにそれは言い過ぎ(勘違い…システムサイズを間違えてた orz)でした。
もうこれでいいです。 → やっぱりf2pyで書いた方がそれなりには速いです。でも、今評価しているコードではPsycoだけでf2pyのコードと比べて0.7倍程度の処理速度でしたので、元がndarrayを使ったPythonコードだと思うと驚くほどに速いです。
Scipy.weaveやらF2Pyを使って計算の高速化を試みていましたが、モジュールによるJITコンパイラ実装であるPsyco(*1)を試してみました。
こちら(*2)にあります様に、psycoのimportとfull()メソッドの呼び出しだけで使える様です。ご利益の方ですが、importしているモジュール内のメソッドには反映されないので、ndarrayをコンテナに使っているプログラムでは効果は薄いですね。それでも30%以上は速くなりました。
*1 http://psyco.sourceforge.net/こちら(*1)で複数リポジトリへの対応の仕方を見つけたのでやってみた。
hgweb.cgiではなくてhgwebdir.cgiを使う、リポジトリの設定はhgweb.configに書く、などの他はこちら(*2, *3)と大体一緒。リポジトリを増やすときは、
大分イメージが掴めてきた。
*1 http://www.proton.jp/main/programming/mercurial.htmlScipy.weaveも良いけどFortranで計算した方が速かったりしないかな?という疑問を解決すべく、f2pyも使ってみました。
やっぱりそれなりに落とし穴がありまして、f90で書くときは変数宣言時の精度指定にkind(0d0)みたいな書き方をするとこけます(参考 *1) orz
あとintent(out)とか指定して、
[f77]Python側でfoo(x,y)と呼び出すと「引数が多すぎるで」と怒られます(参照 *2)。
subroutine foo(x,y)
real,intent(in) :: x
real,intent(out) :: y
y = 2d0 * x
end
[python]みたいに値を受け取らなければいけないようです。ちゃんとここいら(*3)を読んでからやるべきだったかも知れません。
y = foo(x)
肝心の計算速度ですが…ちょっと速くなりましたが、正直どっちでもいい感じです。
*1 http://cens.ioc.ee/projects/f2py2e/FAQ.htmlと言う訳(?)で、Mercurialを導入してみることにした。以前から興味はあったのだけど、一人でコード書いていてVersion Controlを使いたいと思うことが少なかったこともあって、マジメに使おうとは思っていなかった。
さくらを使っているので、情報がちょっと古いけどこちら(*1)とこちら(*2)とこちら(*3)を参考にインストール。
動作確認まではした…けど正直使い方がまだよく分かってない orz
*1 http://d.hatena.ne.jp/umezo/20080320/1206015911朝起きて評価し直してみたら、やっぱりweave使った方が速かった。システムサイズを大きくすると、オブジェクトやコンテナのコピーを避けて計算させるのはやっぱり難しい。
コードをブランチさせるかな、どうしよう。
ndarrayコンテナを添字付きアクセスするときはa[i,j,k]の様に書きます。a[i][j][k]でも動きますが、オーバヘッドが掛かります。とは言っても、添字付きアクセス自体が重すぎですので、なるべくは添字付きアクセスはしない方が良いです。
あと部分配列を取り出すのはa[i1:i2,j1:j2,k1:k2]の様に書きます。この場合、a[i1:i2][j1:j2][k1:k2]はまったくの間違いです。うろ覚えで書いていて、いろんな意味で時間を失いました orz
Scipy.weaveなど試してみたりしましたが、結局どういうふうに着地したか…と言いますと、実はインラインコードは採用しませんでした。何故ならば、ndarrayコンテナをうまく捏ねくり回して計算した方が速くて綺麗だったからです。インタプリタだと思って侮っていました。Python+ndarrayほんと良くできてます。
とにかくまずこのあたり(*1)を勉強した方が良さそうです。これら(*2)を勉強するのはもう少し後にすることにします。
*1 http://www.scipy.org/Tentative_NumPy_Tutorial仕事でPythonコードを書いているのですが、かなり大きなデータファイル(500GB)を読み込んで解析計算をすることが望まれていて、実際の所相当な処理能力を求められつつあります。今手元にある2時間+α程度で作成したコードでは現実的な時間で処理することが難しいと思われます。このコードの処理時間を測定して、どの処理がどれくらい遅いのかを明らかにしながらボトルネックの高速化を図る必要があります。で、コードのいろいろな部分の計測を行いまして、for文を使って繰り返し計算を行う所が遅いという知見が得られました。で、これをどうするかが次の問題です。
C++で書いたコードを呼び出すような力技でいくのは効果があるかもしれないけど、学習時間と手間がしんどいだろうなと想像していました所、Scipy.weaveのinlineメソッドというものがあることをこちら(*1)で知りました。うまくいけば手間が掛からずにC++コードをマージすることができるかも、という淡い期待を抱き試してみることにしました。
うまくは行きましたが、それなりに落とし穴はありました。まず、Blitz(以前仕事で使っていたので懐かしいです)を使おうとするとUbuntu 9.04デフォルトのg++-4.3ではコンパイルできません。こちら(*2)にありますようにg++-4.2を読み出すと動きます。とりあえずg++-4.2から/usr/local/bin/(PATHの順序が/usr/bin/より先)へリンクを張ることで対処しました。
結構戸惑ったのは、コンパイルに失敗したときのエラーメッセージがPythonのものとg++のが入り混じってメッセージの可読性が非常に悪い事です。これはもう、慎重に書くか少しずつ書き足していくか、別にC++のみでコードを書き、十分にバグ取りをしてから持ち込む等をしないうまく行かないように思います。長いC++コードを書ける気がしません。
詳しいことはこちら(*3)やこちら(*4)を参考にしました。
そうして書いたコードですが、確かに速くはなります。ですが、思った以上に呼び出しのオーバーヘッドが大きいようで、実行時間の短いコードを何度も呼び出すような使い方には向いていません。やはり実行時間の長いコードを丸投げするような使い方が良い様に思います。
*1 http://scipy.dip.jp/index.php?SciPy%2FWeave