任天堂のゲームはこれまで,CやC++といったプログラミング言語で開発されており,
そのため高いパフォーマンスを発揮していたが,反面,開発に時間がかかっていたという。
このセッションではそれ以外の方法,つまりHTMLやJavaScriptを使ってWii Uの全機能にアクセスしつつ,
より手軽にゲーム開発を行う方法が説明されるようだ。
http://www.4gamer.net/games/999/G999905/20130316001/
探検
任天堂「今後C++は捨てJavaScriptで開発していく」
2013/03/20(水) 13:07:40.60
392デフォルトの名無しさん
2013/04/03(水) 02:31:33.24 ではバッファオーバーフローするjsとその処理系がどのようなものになるか説明してみてください
393デフォルトの名無しさん
2013/04/03(水) 02:36:12.10394デフォルトの名無しさん
2013/04/03(水) 02:46:14.34 (Cコンパイラの)バイナリデータを吐き出す機能しか持っていない言語は
チューリング完全でないが、チューリング完全の処理系を出力できる。
チューリング完全でないが、チューリング完全の処理系を出力できる。
395デフォルトの名無しさん
2013/04/03(水) 02:52:58.75 >>385
JavaScriptはプロトタイプ指向と言うオブジェクト指向と類似するパラダイムを既に獲得しているので、今更オブジェクト指向を取り込む必要は特に無い
>>388
×Cで吐ける機械語はJSでも吐ける
○Cで書ける処理はJSでも書ける
わかり易い例を出すと、Cと同じ機械語を吐くためにはメモリ破壊出来ないとダメだけどJSでは無理だ
処理速度の面で言うにしてもCと同等の速度が出る「可能性は否定出来ない」程度で現状は未だ無理
最適化に必要な型情報などのヒントを埋め込みまくってようやくCには一歩及ばない上に、そのコードは既に人が書くには辛い領域になっている
動的最適化の果てに静的最適化のみのCを超える可能性とかはあるが、現状ではそれも未達成だ・・・発展著しいし希望は有ると思うけど
JavaScriptはプロトタイプ指向と言うオブジェクト指向と類似するパラダイムを既に獲得しているので、今更オブジェクト指向を取り込む必要は特に無い
>>388
×Cで吐ける機械語はJSでも吐ける
○Cで書ける処理はJSでも書ける
わかり易い例を出すと、Cと同じ機械語を吐くためにはメモリ破壊出来ないとダメだけどJSでは無理だ
処理速度の面で言うにしてもCと同等の速度が出る「可能性は否定出来ない」程度で現状は未だ無理
最適化に必要な型情報などのヒントを埋め込みまくってようやくCには一歩及ばない上に、そのコードは既に人が書くには辛い領域になっている
動的最適化の果てに静的最適化のみのCを超える可能性とかはあるが、現状ではそれも未達成だ・・・発展著しいし希望は有ると思うけど
396デフォルトの名無しさん
2013/04/03(水) 02:54:11.35 >>395
メモリ破壊する処理を書けばいい。
メモリ破壊する処理を書けばいい。
397デフォルトの名無しさん
2013/04/03(水) 02:56:25.62 >>396
破壊できたら只のセキュリティホールでんがな
破壊できたら只のセキュリティホールでんがな
398デフォルトの名無しさん
2013/04/03(水) 02:56:41.64 C言語が出力するバイナリと同様のものはJavascriptで吐ける。
C言語の出力をバイナリ文字列としてコピペして書き出すだけ。
C言語の出力をバイナリ文字列としてコピペして書き出すだけ。
399デフォルトの名無しさん
2013/04/03(水) 02:56:50.05400デフォルトの名無しさん
2013/04/03(水) 02:57:50.43 バイナリファイルはきだせるならなんでも作れるだろ。
401デフォルトの名無しさん
2013/04/03(水) 02:59:26.13 より一般にほとんど言語で、C/C++で書かれたC/C++コンパイラと同等の速度が出る、C/C++コンパイラを書くことは可能。
これはチューリング完全なんかと関係する。
これはチューリング完全なんかと関係する。
402デフォルトの名無しさん
2013/04/03(水) 03:00:19.75 Cで書けるということはクライアントの環境を決め打ちできるということだ(キリッ
403デフォルトの名無しさん
2013/04/03(水) 04:13:43.77 >>399
メモリ破壊のロジックを再現しても実際のメモリ破壊できないだろ・・・レイヤ違うんだし
メモリ破壊のロジックを再現しても実際のメモリ破壊できないだろ・・・レイヤ違うんだし
404デフォルトの名無しさん
2013/04/03(水) 04:56:44.83 メモリ破壊の意味分かってないバカがいるな
さすが低級言語のC/C++厨だな
さすが低級言語のC/C++厨だな
405デフォルトの名無しさん
2013/04/03(水) 05:02:35.17 具体的に説明できない知ったかぶりが煙に巻くときに使う常套句:レイヤ
406デフォルトの名無しさん
2013/04/03(水) 05:42:55.70 相手の発言を曲解して馬鹿にした気になれるってある種の才能だよな・・・
395が言ってる処理ってアルゴリズムの事だと理解できないのか、理解したくないのかどっちなんだろ?
説明されても理解できないの方だとしたら、病院行って診断もらってきたほうがいい。特権手帳もらえるよ。
>>405
煙に巻くもへったくれも、JS上に作った仮想メモリはOSが管理する仮想メモリやCPU見てる実メモリとはレイヤ違うからそのまんまだろ
395が言ってる処理ってアルゴリズムの事だと理解できないのか、理解したくないのかどっちなんだろ?
説明されても理解できないの方だとしたら、病院行って診断もらってきたほうがいい。特権手帳もらえるよ。
>>405
煙に巻くもへったくれも、JS上に作った仮想メモリはOSが管理する仮想メモリやCPU見てる実メモリとはレイヤ違うからそのまんまだろ
407デフォルトの名無しさん
2013/04/03(水) 07:22:06.91 Cすら使いこなせない低能でも
JSでゲーム開発出来ると聞いてアホが喜んでるんだから
水を差すなよ...
JSでゲーム開発出来ると聞いてアホが喜んでるんだから
水を差すなよ...
408デフォルトの名無しさん
2013/04/03(水) 08:11:05.05 ゲーム作ったことある奴ならわかるけど
言語なんか関係ないからな
それ以外のことが難しすぎるし
言語なんか関係ないからな
それ以外のことが難しすぎるし
409デフォルトの名無しさん
2013/04/03(水) 09:03:38.63410デフォルトの名無しさん
2013/04/03(水) 09:10:48.44 チューリング完全は計算能力の話であって計算速度とは関係ないってマジレスしちゃダメなの?
411デフォルトの名無しさん
2013/04/03(水) 09:16:36.70 実際出来るかどうかは知らんけど、チューリング完全とかの概念はむしろ最適化に上限があることを証明するのに使えちゃいそうだよな
412デフォルトの名無しさん
2013/04/03(水) 09:21:26.59 チューリング完全って何だよ
413デフォルトの名無しさん
2013/04/03(水) 09:28:22.39 論理的には計算速度の最適化もできそうだけど、
ソースコードの量の増加に応じた最適化のための計算量が爆発的に増加しそう
実質的には無理じゃないかな?
ソースコードの量の増加に応じた最適化のための計算量が爆発的に増加しそう
実質的には無理じゃないかな?
414デフォルトの名無しさん
2013/04/03(水) 09:30:54.93415デフォルトの名無しさん
2013/04/03(水) 10:01:54.27 コンパイラは、文字列処理にすぎない。
ソースコードをパースして、アセンブラ言語の文字列へ変換するだけ。
C製のCコンパイラと同等の速度が出せない言語のほうが珍しい。チューリング完全ということは処理能力に違いがないということ。
ソースコードをパースして、アセンブラ言語の文字列へ変換するだけ。
C製のCコンパイラと同等の速度が出せない言語のほうが珍しい。チューリング完全ということは処理能力に違いがないということ。
416デフォルトの名無しさん
2013/04/03(水) 10:03:24.28 「Javascriptのコードから」ってルールが抜けてるんなら
バイナリ列のコピーだけでもいいからね。
バイナリ列のコピーだけでもいいからね。
417デフォルトの名無しさん
2013/04/03(水) 10:04:21.81418デフォルトの名無しさん
2013/04/03(水) 10:05:05.44 チューリング完全を完全に誤解してる。
419デフォルトの名無しさん
2013/04/03(水) 10:06:29.14 まったくなんのスレだよ
420デフォルトの名無しさん
2013/04/03(水) 10:10:54.96 万能チューリングマシンとか停止性問題とか神託機械とか、あのへん微妙に中二病患者にウケそうな概念や単語が並んでるからな
421デフォルトの名無しさん
2013/04/03(水) 10:11:20.33422デフォルトの名無しさん
2013/04/03(水) 10:14:38.71 >>421
同等程度の性能しか出せないのに、Javascript製Cコンパイラをつくる意味がない。
それに明らかにコンパイル時間が長引いて実用的でもない。
ゼロからCで書くか、オープンソースのC言語製Cコンパイラを改良した方がいい。
同等程度の性能しか出せないのに、Javascript製Cコンパイラをつくる意味がない。
それに明らかにコンパイル時間が長引いて実用的でもない。
ゼロからCで書くか、オープンソースのC言語製Cコンパイラを改良した方がいい。
423デフォルトの名無しさん
2013/04/03(水) 10:17:37.90 脈絡なく屁理屈をレスするスレ
424デフォルトの名無しさん
2013/04/03(水) 10:18:49.79425デフォルトの名無しさん
2013/04/03(水) 10:33:57.34 JavaScriptで、C言語製ソフトと同等(速度)の事をやることは現実で可能。
Zopfli を Emscripten をつかって JavaScript に移植しました
http://blog.livedoor.jp/imaya_js/archives/6349259.html
Google Zopfli圧縮アルゴリズム、gzip -9より高圧縮 3月11日
http://headlines.yahoo.co.jp/hl?a=20130311-00000019-mycomj-sci
この記事では、C言語で書かれたアプリケーションを Javascript エンジン上で動かすためのツールである Emscripten について解説します。
Emscripten の原理
Emscripten はC言語のコードを Javascript のコードへ変換するツールですが、人間が移植作業を行うように「書き直し」をしてくれるものではありません。
http://teikyo.tumblr.com/2011-emscripten-1
Zopfli を Emscripten をつかって JavaScript に移植しました
http://blog.livedoor.jp/imaya_js/archives/6349259.html
Google Zopfli圧縮アルゴリズム、gzip -9より高圧縮 3月11日
http://headlines.yahoo.co.jp/hl?a=20130311-00000019-mycomj-sci
この記事では、C言語で書かれたアプリケーションを Javascript エンジン上で動かすためのツールである Emscripten について解説します。
Emscripten の原理
Emscripten はC言語のコードを Javascript のコードへ変換するツールですが、人間が移植作業を行うように「書き直し」をしてくれるものではありません。
http://teikyo.tumblr.com/2011-emscripten-1
426デフォルトの名無しさん
2013/04/03(水) 10:39:29.56427デフォルトの名無しさん
2013/04/03(水) 10:39:36.33 emscriptenの出力コードはjavascript上で機械語コードをエミュレートするだけなんだけど
428デフォルトの名無しさん
2013/04/03(水) 10:44:57.82 >>425
ドヤ顔でこれかよ・・・
ドヤ顔でこれかよ・・・
429デフォルトの名無しさん
2013/04/03(水) 10:45:03.65430デフォルトの名無しさん
2013/04/03(水) 10:48:42.80 コンパイラは文字列操作してるだけ。
C:製Cコンパイラと同じ文字列操作をすれば出力は同じで、速度も同じになるのは当たり前。
アセンブリ言語 - Wikipedia
次に示す機械語は AL レジスタに 01100001 というデータをロードする。
10110000 01100001
このバイナリコードを人間が読みやすいように十六進法で表現すると次のようになる。
B0 61
ここで、B0 は「ALに後続の値をコピーする」ことを意味し、61 は 01100001 を十六進法で表したものである。
インテルのアセンブリ言語では、この種の命令に MOV というニーモニックを割り当てており、
セミコロン以下に説明的コメントを添えたアセンブリ言語での表現は次のようになる。
MOV AL, 61h ; Load AL with 97 decimal (61 hex)
この場合、定数61Hがソース、レジスタALがデスティネーションに該当し、命令が実行されると、定数61Hが、レジスタALに単純に格納される。
これが人間にとってはさらに読みやすく覚えやすい。
C:製Cコンパイラと同じ文字列操作をすれば出力は同じで、速度も同じになるのは当たり前。
アセンブリ言語 - Wikipedia
次に示す機械語は AL レジスタに 01100001 というデータをロードする。
10110000 01100001
このバイナリコードを人間が読みやすいように十六進法で表現すると次のようになる。
B0 61
ここで、B0 は「ALに後続の値をコピーする」ことを意味し、61 は 01100001 を十六進法で表したものである。
インテルのアセンブリ言語では、この種の命令に MOV というニーモニックを割り当てており、
セミコロン以下に説明的コメントを添えたアセンブリ言語での表現は次のようになる。
MOV AL, 61h ; Load AL with 97 decimal (61 hex)
この場合、定数61Hがソース、レジスタALがデスティネーションに該当し、命令が実行されると、定数61Hが、レジスタALに単純に格納される。
これが人間にとってはさらに読みやすく覚えやすい。
431425
2013/04/03(水) 10:51:48.53 間違えるな。
Emscriptenで変換したコードが速いと言ってない。
JavaScript製Cコンパイラで、C:製Cコンパイラと同じバイナリ(=同じ速度のバイナリ)を作り出せるかだ。
Emscriptenで変換したコードが速いと言ってない。
JavaScript製Cコンパイラで、C:製Cコンパイラと同じバイナリ(=同じ速度のバイナリ)を作り出せるかだ。
432デフォルトの名無しさん
2013/04/03(水) 10:52:17.91 真面目にJSでのゲーム開発を議論するスレかとおもいきや、普通の初心者スレになっているとは。
433デフォルトの名無しさん
2013/04/03(水) 10:53:41.38 >>431
JavaScriptでCと同等の処理が書けるかって話じゃなくて、同等の速度がだせるかって話なんですけど。
JavaScriptでCと同等の処理が書けるかって話じゃなくて、同等の速度がだせるかって話なんですけど。
434デフォルトの名無しさん
2013/04/03(水) 10:56:50.87 emscripten はそういうのじゃないとおもうんだ
c->js はかのうかもしれない js->c は範疇外だろう?
c->js はかのうかもしれない js->c は範疇外だろう?
435デフォルトの名無しさん
2013/04/03(水) 10:57:37.21 逆にJavaScriptソースと同等機能を実現するC、アセンブラソースを作り出すことも可能。
JavaScript ⇒ C、アセンブラ ⇒ バイナリ としたらJavaScriptも速く出来る。
JavaScript ⇒ C、アセンブラ ⇒ バイナリ としたらJavaScriptも速く出来る。
436デフォルトの名無しさん
2013/04/03(水) 10:58:41.14 「この処理系でJSを実行したらCと同等の速度になる」って実例をバーンと出せば
終わる話なのに、できないでいろいろ理屈を言ってることは、やっぱ遅いんだな。
わかりました。
終わる話なのに、できないでいろいろ理屈を言ってることは、やっぱ遅いんだな。
わかりました。
437デフォルトの名無しさん
2013/04/03(水) 10:59:28.28438デフォルトの名無しさん
2013/04/03(水) 11:00:35.68 >>435
動的型の言語は単純にCに変換できないでしょ。
動的型の言語は単純にCに変換できないでしょ。
439デフォルトの名無しさん
2013/04/03(水) 11:03:15.27440デフォルトの名無しさん
2013/04/03(水) 11:08:59.46 C++からJavaScriptへ変換し、さらにJavaへ移植する話の続き
http://d.hatena.ne.jp/aoisome/20130121/1358779265
[GDC 2013]Webブラウザで「Unreal Engine 3」がヌルヌル動く!? ゲームエンジンを5日でHTML5へ移植した驚きの技術とは
http://www.4gamer.net/games/032/G003263/20130328081/
モジラ、ブラウザ上でゲーム機並みの3Dゲーム体験を可能にする取り組みなど発表
http://headlines.yahoo.co.jp/hl?a=20130328-35030070-cnetj-sci
Mozilla、Firefox 22 にブラウザゲームを高速化する「asm.js」を搭載- インターネットコム(2013年3月28日12時00分)
ゲームは、大量のリソースと複雑なコンピューティングを要求するタスク。
このため、ゲームは、ハードウェアの特性にあわせた専用 OS 向けに、ネイティブコードで書かれるのが普通だ。
だが、Mozilla の JavaScript 高速化プロジェクトにより、高いパフォーマンスを持つブラウザゲームの実現が、現実味を帯びてきた。
米国 Mozilla は3月27日、ゲームエンジン「Unreal Engine」を開発した Epic Games と協働していることを発表した。
この共同プロジェクトは、Unreal Engine 向けのゲームを、Web ブラウザ内で動作可能にすることを目指すもの。
「Emscriptem」は C で書かれたコードを、どの Web ブラウザでも動作する JavaScript に書き換えるクロスコンパイラ。
Mozilla CTO であり、JavaScript の開発者でもある Brendan Eich 氏は InternetNews.com に対し、emscriptem を利用すれば、開発者が Web フレンドリーな新しいタイプの開発へ移行することが、より容易になると説明した。
http://media.image.infoseek.co.jp/isnews/photos/internetcom/internetcom_20130328_010_0-small.jpg
http://news.infoseek.co.jp/article/internetcom_20130328_010
http://d.hatena.ne.jp/aoisome/20130121/1358779265
[GDC 2013]Webブラウザで「Unreal Engine 3」がヌルヌル動く!? ゲームエンジンを5日でHTML5へ移植した驚きの技術とは
http://www.4gamer.net/games/032/G003263/20130328081/
モジラ、ブラウザ上でゲーム機並みの3Dゲーム体験を可能にする取り組みなど発表
http://headlines.yahoo.co.jp/hl?a=20130328-35030070-cnetj-sci
Mozilla、Firefox 22 にブラウザゲームを高速化する「asm.js」を搭載- インターネットコム(2013年3月28日12時00分)
ゲームは、大量のリソースと複雑なコンピューティングを要求するタスク。
このため、ゲームは、ハードウェアの特性にあわせた専用 OS 向けに、ネイティブコードで書かれるのが普通だ。
だが、Mozilla の JavaScript 高速化プロジェクトにより、高いパフォーマンスを持つブラウザゲームの実現が、現実味を帯びてきた。
米国 Mozilla は3月27日、ゲームエンジン「Unreal Engine」を開発した Epic Games と協働していることを発表した。
この共同プロジェクトは、Unreal Engine 向けのゲームを、Web ブラウザ内で動作可能にすることを目指すもの。
「Emscriptem」は C で書かれたコードを、どの Web ブラウザでも動作する JavaScript に書き換えるクロスコンパイラ。
Mozilla CTO であり、JavaScript の開発者でもある Brendan Eich 氏は InternetNews.com に対し、emscriptem を利用すれば、開発者が Web フレンドリーな新しいタイプの開発へ移行することが、より容易になると説明した。
http://media.image.infoseek.co.jp/isnews/photos/internetcom/internetcom_20130328_010_0-small.jpg
http://news.infoseek.co.jp/article/internetcom_20130328_010
441デフォルトの名無しさん
2013/04/03(水) 11:09:47.06 ja.wikipedia.org/wiki/%E5%A4%89%E6%8F%9B%E8%A8%80%E8%AA%9E
asm.js もそうだけど 中間言語というかtranspilerかますと
復元できない
復元までふくめるとcoffeeみたいになるし…あれ解釈エンジンは
おなじだからこそparserラクしてる面もあるし
asm.js もそうだけど 中間言語というかtranspilerかますと
復元できない
復元までふくめるとcoffeeみたいになるし…あれ解釈エンジンは
おなじだからこそparserラクしてる面もあるし
442デフォルトの名無しさん
2013/04/03(水) 11:14:39.09443デフォルトの名無しさん
2013/04/03(水) 11:16:11.82 で、俺の持ってるPCのCPUとGPUを解析して完全に最適化されたコマンドを吐いてくれるJITエンジンはいつ作ってくれるの?
444デフォルトの名無しさん
2013/04/03(水) 11:21:03.45 >>440
asm.jsのコードはJavascriptのコードとしても実行できるけどその場合はかなり遅い
モジラのVMは、asm.jsのコードをjavascriptのコードとしてではなくて
特殊な静的言語で書かれたコードとして解釈して実行することができて、
その場合は同じようなのネイティブコードの半分ぐらいの実行速度が出る
つまりこれはJavascriptのコードを早く実行する技術とは全然違う
asm.jsのコードはJavascriptのコードとしても実行できるけどその場合はかなり遅い
モジラのVMは、asm.jsのコードをjavascriptのコードとしてではなくて
特殊な静的言語で書かれたコードとして解釈して実行することができて、
その場合は同じようなのネイティブコードの半分ぐらいの実行速度が出る
つまりこれはJavascriptのコードを早く実行する技術とは全然違う
445デフォルトの名無しさん
2013/04/03(水) 11:23:55.23 Mozilla、Firefox 22 にブラウザゲームを高速化する「asm.js」を搭載 - Infoseek ニュース
Mozilla のゲームプラットフォーム戦略を担当する Martin Best 氏は InternetNews.com に対し、
asm.js コードは、JavaScript 言語の中核要素を使用すると述べた。
基本的には、asm.js を意識して書かれたコードのみが高速化されることになる。
だがこの技術には後方互換性があり、Best 氏によれば、ブラウザが asm.js をサポートしていない場合であっても、
開発者は非常に効率の高いコードを書けると述べている。
http://news.infoseek.co.jp/article/internetcom_20130328_010
Mozilla のゲームプラットフォーム戦略を担当する Martin Best 氏は InternetNews.com に対し、
asm.js コードは、JavaScript 言語の中核要素を使用すると述べた。
基本的には、asm.js を意識して書かれたコードのみが高速化されることになる。
だがこの技術には後方互換性があり、Best 氏によれば、ブラウザが asm.js をサポートしていない場合であっても、
開発者は非常に効率の高いコードを書けると述べている。
http://news.infoseek.co.jp/article/internetcom_20130328_010
446デフォルトの名無しさん
2013/04/03(水) 11:29:38.72 反論がなくなったから「Javascriptは処理系しだいでCと同等の速度がでる」って話は
間違いでしたって認めたって解釈させてもらいます。
間違いでしたって認めたって解釈させてもらいます。
447デフォルトの名無しさん
2013/04/03(水) 11:31:53.62448デフォルトの名無しさん
2013/04/03(水) 11:35:56.15 >>447
それは、速度を求められるところはCで書かないとCと同等の速度はでないってことですね。
それは、速度を求められるところはCで書かないとCと同等の速度はでないってことですね。
449デフォルトの名無しさん
2013/04/03(水) 11:38:53.98 >>443
CPU負荷や空きメモリ、処理対象データに合わせた動的最適化も追加でよろしく!
CPU負荷や空きメモリ、処理対象データに合わせた動的最適化も追加でよろしく!
450デフォルトの名無しさん
2013/04/03(水) 11:43:43.06 処理の重いところはグラフィックカードがやるから
ライブラリーに投げるだけでしょ?
ロジック部分の生産性が上がるなら言語部分の
速度を議論するのは不毛じゃないの?
ただ、プログラムの規模が大きくなってきたときに
Javascriptってかえって生産性低いのではないだろうかって
気がするんだけど
結局プログラムの生産性を下げるのって不注意で作り込んだ
バグをつぶすところが大きくて、Javascriptでうまく動かすのには
本来コンパイラーガやってくれる部分を
人間が細心の注意を持ってやらなきゃいけない様に見える
そう言う機能をどんどん追加していったら、
結局遅くて使いにくいC++の亜種になったりしそう
HTML5が流行りでみんながこのビッグウエーブに乗ろうと
するし、実際適用範囲が広がるのは確実だと思うけど、
出来るからって何でもそれでやろうとするのは凄く
間違った方向に進むと思うな
ライブラリーに投げるだけでしょ?
ロジック部分の生産性が上がるなら言語部分の
速度を議論するのは不毛じゃないの?
ただ、プログラムの規模が大きくなってきたときに
Javascriptってかえって生産性低いのではないだろうかって
気がするんだけど
結局プログラムの生産性を下げるのって不注意で作り込んだ
バグをつぶすところが大きくて、Javascriptでうまく動かすのには
本来コンパイラーガやってくれる部分を
人間が細心の注意を持ってやらなきゃいけない様に見える
そう言う機能をどんどん追加していったら、
結局遅くて使いにくいC++の亜種になったりしそう
HTML5が流行りでみんながこのビッグウエーブに乗ろうと
するし、実際適用範囲が広がるのは確実だと思うけど、
出来るからって何でもそれでやろうとするのは凄く
間違った方向に進むと思うな
451デフォルトの名無しさん
2013/04/03(水) 11:47:33.33 VB.NETが生産性最高
452デフォルトの名無しさん
2013/04/03(水) 12:02:14.73 JavaScript処理系自体がほぼC/C++製だ。
JavaScript処理系をJavaやJavaScriptやC#や純関数型で書くのも可能だろうが。
速くしたい所を念入りに最適化するのは当然。
JavaScript処理系をJavaやJavaScriptやC#や純関数型で書くのも可能だろうが。
速くしたい所を念入りに最適化するのは当然。
453デフォルトの名無しさん
2013/04/03(水) 12:39:39.19 Cコンパイラが出力した機械語と速度比較するのが間違い。CコンパイラソースをJavaScriptソースに変換できれば機械語として同じ速度だ。
言語性能は同じ土台のインタプリタで比較しろ。
CINT(シーイント)
CINT はC/C++ 言語インタープリタです。
CINTを使うと、C/C++で書かれたソースコードをコンパイルせずに実行できます。
90%-95% 実行可能だそうです。
http://belle.sci.fukuoka-u.ac.jp/index.php?CINT
Production Version 5.34
Availability
ROOT is available in binary and source form. The binaries are available for most supported platforms.
http://root.cern.ch/drupal/content/production-version-534
CINT・C++インタープリタ
日本語訳:柴田淑夫(Shibata Toshio)
この章ではCINT、ROOTのコマンドラインインタープリタおよびスクリプトプロセッサーについて述べる
http://www.dw-sapporo.co.jp/technology/658766f830d530a130a430eb7f6e304d5834/root_usersguide_jp/7CINT.pdf
言語性能は同じ土台のインタプリタで比較しろ。
CINT(シーイント)
CINT はC/C++ 言語インタープリタです。
CINTを使うと、C/C++で書かれたソースコードをコンパイルせずに実行できます。
90%-95% 実行可能だそうです。
http://belle.sci.fukuoka-u.ac.jp/index.php?CINT
Production Version 5.34
Availability
ROOT is available in binary and source form. The binaries are available for most supported platforms.
http://root.cern.ch/drupal/content/production-version-534
CINT・C++インタープリタ
日本語訳:柴田淑夫(Shibata Toshio)
この章ではCINT、ROOTのコマンドラインインタープリタおよびスクリプトプロセッサーについて述べる
http://www.dw-sapporo.co.jp/technology/658766f830d530a130a430eb7f6e304d5834/root_usersguide_jp/7CINT.pdf
454デフォルトの名無しさん
2013/04/03(水) 12:50:29.60 >>453
>CコンパイラソースをJavaScriptソースに変換できれば機械語として同じ速度だ。
Cコンパイラソースって何だ?
Cコンパイラのソースコード?
Cコンパイルするプログラムのソースコード?
何と何が機械語として同じ速度になるの?
>CコンパイラソースをJavaScriptソースに変換できれば機械語として同じ速度だ。
Cコンパイラソースって何だ?
Cコンパイラのソースコード?
Cコンパイルするプログラムのソースコード?
何と何が機械語として同じ速度になるの?
455デフォルトの名無しさん
2013/04/03(水) 12:52:23.05456デフォルトの名無しさん
2013/04/03(水) 12:54:28.66 Cの生産性の悪さとインタープリタの性能の低さを合わせた最強のツールか
457デフォルトの名無しさん
2013/04/03(水) 12:55:49.58 無駄に改行入れる奴って例外なくバカだね
458デフォルトの名無しさん
2013/04/03(水) 12:58:03.46 もはや自分でも何言ってんのか分かってなさそうだ
最近のコンパイル言語はコンパイルからJITコンパイルに移行しつつ有って最近のスクリプト言語もインタプリトからJITコンパイルに移行しつつ有るというのに、コンパイル言語の不完全なインタプリトとスクリプト言語の最新JITコンパイルを比較とか何がしたいんだ。
最近のコンパイル言語はコンパイルからJITコンパイルに移行しつつ有って最近のスクリプト言語もインタプリトからJITコンパイルに移行しつつ有るというのに、コンパイル言語の不完全なインタプリトとスクリプト言語の最新JITコンパイルを比較とか何がしたいんだ。
459デフォルトの名無しさん
2013/04/03(水) 13:00:33.11 機械語、CPUが直に理解できるワードはC言語とは別もの。
機械語で比較するならば、Cコンパイラと同じ出力を作れれば同速度であるといえる。
Cコンパイラのソースコードを移植できる言語であれば、C言語と同速度。
機械語で比較するならば、Cコンパイラと同じ出力を作れれば同速度であるといえる。
Cコンパイラのソースコードを移植できる言語であれば、C言語と同速度。
460デフォルトの名無しさん
2013/04/03(水) 13:07:17.13 >>459
何のプログラムコードで書いた何をするプログラムが同速度になるの?
何のプログラムコードで書いた何をするプログラムが同速度になるの?
461デフォルトの名無しさん
2013/04/03(水) 13:12:22.58 459だとC言語ソースをJavaScriptでコンパイルしたものが
C製Cコンパイラと同速度という意味だが。
JavaScriptソースとC言語ソースに互いに変換可能で無駄がないとすれば
JavaScriptソースもJavaScript製コンパイラでC言語並の速度が出るということ。
C製Cコンパイラと同速度という意味だが。
JavaScriptソースとC言語ソースに互いに変換可能で無駄がないとすれば
JavaScriptソースもJavaScript製コンパイラでC言語並の速度が出るということ。
462デフォルトの名無しさん
2013/04/03(水) 13:15:09.28 >>461
>JavaScriptソースとC言語ソースに互いに変換可能で無駄がない
ここが間違ってる
JavascriptソースからC言語ソースへの変換は、Javascriptソースのほうが情報量が少ないから、
同等なものに変換するには事実上不可能なほどの計算量が必要になる
>JavaScriptソースとC言語ソースに互いに変換可能で無駄がない
ここが間違ってる
JavascriptソースからC言語ソースへの変換は、Javascriptソースのほうが情報量が少ないから、
同等なものに変換するには事実上不可能なほどの計算量が必要になる
463デフォルトの名無しさん
2013/04/03(水) 13:18:32.40 >>462なので、
JavaScriptソースをJavaScript製コンパイラでC言語並の速度を出すというのは不可能
JavaScriptソースをJavaScript製コンパイラでC言語並の速度を出すというのは不可能
464デフォルトの名無しさん
2013/04/03(水) 13:28:12.44 JSって変数が全部バリアント型なのにC並の速度が出る。。。わけないだろバカ
465デフォルトの名無しさん
2013/04/03(水) 13:32:19.09466デフォルトの名無しさん
2013/04/03(水) 13:38:38.02 なんか致命的な勘違いか致命的な極論が混ざってるようにしか見えんわ
ゲスパーしとくと、JSにコンパイラ移植してもコンパイルしたコードはJSの実行環境では動かないから意味は無いしコンパイル元のコードがJSじゃないから本末転倒だぞ
>>464
そこを全部型付きにして高速化を図ろうってのが最近のトレンドだが、もはや人が書くような言語じゃねと言わんばかりに別言語の中間コードから型ヒント付きJSを生成する技術が登場する始末
JSを元にした中途半端な謎中間言語とか誰得状態だし、なんてーかそこまでやるならMSILでもLLVMでもいいからそのへんのJITレイヤをそのまんまJSに組み込んで中間コードからFunctionオブジェクト生成する機能でも追加しろよって感じだ
ゲスパーしとくと、JSにコンパイラ移植してもコンパイルしたコードはJSの実行環境では動かないから意味は無いしコンパイル元のコードがJSじゃないから本末転倒だぞ
>>464
そこを全部型付きにして高速化を図ろうってのが最近のトレンドだが、もはや人が書くような言語じゃねと言わんばかりに別言語の中間コードから型ヒント付きJSを生成する技術が登場する始末
JSを元にした中途半端な謎中間言語とか誰得状態だし、なんてーかそこまでやるならMSILでもLLVMでもいいからそのへんのJITレイヤをそのまんまJSに組み込んで中間コードからFunctionオブジェクト生成する機能でも追加しろよって感じだ
467デフォルトの名無しさん
2013/04/03(水) 13:47:40.93 C言語が機種依存して最適化してる。C言語なみの速度がJavaScriptで実現可能かということは原理的には可能だろ。
C++のテンプレート使うと、必要な型のすべてのバイナリを生成し、バイナリの中身は型付き変数として動作する。
JavaScriptコンパイラを作り最適化したらいいだけ。
C++のテンプレート使うと、必要な型のすべてのバイナリを生成し、バイナリの中身は型付き変数として動作する。
JavaScriptコンパイラを作り最適化したらいいだけ。
468デフォルトの名無しさん
2013/04/03(水) 13:53:54.03469デフォルトの名無しさん
2013/04/03(水) 13:55:33.59 >>467
テンプレートの場合に型が変化するのはそのテンプレート引数の組み合わせだけだけど、
Javascriptの関数の場合に型が変化する組み合わせはそれこそ莫大な数になる可能性が考えられるわけよw
しかも実行と同等なことをしてみないと必要な組み合わせが判明しない
なので無理
テンプレートの場合に型が変化するのはそのテンプレート引数の組み合わせだけだけど、
Javascriptの関数の場合に型が変化する組み合わせはそれこそ莫大な数になる可能性が考えられるわけよw
しかも実行と同等なことをしてみないと必要な組み合わせが判明しない
なので無理
470デフォルトの名無しさん
2013/04/03(水) 13:56:06.23 C言語自体は機種依存してないよな
言語とライブラリを分離してるだけで
#ifdef使えば
UNIXとWindowsですらソースコードレベルのポータビリティが有る訳で
API部分を抽象化しても結局うまくいかないのはJavaが証明したし
JavaScriptもそれを繰り返すことになるだろう
言語とライブラリを分離してるだけで
#ifdef使えば
UNIXとWindowsですらソースコードレベルのポータビリティが有る訳で
API部分を抽象化しても結局うまくいかないのはJavaが証明したし
JavaScriptもそれを繰り返すことになるだろう
471デフォルトの名無しさん
2013/04/03(水) 15:51:24.12472デフォルトの名無しさん
2013/04/03(水) 16:46:56.25 >>471
ちょっと複雑なコードを書いたらすぐエラーになるか、コンパイルが終わらなくなりそう。
ちょっと複雑なコードを書いたらすぐエラーになるか、コンパイルが終わらなくなりそう。
473デフォルトの名無しさん
2013/04/03(水) 17:06:28.40 >>471
ごまかすな
お前が言ってたのはJavascriptのコードをCのコードと同等な速度に変換できるってことだろ?
変換可能な部分のみ変換するのでは
JavascriptのコードをCのコードと同等な速度に変換できるとは言えない
その程度だったら事前に変換してコンパイルじゃなくて、JITコンパイルで十分なのよ
ごまかすな
お前が言ってたのはJavascriptのコードをCのコードと同等な速度に変換できるってことだろ?
変換可能な部分のみ変換するのでは
JavascriptのコードをCのコードと同等な速度に変換できるとは言えない
その程度だったら事前に変換してコンパイルじゃなくて、JITコンパイルで十分なのよ
474デフォルトの名無しさん
2013/04/03(水) 17:10:40.28 GCありきで書かれたクソコードを静的解析してスタックに割り付ける作業に戻れ
475デフォルトの名無しさん
2013/04/03(水) 19:12:32.02 JavaScriptでC言語に並べるのは事実。
CソースをJavaScriptソース内にStringとしてコピペして
JavaScript製Cコンパイラに通したら、C製Cコンパイラと同じ実行ファルを生成でき
速度はC製Cコンパイラと一緒。
CソースをJavaScriptソース内にStringとしてコピペして
JavaScript製Cコンパイラに通したら、C製Cコンパイラと同じ実行ファルを生成でき
速度はC製Cコンパイラと一緒。
476デフォルトの名無しさん
2013/04/03(水) 19:34:34.56477デフォルトの名無しさん
2013/04/03(水) 19:35:41.34 >>475
つまりCで書かないとはやくならないのか。
つまりCで書かないとはやくならないのか。
478デフォルトの名無しさん
2013/04/03(水) 20:04:29.24 最適化トランスコーダを書いてさらにCコンパイラで最適化だ!!!
聞きかじりだが、PyPyみたいになるかもしれんぞ。
聞きかじりだが、PyPyみたいになるかもしれんぞ。
479デフォルトの名無しさん
2013/04/03(水) 20:05:24.22 っていうか、LLVMのフロントエンド書くんだ!!
480デフォルトの名無しさん
2013/04/03(水) 21:40:45.82 LLVMはバックのほうが windows でまともにうごくかな!
481デフォルトの名無しさん
2013/04/03(水) 21:57:45.21 twitter.com/shelarcy/status/319102598693138433
GHCのSIMD命令対応
がんばるHaskeller...
GHCのSIMD命令対応
がんばるHaskeller...
482デフォルトの名無しさん
2013/04/03(水) 22:13:15.70 まあ、関数型は並列性抽出しやすいからな。
483デフォルトの名無しさん
2013/04/04(木) 03:26:18.20 >>467
全てではなく呼び出し関係を追いかけて出現した型だけだし、一度確定した型はC++では変化しない
JavaScriptの場合型が変化するどころか型の定義そのものが後から変化してしまうから手に負えない
>>471
「どこで新型が生成されるか事前に判別でき」「ない」
君の大好きチューリングマシンの停止性問題と同じ理屈で、ある条件である部分(ある内容の型生成)が実行されるかは判別できない
結果、実行中に実際生成された型でその都度ネイティブコードを生成するJIT実行か、連想配列を使ったインタプリタに毛が生えたような実装になる
>>475
それはCのコードをコンパイルしただけでJavaScriptコードをコンパイルした事にはならないし、
JavaScript上ではコンパイルで得たバイナリを実行する手段がなくて何の意味もない
全てではなく呼び出し関係を追いかけて出現した型だけだし、一度確定した型はC++では変化しない
JavaScriptの場合型が変化するどころか型の定義そのものが後から変化してしまうから手に負えない
>>471
「どこで新型が生成されるか事前に判別でき」「ない」
君の大好きチューリングマシンの停止性問題と同じ理屈で、ある条件である部分(ある内容の型生成)が実行されるかは判別できない
結果、実行中に実際生成された型でその都度ネイティブコードを生成するJIT実行か、連想配列を使ったインタプリタに毛が生えたような実装になる
>>475
それはCのコードをコンパイルしただけでJavaScriptコードをコンパイルした事にはならないし、
JavaScript上ではコンパイルで得たバイナリを実行する手段がなくて何の意味もない
484デフォルトの名無しさん
2013/04/04(木) 03:42:06.96 >>478-479
素のJavaScriptで型特定は無理ゲーだし諦めて、もうJScript.net(≠JScript)でよくね?
型ヒントとか色々付けないとコンパイル通らないけど、一応IL吐けるからC++/CLRといい勝負できるかもしれん
もっとゴリゴリやりたい部分はMSILからFunction生成で誤魔化すw
素のJavaScriptで型特定は無理ゲーだし諦めて、もうJScript.net(≠JScript)でよくね?
型ヒントとか色々付けないとコンパイル通らないけど、一応IL吐けるからC++/CLRといい勝負できるかもしれん
もっとゴリゴリやりたい部分はMSILからFunction生成で誤魔化すw
485デフォルトの名無しさん
2013/04/04(木) 21:25:36.61 なんでMS前提なんだよ
486デフォルトの名無しさん
2013/04/05(金) 10:08:24.63 JavaScriptと実用レベルで互換が有ってネイティブコードまでまともに変換できる製品がJScript.netくらいしか思いつかなかったんだ
吐けるバイナリはMSILだけどMSILのJITコンパイルは起動時/インストール時にほとんど終わるからJSのコンパイル基盤って意味では一番まともかと
JScript.netが吐き出すILやそのアセンブリを見たこと無いからなんとも言えんけど、
ILの品質次第ではJavaScriptで書いたコードが等価なC/C++で書いたコードとタメ張るかもしれん
吐けるバイナリはMSILだけどMSILのJITコンパイルは起動時/インストール時にほとんど終わるからJSのコンパイル基盤って意味では一番まともかと
JScript.netが吐き出すILやそのアセンブリを見たこと無いからなんとも言えんけど、
ILの品質次第ではJavaScriptで書いたコードが等価なC/C++で書いたコードとタメ張るかもしれん
487デフォルトの名無しさん
2013/04/05(金) 23:13:48.01 >>486
たぶんないなw
たぶんないなw
488デフォルトの名無しさん
2013/04/05(金) 23:51:12.81 まぁ最近の家庭用据置ならちょっとしたアプリやホビープログラムならスクリプトでお手軽に
ってのはありじゃね
商用のフルパッケージでそんな事してたらアホだけど
ってのはありじゃね
商用のフルパッケージでそんな事してたらアホだけど
489デフォルトの名無しさん
2013/04/06(土) 04:44:20.35 いいからファミリーべーしっくやってろw
490デフォルトの名無しさん
2013/04/06(土) 09:12:28.81 >>488
FPSのなかのLuaさん「・・・」
FPSのなかのLuaさん「・・・」
491デフォルトの名無しさん
2013/04/06(土) 10:25:08.57 いまや商用のフルパッケージなゲームでこそ、
DSLとしてスクリプト言語的なものを使うのは普通だね
DSLとしてスクリプト言語的なものを使うのは普通だね
レスを投稿する
ニュース
- 【速報】政府、与党がNISA未成年解禁を検討 ★2 [蚤の市★]
- 中国外務省「正式な発言撤回なければ受け入れず」 高市首相は台湾有事「存立危機事態」言及せずも「言及しないことと撤回は別問題」★12 [ぐれ★]
- 【TV】ファン5万人がガチで投票! プロ野球総選挙、栄えある1位は [牛丼★]
- 「まだ朝7時に通勤してるんですか?」人気VTuberが語った“働き方への提言”に議論沸騰 [夜のけいちゃん★]
- 【*彡】巨人・坂本勇人 『流れ星に何を願うか』の質問に「結婚相手」と即答、結婚願望告白 女性ファンから歓声と悲鳴 [鉄チーズ烏★]
- 【女子ゴルフ】都玲華(21)30歳年上の既婚者コーチとの交際関係とコーチ契約解消「昨年からお付き合いしてました。」 [阿弥陀ヶ峰★]
