アカウント名:
パスワード:
「あっそうとしか思えん」からが長い!
GC云々とAOTの関連性がよくわからないので不躾な私にもわかるようにもう少し詳しく教えていただけませんか
前半の文章は全く誤りです。asm.jsでもGCは働きます。ただArrayBufferをメモリ空間かのように使うことでGCに頼らない方法を推奨しており、emscriptenも積極的にそういったコードを出力します。ただそれはasm.jsとは直接関係なく普通のJSにおいてもかなり強力なテクニックです。
後半はその通りです。本質的にJITの性質を引き出すことで、部分的にネイティブかそれ以上のパフォーマンスを引き出せるケースはいくつもあります。今回の実行時間1.5倍というのは、ネイティブのコードから機械的に変換されたコードでの場合であり、JSの限界性能ではないということです。おそらく現在でもそれを考慮すると、JSはネイティブに匹敵する速度になったと言って良いと思われます。
あなたこそ少し誤解している風に見受けられます。
asm.jsは普通に人が書いたJavaScriptを実行する為のエンジンは使用していません。まったく別のエンジンを使用して動かしているので、一般的なJSエンジンの挙動はしないと思われます。そもそも、CやC++から変換したコードの実行が主なのでGCする必要がないのに、あえて速度を落としてまでするんですかね?
> JSはネイティブに匹敵する速度いや、全然違います…asm.jsはその名の通りアセンブラ代わりに使っているだけです。(ただ、Firefox以外のエンジンでも普通に動かせるところが画期的ですが)で、AOTのコンパイラが実行時に全部機械語に変換して実行しているだけなんです。
いいえ、私は誤解していません。私は今年ずっとasm.jsのコードを手書きする場合もありましたし、emscriptenも積極的に使い、ベンチもよく使ってきました。ドキュメントや情報もかなり網羅しています。もう一度言いますが、asm.js部分ではGCは働かないというのは、一番誤解されている間違いです。asm.jsでも内部で利用した変数で確保されたメモリは関数終了時にGCが走ってクリアされます。(メモリ空間として利用されているArrayBufferはuse asm外のJSの領域で参照が切れた時GCの対象になります)
また、JSはネイティブに匹敵する速度というのも、今年ずっと
つ http://asmjs.org/spec/latest/#ahead-of-time-compilation [asmjs.org]
Moreover, the code generated by anAOT compiler can be quite efficient, featuring:
もう一度言いますが、asm.js部分ではGCは働かないというのは、一番誤解されている間違いです。asm.jsでも内部で利用した変数で確保されたメモリは関数終了時にGCが走ってクリアされます。(メモリ空間として利用されているArrayBufferはuse asm外のJSの領域で参照が切れた時GCの対
メモリとして用いるArrayBufferはasm.js外に参照を持っているのでGCされるのはasm.js外と言えますが、その他は実エンジン上ではasm.jsの最後のステップとしてGCが行われます。著名なemscriptenのベンチマークのようにArrayBufferが使われていたり、そもそも最初から最後までasm.js空間で実行される場合にはGCされないとみなすことが出来ますが、手描きの場合などで高速化のために部分的にasm.jsでのモジュールを呼び出す場合などには、実質的にasm.js側でGCが行われるとみなされます。
> そもそも最初から最後までasm.js空間で実行される場合にはGCされないとみなすことが出来ますがということは、やっぱりGCされないと考えていいんですよね?多分"use asm"が定義されているスコープ内ではGCされないだろうなという認識であってるかな。関数毎にも指定できるから、その関数を抜けるとGCが走ると。
超具体的にどこのタイミングで可能なのか/すべきなのか/今されてるのかの全ては分かりませんが、asm.jsの処理が終わる時にJS側ではないので、つまりasm.js側でGCが行われることは事実です。ほぼasm.jsだけで完遂するものであれば、OSとC言語でのmallocの例のようにGCが『無い』とみなすことも自然でしょう。また、そもそもいろいろな記事でGCが無いかのように言われるのはmallocを使うような言語から変換するときは、ほぼ全域でArrayBufferがメモリ空間として使われるから、そのことを言っているんだと理解してください。実際はベンチマーク等の特殊な場合を除き、実アプリではIOや他ライブラリとの絡みも多く必要になってくるので、ArrayBuffer以外の部分で起こるGCはOSとC言語の例のように無かったようにみなすのは不自然となります。
> 今回の実行時間1.5倍というのは、ネイティブのコードから機械的に変換されたコードでの場合であり
本当にわかっているのですか?今回のケースは前回と同じくC++からemscriptenで変換されたものですネイティブのコードは関係ありません
ネイティブコード、x86かARMはわかりませんが、clangの出力コードをasm.jsに変換したのではないということです
そういう意味ではありません。大袈裟に言うと、仮にスクラッチでJITが活きる場所は非asmで、そうでない部分はasm.jsで手書きで移植した場合、勿論元のコードに明らかな無駄がなくとも、emscriptenで機械的に出力されるコードよりはるかにパフォーマンスの向上を見込めるということです。そこまでいかなくても現実的に、数値演算ばかりではない、複雑な実アプリの場合こそ、JITが活きやすいので、そういう場合に「少しの苦労で」asm.jsと非asmを組み合わせることで、ネイティブと同等のパフォーマンスまで持っていける段階まで来たということです。
そういう一般論ではなく
> 今回の実行時間1.5倍というのは、ネイティブのコードから機械的に変換されたコードでの場合であり、
とあなたは限定しています
間違いをお認めになれないのなら、それはつまり何もわかっていないということの証拠です
どこが間違いだと思われてるのかさっぱり分かりません。「ネイティブのコードから機械的に変換されたコードの場合」というのは「emscriptenで生成されたコードの場合」ということであり、それとそれに人力を加えた場合にパフォーマンスの比較の話の繋がりに何もおかしなところはないと思いますが、どこが引っかかっていますか?
> 「ネイティブのコードから機械的に変換されたコードの場合」というのは「emscriptenで生成されたコードの場合」ということであり、
emscriptenの入力はネイティブコードではありませんよもしかしてそんなこともご存じなかったとは
はぁ、、、よくわかりませんね。もしかして直接入力に取るのはLLVMのコードだから、「間接的に」という言葉を入れろとかいう揚げ足取りですか、、、?流石に汲み取って欲しいのですが、、、それだけですか?
LLVMのコードはネイティブコードではありませんよ
ネイティブ→LLVM→JSこれでいいですか?何のためにそこに拘るのかが分かりませんが
理解しましたでもやっぱり間違いです少なくとも今回のベンチマークでは、clangが生成したネイティブのコードをさらにLLVMコード経由でasm.jsにはしません
すみませんね。ここで言うネイティブとはCやC++言語のことを指して言ったのですよ。
ここで言うネイティブとはCやC++言語のこと
激しく頭悪そうワロタw
JavaScriptと対比させてJavaやCなんかのことをネイティブって一般的に呼ばれてるよネイティブコードではなくネイティブ(言語)「の」コードなんだから全然おかしくないと思う
JavaScriptと対比させてJavaやCなんかのことをネイティブって一般的に呼ばれてる
激しく頭悪いクソワロタww
言語の話になるとこういうのが湧くな
ここは2chじゃねーつの
煽られても論拠挙げて反論すんのが2ch、スラド民にそこまでの知性は期待できまい。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア
ネイティブコードに近付いて当然 (スコア:2)
時間を掛けてコンパイルできない分、凝った最適化が出来無い中での結果なんで、そこは凄いなと思う。
ただ、これでWebGL使って全画面のアプリを作れば、HTMLとか全て無視した普通のアプリが動いちゃうんだろうな。
まぁネイティブアプリが簡単にマルチプラットフォーム化できればありがたいけど。
Re: (スコア:0)
「あっそうとしか思えん」からが長い!
Re: (スコア:0)
GC云々とAOTの関連性がよくわからないので不躾な私にもわかるようにもう少し詳しく教えていただけませんか
Re: (スコア:0)
前半の文章は全く誤りです。
asm.jsでもGCは働きます。ただArrayBufferをメモリ空間かのように使うことでGCに頼らない方法を推奨しており、emscriptenも積極的にそういったコードを出力します。ただそれはasm.jsとは直接関係なく普通のJSにおいてもかなり強力なテクニックです。
後半はその通りです。
本質的にJITの性質を引き出すことで、部分的にネイティブかそれ以上のパフォーマンスを引き出せるケースはいくつもあります。
今回の実行時間1.5倍というのは、ネイティブのコードから機械的に変換されたコードでの場合であり、JSの限界性能ではないということです。
おそらく現在でもそれを考慮すると、JSはネイティブに匹敵する速度になったと言って良いと思われます。
Re:ネイティブコードに近付いて当然 (スコア:1)
あなたこそ少し誤解している風に見受けられます。
asm.jsは普通に人が書いたJavaScriptを実行する為のエンジンは使用していません。
まったく別のエンジンを使用して動かしているので、一般的なJSエンジンの挙動はしないと思われます。
そもそも、CやC++から変換したコードの実行が主なのでGCする必要がないのに、あえて速度を落としてまで
するんですかね?
> JSはネイティブに匹敵する速度
いや、全然違います…
asm.jsはその名の通りアセンブラ代わりに使っているだけです。
(ただ、Firefox以外のエンジンでも普通に動かせるところが画期的ですが)
で、AOTのコンパイラが実行時に全部機械語に変換して実行しているだけなんです。
Re: (スコア:0)
いいえ、私は誤解していません。
私は今年ずっとasm.jsのコードを手書きする場合もありましたし、emscriptenも積極的に使い、ベンチもよく使ってきました。
ドキュメントや情報もかなり網羅しています。
もう一度言いますが、asm.js部分ではGCは働かないというのは、一番誤解されている間違いです。
asm.jsでも内部で利用した変数で確保されたメモリは関数終了時にGCが走ってクリアされます。
(メモリ空間として利用されているArrayBufferはuse asm外のJSの領域で参照が切れた時GCの対象になります)
また、JSはネイティブに匹敵する速度というのも、今年ずっと
Re: (スコア:0)
つ http://asmjs.org/spec/latest/#ahead-of-time-compilation [asmjs.org]
Moreover, the code generated by an
AOT compiler can be quite efficient, featuring:
もう一度言いますが、asm.js部分ではGCは働かないというのは、一番誤解されている間違いです。
asm.jsでも内部で利用した変数で確保されたメモリは関数終了時にGCが走ってクリアされます。
(メモリ空間として利用されているArrayBufferはuse asm外のJSの領域で参照が切れた時GCの対
Re: (スコア:0)
メモリとして用いるArrayBufferはasm.js外に参照を持っているのでGCされるのはasm.js外と言えますが、その他は実エンジン上ではasm.jsの最後のステップとしてGCが行われます。
著名なemscriptenのベンチマークのようにArrayBufferが使われていたり、そもそも最初から最後までasm.js空間で実行される場合にはGCされないとみなすことが出来ますが、手描きの場合などで高速化のために部分的にasm.jsでのモジュールを呼び出す場合などには、実質的にasm.js側でGCが行われるとみなされます。
Re:ネイティブコードに近付いて当然 (スコア:1)
> そもそも最初から最後までasm.js空間で実行される場合にはGCされないとみなすことが出来ますが
ということは、やっぱりGCされないと考えていいんですよね?
多分"use asm"が定義されているスコープ内ではGCされないだろうなという認識であってるかな。
関数毎にも指定できるから、その関数を抜けるとGCが走ると。
Re: (スコア:0)
超具体的にどこのタイミングで可能なのか/すべきなのか/今されてるのかの全ては分かりませんが、
asm.jsの処理が終わる時にJS側ではないので、つまりasm.js側でGCが行われることは事実です。
ほぼasm.jsだけで完遂するものであれば、OSとC言語でのmallocの例のようにGCが『無い』とみなすことも自然でしょう。
また、そもそもいろいろな記事でGCが無いかのように言われるのはmallocを使うような言語から変換するときは、ほぼ全域でArrayBufferがメモリ空間として使われるから、そのことを言っているんだと理解してください。
実際はベンチマーク等の特殊な場合を除き、実アプリではIOや他ライブラリとの絡みも多く必要になってくるので、ArrayBuffer以外の部分で起こるGCはOSとC言語の例のように無かったようにみなすのは不自然となります。
Re: (スコア:0)
> 今回の実行時間1.5倍というのは、ネイティブのコードから機械的に変換されたコードでの場合であり
本当にわかっているのですか?
今回のケースは前回と同じくC++からemscriptenで変換されたものです
ネイティブのコードは関係ありません
Re: (スコア:0)
ネイティブコード、x86かARMはわかりませんが、clangの出力コードをasm.jsに変換したのではないということです
Re: (スコア:0)
そういう意味ではありません。
大袈裟に言うと、仮にスクラッチでJITが活きる場所は非asmで、そうでない部分はasm.jsで手書きで移植した場合、勿論元のコードに明らかな無駄がなくとも、emscriptenで機械的に出力されるコードよりはるかにパフォーマンスの向上を見込めるということです。
そこまでいかなくても現実的に、数値演算ばかりではない、複雑な実アプリの場合こそ、JITが活きやすいので、そういう場合に「少しの苦労で」asm.jsと非asmを組み合わせることで、ネイティブと同等のパフォーマンスまで持っていける段階まで来たということです。
Re: (スコア:0)
そういう一般論ではなく
> 今回の実行時間1.5倍というのは、ネイティブのコードから機械的に変換されたコードでの場合であり、
とあなたは限定しています
間違いをお認めになれないのなら、それはつまり何もわかっていないということの証拠です
Re: (スコア:0)
どこが間違いだと思われてるのかさっぱり分かりません。
「ネイティブのコードから機械的に変換されたコードの場合」というのは「emscriptenで生成されたコードの場合」ということであり、
それとそれに人力を加えた場合にパフォーマンスの比較の話の繋がりに何もおかしなところはないと思いますが、どこが引っかかっていますか?
Re: (スコア:0)
> 「ネイティブのコードから機械的に変換されたコードの場合」というのは「emscriptenで生成されたコードの場合」ということであり、
emscriptenの入力はネイティブコードではありませんよ
もしかしてそんなこともご存じなかったとは
Re: (スコア:0)
はぁ、、、よくわかりませんね。
もしかして直接入力に取るのはLLVMのコードだから、「間接的に」という言葉を入れろとかいう揚げ足取りですか、、、?
流石に汲み取って欲しいのですが、、、
それだけですか?
Re: (スコア:0)
LLVMのコードはネイティブコードではありませんよ
Re: (スコア:0)
ネイティブ→LLVM→JS
これでいいですか?
何のためにそこに拘るのかが分かりませんが
Re: (スコア:0)
理解しました
でもやっぱり間違いです
少なくとも今回のベンチマークでは、clangが生成したネイティブのコードをさらにLLVMコード経由でasm.jsにはしません
Re: (スコア:0)
すみませんね。
ここで言うネイティブとはCやC++言語のことを指して言ったのですよ。
Re: (スコア:0)
ここで言うネイティブとはCやC++言語のこと
激しく頭悪そうワロタw
Re: (スコア:0)
JavaScriptと対比させてJavaやCなんかのことをネイティブって一般的に呼ばれてるよ
ネイティブコードではなくネイティブ(言語)「の」コードなんだから全然おかしくないと思う
Re: (スコア:0)
JavaScriptと対比させてJavaやCなんかのことをネイティブって一般的に呼ばれてる
激しく頭悪いクソワロタww
Re: (スコア:0)
言語の話になるとこういうのが湧くな
ここは2chじゃねーつの
Re: (スコア:0)
煽られても論拠挙げて反論すんのが2ch、スラド民にそこまでの知性は期待できまい。