任天堂「今後C++は捨てJavaScriptで開発していく」 (887ﾚｽ)
上下前次1-新
432: 2013/04/03(水)10:52 AAS
真面目にＪＳでのゲーム開発を議論するスレかとおもいきや、普通の初心者スレになっているとは。
433: 2013/04/03(水)10:53 AAS
>>431
JavaScriptでCと同等の処理が書けるかって話じゃなくて、同等の速度がだせるかって話なんですけど。
434: 2013/04/03(水)10:56 AAS
emscripten はそういうのじゃないとおもうんだ
c->js はかのうかもしれない js->c は範疇外だろう?
435(2): 2013/04/03(水)10:57 AAS
逆にJavaScriptソースと同等機能を実現するC、アセンブラソースを作り出すことも可能。
JavaScript ⇒ C、アセンブラ ⇒ バイナリ としたらJavaScriptも速く出来る。
436: 2013/04/03(水)10:58 AAS
「この処理系でJSを実行したらCと同等の速度になる」って実例をバーンと出せば
終わる話なのに、できないでいろいろ理屈を言ってることは、やっぱ遅いんだな。
わかりました。
437: 2013/04/03(水)10:59 AAS
ちょっとまてよｗ
>>401 = >>425 かよ
真面目にレスして損したわ･･････
438: 2013/04/03(水)11:00 AAS
>>435
動的型の言語は単純にCに変換できないでしょ。
439: 2013/04/03(水)11:03 AAS
>>435
＞JavaScript ⇒ C
これで作られるCコードを速度まで同等に最適化するのが難しいわけよ
莫大な計算量が必要で現実的じゃない
440(2): 2013/04/03(水)11:08 AAS
C++からJavaScriptへ変換し、さらにJavaへ移植する話の続き
外部ﾘﾝｸ:d.hatena.ne.jp
［GDC 2013］Webブラウザで「Unreal Engine 3」がヌルヌル動く!? ゲームエンジンを5日でHTML5へ移植した驚きの技術とは
外部ﾘﾝｸ:www.4gamer.net
モジラ、ブラウザ上でゲーム機並みの3Dゲーム体験を可能にする取り組みなど発表
外部ﾘﾝｸ:headlines.yahoo.co.jp
Mozilla、Firefox 22 にブラウザゲームを高速化する「asm.js」を搭載- インターネットコム（2013年3月28日12時00分）
省9
441: 2013/04/03(水)11:09 AAS
ja.wikipedia.org/wiki/%E5%A4%89%E6%8F%9B%E8%A8%80%E8%AA%9E
asm.js もそうだけど 中間言語というかtranspilerかますと
復元できない
復元までふくめるとcoffeeみたいになるし…あれ解釈エンジンは
おなじだからこそparserラクしてる面もあるし
442(1): 2013/04/03(水)11:14 AAS
>>440
どっかの記事だと、asm.js でもネイティブコードの倍の遅さらしいけど。
(倍でもすごいけど)
443(1): 2013/04/03(水)11:16 AAS
で、俺の持ってるPCのCPUとGPUを解析して完全に最適化されたコマンドを吐いてくれるJITエンジンはいつ作ってくれるの？
444: 2013/04/03(水)11:21 AAS
>>440
asm.jsのコードはJavascriptのコードとしても実行できるけどその場合はかなり遅い
モジラのVMは、asm.jsのコードをjavascriptのコードとしてではなくて
特殊な静的言語で書かれたコードとして解釈して実行することができて、
その場合は同じようなのネイティブコードの半分ぐらいの実行速度が出る
つまりこれはJavascriptのコードを早く実行する技術とは全然違う
445: 2013/04/03(水)11:23 AAS
Mozilla、Firefox 22 にブラウザゲームを高速化する「asm.js」を搭載 - Infoseek ニュース
Mozilla のゲームプラットフォーム戦略を担当する Martin Best 氏は InternetNews.com に対し、
asm.js コードは、JavaScript 言語の中核要素を使用すると述べた。
基本的には、asm.js を意識して書かれたコードのみが高速化されることになる。
だがこの技術には後方互換性があり、Best 氏によれば、ブラウザが asm.js をサポートしていない場合であっても、
開発者は非常に効率の高いコードを書けると述べている。
外部ﾘﾝｸ:news.infoseek.co.jp
446: 2013/04/03(水)11:29 AAS
反論がなくなったから「Javascriptは処理系しだいでCと同等の速度がでる」って話は
間違いでしたって認めたって解釈させてもらいます。
447(1): 2013/04/03(水)11:31 AAS
>>442
処理内容による。
例えば、asm.jsが円周率を1億万桁求める事をサポートし
それがC言語で書かれていてバイナリとして組み込まれていれば、
単体ネイティブバイナリと計算速度は同等だろう。
448: 2013/04/03(水)11:35 AAS
>>447
それは、速度を求められるところはCで書かないとCと同等の速度はでないってことですね。
449: 2013/04/03(水)11:38 AAS
>>443
CPU負荷や空きメモリ、処理対象データに合わせた動的最適化も追加でよろしく！
450: 2013/04/03(水)11:43 AAS
処理の重いところはグラフィックカードがやるから
ライブラリーに投げるだけでしょ？
ロジック部分の生産性が上がるなら言語部分の
速度を議論するのは不毛じゃないの？
ただ、プログラムの規模が大きくなってきたときに
Javascriptってかえって生産性低いのではないだろうかって
気がするんだけど
省10
451: 2013/04/03(水)11:47 AAS
VB.NETが生産性最高
452: 2013/04/03(水)12:02 AAS
JavaScript処理系自体がほぼC/C++製だ。
JavaScript処理系をJavaやJavaScriptやC#や純関数型で書くのも可能だろうが。
速くしたい所を念入りに最適化するのは当然。
453(2): 2013/04/03(水)12:39 AAS
Cコンパイラが出力した機械語と速度比較するのが間違い。CコンパイラソースをJavaScriptソースに変換できれば機械語として同じ速度だ。
言語性能は同じ土台のインタプリタで比較しろ。
CINT（シーイント）
CINT はC/C++ 言語インタープリタです。
CINTを使うと、C/C++で書かれたソースコードをコンパイルせずに実行できます。
90%-95% 実行可能だそうです。
外部ﾘﾝｸ[php]:belle.sci.fukuoka-u.ac.jp
省8
454: 2013/04/03(水)12:50 AAS
>>453
＞CコンパイラソースをJavaScriptソースに変換できれば機械語として同じ速度だ。
Cコンパイラソースって何だ？
Cコンパイラのソースコード？
Cコンパイルするプログラムのソースコード？
何と何が機械語として同じ速度になるの？
455: 2013/04/03(水)12:52 AAS
>>453
ネイティブのCじゃなくてインタプリタのCとJavascriptを比較しろって意味?
そうする意味がわからない。
それにJavascriptじゃCの9割以上の性能出すのムリなんじゃないの。
456: 2013/04/03(水)12:54 AAS
Ｃの生産性の悪さとインタープリタの性能の低さを合わせた最強のツールか
457: 2013/04/03(水)12:55 AAS
無駄に改行入れる奴って例外なくバカだね
458: 2013/04/03(水)12:58 AAS
もはや自分でも何言ってんのか分かってなさそうだ
最近のコンパイル言語はコンパイルからJITコンパイルに移行しつつ有って最近のスクリプト言語もインタプリトからJITコンパイルに移行しつつ有るというのに、コンパイル言語の不完全なインタプリトとスクリプト言語の最新JITコンパイルを比較とか何がしたいんだ。
459(1): 2013/04/03(水)13:00 AAS
機械語、CPUが直に理解できるワードはC言語とは別もの。
機械語で比較するならば、Cコンパイラと同じ出力を作れれば同速度であるといえる。
Cコンパイラのソースコードを移植できる言語であれば、C言語と同速度。
460: 2013/04/03(水)13:07 AAS
>>459
何のプログラムコードで書いた何をするプログラムが同速度になるの？
461(1): 2013/04/03(水)13:12 AAS
459だとC言語ソースをJavaScriptでコンパイルしたものが
C製Cコンパイラと同速度という意味だが。
JavaScriptソースとC言語ソースに互いに変換可能で無駄がないとすれば
JavaScriptソースもJavaScript製コンパイラでC言語並の速度が出るということ。
462(2): 2013/04/03(水)13:15 AAS
>>461
＞JavaScriptソースとC言語ソースに互いに変換可能で無駄がない
ここが間違ってる
JavascriptソースからC言語ソースへの変換は、Javascriptソースのほうが情報量が少ないから、
同等なものに変換するには事実上不可能なほどの計算量が必要になる
463: 2013/04/03(水)13:18 AAS
>>462なので、
JavaScriptソースをJavaScript製コンパイラでC言語並の速度を出すというのは不可能
464(1): 2013/04/03(水)13:28 AAS
JSって変数が全部バリアント型なのにC並の速度が出る。。。わけないだろバカ
465: 2013/04/03(水)13:32 AAS
動的型付言語とは何なのか
CコンパイラがCソースコードをどのようなマシン語に変換するのか
この辺を勉強してみれば>>462が如何に難しいか理解できる
466: 2013/04/03(水)13:38 AAS
なんか致命的な勘違いか致命的な極論が混ざってるようにしか見えんわ
ゲスパーしとくと、JSにコンパイラ移植してもコンパイルしたコードはJSの実行環境では動かないから意味は無いしコンパイル元のコードがJSじゃないから本末転倒だぞ
>>464
そこを全部型付きにして高速化を図ろうってのが最近のトレンドだが、もはや人が書くような言語じゃねと言わんばかりに別言語の中間コードから型ヒント付きJSを生成する技術が登場する始末
JSを元にした中途半端な謎中間言語とか誰得状態だし、なんてーかそこまでやるならMSILでもLLVMでもいいからそのへんのJITレイヤをそのまんまJSに組み込んで中間コードからFunctionオブジェクト生成する機能でも追加しろよって感じだ
467(3): 2013/04/03(水)13:47 AAS
C言語が機種依存して最適化してる。C言語なみの速度がJavaScriptで実現可能かということは原理的には可能だろ。
C++のテンプレート使うと、必要な型のすべてのバイナリを生成し、バイナリの中身は型付き変数として動作する。
JavaScriptコンパイラを作り最適化したらいいだけ。
468(1): 2013/04/03(水)13:53 AAS
>>467
原理的に可能って、JSでコンパイル時点ですべての型を予測して
あらかじめ生成するなんてムリだろ。
469(1): 2013/04/03(水)13:55 AAS
>>467
テンプレートの場合に型が変化するのはそのテンプレート引数の組み合わせだけだけど、
Javascriptの関数の場合に型が変化する組み合わせはそれこそ莫大な数になる可能性が考えられるわけよｗ
しかも実行と同等なことをしてみないと必要な組み合わせが判明しない
なので無理
470: 2013/04/03(水)13:56 AAS
C言語自体は機種依存してないよな
言語とライブラリを分離してるだけで
#ifdef使えば
UNIXとWindowsですらソースコードレベルのポータビリティが有る訳で
API部分を抽象化しても結局うまくいかないのはJavaが証明したし
JavaScriptもそれを繰り返すことになるだろう
471(3): 2013/04/03(水)15:51 AAS
>>468>>469
あまりに実行中に新型の型を生成するようではエラー出してコンパイルを停止させる。
どこで新型が生成されるか事前に判別できるから、無限ならず有限で済むケースでのみコンパイルを成功させる。
472: 2013/04/03(水)16:46 AAS
>>471
ちょっと複雑なコードを書いたらすぐエラーになるか、コンパイルが終わらなくなりそう。
473: 2013/04/03(水)17:06 AAS
>>471
ごまかすな
お前が言ってたのはJavascriptのコードをCのコードと同等な速度に変換できるってことだろ？
変換可能な部分のみ変換するのでは
JavascriptのコードをCのコードと同等な速度に変換できるとは言えない
その程度だったら事前に変換してコンパイルじゃなくて、JITコンパイルで十分なのよ
474: 2013/04/03(水)17:10 AAS
GCありきで書かれたクソコードを静的解析してスタックに割り付ける作業に戻れ
475(2): 2013/04/03(水)19:12 AAS
JavaScriptでC言語に並べるのは事実。
CソースをJavaScriptソース内にStringとしてコピペして
JavaScript製Cコンパイラに通したら、C製Cコンパイラと同じ実行ファルを生成でき
速度はC製Cコンパイラと一緒。
477: 2013/04/03(水)19:35 AAS
>>475
つまりCで書かないとはやくならないのか。
478(1): 2013/04/03(水)20:04 AAS
最適化トランスコーダを書いてさらにCコンパイラで最適化だ！！！
聞きかじりだが、PyPyみたいになるかもしれんぞ。
479(1): 2013/04/03(水)20:05 AAS
っていうか、LLVMのフロントエンド書くんだ！！
480: 2013/04/03(水)21:40 AAS
LLVMはバックのほうが windows でまともにうごくかな!
481: 2013/04/03(水)21:57 AAS
twitter.com/shelarcy/status/319102598693138433
GHCのSIMD命令対応
がんばるHaskeller...
482: 2013/04/03(水)22:13 AAS
まあ、関数型は並列性抽出しやすいからな。
483: 2013/04/04(木)03:26 AAS
>>467
全てではなく呼び出し関係を追いかけて出現した型だけだし、一度確定した型はC++では変化しない
JavaScriptの場合型が変化するどころか型の定義そのものが後から変化してしまうから手に負えない
>>471
「どこで新型が生成されるか事前に判別でき」「ない」
君の大好きチューリングマシンの停止性問題と同じ理屈で、ある条件である部分(ある内容の型生成)が実行されるかは判別できない
結果、実行中に実際生成された型でその都度ネイティブコードを生成するJIT実行か、連想配列を使ったインタプリタに毛が生えたような実装になる
省3
484: 2013/04/04(木)03:42 AAS
>>478-479
素のJavaScriptで型特定は無理ゲーだし諦めて、もうJScript.net(≠JScript)でよくね？
型ヒントとか色々付けないとコンパイル通らないけど、一応IL吐けるからC++/CLRといい勝負できるかもしれん
もっとゴリゴリやりたい部分はMSILからFunction生成で誤魔化すｗ
485: 2013/04/04(木)21:25 AAS
なんでMS前提なんだよ
486(1): 2013/04/05(金)10:08 AAS
JavaScriptと実用レベルで互換が有ってネイティブコードまでまともに変換できる製品がJScript.netくらいしか思いつかなかったんだ
吐けるバイナリはMSILだけどMSILのJITコンパイルは起動時/インストール時にほとんど終わるからJSのコンパイル基盤って意味では一番まともかと
JScript.netが吐き出すILやそのアセンブリを見たこと無いからなんとも言えんけど、
ILの品質次第ではJavaScriptで書いたコードが等価なC/C++で書いたコードとタメ張るかもしれん
487: 2013/04/05(金)23:13 AAS
>>486
たぶんないなｗ
488(1): 2013/04/05(金)23:51 AAS
まぁ最近の家庭用据置ならちょっとしたアプリやホビープログラムならスクリプトでお手軽に
ってのはありじゃね
商用のフルパッケージでそんな事してたらアホだけど
489: 2013/04/06(土)04:44 AAS
いいからファミリーべーしっくやってろｗ
490: 2013/04/06(土)09:12 AAS
>>488
FPSのなかのLuaさん「・・・」
491: 2013/04/06(土)10:25 AAS
いまや商用のフルパッケージなゲームでこそ、
DSLとしてスクリプト言語的なものを使うのは普通だね
492: 2013/04/06(土)10:35 AAS
大きなゲームでスクリプト使うのは
・リロードで差し替えられることによるトライ＆エラーしやすさ
・ビルド環境不要
という面が大きい。
Lua好きなんだけど、
PCアプリではBlender-Pythonみたいなあまり有名なのが無いのはなぜなんだろう。
493: 2013/04/06(土)12:51 AAS
Moai SDKでググれ
494: 2013/04/06(土)21:04 AAS
AGK / DarkBASIC / Basic4GL / 99BASIC 2013 Part.1
2chｽﾚ:pcnews
世界中でダントツの人気！各BASICの特徴
・ AGK App Game Kit（外部ﾘﾝｸ:www.appgamekit.com）
海外で主流のマルチプラットフォームの開発環境。
C言語風味の記述が特徴で、中身はDarkBASIC。
Ver1.088で3Dインターフェイス対応。
省12
495: 2013/04/07(日)09:54 AAS
[参考] ベンチマーク - FOR-NEXT10億回ループ
（表１）ベンチマークテスト結果（数字が小さいほど速い）
MASM32 JavaScript DarkBASIC AGK 99BASIC
---------------------------------------------------------------------------------
PC（CeleronD2.66GHz）[sec] 0.7828 7.772 20.853 65.423 1532.0
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
MASM32を１とする相対倍率 1.0 9.928 26.638 83.575 1957.0
省10
496: 2013/04/07(日)10:36 AAS
そういうアプリ内の処理時間の割合が20%未満のグループに入るものの比較をしてもほとんど意味ないよ。
80%に含まれるものの比較をしなきゃ。
497: 2013/04/07(日)10:40 AAS
それと、例えば1秒とかの単位時間あたりの処理回数も考慮しないとね。
1秒あたりたかだか100回程度しか行わないのに、10億回の処理時間を比べても意味ないし。
498(1): 2013/04/07(日)10:47 AAS
ループ速度の測り方は難しいけど
ループが一番処理として多いのは間違いないだろ
批判が適当すぎ
499: 2013/04/07(日)10:57 AAS
そもそもBASICと比較してどうすんだ
500: 2013/04/07(日)11:07 AAS
つまんね
501: 2013/04/07(日)11:13 AAS
[参考] ベンチマーク - FOR-NEXT10億回ループ
（表２）ランキング表
開発環境 タイム[sec] MASM32を１とする相対倍率
------------------------------------------------------------------------------------
PC（CeleronD2.66GHz）. MASM32. 0.7828 1.0
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
PC（CeleronD2.66GHz）. JavaScript 7.772 9.928
省13
502: 2013/04/07(日)11:26 AAS
「開発環境：JavaScipt」から滲み出る頭の悪さ
503: 2013/04/07(日)11:27 AAS
>>498
重要なのは、ループ内の処理速度であってループそのものの処理速度ではない。
まあループそのものの処理速度が致命的に遅いのなら問題だが。1回1msかかるとか。
504(1): 2013/04/07(日)11:44 AAS
ループそのものから重ければ推して知るべし
恥かいちゃったね
505: 2013/04/07(日)12:10 AAS
>>504
推して知れないからいろんなahootoutのページでは様々な切り口でベンチしてるんだよ。
それと、今回任天堂がやろうとしているドメインの機能やAPIを考慮したベンチじゃないと意味ないね。
506: 2013/04/07(日)12:12 AAS
まあただのループ比較したって意味ないよね
LINPACKみたいに演算やデータアクセスのあるのを比較すればいいのに
507(1): 2013/04/07(日)12:15 AAS
結構バカが吊れたなｗ
508: 2013/04/07(日)12:26 AAS
今どき釣り宣言とか・・・
509: 2013/04/07(日)12:31 AAS
>>507
顔真っ青だぞお前
510: 2013/04/07(日)12:43 AAS
本日のロバ＝任天堂ｗ
511: 2013/04/07(日)12:47 AAS
わからないとわめくバカｗ
512: 2013/04/07(日)12:52 AAS
つか、masmの10倍くらいしか時間がかからないんだったら問題ないよね
上下前次1-新書関写板覧索設栞歴
あと 375 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ ｱﾎﾞﾝOFF
ぬこの手 ぬこTOP 0.030s