私はかなり長い間アセンブラを学んでいて、パフォーマンス上の利点（もしあれば）を見るためにいくつかの簡単なプロシージャ\関数をそれに書き直そうとしています。私の主な開発ツールはDelphi2007で、最初の例はその言語で作成されますが、他の言語にも簡単に翻訳できます。
問題は次のように述べています。
8ビットのそれぞれが画面の1行のピクセルを表す符号なしバイト値を指定しました。各単一ピクセルは、ソリッド（1）またはトランスペアレント（0）にすることができます。つまり、1バイトの値に8ピクセルがパックされています。最も若いピクセル（ビット）が配列の最も低いインデックスの下に着地するように、これらのピクセルを8バイト配列にアンパックしたいと思います。次に例を示します。
One byte value -----------> eight byte array
10011011 -----------------> [1][1][0][1][1][0][0][1]
Array index number -------> 0 1 2 3 4 5 6 7
以下に、問題を解決している5つの方法を示します。次に、彼らの時間比較と、それらの時間をどのように測定したかを示します。
私の質問は2つの部分で構成されています。
1.1。
方法との詳細な回答をお願いします。なぜメソッドはよりもやや遅いのですか？DecodePixels4aDecodePixels4b4b4a
たとえば、コードが正しく配置されていないために処理速度が遅い場合は、特定のメソッドのどの命令をより適切に配置できるか、およびメソッドを壊さないようにする方法を教えてください。
理論の裏にある実例を見たいと思います。私はアセンブリを学んでいることを覚えておいてください。あなたの答えから知識を得て、将来、より最適化されたコードを書くことができるようにしたいと思います。
2.2。
あなたはより速いルーチンを書くことができますDecodePixels4aか？もしそうなら、それを提示し、あなたが取った最適化のステップを説明してください。より高速なルーチンとは、ここに示されているすべてのルーチンの中で、テスト環境で最短時間で実行されるルーチンを意味します。
すべてのインテルファミリープロセッサーが許可されており、それらと互換性があります。
以下に私が書いたルーチンがあります：
procedure DecodePixels1(EncPixels: Byte; var DecPixels: TDecodedPixels);
var
i3: Integer;
begin
DecPixels[0] := EncPixels and $01;
for i3 := 1 to 7 do
begin
EncPixels := EncPixels shr 1;
DecPixels[i3] := EncPixels and $01;
//DecPixels[i3] := (EncPixels shr i3) and $01; //this is even slower if you replace above 2 lines with it
end;
end;
//Lets unroll the loop and see if it will be faster.
procedure DecodePixels2(EncPixels: Byte; var DecPixels: TDecodedPixels);
begin
DecPixels[0] := EncPixels and $01;
EncPixels := EncPixels shr 1;
DecPixels[1] := EncPixels and $01;
EncPixels := EncPixels shr 1;
DecPixels[2] := EncPixels and $01;
EncPixels := EncPixels shr 1;
DecPixels[3] := EncPixels and $01;
EncPixels := EncPixels shr 1;
DecPixels[4] := EncPixels and $01;
EncPixels := EncPixels shr 1;
DecPixels[5] := EncPixels and $01;
EncPixels := EncPixels shr 1;
DecPixels[6] := EncPixels and $01;
EncPixels := EncPixels shr 1;
DecPixels[7] := EncPixels and $01;
end;
procedure DecodePixels3(EncPixels: Byte; var DecPixels: TDecodedPixels);
begin
asm
push eax;
push ebx;
push ecx;
mov bl, al;
and bl, $01;
mov [edx], bl;
mov ecx, $00;
@@Decode:
inc ecx;
shr al, $01;
mov bl, al;
and bl, $01;
mov [edx + ecx], bl;
cmp ecx, $07;
jnz @@Decode;
pop ecx;
pop ebx;
pop eax;
end;
end;
//Unrolled assembly loop
procedure DecodePixels4a(EncPixels: Byte; var DecPixels: TDecodedPixels);
begin
asm
push eax;
push ebx;
mov bl, al;
and bl, $01;
mov [edx], bl;
shr al, $01;
mov bl, al;
and bl, $01;
mov [edx + $01], bl;
shr al, $01;
mov bl, al;
and bl, $01;
mov [edx + $02], bl;
shr al, $01;
mov bl, al;
and bl, $01;
mov [edx + $03], bl;
shr al, $01;
mov bl, al;
and bl, $01;
mov [edx + $04], bl;
shr al, $01;
mov bl, al;
and bl, $01;
mov [edx + $05], bl;
shr al, $01;
mov bl, al;
and bl, $01;
mov [edx + $06], bl;
shr al, $01;
mov bl, al;
and bl, $01;
mov [edx + $07], bl;
pop ebx;
pop eax;
end;
end;
// it differs compared to 4a only in switching two instructions (but seven times)
procedure DecodePixels4b(EncPixels: Byte; var DecPixels: TDecodedPixels);
begin
asm
push eax;
push ebx;
mov bl, al;
and bl, $01;
shr al, $01; //
mov [edx], bl; //
mov bl, al;
and bl, $01;
shr al, $01; //
mov [edx + $01], bl; //
mov bl, al;
and bl, $01;
shr al, $01; //
mov [edx + $02], bl; //
mov bl, al;
and bl, $01;
shr al, $01; //
mov [edx + $03], bl; //
mov bl, al;
and bl, $01;
shr al, $01; //
mov [edx + $04], bl; //
mov bl, al;
and bl, $01;
shr al, $01; //
mov [edx + $05], bl; //
mov bl, al;
and bl, $01;
shr al, $01; //
mov [edx + $06], bl; //
mov bl, al;
and bl, $01;
mov [edx + $07], bl;
pop ebx;
pop eax;
end;
end;
そして、これが私がそれらをテストする方法です：
program Test;
{$APPTYPE CONSOLE}
uses
SysUtils, Windows;
type
TDecodedPixels = array[0..7] of Byte;
var
Pixels: TDecodedPixels;
Freq, TimeStart, TimeEnd :Int64;
Time1, Time2, Time3, Time4a, Time4b: Extended;
i, i2: Integer;
begin
if QueryPerformanceFrequency(Freq) then
begin
for i2 := 1 to 100 do
begin
QueryPerformanceCounter(TimeStart);
for i := 1 to 100000 do
DecodePixels1(155, Pixels);
QueryPerformanceCounter(TimeEnd);
Time1 := Time1 + ((TimeEnd - TimeStart) / Freq * 1000);
QueryPerformanceCounter(TimeStart);
for i := 1 to 100000 do
DecodePixels2(155, Pixels);
QueryPerformanceCounter(TimeEnd);
Time2 := Time2 + ((TimeEnd - TimeStart) / Freq * 1000);
QueryPerformanceCounter(TimeStart);
for i := 1 to 100000 do
DecodePixels3(155, Pixels);
QueryPerformanceCounter(TimeEnd);
Time3 := Time3 + ((TimeEnd - TimeStart) / Freq * 1000);
QueryPerformanceCounter(TimeStart);
for i := 1 to 100000 do
DecodePixels4a(155, Pixels);
QueryPerformanceCounter(TimeEnd);
Time4a := Time4a + ((TimeEnd - TimeStart) / Freq * 1000);
QueryPerformanceCounter(TimeStart);
for i := 1 to 100000 do
DecodePixels4b(155, Pixels);
QueryPerformanceCounter(TimeEnd);
Time4b := Time4b + ((TimeEnd - TimeStart) / Freq * 1000);
end;
Writeln('Time1 : ' + FloatToStr(Time1 / 100) + ' ms. <- Delphi loop.');
Writeln('Time2 : ' + FloatToStr(Time2 / 100) + ' ms. <- Delphi unrolled loop.');
Writeln('Time3 : ' + FloatToStr(Time3/ 100) + ' ms. <- BASM loop.');
Writeln('Time4a : ' + FloatToStr(Time4a / 100) + ' ms. <- BASM unrolled loop.');
Writeln('Time4b : ' + FloatToStr(Time4b / 100) + ' ms. <- BASM unrolled loop instruction switch.');
end;
Readln;
end.
これが私のマシン（Win32 XP上のIntel®Pentium®E2180）の結果です。
Time1 : 1,68443549919493 ms. <- Delphi loop.
Time2 : 1,33773024572211 ms. <- Delphi unrolled loop.
Time3 : 1,37015271374424 ms. <- BASM loop.
Time4a : 0,822916962526627 ms. <- BASM unrolled loop.
Time4b : 0,862914462301607 ms. <- BASM unrolled loop instruction switch.
結果はかなり安定しています。時間は、私が行った各テスト間で数パーセントしか変化しません。そしてそれは常に真実でした：Time1 > Time3 > Time 2 > Time4b > Time4a
したがって、Time4aとTime4bの違いは、メソッド内の命令の切り替えに依存すると思いますDecodePixels4b。4％の場合もあれば、最大10％の場合もありますが、4b常により遅くなり4aます。
一度に8バイトをメモリに書き込むMMX命令を使用する別の方法を考えていましたが、64ビットレジスタにバイトをアンパックする高速な方法がわかりません。
お時間をいただきありがとうございます。
貴重なご意見ありがとうございました。残念ながら、現代のCPUと比較すると、すべての人に同時に答えることができましたが、「パイプ」は1つしかなく、一度に「応答」する命令は1つしか実行できません;-)それで、いくつかのことをまとめてみますここに、あなたの答えの下に追加のコメントを書いてください。
まず、質問を投稿する前に、Wouter van Nifterickによって提示された解決策を思いついたのですが、実際にはアセンブリコードよりもはるかに低速でした。そのため、ここではそのルーチンを投稿しないことにしましたが、ループDelphiバージョンのルーチンでも同じアプローチを採用したことがわかります。それは私に悪い結果を与えていたので、そこにコメントされています。
これは私にとって謎です。WouterとPhilSのルーチンを使用してコードをもう一度実行しました。結果は次のとおりです。
Time1 : 1,66535493194387 ms. <- Delphi loop.
Time2 : 1,29115785420688 ms. <- Delphi unrolled loop.
Time3 : 1,33716934524107 ms. <- BASM loop.
Time4a : 0,795041753757838 ms. <- BASM unrolled loop.
Time4b : 0,843520166815013 ms. <- BASM unrolled loop instruction switch.
Time5 : 1,49457681191307 ms. <- Wouter van Nifterick, Delphi unrolled
Time6 : 0,400587402866258 ms. <- PhiS, table lookup Delphi
Time7 : 0,325472442519827 ms. <- PhiS, table lookup Delphi inline
Time8 : 0,37350491544239 ms. <- PhiS, table lookup BASM
Time5の結果を見てください、かなり奇妙ですね。生成されたアセンブリコードがWouterによって提供されたものと異なるため、Delphiのバージョンが異なると思います。
2番目の主要な編集：
なぜ5私のマシンでルーチンが遅くなったのか知っています。コンパイラオプションで「範囲チェック」と「オーバーフローチェック」をチェックしました。assemblerルーチンにディレクティブを追加9して、それが役立つかどうかを確認しました。このディレクティブアセンブリ手順では、Delphiインラインバリアントと同じか、それよりもわずかに優れているようです。
最終結果は次のとおりです。
Time1 : 1,22508325749317 ms. <- Delphi loop.
Time2 : 1,33004145373084 ms. <- Delphi unrolled loop.
Time3 : 1,1473583622526 ms. <- BASM loop.
Time4a : 0,77322594033463 ms. <- BASM unrolled loop.
Time4b : 0,846033593023372 ms. <- BASM unrolled loop instruction switch.
Time5 : 0,688689382044384 ms. <- Wouter van Nifterick, Delphi unrolled
Time6 : 0,503233741036693 ms. <- PhiS, table lookup Delphi
Time7 : 0,385254722925063 ms. <- PhiS, table lookup Delphi inline
Time8 : 0,432993919452751 ms. <- PhiS, table lookup BASM
Time9 : 0,362680491244212 ms. <- PhiS, table lookup BASM with assembler directive
3番目の主要な編集：
意見では、@ Pascal Cuoqと@j_random_hackerは、ルーチン間の実行時間の違いで4aあり4b、5データの依存関係が原因です。しかし、私が行ったさらなるテストに基づいて、私はその意見に反対しなければなりません。
4cまた、に基づいて新しいルーチンを発明しました4a。ここにあります：
procedure DecodePixels4c(EncPixels: Byte; var DecPixels: TDecodedPixels);
begin
asm
push ebx;
mov bl, al;
and bl, 1;
mov [edx], bl;
mov bl, al;
shr bl, 1;
and bl, 1;
mov [edx + $01], bl;
mov bl, al;
shr bl, 2;
and bl, 1;
mov [edx + $02], bl;
mov bl, al;
shr bl, 3;
and bl, 1;
mov [edx + $03], bl;
mov bl, al;
shr bl, 4;
and bl, 1;
mov [edx + $04], bl;
mov bl, al;
shr bl, 5;
and bl, 1;
mov [edx + $05], bl;
mov bl, al;
shr bl, 6;
and bl, 1;
mov [edx + $06], bl;
shr al, 7;
and al, 1;
mov [edx + $07], al;
pop ebx;
end;
end;
私はそれがかなりデータに依存していると言うでしょう。
そして、ここにテストと結果があります。事故がないことを確認するために4つのテストを行いました。また、GJによって提案されたルーチン（Time10a、Time10b）に新しい時間を追加しました。
Test1 Test2 Test3 Test4
Time1 : 1,211 1,210 1,220 1,213
Time2 : 1,280 1,258 1,253 1,332
Time3 : 1,129 1,138 1,130 1,160
Time4a : 0,690 0,682 0,617 0,635
Time4b : 0,707 0,698 0,706 0,659
Time4c : 0,679 0,685 0,626 0,625
Time5 : 0,715 0,682 0,686 0,679
Time6 : 0,490 0,485 0,522 0,514
Time7 : 0,323 0,333 0,336 0,318
Time8 : 0,407 0,403 0,373 0,354
Time9 : 0,352 0,378 0,355 0,355
Time10a : 1,823 1,812 1,807 1,813
Time10b : 1,113 1,120 1,115 1,118
Time10c : 0,652 0,630 0,653 0,633
Time10d : 0,156 0,155 0,172 0,160 <-- current winner!
、、、の結果が表示される場合がありますが、これら4aは互いに非常に近いものです。何故ですか？4aから削除したので、4b（4cにはまだありません）の2つの命令：と。コード内の他の場所ではeaxの下の値を使用しないことがわかっているので、事前に予約する必要はありません。これで、私のコードには、ルーチン5のようにプッシュ/ポップのペアが1つしかありません。ルーチン5は、最初にecxでコピーを作成するため、eaxの値を事前予約しますが、ecxを事前予約しません。4b4c5push eaxpop eax
したがって、私の結論は次のとおりです。5と4aと4bの実行時間の違い（3回目の編集前）はデータの依存関係には関係しませんでしたが、プッシュ/ポップ命令の追加のペアによって引き起こされました。
私はあなたのコメントに非常に興味があります。
数日後、GJはPhiSよりもさらに高速なルーチン（Time 10d）を発明しました。いい仕事GJ！