[ruby-dev:34328] Re: ComplexFloat

むらたです．

2008/4/11 Yukihiro Matsumoto <[e-mail]>:
>  |だとすると，ふなばさんは私の提案の何に対して「いびつ」であると
>  |お感じになっているのでしょうか？そこがまだ理解できていないので
>  |教えてください．
>
>  「早すぎる最適化」を懸念しておられる気がします。私としては村
>  田さんの主眼が読み切れてないので保留します。
>
>   * 機能セット(C99 complex関数相当を提供する)
>   * 内部実装(C99 complexをオブジェクトに埋め込む)
>   * 効率(メモリ効率、計算効率)
>   * 拡張ライブラリの書きやすさ
>
>  の話が同時に出てくるので判断しがたいです。

私の主眼は，上記の4つ全て，および，ふなばさんの Complex
(コンテナとしての Complex) との共存をできる限り実現することです．

>  |少なくとも C99 の複素関数群をサポートするか否かは Ruby の数値系の
>  |方向性に大きく影響するはずです．そして，複素関数群をサポートする場合の
>  |実装方法として _Complex を持つかどうかという話になるわけですが，
>  |それは今迄の議論で十分話し合われていると思います．すなわち，
>  |Float を VALUE で持つ必要性は無いということです．
>
>  で見ると、「影響するはずです」までは機能セットの話、
>  「Complexを持つかどうかという話」は内部実装の話です。また、
>  ComplexFloatを導入するのであれば、そこで「FloatをVALUEで持つ
>  必要性は無い」のはその通りですが、Complexクラスしか導入しな
>  いという前提では逆に「Floatを特別扱いしてVALUEで持たない必要
>  性」はまだ結論が出ていない(個人的には消極的)です。

上記4項目について入り乱れていたことで分かりにくくなっているとしたら
申し分けありませんでした．

>  さて、個別の論点について整理しましょう。
>
>  まず、機能セットについては反対しません。また、その実装として
>  (あれば)C99 complexを経由するのもよいと思います。ただし、C99
>  を必須にするのは当面避けたいので、利用するにしても結局互換層
>  を用意する必要があると思います。

互換層は先日の patch に含んであるので，あれを利用できるはずです．

>  内部実装についてですが、以前いただいたパッチのように直接オブ
>  ジェクトに埋め込むのは全体のメモリ効率を低下させるので採用し
>  がたいです。

確かにそのとおりだと思います．私も RVALUE へ double _Complex を
埋め込む実装は取り下げます．その代わりとして，double _Complex*
を持たせる実装を提案したいです．実はそうする事で，複素数値の
メモリアライメントを調整できる可能性がでてきました．すると，
アーキテクチャによっては値のレジスタへの転送が高速化します．
(といってもこれは本当に些細な違いでしかありませんね)

>  独立したComplexFloat(あるいはFloatComplex?)クラ
>  スを採用すると決めるまではこれは保留するのがよいのではないか
>  と思います。個人的にはあまり独立したクラスを導入したくないで
>  すが。

ふなばさんの Complex は，成分クラス (Fixnum, Bignum, Rational, Float)
でメソッドが再定義されたときにその影響を被ります．これは，Complex が
コンテナとして実装されているからです．

それに対して，ComplexFloat (あるいは FloatComplex) を他のクラスの
メソッド再定義に影響されない系として導入できませんか？
つまり，コンテナではない複素数として存在してもらいたいのです．
同じ理由でコンテナではない Rational があっても良いと思います．
自分のクラスだけで閉じていれば YARV での最適化が可能です．

>  効率についてですが、メモリはできるだけ消費しない、速度は速い
>  に越したことはないですが、即値でない以上、限界があると思いま
>  す。

C99 の double _Complex を使う場合，値のロード・ストアおよび演算も含めて
コンパイラによる最適化を期待できます．C99 を使わずに double 2個の配列を
使う場合でも，アーキテクチャによっては SIMD 命令を使った最適化が可能です．

# まぁ，これも些細なことだと言われればそれまでですが．

>  また、Rubyから呼び出す以上、メソッド呼び出しのコストが大
>  きいので、事前の予測は困難ですからあまり急いで最適化について
>  考える必要はなさそうに思います。

これは上述したように，ComplexFloat (あるいは FloatComplex) を閉じた
演算系を持つコンテナではない複素数として実装すれば，
YARV による最適化を実現でき，Complex の実装のように，
rb_funcall を次々と呼び出す必要は無いので高速化が望めます．

また，ComplexFloat 同士の演算をまとめて最適化することも可能ですよね．
これも，やるとしたら YARV で実現することになります．

こういった将来的な最適化の可能性は利点と考えてよいと思うのですが
如何でしょうか．

>  最後に拡張ライブラリの書きやすさですが、C99を必須にできない
>  点などからある程度困難をともないますが、結局はCのcomplexを表
>  現するデータとRubyのオブジェクトを相互変換するAPIがあるかど
>  うかに帰結するように思います。これは内部実装をどのようにする
>  かとは独立の話です。

確かに API を用意することで拡張モジュールが作り易くなるという主張は
意味を持たなくなりますね．ただし，これは独自クラスを作らないという
前提での話しです．

田中さんのアドバイスで，独自クラスを作らなくても良いかなと思い初め，
それに対してまつもとさんも「落とし所が見つかった」と仰っていました．
しかしながら，私が欲しかった ComplexFloat はコンテナではない複素数，
つまり演算系が閉じている複素数なので，フラグで内部実装を切り替える
Complex の内部実装をフラグで切り替える形ではダメでした．


ところで，complex.rb が組込みになることで得られる利点は何ですか？
現在の complex.c の仕様なら Ruby でも実装できるし，むしろその方が
メンテナンスしやすいと思うのです．

私が欲しいコンテナではない複素数としての ComplexFloat が却下される
最大の理由は，既にふなばさんの Complex が組込まれていて，
それとの混乱が予想されるからですよね？

組込みにすることで演算等の最適化が望める ComplexFloat ではなく，
complex.rb の Complex を C に直訳して組込みにする理由が知りたいです．

同様の理由で，Rational についても，Fixnum と Bignum 以外を持つ事は
想定していない [ruby-dev:34317] のに，なぜ演算系が自分のクラスで
閉じてないのか気になります．その理由を教えていただけませんか？

# これらは，ふなばさんに質問すべきでしょうか？

よろしくお願いします．

-- 
Kenta Murata
OpenPGP FP = FA26 35D7 4F98 3498 0810 E0D5 F213 966F E9EB 0BCC