ささださん

堀之内です。

お返事とファイルのアップロード、有難うございました。

「Fixnum と同じ立場にした」ということはわかってましたが、
他言語との比較でどう位置づけられるかが、よくわかってません
でした（根本的な知識不足のため、今も分かってないですが.. ^^;)

これだけではなんですので...

利用場面の参考までということで、私自身のケース
についてお話しします。そもそもが多次元データを相手にすることが
多いため、多数の数値演算を行う場合は、基本的には
NArray でデータを持ってることが多いです。NArrayの配列演算で
すまなくて、ループをまわすのが多かれ少なかれ入ることは多く、
処理のボトルネックになったりします。そういう場合（あるいは
なりそうと最初から予想が付いている場合）、拡張ライブラリに
したりしてます。

＃ さらに脱線しますと、、、（すみません）
   NArray 自身の問題のひとつは、部分読み出しをしたい場合
   に、いちいちサブセットを本当に切り出したオブジェクトを
   作ってしまうということがあります。適当に処理を遅延して
   うまいこと無駄なことをしないようにしてくれるといいんです
   が...。

> Takeshi Horinouchi wrote:
> > だいぶ遅れたレスですみません。
> > 既にスライドを削除されたようなので、うろ覚えですが、
> > C の実行時間を 1 としたとき、 Ruby 1.9 は 12
> > ぐらいで、今回のが 6 ということで大変すばらしいと
> > 思います。でも Java は 3 でさらに速いですね。
> > 今回の改定ではいわば事実上組み込み型と同様に
> > したと考えてよろしいでしょうか。それですと、
> > ごく単純に考えると Java に近づいてもいい気がするの
> > ですが、違いがどういう原因によるものか、よろしければ
> > 教えてくださいませ。
> 
> 　64bit CPU 限定で、組み込みというか、Fixnum と同じ立場にしたという
> ところです。Java の primitive 型と違い、Object としての特性を残すた
> め、Java よりもオーバヘッドがかかっています。また、Java だと JIT コ
> ンパイラを持っているのが一般的ですので、やはりまだまだかないません。
> また、Java といっても volatile を付けた「不公平」な評価なので、あま
> り「Java の N 倍！」ということが明確になっている評価でもありません。
> 実用的なアプリケーションで比較する必要があるかと思います。
> 
> > あと、もしよろしければスライドをいただけましたら
> > 幸いです。（読んだとき保存しなかったので。）
> 
>   http://www.atdot.net/~ko1/pub/rubyfp.pdf
>   http://www.atdot.net/~ko1/pub/PPL2008-rubyfp.pdf
> 
> です。カメラレディと発表スライドになります。
> 
> -- 
> // SASADA Koichi at atdot dot net



--
ML: yarv-dev quickml.atdot.net
Info: http://www.atdot.net/~ko1/quickml/