トップページ⇒tech
1001コメント296KB

Rubyの実装に疑問あり!

■ このスレッドは過去ログ倉庫に格納されています
0001「真面目な」反対派(何が真面目なのか知らないが)NGNG
Rubyの実装は、バイトコード使用ではなく、
構文木をeval関数(巨大なswitch文)でたどっていく方法だが。
これでは速度的に不利だ。
また、そのせいで例外処理にsetjmpとlongjmpを使う風になっていて、
余計な負担がかかっている。
GCもスタックを勝手にサーチして「保守的ごみ集め」をやっているが
これも速度的に問題がある。
開発者のまつもと氏はいったいどう考えて作っているのか、
知りたいところだ、、、。
0002shigeNGNG
終了。
0003shigeNGNG
騙るな。
0004shigeNGNG
お前もな
0005shigeNGNG
Ruby逝ってよし!
0006shigeNGNG
HSP逝ってよし!
0007デフォルトの名無しさんNGNG
真面目な反論など不要!
0008shige ◆3MSu.p0M NGNG
俺が本物だ。
0009matzNGNG
至急削除依頼出してください。
0010デフォルトの名無しさんNGNG
Ruby VM は現在開発中ですよ。
0011デフォルトの名無しさんNGNG
珍しくまともなスレが出たと思ったのに……。
0012デフォルトの名無しさんNGNG
oremona
0013デフォルトの名無しさんNGNG
とりあえずsetjmpなのが嫌。
RubyVMに期待。
0014デフォルトの名無しさんNGNG
>1 キミ速いやつ作ってよ。
0015デフォルトの名無しさんNGNG
その名もTurboRuby!
0016デフォルトの名無しさんNGNG
みなさん大変です!!
Rub...えーとなんだったっけ?・・・が
この世から無くなります!!使っちゃダメですよ!気をつけて!
0017デフォルトの名無しさんNGNG
>15
じゃあオレはQuickRubyを……
0018デフォルトの名無しさんNGNG
Rubyを使うと次第に人間性が損なわれていきます。
それはここの板を見ればわかります。
悪魔の言語、Ruby.....
0019デフォルトの名無しさんNGNG
マイクロソフトはVMがないと動かせないような言語の
ブラウザサポートから撤退するそうです。
だからRub...えーとなんだったっけ?・・・は
あと3ヶ月で消えて無くなります。
0020デフォルトの名無しさんNGNG
Ruby1.6.5だが、
どーも、原因はgcc2.9くさいが、
(Laser5 Rel6.4)
elseifが正しく実行されない。
全部elseにいったりする。
他にちゃんとした実行ファイル作れない人いる?
0021仕様書無しさんNGNG
gcc++♪
gcc++♪
gcc++♪
gcc++♪
gcc++♪
gcc++♪
gcc++♪
gcc++♪
gcc++♪
gcc++♪
gcc++♪
gcc++♪
gcc++♪
gcc++♪
gcc++♪
gcc++♪
gcc++♪
gcc++♪
gcc++♪
gcc++♪
gcc++♪
gcc++♪
gcc++♪
gcc++♪
gcc++♪
0022デフォルトの名無しさんNGNG
>>21
いまどきC++かよ。
0023デフォルトの名無しさんNGNG
gcc++ ???
0024デフォルトの名無しさんNGNG
最近、ム板のレベルが加速度的に下がってるな。
0025デフォルトの名無しさんNGNG
ほー。そういう実装なんだぁ

バイトコードを使用したスクリプト言語ってどれくらいあるの?
知ってる人がいたら情報下さい。
0026デフォルトの名無しさんNGNG
>>1
実装が簡単だからそうしたんでしょ。
Python より多少遅い程度なんだからそう気にしてないけど。
実装は抜本的に直すことも可能だけど言語仕様はそうはいかないからね。
(ちょくちょく細かな手直しはされているが…)
VM 化と Generation GC で数割はパフォーマンスが良くなるだろう。
組み込みクラスも最適化すればばっちり。
後3年待て(w
0027デフォルトの名無しさんNGNG
Rubyの問題は、実装以前の問題です。
0028デフォルトの名無しさんNGNG
信者の問題です。
0029デフォルトの名無しさんNGNG
>>26
この業界で3年待つのか
0030デフォルトの名無しさんNGNG
>>1
拡張ライブラリをCで簡単に書けるようにでしょ。
0031デフォルトの名無しさんNGNG
>>30
つーか「拡張ライブラリをCで」書くという仕様?がある時点で
間違ってると思うが、どうよ?
0032デフォルトの名無しさんNGNG
>「拡張ライブラリをCで」書くという仕様?がある時点で間違ってる
んなこたない。
が、>30の言うことが本当だとしたら本末転倒もいいとこ。
因果関係がいまいちわからんが。
0033デフォルトの名無しさんNGNG
>>30
それって mark&sweep の conservative GC を採用してる以外にも?
0034デフォルトの名無しさんNGNG
GCするときに生成されたオブジェクトはどこかから参照さ
れている、ということをRubyは理解しなくてはいけない。
それを、スタックやらなにやらをトレースすることで調べ
ている。もしこれをRubyがやらないとすると拡張ライブラ
リを書く側が気にしなければならず今ほど簡単に拡張ライ
ブラリは書けなかったと思う。
と言ってはみたがそれほど理解している訳じゃないので
見当違いかもしれぬ。
また、仮に合ってるとしても、自分もこの方法はちょっ
と乱暴だとも思う。
0035 NGNG
35ゲットオォォォォ!!
 ̄ ̄ ̄ ̄ ̄∨ ̄ ̄ ̄       (´´
     ∧∧   )      (´⌒(´
  ⊂(゚Д゚⊂⌒`つ≡≡≡(´⌒;;;≡≡≡
        ̄ ̄  (´⌒(´⌒;;
      ズザーーーーーッ

ドッコイショ・・・・・・・・・
 ̄ ̄ ̄ ̄ ̄∨ ̄ ̄ ̄
     ∧∧          (´;;
    (゚Д゚ ,)⌒ヽ    (´⌒(´
     U‐U^(,,⊃'〜... (´⌒(´⌒;;

ヤレヤレ・・・ツギイクカ
 ̄ ̄ ̄ ̄ ̄∨ ̄ ̄ ̄
  ポ  ∧∧  ポ
  ン  (゚Д゚ ,) . ン
   (´;) U,U )〜 (;;).
(´)〜(⌒;;UU (´ )...〜⌒(`)
003630NGNG
ちなみに34も俺です。何か深く考えずに30書いちゃったけど
全然見当違いのような気がふつふつとしてきた。
あと、最初バイトコードにしなかったのはRubyは動的な部分
が多くて難しいと思ったんじゃないかな。
識者の意見が聞きたいのでageます。
0037デフォルトの名無しさんNGNG
とりあえず移植性の為に、一番単純でタコい方法で
書いてるんだと思う>GC
その結果、確かにたくさんのプラットフォームで
動いてるし。
あの程度なら(レジスタウィンドウとか無ければ)setjmpが
あれば移植出来るし、読めばすぐ理解出来るし。
ただ、例外関係は俺もバイトコードで例外テーブル
持つ方が良い、とは俺も思うなぁ。
そこらへんはどうなんだろう?
0038デフォルトの名無しさんNGNG
そういうコアな部分が全く分からない者としては、
ラフな案でもいいから ruby-dev にふってくれると嬉しいなと思ったりします。
0039デフォルトの名無しさんNGNG
高速化はRuby2.x.xでやるんだろ
0040デフォルトの名無しさんNGNG
構文木インタプリタにした理由は、
・作るのが楽だから
・コンパイル時間がかからないから(one-linerだと速い)
と思われる。

「動的だから」と言うのは良くわからん。

Smalltalkも実行時にmethod加えたり消したりできると思うが
最初からバイトコードだった。
0041デフォルトの名無しさんNGNG
まつもと氏はCプログラマとしては凄いんだろうが、
きっとRubyではCほどプログラム書いてないよね。

OOの熱心な信奉者という感じはしない。むしろあんまり
信頼してないんじゃないか。OO原理主義者ならもっと多く
の部分をRuby自身で書くだろうし。
0042デフォルトの名無しさんNGNG
まつもと氏はOOの熱心な信奉者だよ。
0043デフォルトの名無しさんNGNG
>>42
該当する ML のログか Changelog 分かる?
ざっと探したけど見つからなかった。。。
0044デフォルトの名無しさんNGNG
誤爆。。。
本スレの 283 へのレスだった。
0045デフォルトの名無しさんNGNG
全部見ろ。そしたら分かる。
0046デフォルトの名無しさんNGNG
>>42
じゃあ、なんでRubyの処理系はあんなにCマンセーなんだろ。
なんでパーザくらいRubyで書かないの?
0047デフォルトの名無しさんNGNG
>>46
cで書いてるのは移植性を考えてだろ。
パーザ?yaccのことか?
yaccで効率的なコードを生成できるんだから
わざわざRubyで書く必要なんてっこれっぽちも
無いと思うが?
0048デフォルトの名無しさんNGNG
>>43
例えば、Rubyを作った理由で、オブジェクト指向が
大きな理由になってる。
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-list/63
それ以前に、Rubyの仕様を見れば彼がオブジェクト指向に
なみなみならぬこだわりがあることはすぐにわかると思うけど。
0049デフォルトの名無しさんNGNG

* これからどうするのか

やりたいことは以下の通りです.

+ バグを減らす
+ 知名度をあげる
+ クラスライブラリを増やす
+ thread対応(難しそう…)
+ security強化(最近の流行?)
0050デフォルトの名無しさんNGNG
>>49
何を言いたくて引用したのかしらないけど、
それは6年近く前の発言だよ。
0051デフォルトの名無しさんNGNG
perl5も構文木上を直接実行していますがなにか?
0052デフォルトの名無しさんNGNG
>>1 で保守的なGCって書いてあるけど、conservativeじゃないGCってあるの?
0053デフォルトの名無しさんNGNG
RubyはCのライブラリなんだよ。
GCやマルチスレッドや例外処理があって移植性抜群のC言語処理系。
しかもこれで開発するとスクリプト言語のインタプリタが
おまけとしてついてくる。
0054デフォルトの名無しさんNGNG
>>52
JavaもLispもSmallTalkもconservativeなGCじゃないですが?
0055デフォルトの名無しさんNGNG
>>54
えっと、でも例えば世代GCなんかもconservativeだよね?
明らかに使われないとわかる部分についてだけ回収するという意味で。
自分の用語の理解が間違ってるのかな。。

classicalなGCって意味でconservativeってこと?
005654NGNG
>>55
すみません
発言に誇張がありました。
前述の各処理系でも保守的なGCを採用していることはありえます。
(ていうかSUNのJavaVMもそうらしい、、)

保守的というのは「疑わしきは開放せず」という処理方針の
GCの事です。
これはC言語に代表される
「メモリ上のデータがポインタなのかそうでないのか
厳密に決定できない」処理系では必須になります。
極端にいうとすべてのメモリデータをポインタとみなして
そこからポイントされている領域は使用中の「疑い」がある
として開放しないというものです。

しかし前述の処理系ではポインタと以外が厳密に決定可能なので
保守的でないGCも実装可能です。

しかし保守的なGCはコードが単純なのでメモリ効率よりも
速度を優先する場合はあえて保守的なGCを選択することもあるようです。
(たぶんJavaVMがそう)
0057デフォルトの名無しさんNGNG
>>55
そう言う意味ではほとんどのGCが保守的です。
わざわざconservative GCと言うときは、別の意味です。
「本当にGCで管理しているオブジェクトへのポインタか
どうか正確にわからないので、もしそうでなくても問題
が起きないようなGC」と言う意味です。

LispやSmalltalk,新し目のJavaの処理系は、conservative
GCではありません。GCが管理しているポインタか、そうでない
値(Cの整数とかスタック内にセーブされたPCとか)か、GCが
正確に区別できるようにしてあります。

conservativeでないGCを特に区別するときは、exactなGCとか
preciseなGCと呼ぶようです。
0058デフォルトの名無しさんNGNG
>>47
パーザがクラスとして使えないと、Rubyのプログラムを扱うツールや
プログラミング環境を作るときに、いちいちパーザを自分で書かなきゃ
いけない。あまりにもムダだと思うが。
0059デフォルトの名無しさんNGNG
>>58
そんなことする奴はいないのでOkOk
0060デフォルトの名無しさんNGNG
>>59
ML読むといっぱいいますけど...
0061デフォルトの名無しさんNGNG
>>57
解説ありがとうございます。
JAVAとかでそういうことしてたのですね。知らなかったです。
JAVAで、GCが管理しないポインタというものはどういうも
のがあるのでしょうか?
006261NGNG
 あるネストの中でしか使われないオブジェクトを、コンパイル段階で
静的解析によって求めて、スタックに入れるようにするとかいうことを
するのかな・・・
0063デフォルトの名無しさんNGNG
>>60
いっぱいいるようにみえるけど、実は数人しかいないのでOkOk
0064デフォルトの名無しさんNGNG
AthlonはRuby用に最適化されています
0065デフォルトの名無しさんNGNG
>>58
BNFで書かれたソースが公開されてるんだから、普通パーザ
書きたいなら、C言語でyacc使うんだろ。
そもそもクラスで公開するにしてもRubyで実装する必要は
無いだろ。
0066デフォルトの名無しさんNGNG
最近はパーザって言うのかい。パーサじゃなく。
0067デフォルトの名無しさんNGNG
両方の流儀があるようです。
東大流と京大流(嘘)
0068構文解析を速く、、、NGNG
自分はYACC嫌いなんだけど、Rubyを高速化するために、
書き直しているのなら、構文解析を再帰下向きとかの手書きのものにしてくれないかね。
どうせ、実行時も、動的評価で構文解析するんだろうし。
言語仕様も、もう固まってるんだろ、だいたい、、、。
とりあえず、みんな、あんまYACCに頼るなよ、
遅いんだから、、、。
0069デフォルトの名無しさんNGNG
>>68
再帰下降って速いんだ。知らんかった。
ただ、メンテナンス性は悪いよね。
0070デフォルトの名無しさんNGNG
yaccの出すパーザってグローバル変数つかいまくりじゃなかったっけ?
オブジェクトにできるの?
0071デフォルトの名無しさんNGNG
ぼくもyacc&lex(or bison&flex)はいやだな。
gccとかはそれで作られているけど、市販のコンパイラはどうなんだろ?
0072デフォルトの名無しさんNGNG
>>68
はぁ?LALR(1)のyaccが遅いわけねぇだろ。
>>70
簡単にできる。
いくらグローバル使おうが、extern宣言しない限り、
有効なのはそのソースファイル内だけ。
yaccが吐くのはパース部分だけだから、その部分だけ
オブジェクトに
まとめればよい。
0073デフォルトの名無しさんNGNG
Rubyの技術情報なり解説って、ネット上にあるのかな?
まつもとさんの本で簡単に実装が述べられていたけど。
0074デフォルトの名無しさんNGNG
むしろ、再帰下降の方がバックトラックで遅くなる。
文法を制限しても良いなら、バックトラック無しでできるが。
yaccは表駆動型だから最速のはず。
0075デフォルトの名無しさんNGNG
>>72
もう少し理論を勉強しなさい。
LALR(1)が速いわけねえだろ。
>>71
市販のコンパイラの多くは、「手書き」です。
0076デフォルトの名無しさんNGNG
>>75
速いだろ。
終端記号を認識して表と照らし合わせて遷移するだけ。
もしかして、LL文法と比べて遅いとかいいたいわけ?(w
0077デフォルトの名無しさんNGNG
LL(1)なんか使ってるようじゃ、Rubyの文法はとても
実装できんよ。
それとも、Rubyってそんなに単純な文法だったのか?(w
0078デフォルトの名無しさんNGNG
>>73
まつもと氏曰く、ソースがドキュメントらしいです。

実装について体系的に説明しようと試みているのはここくらいかな。
更新されてないから obsolete 気味だけど。
http://www9.xdsl.ne.jp/~aamine/ja/ruby/hack/
0079デフォルトの名無しさんNGNG
>>70
ソース読んでみようね。
>>75
強弁はやめましょうね。
でも、わたしもyaccに頼るのはあまり賛成しない。
(もっとも、ちゃんとしたコンパイラ屋さんは
全部自分で書いてしまうようですが、、、。)
0080デフォルトの名無しさんNGNG
みんなよく知ってるなぁ。
日曜プログラマのおれにとっちゃ、意味不明だよ。
0081デフォルトの名無しさんNGNG
でも、実際問題として、LR表作るのを手作業とかでやる
やついるの?
yaccの助けを借りるのが一番良いと思うが。
0082デフォルトの名無しさんNGNG
PerlもPythonもgccもyaccのようなツール使ってるけど。
市販の有名なやつは手書きじゃなくて、独自開発のツールなんじゃないの?
0083デフォルトの名無しさんNGNG
字句解析との兼ね合いじゃないの?
0084デフォルトの名無しさんNGNG
LAって何?ロス?じゃないよね
LRは?左右?
0085デフォルトの名無しさんNGNG
どうも、このスレは乱入しにくいね。
もっと、感情的になって、醜く争って!(from Ruby撲滅スレ)
プログラムのことなんてわかんねえよ!
アタマわりいんだよ!
0086デフォルトの名無しさんNGNG
>>80
安心してくれ。ほとんど一人で書いてる。(w
>>84
Look Ahead Left to Right
もしくは
Look Ahead Left-to-right Rightmost
0087デフォルトの名無しさんNGNG
市販のが lex & yacc 使わないのはライセンス問題からではなく?
0088デフォルトの名無しさんNGNG
>>72
>いくらグローバル使おうが、extern宣言しない限り、
>有効なのはそのソースファイル内だけ。

ほぉ?じゃあその方式で作られた「オブジェクト」を
同一プロセス上で二つnewしてみろよ?一発で破綻すること請け合い。

Objectとして使うってのは、そういうことです。
2ついっぺんに使いたい!とか、ね。

>>57
http://www9.xdsl.ne.jp/~aamine/ja/ruby/hack/gc.html
によると、
現状のrubyでも、或るポインタがObjectを指すものかどうか?を
厳密に判定するのに必要なコストは、かなり低く出来るような仕掛けが
既に有るように読めますね。

それはそうと、
バイト(など)コードのインタプリタでも、別に自由度は変わるまい。
javaが自由度低い言語であるのは別にバイトコードであるせいではない。

rubyのCライブラリのスタックの使い方をruby本体のソレと「同一」のものに
してしまう必要も必ずしも無いのだから、あまり本質には関係なかろう。
独自スタックにするという手もあるしね。
独自スタックにすると遅い、という意見も有るかもだが、
今みたいに生スタックをThread切り替えのときにいちいち積み直し
しているのと比べてもなお、遅いといえるかどうか。
0089デフォルトの名無しさんNGNG
>>84
構文解析の方法の一つです。
>>85
他はそんなに醜い争いなんですか?
0090デフォルトの名無しさんNGNG
>>89
プログラムと全く関係ないことで争っている。
小学生の喧嘩みたいで微笑ましく見えることもある :-p
0091デフォルトの名無しさんNGNG
>>90
つーか、プログラム読めも書けもしない消防ばっか。
0092デフォルトの名無しさんNGNG
>>80
っつーか、字句解析とか構文解析とかは情報系の学科にいけば必ずやる話題。
それなりの人数が毎年勉強してる内容。でも、本当にその知識を役立てることが
できるやつはそのうちのほんの一部。
ところで、そういう予備知識のないやつがHSPとか(以下自粛)
0093デフォルトの名無しさんNGNG
HSPは予備知識無しで作ってるから凄い。
0094デフォルトの名無しさんNGNG
>>92
某地方国立大学の情報学科出身ですが、
ここの言語処理系の授業は、ものすごく低レベルでした。
(BASICの「構文の研究」ですよ。授業中は市販のコンパイラ書籍を読み、あとは寝てました。)
院に行ってようやくまともな研究ができるありさまでした。
0095デフォルトの名無しさんNGNG
>>93
他人が一生懸命作った作品をけなすのはやめましょう。
ユーザーも少なくない処理系のようですし。
「君は何を作ったの、見せて」って言われますよ。
0096デフォルトの名無しさんNGNG
>>74
ついでに関数呼び出しのオーバーヘッドも馬鹿にならないね。
あの Ruby の parser.y から EBNF 書いてちまちま左再帰除去してやって
再帰下降パーサ書くのはちょっとやりたくない。
それより最適化の方が楽しそうだ。

>>94
(´-`).。oO(構文の研究って何だろう…)
(´-`).。oO(IF THEN ELSE は条件文ですなどというレベル何だろうか…)
(´-`).。oO(処理系の作り方はやらなかったの?)
0097デフォルトの名無しさんNGNG
>>1
Rubyやまつもとさんを批判するのはいっこうに構わないが、
君は何を作ったの?
RubyVMは現在開発中ですよ。
別に信者ではないけれど、Rubyは言語仕様も実装もよくできていると思うよ。
0098デフォルトの名無しさんNGNG
>ところで、そういう予備知識のないやつがHSPとか(以下自粛)
ニッチを満たしてしまったのだからしょうがない。
もう少し「言語」としてまともだったらと思うが、
今のままではユーザ層がピラミッド型にならずに台形になって先細りだと思う。
0099デフォルトの名無しさんNGNG
>>97
ML で VM に関する議論を全然見ないんだけど。
0100デフォルトの名無しさんNGNG
>>95
93は褒めてるのだと思われ。
0101デフォルトの名無しさんNGNG
本題に集中しよう。
■ このスレッドは過去ログ倉庫に格納されています