nashorn遅いその2


jre8を64bitのb77に変えたのでsun-spider再び。

rhino:1533.3ms +-  1.1%
nashron:19691.9ms +-  3.0%

b75の32bitだとやっぱり絶対値が遅かった様子。
rhinoの結果が64bitのJRE7と同じ結果なので32bitをWOW64で動かしたからか?(b75-b77の間に変更があった?)

ただし、12倍遅いという結果は同じだった。(というか目に見えてnashronの方が遅いのでわざわざベンチマーク走らせる意味もないけど)
むしろnashronの誤差が+-9.5 -> +-3.0と1/3になったのでより実力に近い結果で12倍遅いということが新たに分かった。
結局rhinoのインタプリタモードより3倍遅い。20倍早いマイクロベンチマークとは一体何だったのか?

nashronのロゴって赤いサイだったっけ? 角付いてて赤いくせに3倍遅いとはこれいかに。
rhinoがIE8と互角くらい。純粋なインタプリタでIE8の1/4の速度ってことはやっぱりrhinoのインタプリタは昔からコミュニティで言われる通り思ったより早いみたい。

sun-spiderはたしかスクリプトのロード時間は含めてないので実際のアプリケーションではユーザーは更にロード時間ぶん待たされることになる。
nashronはShellの関数が全部javascriptで実装されてるのでload関数が余計に遅くなる。ただ、format-tofteだけで10050.9msあるからこれ改善するだけで倍近く早くなりそう。


おまけ

rhino on jre 8 b77 64bit

============================================
RESULTS (means and 95% confidence intervals)
--------------------------------------------
Total:                  1533.3ms +-  1.1%
--------------------------------------------
  3d:                    120.3ms +-  9.1%
    cube:                 24.4ms +- 31.1%
    morph:                58.0ms +- 18.7%
    raytrace:             37.9ms +- 20.9%
  access:                198.4ms +-  3.6%
    binary-trees:         24.7ms +- 30.6%
    fannkuch:             82.3ms +-  8.2%
    nbody:                42.1ms +- 16.8%
    nsieve:               49.3ms +- 11.4%
  bitops:                290.0ms +-  2.7%
    3bit-bits-in-byte:    37.7ms +- 20.6%
    bits-in-byte:         56.0ms +- 13.9%
    bitwise-and:         100.0ms +-  7.8%
    nsieve-bits:          96.3ms +-  5.8%
  controlflow:            13.0ms +- 40.9%
    recursive:            13.0ms +- 40.9%
  crypto:                102.7ms +-  7.4%
    aes:                  42.1ms +- 16.8%
    md5:                  33.7ms +- 16.1%
    sha1:                 26.9ms +- 25.6%
  date:                  113.7ms +-  6.3%
    format-tofte:         55.4ms +- 13.7%
    format-xparb:         58.3ms +- 12.3%
  math:                  156.0ms +-  0.0%
    cordic:               66.6ms +- 10.9%
    partial-sums:         66.9ms +- 10.6%
    spectral-norm:        22.6ms +- 33.7%
  regexp:                234.0ms +-  0.0%
    dna:                 234.0ms +-  0.0%
  string:                305.1ms +-  2.6%
    base64:               51.0ms +- 13.7%
    fasta:                51.1ms +- 14.1%
    tagcloud:             87.1ms +-  9.1%
    unpack-code:          68.9ms +- 11.5%
    validate-input:       47.0ms +-  0.0%

nashron on jre 8 b77 64bit

============================================
RESULTS (means and 95% confidence intervals)
--------------------------------------------
Total:                 19691.9ms +-  3.0%
--------------------------------------------
  3d:                   2032.9ms +- 13.9%
    cube:                668.6ms +-  7.8%
    morph:               120.4ms +-  6.0%
    raytrace:           1243.9ms +- 21.4%
  access:               1470.6ms +-  3.6%
    binary-trees:        260.4ms +-  4.3%
    fannkuch:            323.1ms +-  2.2%
    nbody:               726.6ms +-  7.3%
    nsieve:              160.4ms +-  8.6%
  bitops:                403.4ms +- 13.3%
    3bit-bits-in-byte:   127.0ms +- 39.8%
    bits-in-byte:         47.0ms +-  0.0%
    bitwise-and:          66.7ms +- 10.7%
    nsieve-bits:         162.7ms +-  4.8%
  controlflow:           200.6ms +-  5.0%
    recursive:           200.6ms +-  5.0%
  crypto:               1227.9ms +-  8.9%
    aes:                 468.0ms +-  3.1%
    md5:                 369.9ms +- 18.1%
    sha1:                390.0ms +- 18.1%
  date:                10690.6ms +-  6.8%
    format-tofte:      10050.9ms +-  6.7%
    format-xparb:        639.7ms +- 33.8%
  math:                  844.9ms +- 10.7%
    cordic:              207.3ms +- 36.2%
    partial-sums:        436.9ms +-  2.6%
    spectral-norm:       200.7ms +-  5.1%
  regexp:                204.9ms +- 27.7%
    dna:                 204.9ms +- 27.7%
  string:               2616.3ms +- 11.1%
    base64:              512.6ms +- 14.0%
    fasta:               374.4ms +- 12.5%
    tagcloud:            452.6ms +- 21.9%
    unpack-code:         884.9ms +- 25.4%
    validate-input:      391.9ms +- 56.6%

第二次・nashronのrhino非互換調査・中間走り書き


第二次走り書き特記事項

rhino非互換どころの話じゃなくて型周りのバグっぽい。



§型がコンパイル時のシグネチャでアーリーバインディングされる

注釈追加:
この挙動はinvokedynamicを使っているので当然といえば当然なのだが
マッチさせる型の方に問題があるのと変換規則が正しく実装されてない
問題の2つの問題点がある。

nashronはrhinoと同じコンパイルモードで走る処理系なのでスクリプトを
読んだ時点でコンパイルされる。そのため、実際の実行時にバインドされる型は
不明だがコンパイル時にjavaにネイティブな型としてinvokedynamicされる。

そもそもこれはjsがレイトバインディングであるにも関わらず
1)invokedynamicによってバイトコード生成時の型で
メソッドが呼び出されているため(メソッドのlookupの時にjavaの
型としてシグネチャを見ている)
2)コンパイルモードなのでmixedモードの様にインタープリタ
しながらJITするのとは違う
という要因がある。

注釈追加:
所謂mixed(混載)モードとは実行時の一番初めにコンパイラが走るのではなく、
インタープリタを走らせながら並列にJITコンパイラが走るアレ。
例:javaのHotSpotVMやJRubyのmixedモードやブラウザの最近のjs実装の流行り。

さらにjsがレイトバインディングであるため間に(動的な)型変換を挟んでもinvokedynamicで
javaにネイティブな型とマッチさせるのは困難で、これはjavaにネイティブな型ではなく
rhino-invokedynamicの様にNativeObject(nashronではScriptObject)でinvokedynamicする必要がある。
注釈追加:特殊化してNativeObjectのサブクラスでもいい

それか、mixedモードの様に実行しながらバイトコードを吐く必要がある。

この挙動は非互換というより潜在的なバグであるがバグと認識しているかは不明で、
むしろNativeJavaクラスが存在していることを考えるとこれはnashronの想定した挙動かもしれない。
(そのうちブログやメーリングリストでも読んでみる)

§LiveConnectの暗黙の型変換でjsの配列からjavaの配列へ変換できない

たとえばjsの型がArray<string>(jsの配列にjsのstringが含まれる)で呼び出し先の
javaメソッドのシグネチャが[Ljava.lang.StringだとこれはjavaのString配列となる。

このときjsには暗黙の型変換があるのでLCによるjava呼び出しにも暗黙の型変換が適応される。
それによってLC仕様はjs2javaやjava2js用の変換規則を持っていてjsの配列はjavaの配列となる。
(実装レベルで厳密に見るとこの変換後の型はjavaの配列ではなくjavaの配列である事を表現する
native objectのJavaArrayとなるが変換用プロトコルをブラックボックス化しているだけなので
内部プロパティ[[Class]]が"JavaArray"であること以外のこの際気にしなくて良い)

しかし、このときnashronではjsの配列からjavaの配列への"変換を行なっていない"のでLC仕様に違反している。
このため、javaの呼び出し時に配列を要求するコードはrhinoと互換性がなくなる。

先に挙げたコンパイル時にアーリーバインディングされる件があるため状況はさらにややこしい。
(jsはレイトバインディングなので実行してみないと真に要求される型はわからない。例えば特殊変数thisは自由変数)

ecma-262がesでアーリーバインディングをサポートしないと決定したのはレイトバインディングな言語に
アーリーバインディングを持ち込むとこの様に矛盾が生じるため。

§JSONの末尾カンマがErrorにならない

ecma-262のネイティブJSONオブジェクトってどっちだっけ?

§LiveConnectの暗黙の型変換でjsのstringからjavaのstring(Ljava.lang.String)へ変換できない
§シグネチャの型だけではなくオブジェクトの型もアーリーバインディングされる

上記2つは変換規則が間違っているだけでなくバグでまともに型変換されてない

§Function.prototype.bindの引数callerThisの扱いがおかしい

扱いが狂ってるので結果が予測できない。
要求される型と一致しなくても何故か実行できるけど結果は当然正しくなかったり、
要求される型と一致していてもTypeErrorを投げたりする。


invokedynamicの問題は静的型付けを有効にしたGroovyで動的型付けが効かないのと似たようなもの。
Groovyの場合は仕様だが、ecmascriptにはアーリーバインディングはないのでこの挙動はバグ。
というかnashronの仕様[ミス|バグ]じゃなかろうか。
invokedynamicを使うという主目的とソースコードから推測するに多分こういう想定。

型変換されてない"だけ"の部分はJavaオブジェクトを使って型変換するグルーコードを自分で挿入すれば取りあえず単純には動く。
しかし、これでは本末転倒。ただし更に変換規則やメソッドサーチがおかしいのでグルーコードを挿入しても結局まともに動かない。

型周りがおかしいということはLiveConnectがまともに機能しないということなので、つまりはjavaのAPIがまともに使えないということ。

nashornのrhino非互換調査・中間走り書き


§型がコンパイル時のシグネチャでアーリーバインディングされる

nashornはrhinoと同じコンパイルモードで走る処理系なのでスクリプトを
読んだ時点でコンパイルされる。そのため、実際の実行時にバインドされる型は
不明だがコンパイル時にjavaにネイティブな型としてinvokedynamicされる。

そもそもこれはjsがレイトバインディングであるにも関わらず
1)invokedynamicによってバイトコード生成時の型で
メソッドが呼び出されているため(メソッドのlookupの時にjavaの
型としてシグネチャを見ている)
2)コンパイルモードなのでmixedモードの様にインタープリタ
しながらJITするのとは違う
という要因がある。

さらにjsがレイトバインディングであるため間に(動的な)型変換を挟んでもinvokedynamicでjavaの型とマッチさせるのは困難で、
これはjavaの型ではなくrhino-invokedynamicの様にNativeObject(nashornではScriptObject)でinvokedynamicする必要がある。
それか、mixedモードの様に実行しながらバイトコードを吐く必要がある。

この挙動は非互換というより潜在的なバグであるがバグと認識しているかは不明で、
むしろNativeJavaクラスが存在していることを考えるとこれはnashornの想定した挙動かもしれない。
(そのうちブログやメーリングリストでも読んでみる)

§LiveConnectの暗黙の型変換でjsの配列からjavaの配列へ変換できない

たとえばjsの型がArrayだとこれはjsの配列にjsのstringが含まれる。
呼び出し先のjavaメソッドのシグネチャがLjava.lang.StringだとこれはjavaのString配列となる。

このときjsには暗黙の型変換があるのでLCによるjava呼び出しにも暗黙の型変換が適応される。
それによってLC仕様はjs2javaやjava2js用の変換規則を持っていてjsの配列はjavaの配列となる。
(実装レベルで厳密に見るとこの変換後の型はjavaの配列ではなくjavaの配列である事を表現する
native objectのJavaArrayとなるが変換用プロトコルをブラックボックス化しているだけなので
内部プロパティ[Class]が"JavaArray"であること以外のこの際気にしなくて良い)

しかし、このときnashornではjsの配列からjavaの配列への"変換を行なっていない"のでLC仕様に違反している。
このため、javaの呼び出し時に配列を要求するコードはrhinoと互換性がなくなる。

先に挙げたコンパイル時にアーリーバインディングされる件があるため状況はさらにややこしい。
(jsはレイトバインディングなので実行してみないと真に要求される型はわからない。例えば特殊変数thisは自由変数)

ecma-262がesでアーリーバインディングをサポートしないと決定したのはレイトバインディングな言語に
アーリーバインディングを持ち込むとこの様に矛盾が生じるからであるのにinvokedynamicに拘りすぎて本末転倒である。

やっぱり、nashornは遅い。


まず始めに実行環境について

PC:
Phenom II X6 1055T
Radeon HD8550
4.0G RAM

win7SP1 64bit

JRE:
jre-8-ea-bin-b75-windows-i586-31_jan_2013

VM引数:
-XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+EnableInvokeDynamic

nashorn:
nashorn-02f810c26ff9

rhino:
mozilla-rhino-Rhino1_7R4_RELEASE-46-g49648dcにそれ以降のpath全部入り+マルチバイト周りのバグ修正+日本語l10n

benchmark
rhino同梱のsun-spider 0.9.1

jre8-eaを使ったのは始めnashornが「java8で実行しろ」と吐いて死んだため。
VM引数はjava8のinvokedynamicで関連-XXオプションがデフォルトで有効か無効か分からなかったため全部入れた。
このVM引数はnashorn、rhino共に指定。
OSが64bitでjreが32bitなのは64bitバイナリがなぜか403でダウンロード出来なかったため。
jre8-eaがjre7より明らかに遅かったので条件を一致するためrhinoもjre8-eaで走らせる。

結果sun-spider-0.9.1を完走させてみて

nashorn
35507.9ms +- 9.5%
rhino
2881.6ms +- 0.4%

nashornが12倍遅い結果になった。誤差が大きいので何度か試すとまあ大体10倍程度遅い感じ。
マイクロベンチマークだとnashornがrhinoより20倍早かったらしいのだけど、
いくらマイクロベンチマークだからと言って実際のアプリケーション寄りのベンチマークで逆に10倍遅いなんておかしい。
漁ってみた感じoracleが比べているのは恐らくjdkに同梱のrhino1.7 pre R3のインタプリタモードと比べている、くらいしか思いつかない。
なぜならjdk同梱のrhinoはかなり古い版でバイトコード生成にバグがあり、それを回避するためインタプリタモードで動いている。
現在、安定版の1.7R4は中身が激変しているのでrhinoとしてみた時充てにならない。
これならわざわざ車輪の再開発をせずに1.7R4を同梱すれば良かった気もするが、ソースがoracleの外のコミニュティで管理されているリスクを避けるためだろうか?
(jreは標準ライブラリの実装に使っている非公開パッケージ部分のoracle以外の成果物が自由に使えないのにrt.jarが肥え続けるという問題がある)
まあクライアントサイドでの需要は少ないだろうしjavafxではV8なのでサーバーで使いたいのとinvokedynamicのプロパガンダのためだろうけど。

他に思いつく遅い理由といえばShellの関数群(load関数とか)がjavaではなくjsで実装されていることくらい。
誰かもっと早い結果出てないだろうか……。


おまけとしてsun-spider結果詳細

nashorn

--------------------------------------------
Total: 35507.9ms +- 9.5%
--------------------------------------------
3d: 1871.9ms +- 9.3%
cube: 766.7ms +- 13.5%
morph: 169.3ms +- 40.8%
raytrace: 935.9ms +- 11.8%
access: 1326.1ms +- 9.2%
binary-trees: 89.4ms +- 8.1%
fannkuch: 510.3ms +- 1.4%
nbody: 329.7ms +- 30.0%
nsieve: 396.7ms +- 44.4%
bitops: 434.3ms +- 21.0%
3bit-bits-in-byte: 46.6ms +- 1.1%
bits-in-byte: 35.7ms +- 20.0%
bitwise-and: 167.3ms +- 47.0%
nsieve-bits: 184.7ms +- 39.2%
controlflow: 85.1ms +- 64.2%
recursive: 85.1ms +- 64.2%
crypto: 853.4ms +- 9.5%
aes: 396.7ms +- 16.8%
md5: 296.1ms +- 34.3%
sha1: 160.6ms +- 4.5%
date: 25773.1ms +- 12.4%
format-tofte: 25347.7ms +- 12.5%
format-xparb: 425.4ms +- 22.4%
math: 624.3ms +- 6.0%
cordic: 241.0ms +- 43.1%
partial-sums: 263.0ms +- 28.7%
spectral-norm: 120.3ms +- 65.3%
regexp: 448.0ms +- 21.2%
dna: 448.0ms +- 21.2%
string: 4091.6ms +- 7.1%
base64: 340.9ms +- 26.5%
fasta: 552.7ms +- 7.9%
tagcloud: 1285.7ms +- 16.3%
unpack-code: 1713.7ms +- 17.7%
validate-input: 198.6ms +- 33.0%

rhino

--------------------------------------------
Total: 2881.6ms +- 0.4%
--------------------------------------------
3d: 293.7ms +- 1.9%
cube: 71.1ms +- 11.1%
morph: 144.6ms +- 5.0%
raytrace: 78.0ms +- 0.0%
access: 416.9ms +- 1.6%
binary-trees: 42.4ms +- 17.0%
fannkuch: 165.0ms +- 4.7%
nbody: 104.7ms +- 6.5%
nsieve: 104.7ms +- 6.5%
bitops: 550.3ms +- 1.2%
3bit-bits-in-byte: 65.0ms +- 8.2%
bits-in-byte: 111.3ms +- 5.0%
bitwise-and: 224.9ms +- 3.5%
nsieve-bits: 149.1ms +- 5.3%
controlflow: 31.0ms +- 0.0%
recursive: 31.0ms +- 0.0%
crypto: 188.0ms +- 0.0%
aes: 89.4ms +- 8.1%
md5: 51.6ms +- 14.0%
sha1: 47.0ms +- 0.0%
date: 231.9ms +- 2.3%
format-tofte: 121.9ms +- 4.3%
format-xparb: 110.0ms +- 0.0%
math: 309.7ms +- 1.8%
cordic: 133.1ms +- 5.9%
partial-sums: 129.6ms +- 5.6%
spectral-norm: 47.0ms +- 0.0%
regexp: 275.7ms +- 2.5%
dna: 275.7ms +- 2.5%
string: 584.4ms +- 1.3%
base64: 114.3ms +- 5.9%
fasta: 109.0ms +- 0.0%
tagcloud: 140.0ms +- 0.0%
unpack-code: 120.4ms +- 6.0%
validate-input: 100.7ms +- 11.3%

rhino opt -1

------------------------------------------
Total: 7612.9ms +- 0.4%
------------------------------------------
3d: 922.9ms +- 1.0%
cube: 296.4ms +- 0.2%
morph: 345.4ms +- 2.9%
raytrace: 281.0ms +- 0.0%
access: 1557.7ms +- 1.5%
binary-trees: 131.3ms +- 5.8%
fannkuch: 795.7ms +- 2.4%
nbody: 347.6ms +- 2.0%
nsieve: 283.1ms +- 3.5%
bitops: 1662.4ms +- 0.8%
3bit-bits-in-byte: 269.4ms +- 4.1%
bits-in-byte: 423.6ms +- 1.3%
bitwise-and: 503.6ms +- 1.4%
nsieve-bits: 465.9ms +- 1.1%
controlflow: 133.6ms +- 5.8%
recursive: 133.6ms +- 5.8%
crypto: 583.7ms +- 1.3%
aes: 245.3ms +- 2.9%
md5: 165.0ms +- 4.7%
sha1: 173.4ms +- 3.2%
date: 401.4ms +- 1.8%
format-tofte: 254.4ms +- 2.8%
format-xparb: 147.0ms +- 5.3%
math: 947.3ms +- 0.8%
cordic: 456.6ms +- 1.6%
partial-sums: 303.1ms +- 2.5%
spectral-norm: 187.6ms +- 0.3%
regexp: 276.3ms +- 2.6%
dna: 276.3ms +- 2.6%
string: 1127.6ms +- 0.6%
base64: 220.6ms +- 2.5%
fasta: 312.0ms +- 0.0%
tagcloud: 220.7ms +- 2.5%
unpack-code: 180.4ms +- 4.2%
validate-input: 193.9ms +- 4.1%

rhino on java7

------------------------------------------
Total: 1613.7ms +- 2.0%
------------------------------------------
3d: 127.1ms +- 16.7%
cube: 26.9ms +- 26.8%
morph: 60.1ms +- 25.2%
raytrace: 40.1ms +- 28.1%
access: 198.3ms +- 3.6%
binary-trees: 26.7ms +- 25.4%
fannkuch: 78.0ms +- 0.0%
nbody: 42.1ms +- 16.8%
nsieve: 51.4ms +- 13.6%
bitops: 291.9ms +- 2.4%
3bit-bits-in-byte: 42.4ms +- 16.3%
bits-in-byte: 53.3ms +- 14.2%
bitwise-and: 102.7ms +- 7.4%
nsieve-bits: 93.4ms +- 0.5%
controlflow: 13.6ms +- 40.9%
recursive: 13.6ms +- 40.9%
crypto: 100.3ms +- 7.5%
aes: 37.9ms +- 20.9%
md5: 40.1ms +- 19.7%
sha1: 22.3ms +- 33.9%
date: 122.4ms +- 4.5%
format-tofte: 60.1ms +- 9.0%
format-xparb: 62.3ms +- 0.7%
math: 160.4ms +- 4.4%
cordic: 62.6ms +- 0.8%
partial-sums: 75.7ms +- 7.4%
spectral-norm: 22.1ms +- 34.7%
regexp: 278.7ms +- 13.8%
dna: 278.7ms +- 13.8%
string: 321.0ms +- 2.4%
base64: 51.3ms +- 13.9%
fasta: 51.1ms +- 14.1%
tagcloud: 96.0ms +- 6.0%
unpack-code: 73.6ms +- 9.5%
validate-input: 49.0ms +- 10.9%

rhino opt -1 on java7

------------------------------------------
Total: 6242.4ms +- 1.1%
------------------------------------------
3d: 739.9ms +- 1.1%
cube: 258.6ms +- 3.0%
morph: 274.0ms +- 4.2%
raytrace: 207.3ms +- 3.3%
access: 1294.9ms +- 2.1%
binary-trees: 104.7ms +- 6.5%
fannkuch: 666.4ms +- 2.8%
nbody: 280.7ms +- 0.2%
nsieve: 243.0ms +- 3.2%
bitops: 1417.3ms +- 2.8%
3bit-bits-in-byte: 234.0ms +- 3.7%
bits-in-byte: 392.3ms +- 1.4%
bitwise-and: 374.1ms +- 0.1%
nsieve-bits: 416.9ms +- 9.8%
controlflow: 129.4ms +- 5.4%
recursive: 129.4ms +- 5.4%
crypto: 465.7ms +- 2.8%
aes: 187.1ms +- 0.2%
md5: 136.0ms +- 5.4%
sha1: 142.6ms +- 7.0%
date: 274.4ms +- 2.8%
format-tofte: 180.6ms +- 4.1%
format-xparb: 93.9ms +- 0.4%
math: 780.0ms +- 0.0%
cordic: 392.3ms +- 1.4%
partial-sums: 224.9ms +- 3.5%
spectral-norm: 162.9ms +- 4.9%
regexp: 280.7ms +- 13.2%
dna: 280.7ms +- 13.2%
string: 860.1ms +- 2.3%
base64: 180.4ms +- 4.4%
fasta: 234.0ms +- 0.0%
tagcloud: 178.3ms +- 10.3%
unpack-code: 127.0ms +- 4.2%
validate-input: 140.4ms +- 5.9%

Nashornビルドしたった!

こことかここ

NashornはRhinoの20倍早いらしいのでビルドしてjre8のeaでv8-benchmarkとsun-spider走らせたんだけど頗るスコアが悪い。
何かビルドオプションとか実行時オプションが抜けてるんだろうか……jdk.internalパッケージに依存しないスタンドアローンな修正を入れてant通しただけなのでまだソース読んでないのでよく解りません。

20倍っていうのはどこから出てきたんだろうか、jdkのRhinoは1.7 Pre R3なので現行の1.7R4の最大で5倍くらい遅いんですがたぶんこれと比べてるはずだけどそれにしても遅すぎる。
jarサイズもasmとdynalink包括して1.5M byteとランタイムとコンパイラとREPLしか付いてないのにデバッガとGUI REPLと開発用ツールが更に追加されるRhinoは1.1M byteなんですが。

最新のブラウザに匹敵するパフォーマンスが得られていることは間違いないだろう。
とあるのにv8-benchmarkのスコアが300台しか出ない……。sun-spiderは遅すぎて完走してないorz
こういうものなのかなにか問題があるのか原因が全くわからない。

そのうちソース読む!

ちなみにRhinoのdynamicinvoke対応版はR3ベースでバグがあって正常に動かない。R4にマージするかmasterにマージするかしたら動くはず。

rhinoのパッチ

だいぶ前からrhinoの日本語に関わる部分に変更を入れているのですがソースの管理がGITのためコミットしてません。(win64bitなんで環境に変更を入れたくないんです)
公式のrhinoでは一部でマルチバイト文字を考慮していないため2バイト以上の文字が化けることがあります。そのため、デバッガが文字化けしたりCommonJSとか使えなかったりしますがこれを修正してます。ほかにも不完全ですが文字列リソースを翻訳しています。まだすべて終わっていないですが全て終わったら一時的にここで公開するかもしれません。