[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[dennou-ruby:003824] Re: [dennou-ruby:003821] Re: NArray-bigmem on ruby2.2.0 Re: Re: 大規模データ



堀之内様

openmp を使うかどうかのコンパイルオプションはコンパイラによって異なっています。
とりあえず gcc 用のオプションを入れておくというのはありだとは思いますが。

実行時の並列挙動についてですが、
OMP_NUM_THREADS が設定されていない場合は逐次実行、
設定されている場合はその数で並列実行するようになっています。

アプリケーションで指定したい場合は、
ENV["OMP_NUM_THREADS"]=?
とすればよいと考えています。
別の変数を用意しても結局 OMP_NUM_THREADS に入れるだけですので、
あまりメリットはないのではと思います。

最近まったく触っていないので、
ある程度時間がとれたら見直して整理します。

西澤誠也

On Wed Jan 21 2015 at 13:06:32 Takeshi Horinouchi <horinout@xxxxxxxxxxxxxxxxx> wrote:
西澤さま
(中野さんの1月7日のメールへの亀レスです。)

私も ruby 2.2 で narray-bigmem をビルドしてみました。
(今のところ openmp は使わない形で。-- 何も設定せずに
rake したら,コンパイルメッセージに無視するとでてました。)

> を動かしてできるMakefileでは、コンパイル、リンク時に-fopenmpがつかないので、
> CFLAGSとldflagsに書き加えてからmakeしました

手で CFLAGS 等を設定しないといけないのはどうかと思うので,
必要なくできないでしょうか。折角作ってくれた便利なもの
ですから,もうひと手間かけて使い勝手を上げていただけると
素晴らしいです(ありがたいです)。

# 依存ライブラリ(libgomp1 等)については,パッケージするときに
   然るべく記述すればいいので問題ないと思いますが

デフォルトで (依存ライブラリがあれば) openmp 対応でビルド
されるようにする一方で,とくになんの設定もしなければ
シングルで走る(並列化を意識しなければ並列化されない)ように
なってると良いだろうと思います。NArray は基本ライブラリで
広く使いますので,特定の数値モデルを走らせる場合
(その場合はふつう並列化の有無を意識する)とは想定を
変えるべきかと。並列化したいときだけ bigmem 版を使うので
なく,一旦 bigmem 版を入れればそればかり使うというのを
想定するということです。

上の話は,環境変数 OMP_NUM_THREADS が設定されてない場合に,
いきなり全コアを使うのは好ましくないだろうということですが,
さらに言うと,OMP_NUM_THREADS が設定されてさえいれば
自動的に並列化するのがいいかも微妙な気がします。
並列数の制御はアプリケーション側でするのを基本にして,
環境変数は使っていい上限を指定するぐらいの位置づけがよさそう
に思えます(OMP_NUM_THREADS が設定されなれば上限=システム
上の最大数)。どうでしょう?

よろしくお願いします。

> 中野です。
>
> ちょっと古いメールですが、
> debian wheezyで
> narray-bigmemとruby-netcdfをruby2.2.0で試してみました。
> gcc はversion 4.7.2
> 結果、ruby-netcdfのテストがとおりませんでした。
> なかを見てみようかと思いましたが、ちょっと時間がなさそうなので丸投げです。
>
> 以下作業メモです。
> 年末に堀之内さんに会ったときに、
> narray-bigmemで並列にならないといわれたような気がしますが
> ちょっと小細工しないと並列にならないです。
>
> openmp対応するために
> libgomp1というパッケージをいれました。
> また
> ruby extconf.rb
> を動かしてできるMakefileでは、コンパイル、リンク時に-fopenmpがつかないので、
> CFLAGSとldflagsに書き加えてからmakeしました
> 1000x1000x300とかのNArrayを2つ適当に作って延々と足し算するテストをやって見ましたが
> 複数スレッドで何かしら計算できているようです。
>
> 引き続きruby-netcdfも試して見ました。
> 西沢さんのパッチをあてて
> 高麗さんの情報をたよりに
> NArray.constants.include?("SUPPORT_BIGMEM")を
> NArray.constants.include?("SUPPORT_BIGMEM") ||
> NArray.constants.include?(:SUPPORT_BIGMEM)
> にしてmakeして、インストールまではOKでした。
>
> ruby-netcdfに付いているtest.tbを動かして見ましたが、
> netcdf.rbの1行目のエンコーディング(iso-2022-7bit)が気に入らないと怒られました。
> nkfでeucにしてeuc-jpに書き換えたところ先に進みましたが
>
> creating test.nc...
> /home/masuo/cc-env/lib/ruby/site_ruby/2.2.0/numru/netcdf.rb:130:in
> `put_attraw': Unrecognized NArray type (ArgumentError)
> from /home/masuo/cc-env/lib/ruby/site_ruby/2.2.0/numru/netcdf.rb:130:in
> `put_att'
> from test.rb:19:in `<main>'
> といわれ、テストを通っていません。
> オリジナルのNArrayではテスト通ったのでbigmem版だけの問題のようです。
>
> どうぞよろしくお願いいたします。
>
> 中野満寿男
>
>
>
>
>
> 2014年10月30日 9:52 Seiya Nishizawa <seiya@xxxxxxxxxxxxxx>:
> > 竹広様
> >
> > 3/18 日に 本MLに送った
> > narray-bigmem (narray plus over 2GB memory handling and thread
> > parallel processing)
> > というメールにあるように、2GB越え用の narray があります。
> > https://github.com/seiya/narray-bigmem
> > これを使うために、上記メールに添付されているパッチが必要です。
> > あと、東大の高麗さんから以下の変更が必要との指摘もいただいています
> >
> > # gmail でおくると送られてきたメールが見えないので、スレッド番号が分かりません。すいません。
> > # あと、 dennou-ruby ML の web アーカイブが 2014 はつくられていないんですね。
> >
> >
> > ---  高麗さんのメールここから (勝手に転記してすいません > 高麗様)
> > ○ ruby-netcdf-*.*.*/lib/netcdf.rb と ruby-dcl-*.*.*/lib/dcl.rb
> > 頭の部分で NArray か NArray-bigmem かを判定している箇所がありますが、
> > 例:NArray.constants.include?("SUPPORT_BIGMEM")
> > Ruby-1.9以上では、メソッド名がシンボルになっており、
> > 上手く動作しませんでした。
> >
> > NArray.constants.include?("SUPPORT_BIGMEM")
> > を
> > NArray.constants.map{|t|t.to_s}.include?("SUPPORT_BIGMEM")
> > として回避しました。
> >
> > # あと、場合分けを行って、エラーメッセージが出るようになっていますが、
> > # 順番が逆のような気がします
> >
> > ○ ruby-dcl で NumRu::DCL::SUPPORT_BIGMEM が定義されていない
> > ruby-netcdfのパッチでは、同様のものが定義されていたので、
> > それを参考に、init.c.default 内で定義しました。
> >
> > --- /home/kohmasa/usr/src/ruby-dcl-1.7.0/init.c.default
> > +++ /home/kohmasa/usr/src/ruby-dcl-1.7.0_bigmem/init.c.default
> > @@ -1,6 +1,7 @@
> >  #include <stdio.h>
> >  #include "ruby.h"
> >  #include "libtinyf2c.h"
> > +#include "narray.h"
> >
> >  /* for compatibility with ruby 1.6 */
> >  #ifndef RARRAY_PTR
> > @@ -124,6 +125,12 @@
> >      mDCL = rb_define_module_under(mNumRu, "DCL");
> >      rb_define_const(mDCL, "DCLVERSION", rb_str_new2(DCLVersion));
> >
> > +#ifdef NARRAY_BIGMEM
> > +    rb_define_const(mDCL, "SUPPORT_BIGMEM", Qtrue);
> > +#else
> > +    rb_define_const(mDCL, "SUPPORT_BIGMEM", Qfalse);
> > +#endif
> > +
> >      init_grph1_csgi(mDCL);
> >      init_grph1_scpack(mDCL);
> >      init_grph1_sgpack(mDCL);
> >
> > 以上です。
> > --- 高麗さんのメールここまで
> >
> >
> > 西澤誠也
> >
> > 2014年10月30日 6:54 Shin-ichi Takehiro <takepiro@xxxxxxxxxxxxxx>:
> >> 竹広です.
> >>
> >> 諸事情で倍精度 1024^3 程度の大きさのデータを扱わねば
> >> ならなくなりました. 当然ながら読み込んだ配列は
> >> GPhys/NArray の 2GB の限界を越えてしまい, 何かしら
> >> ロードするタイミングでエラーが出てしまいます.
> >>
> >> 2 GB っていまどきデータ解析としては厳しいような気がしますが,
> >> 皆さんどう対処されているのでしょう? チュートリアルに出ていた
> >> 座標変数をループで回して, といったことはあまりやりたくないです.
> >> 識者のご意見お聞かせ下さい.
> >>
> >>                     Takepiro(竹広真一)@数理解析研究所. 京都大学
> >>                         E-mail:takepiro@xxxxxxxxxxxxxx
> >>                                takepiro@xxxxxxxxxxxxxxxxxxxx
> >>
> >>
> >>
> >
> >
> >
> > --
> > Seiya Nishizawa
> > RIKEN Advanced Institute for Computational Science
> > Tel: +81-78-940-5754, Fax: +81-78-304-4972
> > 7-1-26, Minatojima-minami-machi, Chuo-ku, Kobe, Hyogo 650-0047, Japan
> >
> >
>
>
>
> --
> Masuo NAKANO, Ph.D.
> Dept. Seamless Environmental Prediction Research, JAMSTEC
> 3173-25 Showa-machi, Kanazawa-ku
> Yokohama, 236-0001, JAPAN
> TEL: +81-45-778-5616
>

堀之内 武
北海道大学 地球環境科学研究院 地球圏科学部門
〒060-0810 札幌市北区北10条西5丁目