任天堂「今後C++は捨てJavaScriptで開発していく」

2013/03/20(水) 13:07:40.60
任天堂のゲームはこれまで，CやC＋＋といったプログラミング言語で開発されており，
そのため高いパフォーマンスを発揮していたが，反面，開発に時間がかかっていたという。
このセッションではそれ以外の方法，つまりHTMLやJavaScriptを使ってWii Uの全機能にアクセスしつつ，
より手軽にゲーム開発を行う方法が説明されるようだ。
http://www.4gamer.net/games/999/G999905/20130316001/
2013/04/01(月) 22:21:57.57
アセンブラ、C、Java、JavaScriptができれば
大体のところは網羅してると思うな。
360デフォルトの名無しさん
垢版 |
2013/04/01(月) 22:25:07.14
覚えられても、あえて覚えない拘りをもつんだろ。
ダーウィンだったかが、必ずしも強者が生き残るのでなく環境に適応したものが残るとかいってた。
2013/04/01(月) 22:43:04.18
正直、言語一つ極めれば大抵の他言語は余裕で覚えられる
2013/04/01(月) 23:16:07.87
手続き型から関数型はちとつらい
2013/04/02(火) 03:07:18.48
俺が生きてる間には関数型が覇権握ることはなさそうだし
とりあえず無視しとく
2013/04/02(火) 03:08:26.67
SQLを使ってる人は、関数型もすんなり使えると思う。
SQLと関数型言語は考え方が違い。

このことに気づいている人も結構いる。

https://www.google.co.jp/search?q=SQL+関数型言語
2013/04/02(火) 06:12:02.51
node.jsとか時代はJavaScriptなん？
2013/04/02(火) 06:28:39.86
>>358>>359>>361
それだけでは、とてもじゃないけど関数型言語を使いこなせる気がしない

極めるのうちに自前で他パラダイムの要素混ぜ始めるのまで含めなければ、だけど

>>365
JavaScriptの応用がホットなのは確かだけど、最終的には適材適所じゃね？
2013/04/02(火) 12:11:06.35
>>365
flashが倒れた以上後釜を狙う立場にいるのは確か
2013/04/02(火) 12:37:02.55
>>366
ループの処理を再帰に変換するのが脳内で一瞬でできるようになれば
そんなに難しくはないような気がしてる。
2013/04/02(火) 12:38:21.20
>>368
最終的には再起を先に考えてしまって後でループに直したりし始めるけどなw
2013/04/02(火) 12:40:51.36
関数は第一級オブジェクト
2013/04/02(火) 12:42:12.08
jQueryとHTML5で既にFlashの後釜
node.jsはローカル鯖テストに使ってる。便利な気がする。同一言語で扱えるので。
コンパイラが絶滅する時代が来るのかな。
(C++は進化してきているのがわかる。JavaScriptに近い部分もあり。)
2013/04/02(火) 12:53:34.06
生のJavaScriptを書くやり方の方が絶滅すると思う
JavaScript（or そのサブセット）を出力するコンパイラが主流になる
2013/04/02(火) 14:56:20.30
変換無しで実行できるっていうのもひとつのメリットだからね
主要ブラウザで直接実行可能なのがJavascriptだけな状態が続くなら
絶滅させるのは難しい
374デフォルトの名無しさん
垢版 |
2013/04/02(火) 16:06:59.30
将来のプログラマはCもjavaも両方出来ないとダメになったぞ
まぁ、移植の手間が省けるぶんゆとり化が進むだろうけど
2013/04/02(火) 18:24:13.21
JavaScriptとJavaが同じだと思ってる人が何人かこのスレに居るな
2013/04/02(火) 20:54:54.84
任天堂のハードの機能に依存したソーシャルゲーとかが作りやすくなるってことか
それこそ個人のサイトでも任天堂ハードを利用したアプリが公開できる
2013/04/02(火) 21:20:51.76
>>376
それできるの？
セキュリティとかロイヤルティとか難しい気がするが
2013/04/02(火) 21:23:39.32
そもそもソースの隠蔽が無理
2013/04/03(水) 00:09:38.97
「JavaScriptは遅い」って言う人はプログラミングについて完全に誤解してる
「JavaScript（を機械語に変換する特定の処理系）は遅い」なら正しいが
「JavaScript（というプログラミング言語）は遅い」という発言はおかしい
プログラムの処理速度を決めるのは言語処理系であって、言語そのものではない
2013/04/03(水) 00:11:10.52
またバカが来た
2013/04/03(水) 00:49:11.92
処理系ががんばればいくらでも速く出来るとか思ってるやつのほうが完全に誤解してるだろ。
2013/04/03(水) 00:57:13.59
まあjs厨はバカしかいないってことで
383デフォルトの名無しさん
垢版 |
2013/04/03(水) 01:01:02.84
>>373
googleがDartを本気でjsと置き換えようとしてるらしいが、どうなることやら
2013/04/03(水) 01:20:33.24
>>378
それいうとあらゆるクライアントサイドプログラムもソース隠蔽は無理じゃね？
ネイティブコードからの逆コンパイル可読性に負けるとはいえ、変数名全部圧縮したJSってMSILからC#に復元したコードと大差ないレベルじゃね？
2013/04/03(水) 01:57:13.31
JavaScriptは、いずれどこかの時点でオブジェクト指向機能を
取り入れた別の物に進化してHTML6の一部になると思う
いまのJavaScriptの環境はC言語で関数ポインター駆使して
一生懸命オブジェクト指向設計してた時と同じように
無理が来てると思う
2013/04/03(水) 02:01:29.30
お前らasm.jsの記事すらまともに理解できないのか
2013/04/03(水) 02:15:15.27
asやってたからjsに変えるのは楽だけど何となく型宣言がないのは気持ち悪い
2013/04/03(水) 02:19:10.19
>>381
何言ってんだ？
原理的にCで吐ける機械語はJSでも吐けるんだが
チューリング完全て知ってるか？
2013/04/03(水) 02:28:20.77
マジバカわろた
390デフォルトの名無しさん
垢版 |
2013/04/03(水) 02:29:33.48
機械語を書き出せるのはチューリング完全と関係ない。
言語がチューリング完全でなくとも出来る。
2013/04/03(水) 02:31:09.29
>>390
チューリング完全な機械語を吐くにはチューリング完全な言語を処理系に食わせなきゃ無理
機械語を吐くこと≠チューリング完全な機械語を吐くこと
2013/04/03(水) 02:31:33.24
ではバッファオーバーフローするjsとその処理系がどのようなものになるか説明してみてください
393デフォルトの名無しさん
垢版 |
2013/04/03(水) 02:36:12.10
>>391
CコンパイラのバイナリをBASE64などでコピペして
チューリング完全でない言語でデコードして書き出す。
394デフォルトの名無しさん
垢版 |
2013/04/03(水) 02:46:14.34
(Cコンパイラの)バイナリデータを吐き出す機能しか持っていない言語は
チューリング完全でないが、チューリング完全の処理系を出力できる。
2013/04/03(水) 02:52:58.75
>>385
JavaScriptはプロトタイプ指向と言うオブジェクト指向と類似するパラダイムを既に獲得しているので、今更オブジェクト指向を取り込む必要は特に無い

>>388
×Cで吐ける機械語はJSでも吐ける
○Cで書ける処理はJSでも書ける

わかり易い例を出すと、Cと同じ機械語を吐くためにはメモリ破壊出来ないとダメだけどJSでは無理だ
処理速度の面で言うにしてもCと同等の速度が出る「可能性は否定出来ない」程度で現状は未だ無理
最適化に必要な型情報などのヒントを埋め込みまくってようやくCには一歩及ばない上に、そのコードは既に人が書くには辛い領域になっている
動的最適化の果てに静的最適化のみのCを超える可能性とかはあるが、現状ではそれも未達成だ・・・発展著しいし希望は有ると思うけど
2013/04/03(水) 02:54:11.35
>>395
メモリ破壊する処理を書けばいい。
2013/04/03(水) 02:56:25.62
>>396
破壊できたら只のセキュリティホールでんがな
398デフォルトの名無しさん
垢版 |
2013/04/03(水) 02:56:41.64
C言語が出力するバイナリと同様のものはJavascriptで吐ける。
C言語の出力をバイナリ文字列としてコピペして書き出すだけ。
2013/04/03(水) 02:56:50.05
>>397
> Cで書ける処理はJSでも書ける

って書いてある。メモリ破壊する処理を書けばいい。
2013/04/03(水) 02:57:50.43
バイナリファイルはきだせるならなんでも作れるだろ。
401デフォルトの名無しさん
垢版 |
2013/04/03(水) 02:59:26.13
より一般にほとんど言語で、C/C++で書かれたC/C++コンパイラと同等の速度が出る、C/C++コンパイラを書くことは可能。
これはチューリング完全なんかと関係する。
2013/04/03(水) 03:00:19.75
Cで書けるということはクライアントの環境を決め打ちできるということだ（ｷﾘｯ
2013/04/03(水) 04:13:43.77
>>399
メモリ破壊のロジックを再現しても実際のメモリ破壊できないだろ・・・レイヤ違うんだし
2013/04/03(水) 04:56:44.83
メモリ破壊の意味分かってないバカがいるな
さすが低級言語のC/C++厨だな
2013/04/03(水) 05:02:35.17
具体的に説明できない知ったかぶりが煙に巻くときに使う常套句：レイヤ
2013/04/03(水) 05:42:55.70
相手の発言を曲解して馬鹿にした気になれるってある種の才能だよな・・・
395が言ってる処理ってアルゴリズムの事だと理解できないのか、理解したくないのかどっちなんだろ？
説明されても理解できないの方だとしたら、病院行って診断もらってきたほうがいい。特権手帳もらえるよ。

>>405
煙に巻くもへったくれも、JS上に作った仮想メモリはOSが管理する仮想メモリやCPU見てる実メモリとはレイヤ違うからそのまんまだろ
2013/04/03(水) 07:22:06.91
Cすら使いこなせない低能でも
JSでゲーム開発出来ると聞いてアホが喜んでるんだから
水を差すなよ...
2013/04/03(水) 08:11:05.05
ゲーム作ったことある奴ならわかるけど
言語なんか関係ないからな
それ以外のことが難しすぎるし
2013/04/03(水) 09:03:38.63
>>388
それじゃ現状でJavaScriptが遅いのはどういう理由なの?
実装してる連中がバカだから?
(実際的にはムリだけど)原理的には可能っていう屁理屈?
2013/04/03(水) 09:10:48.44
チューリング完全は計算能力の話であって計算速度とは関係ないってマジレスしちゃダメなの？
2013/04/03(水) 09:16:36.70
実際出来るかどうかは知らんけど、チューリング完全とかの概念はむしろ最適化に上限があることを証明するのに使えちゃいそうだよな
2013/04/03(水) 09:21:26.59
チューリング完全って何だよ
2013/04/03(水) 09:28:22.39
論理的には計算速度の最適化もできそうだけど、
ソースコードの量の増加に応じた最適化のための計算量が爆発的に増加しそう
実質的には無理じゃないかな？
2013/04/03(水) 09:30:54.93
>>413
動的型の言語の実行時にきまる動作を静的なコードで
置き換えようとするとコードの量が無限に大きくなりそうだな。
415デフォルトの名無しさん
垢版 |
2013/04/03(水) 10:01:54.27
コンパイラは、文字列処理にすぎない。
ソースコードをパースして、アセンブラ言語の文字列へ変換するだけ。
C製のCコンパイラと同等の速度が出せない言語のほうが珍しい。チューリング完全ということは処理能力に違いがないということ。
2013/04/03(水) 10:03:24.28
「Javascriptのコードから」ってルールが抜けてるんなら
バイナリ列のコピーだけでもいいからね。
2013/04/03(水) 10:04:21.81
>>412
計算理論において、ある計算のメカニズムが万能チューリングマシンと同じ計算能力をもつとき、その計算モデルはチューリング完全（チューリングかんぜん、Turing-complete）あるいは計算完備であるという。--Wikipedia/チューリング完全
>>414
生成され得ないパターンを除外してくとかはある程度出来るだろうけど、停止性判定不能コードの後ろに判定対象が並んでるとかの場合に
チューリングマシンの停止性問題から「有るコードが有る型で実行されるかは有限時間で判定不可能である」って導けそうな気がするんだよな
2013/04/03(水) 10:05:05.44
チューリング完全を完全に誤解してる。
2013/04/03(水) 10:06:29.14
まったくなんのスレだよ
2013/04/03(水) 10:10:54.96
万能チューリングマシンとか停止性問題とか神託機械とか、あのへん微妙に中二病患者にウケそうな概念や単語が並んでるからな
2013/04/03(水) 10:11:20.33
>>415
Cと同等の速度が出せない言語がめずらしいって言っても、
実際には出せてない言語は多いよね。
なんで?
実装してる連中がバカだから?
(実際的にはムリだけど)原理的には可能っていう屁理屈?
422デフォルトの名無しさん
垢版 |
2013/04/03(水) 10:14:38.71
>>421
同等程度の性能しか出せないのに、Javascript製Cコンパイラをつくる意味がない。
それに明らかにコンパイル時間が長引いて実用的でもない。
ゼロからCで書くか、オープンソースのC言語製Cコンパイラを改良した方がいい。
2013/04/03(水) 10:17:37.90
脈絡なく屁理屈をレスするスレ
2013/04/03(水) 10:18:49.79
>>422
ああ、JavaScriptでも同等の処理を書けるってはなしで、
速度はやっぱり遅いんだな。
425デフォルトの名無しさん
垢版 |
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
2013/04/03(水) 10:39:29.56
>>425
リンク先をざっと見てみましたけど、JavaScriptのコードをCと同等の速度で
実行できるってのはどこに載ってるんでしょうか。
2013/04/03(水) 10:39:36.33
emscriptenの出力コードはjavascript上で機械語コードをエミュレートするだけなんだけど
2013/04/03(水) 10:44:57.82
>>425
ドヤ顔でこれかよ・・・
2013/04/03(水) 10:45:03.65
>>425
それある程度の速度が出るのはJITコンパイルが前提だよ
上で馬鹿がわめいているような事前コンパイルでJavascirptを高速なネイティブコードに変換するのは難しい
430デフォルトの名無しさん
垢版 |
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に単純に格納される。
これが人間にとってはさらに読みやすく覚えやすい。
431425
垢版 |
2013/04/03(水) 10:51:48.53
間違えるな。
Emscriptenで変換したコードが速いと言ってない。
JavaScript製Cコンパイラで、C:製Cコンパイラと同じバイナリ(=同じ速度のバイナリ)を作り出せるかだ。
2013/04/03(水) 10:52:17.91
真面目にＪＳでのゲーム開発を議論するスレかとおもいきや、普通の初心者スレになっているとは。
2013/04/03(水) 10:53:41.38
>>431
JavaScriptでCと同等の処理が書けるかって話じゃなくて、同等の速度がだせるかって話なんですけど。
2013/04/03(水) 10:56:50.87
emscripten はそういうのじゃないとおもうんだ
c->js はかのうかもしれない js->c は範疇外だろう?
435デフォルトの名無しさん
垢版 |
2013/04/03(水) 10:57:37.21
逆にJavaScriptソースと同等機能を実現するC、アセンブラソースを作り出すことも可能。
JavaScript　⇒　C、アセンブラ　⇒　バイナリ　としたらJavaScriptも速く出来る。
2013/04/03(水) 10:58:41.14
「この処理系でJSを実行したらCと同等の速度になる」って実例をバーンと出せば
終わる話なのに、できないでいろいろ理屈を言ってることは、やっぱ遅いんだな。
わかりました。
2013/04/03(水) 10:59:28.28
ちょっとまてよｗ
>>401 = >>425 かよ
真面目にレスして損したわ･･････
2013/04/03(水) 11:00:35.68
>>435
動的型の言語は単純にCに変換できないでしょ。
2013/04/03(水) 11:03:15.27
>>435
＞JavaScript　⇒　C
これで作られるCコードを速度まで同等に最適化するのが難しいわけよ
莫大な計算量が必要で現実的じゃない
440デフォルトの名無しさん
垢版 |
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
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ラクしてる面もあるし
2013/04/03(水) 11:14:39.09
>>440
どっかの記事だと、asm.js　でもネイティブコードの倍の遅さらしいけど。
(倍でもすごいけど)
2013/04/03(水) 11:16:11.82
で、俺の持ってるPCのCPUとGPUを解析して完全に最適化されたコマンドを吐いてくれるJITエンジンはいつ作ってくれるの？
2013/04/03(水) 11:21:03.45
>>440
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
2013/04/03(水) 11:29:38.72
反論がなくなったから「Javascriptは処理系しだいでCと同等の速度がでる」って話は
間違いでしたって認めたって解釈させてもらいます。
447デフォルトの名無しさん
垢版 |
2013/04/03(水) 11:31:53.62
>>442
処理内容による。
例えば、asm.jsが円周率を1億万桁求める事をサポートし
それがC言語で書かれていてバイナリとして組み込まれていれば、
単体ネイティブバイナリと計算速度は同等だろう。
2013/04/03(水) 11:35:56.15
>>447
それは、速度を求められるところはCで書かないとCと同等の速度はでないってことですね。
2013/04/03(水) 11:38:53.98
>>443
CPU負荷や空きメモリ、処理対象データに合わせた動的最適化も追加でよろしく！
2013/04/03(水) 11:43:43.06
処理の重いところはグラフィックカードがやるから
ライブラリーに投げるだけでしょ？
ロジック部分の生産性が上がるなら言語部分の
速度を議論するのは不毛じゃないの？
ただ、プログラムの規模が大きくなってきたときに
Javascriptってかえって生産性低いのではないだろうかって
気がするんだけど
結局プログラムの生産性を下げるのって不注意で作り込んだ
バグをつぶすところが大きくて、Javascriptでうまく動かすのには
本来コンパイラーガやってくれる部分を
人間が細心の注意を持ってやらなきゃいけない様に見える
そう言う機能をどんどん追加していったら、
結局遅くて使いにくいC++の亜種になったりしそう
HTML5が流行りでみんながこのビッグウエーブに乗ろうと
するし、実際適用範囲が広がるのは確実だと思うけど、
出来るからって何でもそれでやろうとするのは凄く
間違った方向に進むと思うな
2013/04/03(水) 11:47:33.33
VB.NETが生産性最高
452デフォルトの名無しさん
垢版 |
2013/04/03(水) 12:02:14.73
JavaScript処理系自体がほぼC/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
2013/04/03(水) 12:50:29.60
>>453
＞CコンパイラソースをJavaScriptソースに変換できれば機械語として同じ速度だ。
Cコンパイラソースって何だ？
Cコンパイラのソースコード？
Cコンパイルするプログラムのソースコード？

何と何が機械語として同じ速度になるの？
2013/04/03(水) 12:52:23.05
>>453
ネイティブのCじゃなくてインタプリタのCとJavascriptを比較しろって意味?
そうする意味がわからない。

それにJavascriptじゃCの9割以上の性能出すのムリなんじゃないの。
2013/04/03(水) 12:54:28.66
Ｃの生産性の悪さとインタープリタの性能の低さを合わせた最強のツールか
2013/04/03(水) 12:55:49.58
無駄に改行入れる奴って例外なくバカだね
2013/04/03(水) 12:58:03.46
もはや自分でも何言ってんのか分かってなさそうだ

最近のコンパイル言語はコンパイルからJITコンパイルに移行しつつ有って最近のスクリプト言語もインタプリトからJITコンパイルに移行しつつ有るというのに、コンパイル言語の不完全なインタプリトとスクリプト言語の最新JITコンパイルを比較とか何がしたいんだ。
新着レスの表示
レスを投稿する

5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況