JavaがC ++よりも高速になるのはなぜですか？

ベンチマークでJavaがC ++よりも優れている場合があります。もちろん、C ++のパフォーマンスが優れている場合もあります。

次のリンクを参照してください。

• http://keithlea.com/javabench/
• http://blog.dhananjaynene.com/2008/07/performance-comparison-c-java-python-ruby-jython-jruby-groovy/
• http://blog.cfelde.com/2010/06/c-vs-java-performance/

しかし、これはどのように可能ですか？解釈されたバイトコードは、コンパイルされた言語よりも高速である可能性があるということを、私の心を揺さぶります。

誰か説明してもらえますか？ありがとう！

まず、ほとんどのJVMにはコンパイラーが含まれているため、「解釈されたバイトコード」は実際には非常にまれです（少なくともベンチマークコードでは、実際のコードでは非常にまれではありません。通常、コードは、 ）。

第二に、関与するベンチマークのかなりの数が非常に偏っているように見えます（意図または無能かどうか、私は本当に言うことはできません）。たとえば、数年前、私はあなたが投稿したリンクの1つからリンクされたソースコードのいくつかを見ました。このようなコードがありました：

  init0 = (int*)calloc(max_x,sizeof(int));
  init1 = (int*)calloc(max_x,sizeof(int));
  init2 = (int*)calloc(max_x,sizeof(int));
  for (x=0; x<max_x; x++) {
    init2[x] = 0;
    init1[x] = 0;
    init0[x] = 0;
  }

callocすでにゼロ化されているメモリを提供するため、forループをゼロ化して再び使用すると明らかに無駄になります。これに続いて（メモリが機能する場合）、メモリを他のデータで埋めることにより（ゼロ化されていることに依存しない）、ゼロ化はすべて不要でした。上記のコードを単純なものmalloc（普通の人が最初から使用していたように）に置き換えると、C ++バージョンの速度がJavaバージョンに勝るのに十分なほど向上しました（メモリが提供される場合、かなり広いマージンで）。

（別の例として）methcall最後のリンクのブログエントリで使用されているベンチマークを検討してください。名前（および物事がどのように見えるか）にもかかわらず、このC ++バージョンはメソッド呼び出しのオーバーヘッドについてはあまり測定していません。重要であることが判明したコードの部分は、トグルクラスにあります。

class Toggle {
public:
    Toggle(bool start_state) : state(start_state) { }
    virtual ~Toggle() {  }
    bool value() {
        return(state);
    }
    virtual Toggle& activate() {
        state = !state;
        return(*this);
    }
    bool state;
};

重要な部分は判明したstate = !state;。コードを変更してintaの代わりに状態をエンコードするとどうなるか考えてみてくださいbool：

class Toggle {
    enum names{ bfalse = -1, btrue = 1};
    const static names values[2];
    int state;

public:
    Toggle(bool start_state) : state(values[start_state]) 
    { }
    virtual ~Toggle() {  }
    bool value() {  return state==btrue;    }

    virtual Toggle& activate() {
        state = -state;
        return(*this);
    }
};

この小さな変更により、全体的な速度が約5：1のマージンで向上します。ベンチマークはメソッド呼び出し時間を測定することを目的としていましたが、実際には、測定したほとんどの時間はintとの間で変換する時間でしたbool。オリジナルによって示された非効率性は不幸であることは確かに同意します-しかし、実際のコードではほとんど発生しないようであり、発生した場合/発生した場合に修正できる容易さを考えると、考えるのに苦労しますそれは多くの意味として。

誰かが関連するベンチマークを再実行することを決定した場合、Javaバージョンにもほぼ同等の些細な変更が加えられることを追加する必要があります（または少なくとも一度は作成されます-テストを再実行していません）最近のJVMがまだ確認しています）Javaバージョンもかなり大幅に改善されています。Javaバージョンには、次のようなNthToggle :: activate（）があります。

public Toggle activate() {
this.counter += 1;
if (this.counter >= this.count_max) {
    this.state = !this.state;
    this.counter = 0;
}
return(this);
}

this.state直接操作する代わりにベース関数を呼び出すようにこれを変更すると、大幅に速度が向上します（ただし、変更されたC ++バージョンに対応するには十分ではありません）。

そのため、最終的に、解釈されたバイトコードとこれまでに見られた最悪のベンチマーク（私が見た）のいくつかについての誤った仮定になります。どちらも意味のある結果をもたらしていない。

私自身の経験では、経験豊富なプログラマーが最適化に同等の注意を払っていると、C ++はJavaよりも頻繁に勝ちますが、（少なくともこれら2つの間では）プログラマーやデザインほど大きな違いはありません。引用されているベンチマークは、彼らがベンチマークと称している言語についてよりも、著者の（能力）/（不）正直さについて多くを語っています。

[編集：上記の1か所で暗示されているが、おそらくそうあるべきだと直接述べられていないので、引用する結果は、その時点で最新のC ++およびJava実装を使用して5年前にテストしたときに得られた結果です。現在の実装でテストを再実行していません。しかし、一見すると、コードが修正されていないことが示されているため、変更されるのは、コンパイラーがコードの問題を隠蔽することだけです。

我々は、Javaの例を無視する場合は、しかし、あると解釈コードは（困難とやや変わったが）コンパイルされたコードよりも高速に実行するために実際に可能。

これが起こる通常の方法は、解釈されるコードがマシンコードよりもはるかにコンパクトであること、またはコードキャッシュよりも大きなデータキャッシュを持つCPUで実行されていることです。

このような場合、小さなインタープリター（たとえば、Forth実装の内部インタープリター）は、コードキャッシュに完全に収まる場合があり、それが解釈するプログラムは、データキャッシュに完全に収まる場合があります。キャッシュは通常、メインメモリよりも少なくとも10倍速く、多くの場合ははるかに速くなります（100倍になることは特に珍しいことではありません）。

そのため、キャッシュがメインメモリよりもN倍速く、各バイトコードを実装するのにNより少ないマシンコード命令が必要な場合、バイトコードが勝つはずです（単純化していますが、一般的な考え方はまだすべきだと思います）明らかである）。

時間に制限のない専門家が手作業で行う C / C ++ は、少なくともJavaと同じかそれより高速になります。最終的に、Java自体はC / C ++で記述されているため、エンジニアリングに十分な労力をかけたい場合は、もちろんJavaのすべてを実行できます。

ただし、実際には、Javaは次の理由で非常に高速に実行されることがよくあります。

• JITコンパイル-Javaクラスはバイトコードとして格納されますが、これは（通常）プログラムの起動時にJITコンパイラーによってネイティブコードにコンパイルされます。コンパイルされると、それは純粋なネイティブコードです。したがって、理論的には、プログラムが十分に長く実行されると（つまり、すべてのJITコンパイルが完了した後）、コンパイルされたC / C ++と同じように実行することが期待できます
• Javaのガベージコレクションは非常に高速で効率的です。HotspotGCは、おそらく世界で最高のオールラウンドGC実装です。これは、サンや他の企業が何年もかけて専門家として努力した結果です。C / C ++でロールバックする複雑なメモリ管理システムは、ほとんど悪化します。もちろん、C / C ++でかなり高速/軽量の基本的なメモリ管理スキームを作成できますが、完全なGCシステムほど汎用性はありません。最新のシステムのほとんどは複雑なメモリ管理を必要とするため、Javaは実際の状況で大きな利点があります。
• プラットフォームのターゲット設定の改善 -アプリケーションの起動（JITコンパイルなど）にコンパイルを遅らせることにより、Javaコンパイラは、実行中の正確なプロセッサを知っているという事実を利用できます。これにより、「最小公分母」プロセッサ命令セットをターゲットとする必要があるプリコンパイル済みのC / C ++コードでは実行できない非常に有益な最適化が可能になります。
• 実行時統計 -JITコンパイルは実行時に行われるため、プログラムの実行中に統計を収集でき、最適化が可能になります（たとえば、特定の分岐が行われる確率がわかります）。これにより、Java JITコンパイラーは、C / C ++コンパイラー（最も可能性の高い分岐を事前に「推測」する必要があるため、多くの場合間違っている可能性がある）よりも優れたコードを生成できます。
• 非常に優れたライブラリ -Javaランタイムには、優れたパフォーマンスを備えた非常によく記述されたライブラリが多数含まれています（特にサーバー側アプリケーション用）。多くの場合、これらは自分で書いたり、C / C ++で簡単に入手できるよりも優れています。

同時に、C / C ++にはいくつかの利点もあります。

• 高度な最適化を行う時間の増加 -C / C ++コンパイルは1回行われるため、高度な最適化を行うように設定すると、かなりの時間を費やすことができます。Javaで同じことができなかった理論的な理由はありませんが、実際にはJavaにコードを比較的迅速にJITコンパイルさせたいため、JITコンパイラは「単純な」最適化に集中する傾向があります。
• バイトコードでは表現できない命令 -Javaバイトコードは完全に汎用ですが、バイトコードではできない低レベルでできることがいくつかあります（チェックされていないポインター演算が良い例です！）。（ab）これらの種類のトリックを使用することにより、パフォーマンス上の利点を得ることができます
• 「安全性」の制約が少ない-Javaは、プログラムが安全で信頼できることを保証するために、余分な作業を行います。例としては、配列の境界チェック、特定の同時実行性の保証、nullポインターのチェック、キャストの型安全性などがあります。C/ C ++でこれらを回避することで、パフォーマンスが向上します（おそらくこれは悪い考えです！）

全体：

• JavaとC / C ++は同様の速度を実現できます
• C / C ++はおそらく極端な状況でわずかな優位性を持っています（たとえば、AAAゲーム開発者がまだそれを好むのは驚くことではありません）
• 実際には、上記のさまざまな要因が特定のアプリケーションでどのようにバランスを取るかによって異なります。

Javaランタイムはバイトコードを解釈しません。むしろ、Just In Time Compilationと呼ばれるものを使用します。基本的に、プログラムが実行されると、バイトコードを受け取り、特定のCPU用に最適化されたネイティブコードに変換します。

すべてが平等であると言うことができます：いいえ、Javaは決して速くなるべきではありません。Javaを常にC ++でゼロから実装することで、少なくとも同等のパフォーマンスを得ることができます。ただし、実際には：

• JIT はエンドユーザーのマシンでコードをコンパイルし、実行している正確なCPUに対して最適化できるようにします。ここにはコンパイルのためのオーバーヘッドがありますが、集中的なアプリの場合は十分に成果が得られるでしょう。多くの場合、実際のプログラムは使用しているCPU用にコンパイルされていません。
• Javaコンパイラーは、C ++コンパイラーよりも自動最適化の方が優れている可能性があります。または、そうではないかもしれませんが、現実の世界では、物事は必ずしも完全ではありません。
• パフォーマンスの動作は、ガベージコレクションなどの他の要因によって異なる場合があります。C ++では、通常、オブジェクトを処理したらすぐにデストラクタを呼び出します。Javaでは、参照を解放するだけで、実際の破棄が遅れます。これは、パフォーマンスの点で、ここでもそこでもない違いの別の例です。もちろん、C ++でGCを実装して実行できると主張することもできますが、現実には少数の人々がやりたい、やりたい、できるということです。

余談ですが、これは80年代/ 90年代のCに関する議論を思い出させます。誰もが「Cはアセンブリと同じくらい高速になるのだろうか？」基本的には、答えは紙に書かれていませんでしたが、実際には、Cコンパイラはアセンブリプログラマの90％よりも効率的なコードを作成しました（まあ、少し成熟したら）。

ただし、割り当てはメモリ管理の半分にすぎません。割り当て解除は残りの半分です。ほとんどのオブジェクトでは、ガベージコレクションの直接コストはゼロであることがわかります。これは、コピーコレクターが死んだオブジェクトにアクセスしたりコピーしたりする必要はなく、ライブオブジェクトのみをコピーする必要があるためです。そのため、割り当て後すぐにガベージになるオブジェクトは、収集サイクルにワークロードを提供しません。

...

JVMは驚くべきことに、開発者だけが知ることができると仮定していたことを理解するのに優れています。JVMがケースごとにスタック割り当てとヒープ割り当てを選択できるようにすることで、プログラマがスタックに割り当てるかヒープに割り当てるかを悩ませることなく、スタック割り当てのパフォーマンス上の利点を得ることができます。

http://www.ibm.com/developerworks/java/library/j-jtp09275/index.html

完全に最適化されたJavaプログラムが完全に最適化されたC ++プログラムに勝ることはめったにありませんが、メモリ管理などの違いにより、Javaで慣用的に実装される多くのアルゴリズムが、C ++で慣用的に実装される同じアルゴリズムよりも速くなる可能性があります。

@Jerry Coffinが指摘したように、簡単な変更でコードをはるかに高速化できる場合が多くありますが、多くの場合、パフォーマンスの改善に値するために、ある言語または他の言語であまりにも多くの不潔な調整が必要になる場合があります。これはおそらく、JavaがC ++よりも優れていることを示す優れたベンチマークで見られるものです。

また、通常はそれほど重要ではありませんが、JavaなどのJIT言語では実行できるがC ++では実行できないパフォーマンスの最適化がいくつかあります。Javaランタイムには、コードのコンパイル後に改善を含めることができます。つまり、JITは最適化されたコードを生成して、新しい（または少なくとも異なる）CPU機能を利用できる可能性があります。このため、10年前のJavaバイナリは、10年前のC ++バイナリよりも潜在的に優れている可能性があります。

最後に、全体像の完全な型安全性は、非常にまれなケースですが、極端なパフォーマンスの向上をもたらします。ほぼ完全にC＃ベースの言語で記述された実験的なOSであるSingularityは、ハードウェアプロセスの境界や高価なコンテキストスイッチが不要なため、プロセス間通信とマルチタスクがはるかに高速です。

Tim HollowayによるJavaRanchの投稿：

プリミティブな例を次に示します。機械が数学的に決定されたサイクルで動作する場合、分岐命令には通常2つの異なるタイミングがありました。1つは分岐が行われたとき、もう1つは分岐が行われなかったときです。通常、分岐のない場合の方が高速でした。明らかに、これは、どのケースがより一般的であるかという知識に基づいてロジックを最適化できることを意味します（「知っている」ことが必ずしも実際のケースとは限らないという制約があります）。

JIT再コンパイルは、これをさらに一歩進めます。実際のリアルタイムの使用状況を監視し、実際に最も一般的なケースに基づいてロジックを切り替えます。そして、ワークロードがシフトした場合は、元に戻します。静的にコンパイルされたコードではこれができません。これが、Javaが手作業で調整されたアセンブリ/ C / C ++コードよりも優れている場合がある方法です。

ソース：http : //www.coderanch.com/t/547458/Performance/java/Ahead-Time-vs-Just-time

これは、C ++プログラムをビルドするときに明示的にではなく、Javaプログラムの実行時にマシンコードを生成する最終ステップがJVM 内で透過的に行われるためです。

最新のJVMは、可能な限り高速にバイトコードをネイティブマシンコードにオンザフライでコンパイルするのに非常に多くの時間を費やしているという事実を考慮する必要があります。これにより、JVMは実行中のプログラムのプロファイリングデータを知ることでさらに改善できるあらゆる種類のコンパイラトリックを実行できます。

ゲッターを自動的にインライン化するようなもので、値を取得するためにJUMP-RETURNが必要ないように、物事を高速化します。

ただし、高速プログラムを実際に許可したのは、後でクリーンアップすることです。Javaのガベージコレクションメカニズムは、Cの手動のmalloc-free よりも高速です。多くの最新のmalloc-free実装は、下にあるガベージコレクタを使用します。

短い答え-そうではありません。それを忘れて、トピックは火や車輪と同じくらい古いです。Javaまたは.NETは、C / C ++よりも高速ではありません。最適化についてまったく考える必要のないほとんどのタスクに十分な速度です。フォームやSQL処理に似ていますが、それで終わりです。

ベンチマーク、または無能な開発者によって作成された小さなアプリの場合、最終的な結果は、Java / .NETがおそらく近くなり、さらに高速になるでしょう。

実際には、スタック上のメモリの割り当て、または単にmemzonesを使用するなどの単純なことは、その場でJava / .NETを単純に強制終了します。

ガベージコレクションの世界では、すべてのアカウンティングでmemzoneを使用しています。memzoneをCに追加すると、Cはその場で高速になります。特に、JavaとCの「高性能コード」ベンチマークでは、次のようになります。

for(...)
{
alloc_memory//Allocating heap in a loop is verrry good, in't it?
zero_memory//Extra zeroing, we really need it in our performance code
do_stuff//something like memory[i]++
realloc//This is lovely speedup
strlen//loop through all memory, because storing string length is soo getting old
free//Java will do that outside out timing loop, but oh well, we're comparing apples to oranges here
}//loop 100000 times

C / C ++（または新しい配置）でスタックベースの変数を使用してみてください。これらはsub esp, 0xff、単一のx86命令に変換され、Javaでそれを打ち負かすことができません。

ほとんどの場合、C ++とJavaを比較するベンチを見ると、次のようになります。間違ったメモリ割り当て戦略、リザーブなしの自己成長コンテナ、複数の新しいコンテナ。これは、パフォーマンス指向のC / C ++コードに近いものでもありません。

また、よく読んでください：https : //days2011.scala-lang.org/sites/days2011/files/ws3-1-Hundt.pdf

現実には、どちらもプログラマーが指示したとおりに行う高レベルのアセンブラーであり、プログラマーが指示したとおりの順序でプログラマーが指示したとおりです。パフォーマンスの違いは非常に小さいため、すべての実用的な目的にとって重要ではありません。

言語は「遅い」わけではなく、プログラマーは遅いプログラムを書きました。研究の著者が彼の特定のgrを磨こうとしない限り、プログラムが代替言語の最良の方法を使用して同じことを行うプログラムよりも（実用的な目的のために）1つの言語で最良の方法で書かれることは非常にまれです。

明らかに、ハードリアルタイムの組み込みシステムのようなまれなエッジケースに行く場合、言語の選択が違いを生む可能性がありますが、これはどのくらいの頻度ですか？そして、それらのケースのうち、正しい選択がどれくらいの頻度で盲目的に明らかでないか。

次のリンクを参照してください...しかし、これはどのように可能ですか？解釈されたバイトコードは、コンパイルされた言語よりも高速である可能性があるということを、私の心を揺さぶります。

1. それらのブログ投稿は信頼できる証拠を提供しますか？
2. それらのブログ投稿は決定的な証拠を提供しますか？
3. それらのブログ投稿は、「解釈されたバイトコード」についての証拠さえ提供しますか？

キース・リーは「明らかな欠陥」があると言いますが、それらの「明白な欠陥」については何もしません。2005年に、これらの古いタスクは破棄され、ベンチマークゲームで現在表示されているタスクに置き換えられました。

キースリーは、「今では時代遅れのGreat Computer Language ShootoutからC ++とJavaのベンチマークコードを取得し、テストを実行しました」と言いますが、実際には、それらの時代遅れのテストのうち25のうち14の測定のみを示しています。

キース・リーは、7年前にブログ投稿で何も証明しようとしていないと言いましたが、当時、彼は「Javaが遅いと言うのを聞いてうんざりしていました。当時彼が証明しようとしていたことがありました。

クリスチャンフェルデは、「コードを作成したのではなく、テストを再実行しただけです」と言っています。キースリーが選択したタスクとプログラムの測定値を公表するという彼の決定に対する責任から彼を免除したかのように。

25個の小さなプログラムでも、確実な証拠が得られますか？

これらの測定値は、Javaが解釈されない「混合モード」Javaとして実行されるプログラムに関するものです- 「HotSpotの仕組みを思い出してください」。Javaがバイトコードのみを解釈するように強制することができるため、Javaが「解釈されたバイトコード」をどれだけうまく実行できるかを簡単に見つけることができます。

「解釈されたバイトコード」というこの奇妙な概念がどれほど普及しているのか、私は楽しみにしています。JITコンパイルについて聞いたことがありますか？引数をJavaに適用することはできません。

ただし、JVMを別にすれば、直接スレッド化されたコードや、ささいなバイトコードの解釈でさえ、非常に最適化されたネイティブコードよりも簡単に優れている場合があります。説明は非常に簡単です。バイトコードは非常にコンパクトであり、同じアルゴリズムのネイティブコードバージョンで1回の反復で複数のキャッシュミスが発生すると、小さなキャッシュに収まります。

JIT、GCなどは別として、C ++は非常に簡単にJavaよりもはるかに遅くすることができます。これはベンチマークには表示されませんが、Java開発者とC ++開発者によって作成された同じアプリは、Javaではるかに高速になる可能性があります。

• 演算子のオーバーロード。「+」や「=」などの単純な演算子はすべて、安全性チェック、ディスク操作、ロギング、追跡、プロファイリングを行う数百行のコードを呼び出す場合があります。そして、それらは非常に使いやすいので、一度演算子をオーバーロードすると、使用法がどのように積み重なるかに気付かずに、自然かつ豊富に使用します。
• テンプレート。これらは、メモリほどの速度には影響しません。テンプレートを慎重に使用しないと、気付かないうちに数百万行のコード（基本テンプレートの代替）が生成されます。しかし、その後、バイナリの読み込み時間、メモリ使用量、スワップ使用量-すべてがベンチマークに対しても作用します。また、RAMの使用量は屋根を通ります。

高度な継承パターンに関しては、これらは非常に似ています-C ++にはJavaにはないものがあり、その逆もありますが、それらはすべて同様の大きなオーバーヘッドをもたらします。そのため、オブジェクト中心のプログラミングでは特別なC ++の利点はありません。

もう1つ注意点があります。GCは、割り当てを手動で管理するよりも高速または低速です。多くの小さなオブジェクトを割り当てると、GC環境では通常、メモリのチャンクが割り当てられ、新しいオブジェクトの必要に応じてその一部がディスパッチされます。管理対象-各オブジェクト=個別の割り当てにはかなりの時間がかかります。OTOH、大量のメモリを一度にmalloc（）してから、その一部をオブジェクトに手動で割り当てるか、オブジェクトのいくつかの大きなインスタンスを使用すると、はるかに高速になります。

どういうわけかStack Exchangeは他のスタックポイントを取得しないので、残念ながら返事はありません...

しかし、ここで2番目に多く投票された答えは、私の謙虚な意見では誤報に満ちています。

C / C ++の専門家による手巻きアプリは、常にJavaアプリケーションよりもずっと高速になります。「JavaまたはFasterほど高速」というものはありません。以下に引用する項目があるため、それはただ高速です。

JITコンパイル：自動オプティマイザーがエキスパートプログラマーの能力を備え、意図とCPUが実際に実行するコードとのリンクを確認することを本当に期待しますか？さらに、あなたがするすべてのJITは、すでにコンパイルされたプログラムと比較して時間のロスです。

ガベージコレクションは、プログラマが多かれ少なかれ効率的な方法で、割り当て解除を忘れていたリソースを単に割り当て解除するツールです。

明らかに、これは、Cプログラマーが専門家（用語を選んだ）がメモリを処理するために行うよりも遅くなる可能性があります（正しく作成されたアプリにリークはありません）。

パフォーマンスが最適化されたCアプリケーションは、実行中のCPUを認識し、そのCPUでコンパイルされています。それ以外の場合、パフォーマンスのためのすべてのステップを十分に実行しなかったことを意味しますか。

実行時の統計 これは私の知識を超えていますが、Cの専門家は、自動最適化を再び上回る十分な分岐予測知識を持っていると思われます-

非常に優れたライブラリ Javaのライブラリを介してすぐに利用できる最適化されていない関数が多数あり、どの言語でも同じことが言えますが、最適化されたライブラリは特に計算用にCで記述されています。

JVM は抽象化の層です。これは、その多くが上にある優れた点と、設計によって全体的なソリューションが遅くなることの両方を意味します。

全体：

Javaは、多くの保護、機能、ツールを備えたJVMで動作するため、C / C ++の速度に到達することはできません。

C ++は、コンピューティングまたはゲーム用の最適化されたソフトウェアに明確な優位性を持ち、最高のJava実装が2ページ目でしか見られないという点で、C ++実装がコーディングコンテストで勝つのを見るのが一般的です。

実際には、C ++はおもちゃではなく、ほとんどの現代言語で処理できる多くの間違いを回避することはできませんが、よりシンプルで安全性が低いため、本質的に高速です。

そして結論として、私はほとんどの人がこれについて2セントを与えず、最終的に最適化は非常に少数の幸運な開発者のみに予約されたスポーツであり、パフォーマンスが本当に懸念される場合を除いて言いたいと思います（ハードウェアを10倍しても役に立たない-または少なくとも数百万を表す）、ほとんどのマネージャーは最適化されていないアプリと大量のハードウェアを好みます。

少なくとも2つの印象的なmmoがJavaで行われているのを見てきました。これは、ゲームに十分な速さがないというのは間違った言い方です。ゲーム設計者が他の言語よりもC ++を好むからといって、単にJavaに関連しているだけではないというだけで、プログラマーが他のプログラミング言語/パラダイムに手を出したことがないと言うだけです。C / C ++またはJavaのような高度な言語のあらゆるものが、速度の議論に技術的に対応または打ち勝つコードを生成できます。それはプログラマーが知っていること、チームが最も協力していること、そして最も重要なことは彼らが言ったツールを使用する理由です。プログラミングのゲーム開発の側面に取り組んでいるので、議論にはもっと多くのことが必要です。簡単に言えば」s QAを満たすツールを使用することでビジネスに没頭するためのお金と時間についてのすべてであり、現実の世界では、Javaまたは他の言語よりもC ++を選択するというxxの理由は重要ではありません。それは単なる大量生産の決定です。最も基本的なレベルのコンピューティングアルゴリズムで遊んでいるのは1と0だけであり、速度の引数はゲームに適用される最も愚かな引数の1つです。ひどく速度の向上が必要な場合は、プログラミング言語を完全に削除し、アセンブリを操作してください。