[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 2chのread.cgiへ]
Update time : 10/19 19:42 / Filesize : 260 KB / Number-of Response : 1002
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

「コンパイラ・スクリプトエンジン」相談室13



1 名前:デフォルトの名無しさん mailto:sage [2009/01/28(水) 20:49:02 ]
プログラミング言語処理系の開発に興味のある人達のスレッドです。

字句解析・構文解析から,データフロー解析,ループ並列化,データ分散,SSA変換,
CPS変換,レジスタ割付,命令スケジューリング,ソフトウェアパイプライン,
SIMD命令生成,VLIW向けクラスタリング,スクラッチメモリ向け最適化,リンク時最適化,
JIT,動的バイナリ変換等の各種最適化,それにVM,GC,低消費電力化などなど。
意味論に関する話題も歓迎です。

過去スレ
1 pc.2ch.net/tech/kako/981/981672957.html
2 pc2.2ch.net/test/read.cgi/tech/1021136715/
3 pc5.2ch.net/test/read.cgi/tech/1070089173/
4 pc5.2ch.net/test/read.cgi/tech/1100097050/
5 pc8.2ch.net/test/read.cgi/tech/1106129164/
6 pc8.2ch.net/test/read.cgi/tech/1115335709/
7 pc8.2ch.net/test/read.cgi/tech/1129287390/
8 pc8.2ch.net/test/read.cgi/tech/1131273918/
9 pc8.2ch.net/test/read.cgi/tech/1135082582/
10 pc8.2ch.net/test/read.cgi/tech/1146844753/
11 pc11.2ch.net/test/read.cgi/tech/1160879890/
12 pc11.2ch.net/test/read.cgi/tech/1188688416/
関連リンクは多分 >>2-10 あたり

363 名前:345 mailto:sage [2009/08/15(土) 00:07:23 ]
スクリプトエンジンのスレだから、
「組み込み用途における技術的観点での比較」に絞ってレスする。
宗教戦争を煽る気はない。

>>346
>あまりその辺の分野は活発ではないような気がする。

Rubyは組み込みの実績が少ないし活動が活発ではないという理由かな。
それは技術的な理由からは外れている気がする。そうなった理由(背景)がこのスレの主題。

>>349
>そのせいで、パーサとVMが独立できないので、言語まるごと組み込む必要が
>あるのが大変なんじゃないかと。

Rubyが言語まるごと(パーザ+VM)組み込む必要があるのは事実。
ただし、個人的な感覚として、アプリケーションにスクリプトを組み込む目的の多くは、
ユーザによるアプリケーション機能の自由な拡張(スクリプティング)なのだから、
まるごと実装は欠点にはならないと思う。(JavaVMのようなコンパイラ系は別)

(長いので続く)

364 名前:345 mailto:sage [2009/08/15(土) 00:10:47 ]
(>>363の続き)

>>355
>まず指摘されてたけど、メモリ管理の点で、1.8時代はネイティブスレッドとは
>破滅的に相性が悪かったし、

Rubyとネイティブスレッドとの破滅的な相性の悪さは事実なので同意。
ただし、多くのアプリケーションでは、ネイティブスレッドが前提とはならない
(あるいはRubyの疑似スレッドでもかまわない)ケースが大半を占めるのではないかと思う。

>ウィンドウシステム・3D・DirexX関係も相性はあまりよくない。

RubyもGNOME, WxWidget, Qt, Cocoa, SDLとウィンドウ(GUI toolkit)は揃っているし、
3DもOpenGL拡張ライブラリがあるから、相性が悪い理由にはならない。
DirectXは(おそらく)Rubyで対応しておらず、Phytonの実績が多いのかも(?)しれないが、
それは実績が多いという事実の言明だけであって、具体的な技術面の指摘ではない。
そもそも、これらは拡張ライブラリであってエンジン組み込みではないからスレ違い。

>それに対してPythonは参照カウントとマーク&スイープの組み合わせで、
>マーク&スイープもおとなしいタイプ。

GC制御に関わる所有ルールの難解さは、RubyにもPythonにも同様に存在する。
またGC方式の差異は、組み込み用途の利点とは直接的に結びつかないのでスレ違い。
(もし関連性があると考えているなら、具体的に差異を説明してください)

>あと、これは俺の想像だけど、Pythonの作者は、PythonからCを使うってのと
>CからPythonを使うってのを対称的で対等なものとして考えている雰囲気があるし、

対称性はRubyも変わらない。実装の難易度も同等というのが、個人的な実感。

(まだ続く)

365 名前:345 mailto:sage [2009/08/15(土) 00:15:27 ]
(>>364の続き)

>技術的に変なこだわりはなくて、いろんなところに配慮しながら無難な実装をしてる。

これは(スレ違いだけど)同感で、PythonがSimple is bestを追求してるのは好感。ただし、

>Rubyは実装技術オタクのMatzが作ったので、変なところでこだわってたり
>無駄に離れ業やってたりしてタチが悪い

については、組み込み用途とは無関係だし、Rubyがスキャナとパーザの実装で
離れ業をしている事を除けば、具体性の無いMatzへの個人批判でしかないのでスレ違い。

以上、個人の印象/主観を除いたRubyの組み込み用途における技術的な問題点をまとめると、

- 言語まるごと(パーザ+VM)組み込む必要がある
- ネイティブスレッドとの破滅的な相性の悪さ

の二点のみ。組み込み用途に限れば、Pythonと比較した決定的な欠陥は見当たらない。
実際、拡張ライブラリ(Ruby->C呼び出し)を自作できるRubyプログラマであれば、
Ruby組み込み(C->Ruby呼び出し)も難儀な実装作業ではない、というのが個人的な実感。
(PythpnでもPython->C呼び出しが実装できない人であれば(その逆の)組み込みが難しいのは同じ)

(ゴメン、次で最後だから許して)

366 名前:345 mailto:sage [2009/08/15(土) 00:18:02 ]
(>>365の続き)

あと(技術的な観点ではないけど)付け加えるとすれば、
Pythonは公式文書として組み込み方法が解説されているのに対して、
Rubyはインタプリタソース(ruby-1.8.x-xxx.tar.gz)に含まれるごく簡単な解説が
唯一の公式文書であるため、自力でネット/書籍から情報を得る必要があるという差異が、
組み込み実績という結果に大きく影響していると思われる。

これだけだと何の事か分かりずらいと思うので、最後に具体的なアドバイスをまとめる。

- RubyプログラマはRuby組み込みで、PythonプログラマはPython組み込みを選ぶのが楽
- ただし、ネイティブスレッドが前提なアプリケーションであれば、Pythonしかない
- どちらも知らない人は、(解説文書が整備されている)Phyton組み込みが無難な選択(=お勧め)
- ただし、言語の選択は、システム全体を見渡してから判断すべき(解説文書の有無だけで
 言語を選択すると、本末転倒になる恐れがある(木を見て森を見ず))

長文/連投のスレ汚し、失礼しますた。






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<260KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef