アカウント名:
パスワード:
前半の文章は全く誤りです。asm.jsでもGCは働きます。ただArrayBufferをメモリ空間かのように使うことでGCに頼らない方法を推奨しており、emscriptenも積極的にそういったコードを出力します。ただそれはasm.jsとは直接関係なく普通のJSにおいてもかなり強力なテクニックです。
後半はその通りです。本質的にJITの性質を引き出すことで、部分的にネイティブかそれ以上のパフォーマンスを引き出せるケースはいくつもあります。今回の実行時間1.5倍というのは、ネイティブのコードから機械的に変換されたコードでの場合であり、JSの限界性能ではないということです。おそらく現在でもそれを考慮すると、JSはネイティブに匹敵する速度になったと言って良いと思われます。
> 今回の実行時間1.5倍というのは、ネイティブのコードから機械的に変換されたコードでの場合であり
本当にわかっているのですか?今回のケースは前回と同じくC++からemscriptenで変換されたものですネイティブのコードは関係ありません
そういう意味ではありません。大袈裟に言うと、仮にスクラッチで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)に設定を変更する必要があります。
192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり
ネイティブコードに近付いて当然 (スコア:2)
時間を掛けてコンパイルできない分、凝った最適化が出来無い中での結果なんで、そこは凄いなと思う。
ただ、これでWebGL使って全画面のアプリを作れば、HTMLとか全て無視した普通のアプリが動いちゃうんだろうな。
まぁネイティブアプリが簡単にマルチプラットフォーム化できればありがたいけど。
Re: (スコア:0)
前半の文章は全く誤りです。
asm.jsでもGCは働きます。ただArrayBufferをメモリ空間かのように使うことでGCに頼らない方法を推奨しており、emscriptenも積極的にそういったコードを出力します。ただそれはasm.jsとは直接関係なく普通のJSにおいてもかなり強力なテクニックです。
後半はその通りです。
本質的にJITの性質を引き出すことで、部分的にネイティブかそれ以上のパフォーマンスを引き出せるケースはいくつもあります。
今回の実行時間1.5倍というのは、ネイティブのコードから機械的に変換されたコードでの場合であり、JSの限界性能ではないということです。
おそらく現在でもそれを考慮すると、JSはネイティブに匹敵する速度になったと言って良いと思われます。
Re: (スコア:0)
> 今回の実行時間1.5倍というのは、ネイティブのコードから機械的に変換されたコードでの場合であり
本当にわかっているのですか?
今回のケースは前回と同じくC++からemscriptenで変換されたものです
ネイティブのコードは関係ありません
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、スラド民にそこまでの知性は期待できまい。