私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ+ JavaScript の質問用スレッド vol.135 +
JavaScript スレッド一覧へ / JavaScript とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 :
レスフィルター : (試験中)
phpよりjavascriptを勉強すべき、という理由を教えてください 私は頭が悪いので分かりやすく頼みます
PHPを作ってるところは一つ
JavaScriptはMS、Google、Apple、Mozillaと大企業が力を注いている
JavaScriptはMS、Google、Apple、Mozillaと大企業が力を注いている
javascriptも、もはやc++やその他言語を呼び出すだけのものになりつつある
C++はもはやJavaScriptから呼び出すライブラリに成り下がったんだな
(javascriptの実行速度が遅すぎて使えないからこういう方法が生まれたんだけど…)ボソッ
でファミコンエミュレータwasmにしてみたらjsより遅かったんでしょワロスwwwww
>>411
ブラウザ /JS版 /Wasm版
Chrome 63/4.36ms/5.68ms
Firefox 58/5.76ms/3.98ms
Safari 11/9.98ms/4.21ms
これ?要はchromeの実装がクソ雑魚だったってだけでしょ
firefoxとsafariはjs版を大きく超えてる
ブラウザ /JS版 /Wasm版
Chrome 63/4.36ms/5.68ms
Firefox 58/5.76ms/3.98ms
Safari 11/9.98ms/4.21ms
これ?要はchromeの実装がクソ雑魚だったってだけでしょ
firefoxとsafariはjs版を大きく超えてる
>>406
1週間~10年といったところ
1週間~10年といったところ
なんでchromeで遅くなってるの?
chrome、前はjsの最適化で最速とか言ってたけど
sandboxとかセキュリティ絡み?
chrome、前はjsの最適化で最速とか言ってたけど
sandboxとかセキュリティ絡み?
>>412
ご覧くださいwww「javascriptの実行速度が 遅 す ぎ て 使 え な い」とまでイキッておいてコレwwwww
ご覧くださいwww「javascriptの実行速度が 遅 す ぎ て 使 え な い」とまでイキッておいてコレwwwww
cとphpやpyの差みたいに10倍かそれ以上速くなるもんだとばっかり思ってた
カスだな
カスだな
コンパイルの手間かけてまでこの程度かよw
時間は有効に使えよ?みんなお前に付き合うほどヒマじゃねーんだw
時間は有効に使えよ?みんなお前に付き合うほどヒマじゃねーんだw
これでセキュリティに穴が見つかろうものならまるで利用価値なしのゴミ屑扱いになってしまう
>>413
意地悪
意地悪
wasm使うならもはやjs発である必要性ないと思うんだが
js使いたいだけっていう
違うコンパイル言語開発しろって
js使いたいだけっていう
違うコンパイル言語開発しろって
>>403-406
プログラマーが、クソ言語のPHP を使う理由がない
Ruby on Rails などのフレームワークを使うけど、
画面は、Vue.js など、JavaScript(JS) になるので必須
初心者は、Ruby, JS を数年やればよい。
それ以外の言語は難しいから、数年後に始める
プログラマーが、クソ言語のPHP を使う理由がない
Ruby on Rails などのフレームワークを使うけど、
画面は、Vue.js など、JavaScript(JS) になるので必須
初心者は、Ruby, JS を数年やればよい。
それ以外の言語は難しいから、数年後に始める
wasm, wasmってまあ良く聞くけど
・wasmの性能って「元の言語/コードの効率性」と「wasm形式にしてくれるコンパイラの(最適化)性能」と
「ブラウザの方のwasm動作環境の性能」の全部に左右されんだよね?
・「wasmはロード時間短縮にはなるけど動作速度は変わらない」って主張が今でもいくらか見られるけど
jsで動かしてたものをc-wasmに変えれば動作速度は劇的に改善される可能性もまあ普通にあるよね?
・jsと違って低次元なメモリ管理できちゃうけど、
wasmが個々のwasmに割り当てられたメモリ領域以外を読み書きできちゃって
セキュリティ的に大問題になる、ってことは生じ得ないの?
activexで脆弱性突いてウィルス散布、みたいな現象はノーサンキューなんだけど
・wasmの性能って「元の言語/コードの効率性」と「wasm形式にしてくれるコンパイラの(最適化)性能」と
「ブラウザの方のwasm動作環境の性能」の全部に左右されんだよね?
・「wasmはロード時間短縮にはなるけど動作速度は変わらない」って主張が今でもいくらか見られるけど
jsで動かしてたものをc-wasmに変えれば動作速度は劇的に改善される可能性もまあ普通にあるよね?
・jsと違って低次元なメモリ管理できちゃうけど、
wasmが個々のwasmに割り当てられたメモリ領域以外を読み書きできちゃって
セキュリティ的に大問題になる、ってことは生じ得ないの?
activexで脆弱性突いてウィルス散布、みたいな現象はノーサンキューなんだけど
そもそもwasmっていうのは既存のサイト速くするものではないからな
既存のサイトは、サーバー側でバッチ処理をさせるという設計
クライアントでやることが少ないから、いくらwasmでクライアントが
速くなったとしても効果は殆ど無い。
ぶっちゃけるとwsamの主な用途はゲームだよ
ゲームは反応速度が重要なのでバッチ処理でさせると成り立たない
あとはせいぜいグラフィックソフトぐらいだろう
既存のサイトは、サーバー側でバッチ処理をさせるという設計
クライアントでやることが少ないから、いくらwasmでクライアントが
速くなったとしても効果は殆ど無い。
ぶっちゃけるとwsamの主な用途はゲームだよ
ゲームは反応速度が重要なのでバッチ処理でさせると成り立たない
あとはせいぜいグラフィックソフトぐらいだろう
ユーザに気付かれないようにクライアントに高処理効率でマイニングさせるとかな
>>426
WASMはJSエンジンのバックエンドを流用できるよう設計されていて
現状ではGCもなくほぼasm.jsと同じだからasm.jsのバックエンドが使われてるよ
正確には最近はasm.jsの方がWASMにコンパイルされてWASMのバックエンドで動くんだけど
だから実行速度に関してはJSの限界というかasm.jsと同等になる
ただこれからSIMDが入ったりして、最適化も進めば
原理上ターゲットを絞りきれないネイティブコードより早くなることもあり得る
ただJSで動かしていたものをWASMにすれば早くなるかと言うとそういうものではない
asm.jsでも同じだが、JS-WASM間の関数のやり取りにはオーバーヘッドがあって、
インライン化などの相互最適化も効かないので
基本的に沢山呼び出される小さな関数をWASMにすると性能は悪化する
だから大きな処理を丸っとWASMにするという使い方が一番良い
それと別に低次元なメモリ管理はできない
WASMにとってのメモリとはただのArrayBufferだから
勿論サイドチャネル攻撃はいくらかできるがそれはもうWASMに限った話ではないので仕方がない
WASMはJSエンジンのバックエンドを流用できるよう設計されていて
現状ではGCもなくほぼasm.jsと同じだからasm.jsのバックエンドが使われてるよ
正確には最近はasm.jsの方がWASMにコンパイルされてWASMのバックエンドで動くんだけど
だから実行速度に関してはJSの限界というかasm.jsと同等になる
ただこれからSIMDが入ったりして、最適化も進めば
原理上ターゲットを絞りきれないネイティブコードより早くなることもあり得る
ただJSで動かしていたものをWASMにすれば早くなるかと言うとそういうものではない
asm.jsでも同じだが、JS-WASM間の関数のやり取りにはオーバーヘッドがあって、
インライン化などの相互最適化も効かないので
基本的に沢山呼び出される小さな関数をWASMにすると性能は悪化する
だから大きな処理を丸っとWASMにするという使い方が一番良い
それと別に低次元なメモリ管理はできない
WASMにとってのメモリとはただのArrayBufferだから
勿論サイドチャネル攻撃はいくらかできるがそれはもうWASMに限った話ではないので仕方がない
ネイティブより速くとか無理ゲーだろ
C/C++で書いたアプリより速く計算しますってことだぞ
C/C++で書いたアプリより速く計算しますってことだぞ
jsが超早くなった!! cよりも早く!!
→ c側のコードが糞過ぎただけでした
chromeのjs処理が**より数段早くなった!!
→ chromeが決め打ち特化でチューンした部分だけでの話でした
この手の誤った性能比較話を連想した
→ c側のコードが糞過ぎただけでした
chromeのjs処理が**より数段早くなった!!
→ chromeが決め打ち特化でチューンした部分だけでの話でした
この手の誤った性能比較話を連想した
ブラウザが仮想マシンの代わりになるのはいいけど
そのブラウザが乱立してる状況じゃ安定性は得られんよね
結局Windows OSみたいな独裁体制にしないと
そのブラウザが乱立してる状況じゃ安定性は得られんよね
結局Windows OSみたいな独裁体制にしないと
>>431
全然無理じゃない
そこらのネイティブコードっていうのは多くの環境に対応するため最新のCPU機能を使いきれずコンパイルされてるから
ちょっとしっかりしたのだとスイッチ使ったりインストール時にコンパイルするけど
それでも実行の直前にコンパイルするのに原理的に勝りはしない
WASMならそれこそ10年前に書いたコードでも最新の機能を使って最新のコンパイラでコンパイルされる
まあ現実未だ可能性の話でしか無いが、中間コンパイルというものにはそういうメリットが昔からある
コンパイルするということは書いたコンテキストが失われるということだから
それに将来的にJITも働くようになればもっと最適化の可能性が広がる
無理ゲーだが原理的な可能性はあるということ
特に個人的にはメニーコアの時代がやってきてるのにOSが支援が弱い
パラレリズムとそのバランサをブラウザにやってもらいたい
>>432
決め打ちチューンは正当な最適化手段
可能性の高い方に賭けるというのはCPUでさえもやってること
全然無理じゃない
そこらのネイティブコードっていうのは多くの環境に対応するため最新のCPU機能を使いきれずコンパイルされてるから
ちょっとしっかりしたのだとスイッチ使ったりインストール時にコンパイルするけど
それでも実行の直前にコンパイルするのに原理的に勝りはしない
WASMならそれこそ10年前に書いたコードでも最新の機能を使って最新のコンパイラでコンパイルされる
まあ現実未だ可能性の話でしか無いが、中間コンパイルというものにはそういうメリットが昔からある
コンパイルするということは書いたコンテキストが失われるということだから
それに将来的にJITも働くようになればもっと最適化の可能性が広がる
無理ゲーだが原理的な可能性はあるということ
特に個人的にはメニーコアの時代がやってきてるのにOSが支援が弱い
パラレリズムとそのバランサをブラウザにやってもらいたい
>>432
決め打ちチューンは正当な最適化手段
可能性の高い方に賭けるというのはCPUでさえもやってること
前身のasm.jsなんて大分前からあるのに
なんで変な誤解されるんだろ
なんで変な誤解されるんだろ
全C使いと全Java使いの中央値の力量を持った者同士にアプリを作らせたら
Java使いの方がパフォーマンスも安定性も使い勝手も良いもの作ることは間違いない
でもAndroid開発でもそうだけど今どきCやC++を使うということは
「あえて」使ってるということだから、プログラマのレベルも高いし
それで比較的劣るものができるはずがない
Java使いの方がパフォーマンスも安定性も使い勝手も良いもの作ることは間違いない
でもAndroid開発でもそうだけど今どきCやC++を使うということは
「あえて」使ってるということだから、プログラマのレベルも高いし
それで比較的劣るものができるはずがない
>>443
証明したければ自分が相当数の被験者集めて実験したら?
証明したければ自分が相当数の被験者集めて実験したら?
俺はあくまで(経験上)間違いがないと言っただけで
証明が欲しいなら勝手に自分でやれってことだ
証明が欲しいなら勝手に自分でやれってことだ
>>448は無職の荒らしであって実はJavaもCも扱ったことがない
俺の経験上間違いない
俺の経験上間違いない
赤の他人の正しさを「証明」する人はいないが、「確認」ならするかもしれない
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / JavaScript スレッド一覧へ
みんなの評価 : 類似してるかもしれないスレッド
- + JavaScript の質問用スレッド vol.130 + (1001) - [97%] - 2017/11/25 20:45
- + JavaScript の質問用スレッド vol.137 + (1003) - [97%] - 2019/3/26 11:46
- + JavaScript の質問用スレッド vol.130 + (974) - [97%] - 2016/10/26 14:18
- + JavaScript の質問用スレッド vol.115 + (1001) - [97%] - 2014/5/29 16:16
- + JavaScript の質問用スレッド vol.131 + (1004) - [97%] - 2018/3/7 13:30
- + JavaScript の質問用スレッド vol.132 + (1001) - [97%] - 2018/4/19 11:00
- + JavaScript の質問用スレッド vol.133 + (1001) - [97%] - 2018/6/8 10:45
- + JavaScript の質問用スレッド vol.131 + (1000) - [97%] - 2017/1/25 8:01
- + JavaScript の質問用スレッド vol.136 + (1001) - [97%] - 2019/1/8 11:30
- + JavaScript の質問用スレッド vol.134 + (1001) - [97%] - 2018/8/3 23:15
- + JavaScript の質問用スレッド vol.138 + (1004) - [97%] - 2019/4/20 23:45
- + JavaScript の質問用スレッド vol.139 + (1001) - [97%] - 2019/5/27 15:15
- + JavaScript の質問用スレッド vol.105 + (1001) - [97%] - 2013/5/20 4:45
- + JavaScript の質問用スレッド vol.125 + (1001) - [97%] - 2015/10/7 17:45
- + JavaScript の質問用スレッド vol.118 + (1002) - [95%] - 2014/8/29 22:30
- + JavaScript の質問用スレッド vol.119 + (1002) - [95%] - 2014/10/3 15:30
- + JavaScript の質問用スレッド vol.117 + (1009) - [95%] - 2014/8/5 3:30
トップメニューへ / →のくす牧場書庫について