元スレ+ JavaScript の質問用スレッド vol.135 +
JavaScript覧 / PC版 /みんなの評価 :
401 = :
>>388の人気に嫉妬w
402 :
phpよりjavascriptを勉強すべき、という理由を教えてください 私は頭が悪いので分かりやすく頼みます
403 = :
PHPを作ってるところは一つ
JavaScriptはMS、Google、Apple、Mozillaと大企業が力を注いている
404 = :
javascriptも、もはやc++やその他言語を呼び出すだけのものになりつつある
405 = :
いつから呼び出せるようになったの?
406 = 402 :
>>403
なるほど、ありがとうございます
本当に死ぬ気で毎日勉強した場合、
理解できるようになるまでどれくらい掛かりますか
407 = :
>>405
去年の8月くらいから
WebAssembly -http://webassembly.org/
408 = :
C++はもはやJavaScriptから呼び出すライブラリに成り下がったんだな
409 = :
呼び出されることすらできなかった状態から成り上がったんやぞ。
410 = :
(javascriptの実行速度が遅すぎて使えないからこういう方法が生まれたんだけど…)ボソッ
411 = :
でファミコンエミュレータwasmにしてみたらjsより遅かったんでしょワロスwwwww
412 = :
>>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版を大きく超えてる
413 = :
>>406
1週間~10年といったところ
414 = :
>>412
え?たったそんだけしか違わないの?msって
人間が知覚できるレベルじゃないじゃん
415 = :
いやだって巨大なプログラム用だから
417 = :
>>412
ご覧くださいwww「javascriptの実行速度が 遅 す ぎ て 使 え な い」とまでイキッておいてコレwwwww
418 = :
cとphpやpyの差みたいに10倍かそれ以上速くなるもんだとばっかり思ってた
カスだな
419 = :
コンパイルの手間かけてまでこの程度かよw
時間は有効に使えよ?みんなお前に付き合うほどヒマじゃねーんだw
420 = :
これでセキュリティに穴が見つかろうものならまるで利用価値なしのゴミ屑扱いになってしまう
421 = 402 :
>>413
意地悪
423 = :
>>406
どういうところに行きたいかによるから何とも…試しにこういうのでもやってみれば?
http://prog-8.com/languages/es6
424 = :
wasm使うならもはやjs発である必要性ないと思うんだが
js使いたいだけっていう
違うコンパイル言語開発しろって
425 = :
>>403-406
プログラマーが、クソ言語のPHP を使う理由がない
Ruby on Rails などのフレームワークを使うけど、
画面は、Vue.js など、JavaScript(JS) になるので必須
初心者は、Ruby, JS を数年やればよい。
それ以外の言語は難しいから、数年後に始める
426 = :
wasm, wasmってまあ良く聞くけど
・wasmの性能って「元の言語/コードの効率性」と「wasm形式にしてくれるコンパイラの(最適化)性能」と
「ブラウザの方のwasm動作環境の性能」の全部に左右されんだよね?
・「wasmはロード時間短縮にはなるけど動作速度は変わらない」って主張が今でもいくらか見られるけど
jsで動かしてたものをc-wasmに変えれば動作速度は劇的に改善される可能性もまあ普通にあるよね?
・jsと違って低次元なメモリ管理できちゃうけど、
wasmが個々のwasmに割り当てられたメモリ領域以外を読み書きできちゃって
セキュリティ的に大問題になる、ってことは生じ得ないの?
activexで脆弱性突いてウィルス散布、みたいな現象はノーサンキューなんだけど
427 = :
そもそもwasmっていうのは既存のサイト速くするものではないからな
既存のサイトは、サーバー側でバッチ処理をさせるという設計
クライアントでやることが少ないから、いくらwasmでクライアントが
速くなったとしても効果は殆ど無い。
ぶっちゃけるとwsamの主な用途はゲームだよ
ゲームは反応速度が重要なのでバッチ処理でさせると成り立たない
あとはせいぜいグラフィックソフトぐらいだろう
428 = :
ユーザに気付かれないようにクライアントに高処理効率でマイニングさせるとかな
430 = :
>>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に限った話ではないので仕方がない
431 = :
ネイティブより速くとか無理ゲーだろ
C/C++で書いたアプリより速く計算しますってことだぞ
432 = :
jsが超早くなった!! cよりも早く!!
→ c側のコードが糞過ぎただけでした
chromeのjs処理が**より数段早くなった!!
→ chromeが決め打ち特化でチューンした部分だけでの話でした
この手の誤った性能比較話を連想した
433 = :
ブラウザが仮想マシンの代わりになるのはいいけど
そのブラウザが乱立してる状況じゃ安定性は得られんよね
結局Windows OSみたいな独裁体制にしないと
434 = :
>>431
全然無理じゃない
そこらのネイティブコードっていうのは多くの環境に対応するため最新のCPU機能を使いきれずコンパイルされてるから
ちょっとしっかりしたのだとスイッチ使ったりインストール時にコンパイルするけど
それでも実行の直前にコンパイルするのに原理的に勝りはしない
WASMならそれこそ10年前に書いたコードでも最新の機能を使って最新のコンパイラでコンパイルされる
まあ現実未だ可能性の話でしか無いが、中間コンパイルというものにはそういうメリットが昔からある
コンパイルするということは書いたコンテキストが失われるということだから
それに将来的にJITも働くようになればもっと最適化の可能性が広がる
無理ゲーだが原理的な可能性はあるということ
特に個人的にはメニーコアの時代がやってきてるのにOSが支援が弱い
パラレリズムとそのバランサをブラウザにやってもらいたい
>>432
決め打ちチューンは正当な最適化手段
可能性の高い方に賭けるというのはCPUでさえもやってること
435 = :
前身のasm.jsなんて大分前からあるのに
なんで変な誤解されるんだろ
436 = :
それで、javaはcより速くなりましたか?
437 = :
原理的に無理
438 = :
生理的に無理
439 = :
物理的に無理
440 = :
いつから、Javaの話になった?
441 = :
スレタイから
442 = :
全C使いと全Java使いの中央値の力量を持った者同士にアプリを作らせたら
Java使いの方がパフォーマンスも安定性も使い勝手も良いもの作ることは間違いない
でもAndroid開発でもそうだけど今どきCやC++を使うということは
「あえて」使ってるということだから、プログラマのレベルも高いし
それで比較的劣るものができるはずがない
443 = :
証明よろ
444 = :
>>443
証明したければ自分が相当数の被験者集めて実験したら?
445 = :
>>444
>>443ではないが、なぜ442が441の論を証明しなければならんのだ?
446 = :
ガイジだからさ
447 = :
俺の意見は間違いない
俺の意見をお前が証明しろ
448 = :
俺はあくまで(経験上)間違いがないと言っただけで
証明が欲しいなら勝手に自分でやれってことだ
449 = :
>>448は無職の荒らしであって実はJavaもCも扱ったことがない
俺の経験上間違いない
450 = :
赤の他人の正しさを「証明」する人はいないが、「確認」ならするかもしれない
類似してるかもしれないスレッド
- + 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
トップメニューへ / →のくす牧場書庫について