インラインアセンブリ言語はネイティブC ++コードよりも遅いですか？

インラインアセンブリ言語とC ++コードのパフォーマンスを比較しようとしたので、サイズ2000の2つの配列を100000回追加する関数を作成しました。これがコードです：

#define TIMES 100000
void calcuC(int *x,int *y,int length)
{
    for(int i = 0; i < TIMES; i++)
    {
        for(int j = 0; j < length; j++)
            x[j] += y[j];
    }
}


void calcuAsm(int *x,int *y,int lengthOfArray)
{
    __asm
    {
        mov edi,TIMES
        start:
        mov esi,0
        mov ecx,lengthOfArray
        label:
        mov edx,x
        push edx
        mov eax,DWORD PTR [edx + esi*4]
        mov edx,y
        mov ebx,DWORD PTR [edx + esi*4]
        add eax,ebx
        pop edx
        mov [edx + esi*4],eax
        inc esi
        loop label
        dec edi
        cmp edi,0
        jnz start
    };
}

ここにありmain()ます：

int main() {
    bool errorOccured = false;
    setbuf(stdout,NULL);
    int *xC,*xAsm,*yC,*yAsm;
    xC = new int[2000];
    xAsm = new int[2000];
    yC = new int[2000];
    yAsm = new int[2000];
    for(int i = 0; i < 2000; i++)
    {
        xC[i] = 0;
        xAsm[i] = 0;
        yC[i] = i;
        yAsm[i] = i;
    }
    time_t start = clock();
    calcuC(xC,yC,2000);

    //    calcuAsm(xAsm,yAsm,2000);
    //    for(int i = 0; i < 2000; i++)
    //    {
    //        if(xC[i] != xAsm[i])
    //        {
    //            cout<<"xC["<<i<<"]="<<xC[i]<<" "<<"xAsm["<<i<<"]="<<xAsm[i]<<endl;
    //            errorOccured = true;
    //            break;
    //        }
    //    }
    //    if(errorOccured)
    //        cout<<"Error occurs!"<<endl;
    //    else
    //        cout<<"Works fine!"<<endl;

    time_t end = clock();

    //    cout<<"time = "<<(float)(end - start) / CLOCKS_PER_SEC<<"\n";

    cout<<"time = "<<end - start<<endl;
    return 0;
}

次に、プログラムを5回実行して、時間と見なすことができるプロセッサのサイクルを取得します。上記の関数のみを呼び出すたびに。

そして、これが結果です。

アセンブリバージョンの機能：

Debug   Release
---------------
732        668
733        680
659        672
667        675
684        694
Average:   677

C ++バージョンの機能：

Debug     Release
-----------------
1068      168
 999      166
1072      231
1002      166
1114      183
Average:  182

リリースモードのC ++コードは、アセンブリコードよりも約3.7倍高速です。どうして？

私が書いたアセンブリコードは、GCCが生成したものほど効果的ではないと思います。私のような一般的なプログラマーが、コンパイラーが生成する対戦相手よりも速くコードを書くのは難しいです。つまり、自分の手で作成したアセンブリー言語のパフォーマンスを信頼せず、C ++に集中して、アセンブリー言語を忘れてはなりませんか？

はい、ほとんどの場合。

まず第一に、低水準言語（この場合はアセンブリ）は常に高水準言語（この場合はC ++およびC）よりも高速なコードを生成するという誤った仮定から始めます。それは真実ではない。Cコードは常にJavaコードより高速ですか？いいえ、別の変数があるからです：プログラマー。コードの記述方法とアーキテクチャの詳細に関する知識は、パフォーマンスに大きな影響を与えます（この場合で見たように）。

手作りのアセンブリコードがコンパイルされたコードよりも優れている例をいつでも作成できますが、通常は架空の例または単一のルーチンであり、500.000行以上のC ++コードの真のプログラムではありません）。私は、コンパイラは、アセンブリより良いコードの95％の時間を作るとなると思う時々 、唯一のいくつかの珍しい回、あなたは、いくつかの短い、の書き込みアセンブリコードに必要になることがあり、高度に使用、パフォーマンスの重要なルーチンまたはアクセスを持っている場合は、あなたのお気に入りのハイレベル言語を備え公開しません。この複雑さに少し触れたいですか？この素晴らしい答えをここで読んでください。

なんでこれ？

まず第一に、コンパイラーは私たちが想像もできない最適化を行うことができ（この短いリストを参照）、秒単位で（数日を必要とする場合）最適化を行うためです。

アセンブリでコーディングするときは、明確に定義された呼び出しインターフェイスを使用して、明確に定義された関数を作成する必要があります。ただし、プログラム全体の最適化や、レジスターの割り当て、定数の伝播、共通の部分式の削除、命令のスケジューリングなど、明白ではない複雑な最適化（ポリトープモデルなど）などの手続き間の最適化を考慮に入れることができます。上のRISCアーキテクチャ連中はこの何年も前の心配を停止（命令スケジューリングは、例えば、非常に難しいことです手でチューン）と近代的なCISCの CPUは非常に長い持っているパイプラインを あまりにも。

一部の複雑なマイクロコントローラーでは、コンパイラーがより優れた（そして保守が容易な）最終コードを生成するため、システムライブラリでさえ、アセンブリではなくCで記述されています。

コンパイラは一部のMMX / SIMDx命令を自動的に単独で使用することがあり、それらを使用しない場合は単純に比較できません（他の回答はすでにアセンブリコードを非常によくレビューしています）。ループのためだけに、これはコンパイラーによって一般的にチェックされるもののループ最適化の短いリストです（C＃プログラムのスケジュールが決定したときに自分で実行できると思いますか？）アセンブリで何かを書く場合、私は少なくともいくつかの簡単な最適化を検討する必要があると思います。配列の教科書の例は、サイクルを展開することです（そのサイズはコンパイル時に既知です）。それを実行して、もう一度テストを実行してください。

最近では、別の理由でさまざまなCPUが多すぎるために、アセンブリ言語を使用する必要があることもほとんどありません。それらすべてをサポートしますか？それぞれに特定のマイクロアーキテクチャといくつかの特定の命令セットがあります。機能ユニットの数は異なり、すべてをビジー状態に保つために、組み立て手順を調整する必要があります。Cで作成する場合はPGOを使用できますが、アセンブリでは、その特定のアーキテクチャについての高度な知識が必要になります（別のアーキテクチャについてすべてを再考してやり直す必要があります）。小さなタスクの場合、コンパイラーは通常それをよりよく行い、複雑なタスクの場合、通常、作業は返済されません（そしてコンパイラはとにかくより良いかもしれません）。

座ってコードを見てみると、おそらく、アセンブリに変換するよりもアルゴリズムを再設計するほうが多く得られることがわかります（SOに関するこの素晴らしい投稿を読んでください）。高度な最適化があります（そしてコンパイラへのヒント）アセンブリ言語に頼る必要がある前に効果的に適用できます。組み込み関数を頻繁に使用すると、探しているパフォーマンスが向上し、コンパイラーは最適化のほとんどを実行できることに言及する価値があるでしょう。

以上のことから、5〜10倍高速のアセンブリコードを生成できる場合でも、1週間の時間を支払うか、50ドル高速なCPUを購入するかを顧客に尋ねる必要があります。ほとんどの場合（そして特にLOBアプリケーションでは）極端な最適化はほとんど必要ありません。

アセンブリコードは最適ではなく、改善される可能性があります。

• 内部ループでレジスター（EDX）をプッシュおよびポップしています。これはループの外に移動する必要があります。
• ループのすべての反復で配列ポインターを再ロードします。これはループの外に移動する必要があります。
• 最新のほとんどのCPUで非常に遅いことloopがわかっている命令を使用します（おそらく、古いアセンブリブックを使用した結果*）。
• 手動ループ展開を利用しません。
• 利用可能なSIMD命令は使用しません。

したがって、アセンブラに関するスキルセットを大幅に向上させない限り、パフォーマンスのためにアセンブラコードを記述することは意味がありません。

*もちろんloop、古代の集会本から本当に教訓を得たかどうかはわかりません。しかし、実際のコードでそれを目にすることはほとんどありません。そこにあるすべてのコンパイラーはを放出しないほどスマートなloopので、私見の悪い本や古い本でしか見られません。

アセンブリに入る前でも、より高いレベルに存在するコード変換があります。

static int const TIMES = 100000;

void calcuC(int *x, int *y, int length) {
  for (int i = 0; i < TIMES; i++) {
    for (int j = 0; j < length; j++) {
      x[j] += y[j];
    }
  }
}

ループ回転を介してに変換することができます：

static int const TIMES = 100000;

void calcuC(int *x, int *y, int length) {
    for (int j = 0; j < length; ++j) {
      for (int i = 0; i < TIMES; ++i) {
        x[j] += y[j];
      }
    }
}

これは、メモリの局所性に関してははるかに優れています。

これはさらに最適化される可能性がありますa += b。X回実行するa += X * bことは、次のように実行することと同じです。

static int const TIMES = 100000;

void calcuC(int *x, int *y, int length) {
    for (int j = 0; j < length; ++j) {
      x[j] += TIMES * y[j];
    }
}

ただし、私のお気に入りのオプティマイザー（LLVM）はこの変換を実行しないようです。

[編集]私は、我々が持っていた場合、変換が実行されることがわかっrestrictへの修飾子をxとy。確かに、この制限はなく、x[j]そしてy[j]可能性この変換の誤を行う同じ場所にエイリアス。[編集を終了]

とにかく、これは最適化されたCバージョンだと思います。すでにそれははるかに簡単です。これに基づいて、ASMでの亀裂を以下に示します（Clangで生成させたので、役に立たない）。

calcuAsm:                               # @calcuAsm
.Ltmp0:
    .cfi_startproc
# BB#0:
    testl   %edx, %edx
    jle .LBB0_2
    .align  16, 0x90
.LBB0_1:                                # %.lr.ph
                                        # =>This Inner Loop Header: Depth=1
    imull   $100000, (%rsi), %eax   # imm = 0x186A0
    addl    %eax, (%rdi)
    addq    $4, %rsi
    addq    $4, %rdi
    decl    %edx
    jne .LBB0_1
.LBB0_2:                                # %._crit_edge
    ret
.Ltmp1:
    .size   calcuAsm, .Ltmp1-calcuAsm
.Ltmp2:
    .cfi_endproc

これらのすべての命令がどこから来ているのかわからないのですが、いつでも楽しんで、比較してみることができます...しかし、コードでは、アセンブリバージョンではなく、最適化されたCバージョンを使用します。はるかにポータブルです。

短い答え：はい。

長い答え：はい、自分が何をしているかを本当に理解していて、そうする理由がある場合を除きます。

私は私のasmコードを修正しました：

  __asm
{   
    mov ebx,TIMES
 start:
    mov ecx,lengthOfArray
    mov esi,x
    shr ecx,1
    mov edi,y
label:
    movq mm0,QWORD PTR[esi]
    paddd mm0,QWORD PTR[edi]
    add edi,8
    movq QWORD PTR[esi],mm0
    add esi,8
    dec ecx 
    jnz label
    dec ebx
    jnz start
};

リリースバージョンの結果：

 Function of assembly version: 81
 Function of C++ version: 161

リリースモードのアセンブリコードは、C ++のほぼ2倍高速です。

手で書いたアセンブリ言語のパフォーマンスを信用してはいけないという意味ですか

はい、それはまさにそれが意味することであり、それはすべての言語に当てはまります。言語Xで効率的なコードを書く方法がわからない場合は、Xで効率的なコードを書く能力を信用しないでください。したがって、効率的なコードが必要な場合は、別の言語を使用する必要があります。

アセンブリはこれに特に敏感です。なぜなら、まあ、あなたが見るものはあなたが得るものだからです。CPUに実行させる特定の命令を記述します。高水準言語では、コードを変換し、多くの非効率を取り除くことができるコンパイラが間にあります。アセンブリを使用すると、自分で作業できます。

現在、アセンブリ言語を使用する唯一の理由は、その言語ではアクセスできないいくつかの機能を使用することです。

これは以下に適用されます：

• MMUなどの特定のハードウェア機能にアクセスする必要があるカーネルプログラミング
• コンパイラーでサポートされていない非常に特定のベクトルまたはマルチメディア命令を使用する高性能プログラミング。

しかし、現在のコンパイラーは非常にスマートd = a / b; r = a % b;です。Cにそのような演算子がなくても、除算と剰余を利用できる場合は、1つの命令で除算と剰余を計算する単一の命令で2つの個別のステートメントを置き換えることも できます。

現代のコンパイラーがコードの最適化で素晴らしい仕事をしているのは事実ですが、それでも、アセンブリーについて学ぶことをお勧めします。

まず第一にあなたは明らかに それに脅かされていません。それは素晴らしい、素晴らしいプラスです。次に、あなたは速度の仮定を検証または破棄するためにプロファイリングすることで正しい軌道に乗っており、経験豊富な人々からの入力を求めています。人類に知られている最大の最適化ツールを持っている： 脳。

経験が増えるにつれて、それをいつ、どこで使用するかを学習します（通常、アルゴリズムレベルで深く最適化した後、コード内の最もタイトで最も内側のループ）。

インスピレーションを得るために、Michael Abrashの記事を参照することをお勧めします（彼から連絡がない場合は、彼は最適化の第一人者です。彼は、Quakeソフトウェアレンダラーの最適化でJohn Carmackと協力しました！）

「最速のコードのようなものはありません」-Michael Abrash

私はasmコードを変更しました：

 __asm
{ 
    mov ebx,TIMES
 start:
    mov ecx,lengthOfArray
    mov esi,x
    shr ecx,2
    mov edi,y
label:
    mov eax,DWORD PTR [esi]
    add eax,DWORD PTR [edi]
    add edi,4   
    dec ecx 
    mov DWORD PTR [esi],eax
    add esi,4
    test ecx,ecx
    jnz label
    dec ebx
    test ebx,ebx
    jnz start
};

リリースバージョンの結果：

 Function of assembly version: 41
 Function of C++ version: 161

リリースモードのアセンブリコードは、C ++のほぼ4倍高速です。IMHo、アセンブリコードの速度はプログラマーによって異なります

とても面白いトピックです！
SashaのコードでSSEによってMMXを変更しました
でが私の結果です。

Function of C++ version:      315
Function of assembly(simply): 312
Function of assembly  (MMX):  136
Function of assembly  (SSE):  62

SSEを使用したアセンブリコードは、C ++の5倍高速です。

ほとんどの高水準言語コンパイラは非常に最適化されており、それらが何をしているかを知っています。逆アセンブルコードをダンプして、ネイティブアセンブリと比較できます。私はあなたがコンパイラが使用しているいくつかの素晴らしいトリックを見ることになると思います。

ちょうど例えば、それがもう正しいかどうかはわかりませんが:)：

実行：

mov eax,0

よりサイクルがかかる

xor eax,eax

同じことをします。

コンパイラーはこれらすべてのトリックを知っており、それらを使用します。

コンパイラはあなたを倒しました。試してみますが、保証はいたしません。TIMESによる「乗算」は、より適切なパフォーマンステストを行うためのものでyありx、16にアラインされてlengthおり、ゼロ以外の4の倍数であると想定します。

  mov ecx,length
  lea esi,[y+4*ecx]
  lea edi,[x+4*ecx]
  neg ecx
loop:
  movdqa xmm0,[esi+4*ecx]
  paddd xmm0,[edi+4*ecx]
  movdqa [edi+4*ecx],xmm0
  add ecx,4
  jnz loop

私が言ったように、私は保証をしません。しかし、それがはるかに速く実行できる場合、私は驚かれます-ここでのボトルネックは、すべてがL1ヒットであっても、メモリスループットです。

まったく同じアルゴリズムを命令ごとにアセンブリで盲目的に実装すると、コンパイラーが実行できるよりも遅いことが保証されます。

それは、コンパイラーが行う最小の最適化でさえ、最適化をまったく行わない厳密なコードよりも優れているためです。

もちろん、コンパイラーを打ち負かすことは可能です。特にそれがコードの小さなローカライズされた部分である場合、私は自分でやらなくてはなりません。4倍高速化しますが、この場合、ハードウェアの十分な知識と、一見すると直感に反する多くのトリックに大きく依存する必要があります。

コンパイラーとして、固定サイズのループを多くの実行タスクに置き換えます。

int a = 10;
for (int i = 0; i < 3; i += 1) {
    a = a + i;
}

作り出す

int a = 10;
a = a + 0;
a = a + 1;
a = a + 2;

そして最終的には、「a = a + 0;」であることがわかります。それは役に立たないので、この行を削除します。うまくいけば、あなたの頭の中の何かがコメントとしていくつかの最適化オプションを付ける用意があります。これらの非常に効果的な最適化により、コンパイルされた言語が高速になります。

それはまさにそれが意味することです。マイクロ最適化はコンパイラに任せます。

この例は、低レベルのコードに関する重要な教訓を示しているので、気に入っています。はい、Cコードと同じ速さのアセンブリを記述できます。これはトートロジー的に真実ですが、必ずしも何も意味しません。明らかに誰かがそうできなければ、アセンブラは適切な最適化を知りません。

同様に、言語の抽象化の階層を上っていくと、同じ原則が適用されます。はい、ダーティなperlスクリプトと同じくらい高速なパーサーをCで書くことができ、多くの人々がそうしています。ただし、Cを使用したためにコードが高速になるという意味ではありません。多くの場合、高級言語はあなたが考えたこともないような最適化を行います。

多くの場合、一部のタスクを実行する最適な方法は、タスクが実行されるコンテキストによって異なります。ルーチンがアセンブリ言語で記述されている場合、通常、命令のシーケンスをコンテキストに基づいて変更することはできません。簡単な例として、次の簡単な方法を考えます。

inline void set_port_high(void)
{
  (*((volatile unsigned char*)0x40001204) = 0xFF);
}

上記の32ビットARMコードのコンパイラは、おそらく次のようにレンダリングします。

ldr  r0,=0x40001204
mov  r1,#0
strb r1,[r0]
[a fourth word somewhere holding the constant 0x40001204]

多分

ldr  r0,=0x40001000  ; Some assemblers like to round pointer loads to multiples of 4096
mov  r1,#0
strb r1,[r0+0x204]
[a fourth word somewhere holding the constant 0x40001000]

これは、次のいずれかの方法で、手動で組み立てたコードでわずかに最適化できます。

ldr  r0,=0x400011FF
strb r0,[r0+5]
[a third word somewhere holding the constant 0x400011FF]

または

mvn  r0,#0xC0       ; Load with 0x3FFFFFFF
add  r0,r0,#0x1200  ; Add 0x1200, yielding 0x400011FF
strb r0,[r0+5]

手動で組み立てたアプローチはどちらも、16バイトではなく12バイトのコードスペースを必要とします。後者は、「ロード」を「アド」に置き換えます。これにより、ARM7-TDMIでは2サイクル速く実行されます。コードがr0が知らない/わからないコンテキストで実行される場合、アセンブリ言語のバージョンはコンパイルされたバージョンよりもいくらか優れています。一方、あるレジスタ[eg r5]が目的のアドレス0x40001204 [eg 0x40001000]の2047バイト以内の値を保持することをコンパイラが知っていて、さらに他のレジスタ[eg r7]が行くことを知っていたとします。下位ビットが0xFFである値を保持します。その場合、コンパイラーはコードのCバージョンを最適化して単純に次のようにすることができます。

strb r7,[r5+0x204]

手動で最適化されたアセンブリコードよりもはるかに短くて高速です。さらに、set_port_highが次のコンテキストで発生したとします。

int temp = function1();
set_port_high();
function2(temp); // Assume temp is not used after this

組み込みシステム用にコーディングする場合は、まったく信じられないことではありません。set_port_highがアセンブリコードで記述されている場合、コンパイラはfunction1、アセンブリコードを呼び出す前にr0（からの戻り値を保持する）を別の場所に移動し、その後、その値をr0に戻す必要がありfunction2ます（r0の最初のパラメータが予期されるため）。したがって、「最適化された」アセンブリコードには5つの命令が必要です。格納するアドレスまたは値を保持するレジスターをコンパイラーが知らなかったとしても、その4命令バージョン（使用可能なレジスターを使用するように適応できる-必ずしもr0とr1ではない）は、「最適化された」アセンブリーに勝るものです。 -言語バージョン。前述のように、コンパイラがr5とr7に必要なアドレスとデータを持ち、1つの命令で-function1これらのレジスタは変更されないため、set_port_highstrb「手動で最適化された」アセンブリコードよりも小さくて高速な4つの命令。

プログラマーが正確なプログラムフローを知っている場合、手動で最適化されたアセンブリコードはコンパイラよりも優れている場合がありますが、コンテキストがわかる前にコードの一部が記述されている場合や、ソースコードの一部が複数のコンテキストから呼び出されます[ set_port_highコード内の50の異なる場所で使用されている場合、コンパイラーはそれらをそれぞれ最適に展開する方法を個別に決定できます]。

一般的に、アセンブリ言語は、コードの各部分が非常に限られた数のコンテキストからアプローチできる場合に最大のパフォーマンス向上をもたらす傾向があり、一部の部分でパフォーマンスが低下する傾向があることをお勧めします。コードは、さまざまなコンテキストからアプローチできます。興味深いことに（そして便利に）アセンブリがパフォーマンスにとって最も有益なケースは、多くの場合、コードが最も単純で読みやすいケースです。アセンブリ言語のコードが厄介な混乱に変わる場所は、多くの場合、アセンブリを記述することでパフォーマンスの利点が最小になる場所です。

[マイナーな注意：アセンブリコードを使用して、高度に最適化されたねばねばした混乱を生み出すことができる場所がいくつかあります。たとえば、ARMに対して実行したコードの1つは、RAMからワードをフェッチし、値の上位6ビットに基づいて約12のルーチンの1つを実行する必要がありました（多くの値が同じルーチンにマッピングされています）。私はそのコードを次のようなものに最適化したと思います：

ldrh  r0,[r1],#2! ; Fetch with post-increment
ldrb  r1,[r8,r0 asr #10]
sub   pc,r8,r1,asl #2

レジスタr8は常にメインディスパッチテーブルのアドレスを保持していました（コードがその時間の98％を費やすループ内では、他の目的で使用することはありません）。すべての64エントリは、その前の256バイトのアドレスを参照していました。プライマリループにはほとんどの場合、約60サイクルという厳しい実行時間制限があったため、9サイクルのフェッチとディスパッチは、その目標を達成するために非常に役立ちました。256ビットの32ビットアドレスのテーブルを使用すると1サイクル速くなりますが、1KBの非常に貴重なRAMを消費します[フラッシュは複数の待機状態を追加します]。64ビットの32ビットアドレスを使用するには、フェッチしたワードから一部のビットをマスクする命令を追加する必要があり、実際に使用したテーブルよりも192バイト多く使用されていました。8ビットオフセットのテーブルを使用すると、非常にコンパクトで高速なコードが得られました。しかし、コンパイラが思いつくものとは思いませんでした。また、コンパイラがテーブルアドレスを保持するためにレジスタを「フルタイム」専用にすることも期待していません。

上記のコードは、自己完結型システムとして実行するように設計されています。定期的にCコードを呼び出すことができますが、通信しているハードウェアが16ミリ秒ごとに約1ミリ秒の間隔で安全に "アイドル"状態になる特定の時間のみです。

最近、私が行ったすべての速度最適化は、脳が損傷した遅いコードを適切なコードに置き換えることでした。しかし、速度が非常に重要であり、私は何かを速く作ることに真剣に取り組んだため、結果は常に反復的なプロセスであり、反復ごとに問題へのより多くの洞察を与え、より少ない操作で問題を解決する方法を見つけました。最終的な速度は常に、問題にどれだけの洞察を得たかによって決まりました。いずれかの段階で、アセンブリコード、または最適化しすぎたCコードを使用した場合、より良いソリューションを見つけるプロセスが影響を受け、最終結果が遅くなります。

正しい方法でより深い知識を持つアセンブリ言語を使用していない限り、C ++はより高速です。

ASMでコーディングする場合、論理的に可能な場合はCPUがより多くの命令を並行して実行できるように、命令を手動で再編成します。たとえば、ASMでコーディングするときはRAMをほとんど使用していません。ASMにはコードが20000行以上あり、push / popを使用したことがありません。

オペコードの途中でジャンプして、コードと動作を自己修正し、自己修正コードによるペナルティはない可能性があります。レジスタへのアクセスには、CPUの1ティック（場合によっては.25ティック）が必要です。RAMへのアクセスには数百時間がかかる場合があります。

ASMの最後の冒険では、RAMを使用して変数を格納したことはありません（ASMの数千行分）。ASMは、C ++よりも想像以上に高速である可能性があります。しかし、それは次のような多くの変動要因に依存します。

1. I was writing my apps to run on the bare metal.
2. I was writing my own boot loader that was starting my programs in ASM so there was no OS management in the middle.

生産性の問題に気付いたので、C＃とC ++を習得しています!! 純粋なASMだけを自由時間に使用して、想像できる最速のプログラムを実行することができます。しかし、何かを生み出すためには、高級言語を使用してください。

たとえば、私がコーディングした最後のプログラムはJSとGLSLを使用していて、遅いJSについて話しても、パフォーマンスの問題に気づくことはありませんでした。これは、GPUを3Dでプログラミングするという単なる概念では、GPUにコマンドを送信する言語の速度がほとんど無関係になるためです。

ベアメタル上でのアセンブラ単独の速度は反駁できません。C ++の内部ではさらに遅くなるでしょうか？-それは、アセンブラーを最初に使用しないコンパイラーでアセンブリー・コードを作成していることが原因である可能性があります。

私の評議会は、たとえ私がアセンブリを愛しているとしても、それを避けることができるのであれば、アセンブリコードを決して記述しないことです。

ここでのすべての回答は、1つの側面を除外しているように見えます。特定の目的を達成するためのコードを記述しないこともありますが、それだけの面白さのためです。そうするための時間を投資するのは経済的ではないかもしれませんが、間違いなく、最速のコンパイラー最適化コードスニペットを手動でローリングされたasmの代わりに速度で打ち負かすほどの満足感はありません。

c ++コンパイラーは、組織レベルで最適化した後、ターゲットのCPUの組み込み関数を利用するコードを生成します。HLLは、いくつかの理由でアセンブラを追い越したり、パフォーマンスを向上させたりすることはありません。1.）HLLは、すべての必要なサイクル（フリップとフロップ）でコンパイルされ、アクセサコード、境界チェック、および場合によっては組み込みガベージコレクション（以前のOOPマニエリスムのスコープに対応）で出力されます。HLLは最近（新しいC ++やGOのような他のものを含む）優れた仕事をしますが、アセンブラー（つまり、コード）を上回る場合は、CPUのドキュメントを参照する必要があります。 op-codeに至るまでHLLは詳細を抽象化し、それらを排除しません。ホストOSによって認識されている場合でも、アプリは実行されません。

ほとんどのアセンブラコード（主にオブジェクト）は、「ヘッドレス」として出力され、他の実行可能形式に含めることができるため、必要な処理がはるかに少なくて済みます。実行可能ファイルがアセンブラー（NAsm、YAsmなど）によって出力される場合、機能のHLLコードと完全に一致するまで、実行速度は速くなりますが、結果は正確に比較されます。

任意の形式でHLLからアセンブラーベースのコードオブジェクトを呼び出すと、変数/定数データ型にグローバルに割り当てられたメモリを使用するメモリ空間呼び出しに加えて、本質的に処理オーバーヘッドが追加されます（これはLLLとHLLの両方に適用されます）。最終的な出力では、最終的にCPUをハードウェア（オペコード）に対するAPIとabiとして使用し、アセンブラーと「HLLコンパイラー」は本質的/基本的に同じですが、唯一の真の例外は読みやすさ（文法的）です。

FAsmを使用したアセンブラーでのHello Worldコンソールアプリケーションは1.5 KB（これはWindowsではFreeBSDとLinuxではさらに小さくなっています）であり、GCCがその最高の日に投げ出すことができるものをすべて上回ります。その理由は、いくつか例を挙げると、nopsによる暗黙的なパディング、アクセス検証、および境界チェックです。本当の目標は、クリーンなHLLライブラリと、「ハードコア」な方法でCPUをターゲットにし、最近ではほとんど（最終的に）実行する最適化可能なコンパイラーです。GCCはYAsmよりも優れているわけではありません。問題となっているのは、コーディングの実践と開発者の理解であり、「最適化」は初心者の探索と暫定的なトレーニングと経験の後に行われます。

コンパイラーは、アセンブラーと同じオペコードで出力用にリンクおよびアセンブルする必要があります。これらのコードは、CPUが除くすべてのものであるためです（CISCまたはRISC [PICも]）。YAsmは初期NAsmを大幅に最適化およびクリーンアップし、最終的にはそのアセンブラからのすべての出力を高速化しますが、それでもYAsmはNAsmと同様に、開発者に代わってOSライブラリをターゲットとする外部依存関係を持つ実行可能ファイルを生成するため、マイレージが異なる場合があります。最後に、C ++はアセンブラよりも信じられないほどはるかに安全な時点にあり、特に商業部門では80％以上です...

コンパイラが大量のOOサポートコードを生成する場合、アセンブリはより高速になる可能性があります。

編集：

反対投票者へ：OPは、「C ++に集中して、アセンブリ言語を忘れるべきですか？」と書いた。そして私は私の答えを待ちます。特にメソッドを使用する場合は、OOが生成するコードを常に監視する必要があります。アセンブリ言語を忘れないということは、OOコードが生成するアセンブリを定期的に確認することを意味します。これは、優れたパフォーマンスのソフトウェアを作成するために必要だと思います。

実際、これはオブジェクト指向だけでなく、すべてのコンパイル可能なコードに関係します。