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

[Takeshi Horinouchi <horinout@xxxxxxxxxxxxxxxxx>]

堀之内です。

> 現在開発中の版が同じく "NArray" を名乗るかどうかは定かではない状態で，本
> 家と同じ名前のまま派生版を作成し，将来的にこれに依存する形にする(本家に
> 追従しない)，というならば，やはり名前を変更すべきだと思います．

この件，考えてみました。
他の電脳 ruby 製品と同じように NumRu の傘をかぶせるとよいだろう
というのが，今のところベストな解です。どうですか？ ＞ 西澤さん。

もともと NumRu の傘は，名前空間を保護して，将来クラス名に
バッティングがある有用なライブラリが出てきても
問題が起こらない（共存させられる）ようにするというのが
最大の意図でした。

パッケージ名は numru-narray (または numru_narray) とする
（numru-narray-bigmem としない）。クラス名は NumRu::NArray
(module NumRu の中で定義する)，ロードは require "numru/narray" 。

こうすれば，本家と共存できます（仕様変更されても）。一つの
プログラムの中で両方使うことすら可能です（しないほうがいい
ですが）。include NumRu すれば今までと同じ名前で使えます
（するかどうかはユーザー次第で，NumRu を使わない人には
迷惑がかからない）。他の電脳 Ruby ライブラリと合うようになり
ますし，新しい名前を考えなくていい。既存のプログラムの改修は，
電脳 Ruby ライブラリ内では require "narray"  を 
require "numru/narray" に変えることだけです。アプリケーション
においては，それに加えて必要に応じて include NumRu 等をするこ
とが加わります。この程度の改修コストで，トップレベルの NArray
が将来どう展開してもよくなるなら，結構なことではないかと思います。

なお，このようにするなら NArrayMiss も NumRu の下に入れましょう。

＃ ちなみに，require "narray" と require "numru/narray" を
   両方したら，module NumRu の中では NArray といえば
   NumRu::NArray のことになり，外ではトップレベルの NArray
   と，ややしいことになます。

＃ 佐々木さん，どうもありがとう。ルーズなので言われないと考えなかっ
   たと思います。

> 佐々木です．
> 
> At Thu, 22 Jan 2015 18:09:35 +0900,
> Takeshi Horinouchi <horinout@xxxxxxxxxxxxxxxxx> wrote:
> >
> > > 本家はもうこれ以上アップデートしないと宣言されているので、取り込んで
> > > もらうのは大変かと思います(今回限りであればよいと思いますが、変更が
> > > ある度にお願いするのは双方の負担だと思います)。
> >
> > そうかも。
> 
> 現在開発中の版が同じく "NArray" を名乗るかどうかは定かではない状態で，本
> 家と同じ名前のまま派生版を作成し，将来的にこれに依存する形にする(本家に
> 追従しない)，というならば，やはり名前を変更すべきだと思います．
> 
> > 旧版のメンテは引き継ぐみたいな形に実質できればいいんですが...。
> 
> 「旧版のメンテ」を引き継ぐためにもフォークして名前変えるべきです．
> 同じ名前で旧版をメンテするのは混乱の元です．
> 
> At Thu, 22 Jan 2015 18:09:35 +0900,
> Takeshi Horinouchi <horinout@xxxxxxxxxxxxxxxxx> wrote:
> >
> > 早速の改訂をありがとうございました。
> >
> > > ruby-netcdf, ruby-dcl のパッチをリポジトリに入れました。
> >
> > ruby-netcdf のほうはもうすぐ対応版をリリースするので
> > 不要だと思います（対応漏れが多々ありますし）。
> >
> > > int64 のサポートは必須なので、 typecode がずれる問題はとりあえずそのままです。
> >
> > まあ，仕方ないか...
> >
> > > 本家はもうこれ以上アップデートしないと宣言されているので、
> > > 取り込んでもらうのは大変かと思います(今回限りであればよいと思いますが、変更がある度にお願いするのは双方の負担だと思います)。
> >
> > そうかも。
> >
> > 旧版のメンテは引き継ぐみたいな形に実質できればいいんですが...。
> >
> > > 西澤です
> > >
> > > "int{16|32|64}" は "sint", "int", "long" に変更してコミットしました。
> > > gcc の場合はデフォルトで openmp が有効になるようにしました。
> > >
> > > ruby-netcdf, ruby-dcl のパッチをリポジトリに入れました。
> > > 高麗さんの指摘を取り込み、また、いくつかバグがあったので修正しています。
> > >
> > > int64 のサポートは必須なので、 typecode がずれる問題はとりあえずそのままです。
> > >
> > > 本家はもうこれ以上アップデートしないと宣言されているので、
> > > 取り込んでもらうのは大変かと思います(今回限りであればよいと思いますが、変更がある度にお願いするのは双方の負担だと思います)。
> > >
> > >
> > > 西澤誠也
> > >
> > >
> > > 2015年1月22日 16:04 Takeshi Horinouchi <horinout@xxxxxxxxxxxxxxxxx>:
> > > > 西澤さま：
> > > >
> > > > narray-bigmem の改訂依頼です。整数要素の型の名前を "sint", "int"
> > > > から，"int16", "int32" に変えてますが（narray.c l.47-48），振る舞い
> > > > の互換性がなくなるので，もとに戻して貰えないでしょうか（int16 など
> > > > のほうがわかり易いの確かですが，互換性のほうを優先してほしいです）。
> > > >
> > > > bigmem では，新たに 64-bit 整数もサポートしましたね。こちらは
> > > > "int64" になってますが，今までの命名法にあわせるなら "long"
> > > > ですね。
> > > >
> > > > ただ，64-bit をサポートすることで typecode がずれるのが
> > > > どうかなと思ってます。coerce の関係上，最後にもっていく
> > > > ことはできないですしね。
> > > >
> > > > dcmodel ミーティングで narray-bigmem の話題になったのですが，
> > > > 本家 （NArray 「旧バージョン」）のほうに取り込んでくれるよう
> > > > 働きかけてみるのはどうでしょう。
> > > >
> > > > 堀之内
> > > >
> > > >> 西澤さま：
> > > >>
> > > >> さっそく有難うございます。
> > > >>
> > > >> > openmp を使うかどうかのコンパイルオプションはコンパイラによって異なっています。
> > > >> > とりあえず gcc 用のオプションを入れておくというのはありだとは思いますが。
> > > >>
> > > >> そいつが configure されるようになると嬉しいです。
> > > >> （どうすればいいかわかりませんが，
> > > >> どこかにサンプルがあったりしないですかね。）
> > > >>
> > > >> > 実行時の並列挙動についてですが、
> > > >> > OMP_NUM_THREADS が設定されていない場合は逐次実行、
> > > >> > 設定されている場合はその数で並列実行するようになっています。
> > > >>
> > > >> ちゃんと望ましい（と私が思った）ようになってるんですね。
> > > >>
> > > >> narray-bigmem にはもともとの NArray の README 等があるだけ
> > > >> なので，本家から何を変えたかとか，どうやって使うものかという
> > > >> 説明がまったくないようです。README_bigmem みたいな
> > > >> ファイルを作って，基本的なことを簡単に書き（配列サイズを
> > > >> 64-bit変数で持つようにして 2GB の壁をなくしたとか，配列演算
> > > >> でスレッド並列を可能にしたとか），
> > > >> 並列化のコンパイルや実行法についても簡単に書いてもらえると
> > > >> いいと思います。（さらに，それが github のページで目立つ
> > > >> ようにする。中身を張り付けるとか。）
> > > >> configure 未対応でも，例えば gcc ならこう
> > > >> やってビルドしてねという情報があるとありがたいです。
> > > >>
> > > >> > アプリケーションで指定したい場合は、
> > > >> > ENV["OMP_NUM_THREADS"]=?
> > > >> > とすればよいと考えています。
> > > >> > 別の変数を用意しても結局 OMP_NUM_THREADS に入れるだけですので、
> > > >> > あまりメリットはないのではと思います。
> > > >>
> > > >> なるほど。（それも上記 README に書いてあると嬉しいです。）
> > > >>
> > > >> 堀之内
> > > >>
> > > >>
> > > >> > 最近まったく触っていないので、
> > > >> > ある程度時間がとれたら見直して整理します。
> > > >> >
> > > >> > 西澤誠也
> > > >> >
> > > >> > On Wed Jan 21 2015 at 13:06:32 Takeshi Horinouchi <
> > > >> > horinout@xxxxxxxxxxxxxxxxx> wrote:
> > > >> >
> > > >> > > 西澤さま
> > > >> > > （中野さんの１月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を２つ適当に作って延々と足し算するテストをやって見ましたが
> > > >> > > > 複数スレッドで何かしら計算できているようです。
> > > >> > > >
> > > >> > > > 引き続き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の１行目のエンコーディング(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 っていまどきデータ解析としては厳しいような気がしますが,
> > > >> > > > >> 皆さんどう対処されているのでしょう? チュートリアルに出ていた
> > > >> > > > >> 座標変数をループで回して, といったことはあまりやりたくないです.
> > > >> > > > >> 識者のご意見お聞かせ下さい.
> > > >> > > > >>
> 
> ---
> Youhei SASAKI, Ph.D.
> Department of Mathematics, Kyoto University
> Kitashirakawa Oiwake-chou, Sakyou-ku, Kyoto, 606-8502 JAPAN
> E-mail: <uwabami@xxxxxxxxxxxxxx>
>         <uwabami@xxxxxxxxxxxxxxxxxx>
> TEL:+81-(0)75-753-3731(direct)  FAX:+81-(0)75-753-3711
> GPG fingerprint:
>   4096/RSA: 66A4 EA70 4FE2 4055 8D6A C2E6 9394 F354 891D 7E07

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