- 1 ：デフォルトの名無しさん：2005/10/27(木) 02:55:36
- C++やインラインアセンブラ、SSEなどによる高速化の手法
について語りましょう。 - 178 ：デフォルトの名無しさん：2009/01/07(水) 23:00:55
- メモリ（バキューン！）とかを考慮すると構造体より配列のほうが高速？
- 179 ：デフォルトの名無しさん：2009/01/08(木) 00:02:43
- >>178
同じ。 - 185 ：デフォルトの名無しさん：2009/01/09(金) 14:29:17
- >>179
うほ？
>>178の意味がいまいち分からんが、
char array[0x100];
と
struct{char value;} array[0x100];
だったらレジスタサイズにパディングされる分、構造体の方が早くね？
ちなみに、同じ事だが容量気にして構造体のなかでshortとか使うと
パデイング入るんでメモリに無駄が発生する。
まぁ、パディングを知っていれば無駄を防ぐこともできるけど。 - 189 ：デフォルトの名無しさん：2009/01/11(日) 01:50:19
- >>185
> struct{char value;} array[0x100];
> だったらレジスタサイズにパディングされる分、構造体の方が早くね？
pragmaやattributeでパックしない限りpaddingは入らないだろ。 - 191 ：,,・´∀｀・,,）っ-●◎○：2009/01/11(日) 06:05:36
- >>189
構造体やその配列の場合、パディングが入る。
デフォルトが4バイト単位だったかな？ - 360 ：デフォルトの名無しさん：2009/09/08(火) 20:07:19
- だんごじゃないけどi5はi5だよ。それ以上でもそれ以下でもない。
- 361 ：デフォルトの名無しさん：2009/09/08(火) 20:13:34
- >>360
おめーみたいなカスには聞いとらん失せろゴミが
ダンゴさんマダー？ - 363 ：デフォルトの名無しさん：2009/09/08(火) 21:25:40
- >>361
ちょｗだれｗｗ
ほれ、なんかcore2の時とかこれはいいぜーとかなんか詳しく言ってたような気がしたから
i7なりi5なりのアーキテクチャ面からの意見を聞いてみたかったんだ - 382 ：デフォルトの名無しさん：2009/09/10(木) 00:35:11
- おい！テーブル使わん言ったじゃねえかよ。氏ねカス。
- 387 ：デフォルトの名無しさん：2009/10/08(木) 03:33:43
- unsigned int mod6(unsigned int m){
unsigned int a = 0;
static unsigned int x[] = {0,2,4,0,2,4,0,2,4,0,2,4,0,2,4,0,2,4,0,2,4,0,2,4};
__asm{
mov eax, m
test eax, 1
jz Mod3
inc a
Mod3:
shr eax, 1
lea ebx, x
mov edx, eax
and eax, 0000ffffh
shr edx, 16
add eax, edx
mov edx, eax
and eax, 0000003fh
mov ecx, edx
and edx, 00000fffh
shr ecx, 12
shr edx, 6
add eax, ecx
add eax, edx
mov edx, eax
and eax, 0000000fh
shr edx, 4
add eax, edx
mov edx, x[eax*4]
add a, edx
}
return a;
} - 399 ：デフォルトの名無しさん：2009/10/08(木) 15:58:42
- 逆数乗算で商を求めて元の値から引いたほうが速い
今のCore MAでは整数乗算は浮動小数除算機と兼用してて
非除数 － (除数×小数点以下切り捨てた商)
まあベンチ取ってみればわかるがコンパイラの吐くコードにも勝てんと思う - 401 ：デフォルトの名無しさん：2009/10/08(木) 17:45:39
- static??const??int??rcp6??=??1.0??/??6.0??*??std::pow(2.0,16.0);
int??x??=??255??-??((255??*??rcp6)??>>??16)??*??6;
確かにこれで十分な気がするし、>>387より速そうだ。 - 414 ：デフォルトの名無しさん：2009/10/09(金) 01:24:41
- >>387
inline unsigned int mod6(unsigned int a){
unsinged int b = (a >> 3) + (a >> 5); // /6
unsinged int c = (b << 1) + (b << 2); // *6
return a - c;
} - 456 ：デフォルトの名無しさん：2009/10/22(木) 03:07:47
- C/C++でメモリプール(int, doubleなど様々な型が共存)を作り、
メモリプール内部でメモリの詰め直しを行って最適化しようと試みています。
入門書＋α（boostがわかるぐらい）なので、
キャッシュやメモリに関する特殊なことは全然わかりません。
何か気をつけなければならないことや忠告があれば教えてください。 - 488 ：,,・´∀｀・,,）っ-○○○：2009/10/28(水) 04:46:10
- for (i = 0; i < N; i+=4) {
sum1 += A[i];
sum2 += A[i+1];
sum3 += A[i+2];
sum4 += A[i+3];
}
sum = sum1 + sum2 + sum3 + sum4;
っていうか組み込み関数使えよ - 498 ：デフォルトの名無しさん：2009/10/29(木) 08:44:26
- >>488
これってNがわかっていないとコンパイラはやってくれないよね？
ICCだと出来るのかな？
GCCではベクトル化してくれなかった。 - 539 ：デフォルトの名無しさん：2011/01/28(金) 11:43:56
- x86は浮動小数点が弱くて仕方がないからなあ
8087のコプロセッサの頃からの負の遺産を引きずっている
でもL1/大容量L2キャッシュを媒介にする事によって相当克服して来てはいるんだけどな
PowerPCなどにどうしても勝てない - 596 ：デフォルトの名無しさん：2011/05/30(月) 10:20:14.97
- 結論から言うとメモリの転送がボトルネックです。
書き出しのアライメントを揃える事とstreamを使う事で何割かは改善出来ますが、基本的に速く出来ません。
最適化とは遅い部分を探し出す事に他なりません。
安直にSSEとかマルチプロセッサにしようと思わず、真にボトルネックを見つけられるようになりましょう。
真に遅い部分が分かったなら、平均化フィルタと何が違うのか、どうしてもう速く出来ないのかが理解出来るようになります。 - 598 ：デフォルトの名無しさん：2011/06/13(月) 15:11:06.75
- >>596
メモリの転送がボトルネックなのか、演算部分がボトルネックなのかは
どうやって判断すればいいのですか？つまりどこを見たらよいのか。
あるいはあなたはどうやってますか？
ツールとか使うのでしょうか？ - 618 ：デフォルトの名無しさん：2011/07/02(土) 22:44:49.03
- mapの方がアライメントされてないんじゃない？
- 619 ：デフォルトの名無しさん：2011/07/02(土) 23:38:54.68
- std::pair<int, hoge>からaligned_stl::pair<int, hoge>へのコードがバグってるんじゃないの
- 620 ：618：2011/07/03(日) 00:21:26.44
- 適当な事書いたと思ったけど、std::mapにカスタムアロケータでいけるっぽい
http://ideone.com/sOWl6 - 621 ：デフォルトの名無しさん：2011/07/03(日) 02:45:36.94
- >>618
mapの方は、__declspec(align(16))みたいなことはしてませんが
カスタムアロケータを渡しており、カスタムのpair(aligned_stl::pair)を使うように指定してます。
>>619
わかりづらくてすみませんorz
std::pairは一切使っておらず、aligned_stl::pairのみです。
make_pairもaligned_stl::pairを返します。
>>620
ありがとうございます、Win7 64bitのVC2008Expressで動かしてみましたが
カスタムアロケータのc.insertで、Hoge()の引数なしのコンストラクタで落ちます(x_ = static_x)
Hoge hoge;
c.insert( ::std::make_pair<int,Hoge>(i, hoge) );
とやると、make_pairのところのコピーコンストラクタで落ちます( x_ = src.x_)。
なので、前回書いたのと同様に
Hoge hoge;
std::pair<int, Hoge> pairArg(i, hoge);
とやってからpairArgを渡すと落ちませんでした(c.insertのみ。d.insertは落ちる)。
どうもpairに関してはアラインメント指定しなくても、中のメンバが
アラインメント指定されていれば問題ないようですね(アロケータだけでよい？)。
もうちょっと試してまた報告します。
ただ、2008だとアラインメント指定が一時オブジェクトに対して効かないと考えたほうが
いいのかもしれませんね（´・ω:;.:... （インライン展開された場合は除く）
ありがとうございました。 - 638 ：デフォルトの名無しさん：2011/07/05(火) 22:56:13.54
- 余分なカッコが多すぎるコードってみにくくて嫌いだ。
if (a == 0 && b == 0 || c == 0 && d == 0)
if ((((a == 0) && (b == 0)) || ((c == 0) && (d == 0))))
この二つだと上の方がはるかに見やすいと個人的には思うが、
見やすさを優先してカッコをつけるとか言って下のように書く人がいる。 - 649 ：デフォルトの名無しさん：2011/10/10(月) 19:26:30.72
- 指定桁数で四捨五入する以下の関数の実行速度を上げたいの。
(valueは0～9999、digitsは0～5が保証される)
SSE使って高速化頼む。
double NormalizeDouble(double value, int digits) {
static double t0[] = { 1, 10, 100, 1000, 10000, 100000 };
static double t1[] = { 1, 0.1, 0.01, 0.001, 0.0001, 0.00001 };
return (int)(value * t0[digits] + 0.5) * t1[digits];
} - 652 ：デフォルトの名無しさん：2011/10/10(月) 19:49:57.12
- >>649
最適化スレで終了宣言してからにしろよ - 653 ：デフォルトの名無しさん：2011/10/10(月) 19:50:50.26
- でもベクトル化で少しは早くなるわよ
- 664 ：デフォルトの名無しさん：2011/12/17(土) 22:41:12.80
- signed shortの配列に
floatもしくはdouble型の乗算をして
クリップ処理をほどこし
signed shortの配列に戻すのを
SSEにしたいのでやってください
これ
signed short s[100];
float f
init a;
for (a=0;a<100;a++)
s = s[a] * f; - 665 ：デフォルトの名無しさん：2011/12/17(土) 23:06:34.33
- それ、どう考えても実数型⇔整数型のコストがでかすぎる。
たった100件でいいなら実数で持てないの? - 679 ：デフォルトの名無しさん：2011/12/19(月) 02:15:44.43
- 初めてSSEに触れるので、まずは簡単なコードを作成してみたのですが、
SSEを使わないほうが40倍も速いという驚愕の結果が出ました。
何が間違っているんでしょうか？？
コンパイラ：VC++2005（Releaseモード、浮動小数点モデル：FAST）
float* f4pakAdd( float* pfA, float* pfB )
{
_declspec( align( 16 ) ) static float fC[ 4 ];
_asm
{
mov ebx, pfA
movaps xmm0, oword ptr [ebx]
mov ebx, pfB
movaps xmm1, oword ptr [ebx]
addps xmm0, xmm1
movaps fC, xmm0
}
return fC;
}
呼び出し側
for( int i = 0; i < 10000000; i++ )
{
pfC = f4pakAdd( fA, fB );
} - 682 ：デフォルトの名無しさん：2011/12/19(月) 02:34:54.14
- パイプライン化したコードでもないし、スタックチェックが行われている気がするが。
逆アセ確認したかい？ - 707 ：デフォルトの名無しさん：2011/12/23(金) 11:26:47.88
- どんな変数も問答無用でアライメント16にするようにコンパイルする設定があれば
面倒な記述を減らせると思うんですが、何かデメリットあるんでしょうか？
メモリの隙間ができて勿体無いとかあるかもしれませんが、メモリ量の多い昨今、
それほど問題にならないのでは？と思います。
むしろアライメントすることでメモリアクセスの冗長さを減らせて帯域を節約する効果も
あって一石二鳥ではと思うんです。 - 708 ：デフォルトの名無しさん：2011/12/23(金) 11:59:03.43
- gccだと-mpreferred-stack-boundary=4がデフォルトだから既に16バイトアライメントだよ
構造体の詰め物は互換性もあるし難しいじゃないか - 710 ：,, ・´ ∀ ｀・ ,,）っ-○○○：2011/12/23(金) 12:41:37.02
- >>707
なにそれ君いまだにPS3向けのゲームとか組まされてるわけ？ - 711 ：デフォルトの名無しさん：2011/12/23(金) 15:57:24.48
- >>708
glibcのmallocは8バイトだよ
>>710
SandyBridgeでもアラインメント取れてないと遅いでしょ - 713 ：デフォルトの名無しさん：2011/12/23(金) 17:19:17.60
- >>711
Nehalem以降はmovups/dquもペナルティ無く使えるでしょ
まあ結局Core2以前も考慮するとコード振り分けるから労力は変わらないのだけれど... - 714 ：707：2011/12/24(土) 02:12:26.59
- すみません、自分は日曜プログラマレベルで、対象CPUはx86、環境はVC++です。
VC++の設定を見ていると、「構造体メンバのアライメント」というのがあって16バイトアライメントを選べるようになってました。
同様に通常の変数もアライメントできる設定があるかと思い探しましたが見付かりませんでした。 - 715 ：デフォルトの名無しさん：2011/12/24(土) 02:18:17.32
- どう考えてもこれ以上削れないってくらいの手書きインラインアセンブリコードに対し、
C記述版をVC++のReleaseモード（最適化O2）でコンパイルしたもののほうが1.3倍速かったです。
生成されたアセンブリを覗いてみたところ、
変数 * 3
というコードを
lea edx, DWORD PTR [eax+eax*2]
としていてびっくりしました。
これって、アドレス演算を行うローダ（専用の演算器？）を使うことで、
通常のALUと並行して演算（スーパースカラって言うんでしたっけ？）し
高速化しているということなんでしょうか？？ - 716 ：デフォルトの名無しさん：2011/12/24(土) 02:34:46.72
- >>714
__declspec(align(N)) - 717 ：707：2011/12/24(土) 02:44:05.59
- >>716
ありがとうございます。
それは知っているんですが、>>707でも書いた通り、
そういった記述をわざわざせずとも、自動で全てアライメントしてくれるような設定があればイイのでは？
と思った次第です。
しかし、上でも仰られたように、互換性の問題があったりで難しいのでしょうね・・・
でも二重インクルード防止の「#pragma once」のように、互換性を考慮しない機能があったりするくらいですから、
自分のようにずっとVC++しか使わない人間を対象にそういうオプションが用意されていても良いのではと思いました。 - 733 ：デフォルトの名無しさん：2012/03/09(金) 12:53:25.77
- unsigned int maxpos(unsigned int src[256])
{
unsigned int i, m = 0;
for(i = 1; i < 256; i++)if(src[m] < src[i])m = i;
return m;
}
これをSSEで高速化する方法があれば教えて下さい - 739 ：デフォルトの名無しさん：2012/03/11(日) 00:41:15.69
- >>733
画像とか統計の基礎だな。疑似コードで書くとこんな感じだ
maxpos(src[256]) {
pos = {0, 1, 2, 3};
for(i=0; i<256; i+=4) {
s=load(&src[i]);
isGT=maxVal<s;
maxVal=isGT&s | ~isGT&maxVal;
maxPos=isGT&pos | ~isGT&maxPos;
pos += 4;
}
return max_position(
maxVal[0], maxPos[0],
maxVal[1], maxPos[1],
maxVal[2], maxPos[2],
maxVal[3], maxPos[3]);
} - 762 ：,, ・´ ∀ ｀・ ,,）っ-○○○：2012/03/14(水) 07:23:58.09
- packed unsigned intの比較（マスク生成）だけど、両項のMSBを反転してからpcmpgtdするより
psubd + psradのほうが速いかもしれない - 768 ：デフォルトの名無しさん：2012/03/21(水) 23:53:20.16
- P6,P2,P3,P4はforwardならnot taken backwardならtakenがデフォルト
P4はPrefixでヒントを出せる
PM,Core2はランダム
ソースはAgner - 775 ：デフォルトの名無しさん：2012/03/24(土) 21:41:50.71
- そう思ってくれるのはいいが、間違いの指摘と
実際はどうなってんのか答えてくれ
批難だけの回答はいらん。 - 778 ：デフォルトの名無しさん：2012/03/24(土) 21:52:06.49
- >>775
じゃあ間違いを指摘してやる。
>大概returnやthrowが行われるからifをすっ飛ばせば速いのは解る。
前方への条件分岐は、「分岐しない」と予測される、とオマエ以外の全員が言っている。
if (xx) return
で「すっ飛ばせば云々」なんて、理解していないまま「わかったつもりになってるだけ」の証拠。
>今のCPUは分岐ヒントとか投棄とかあって単純じゃないんだろ
ヒントはともかく、投機はまさに「投機実行するために分岐予測をする」のであって
「投機実行もあるから分岐予測が複雑になる」はナンセンス。
もちろん、エンプラ系/VLIW系では「分岐の有無の両経路を実行する」なんてのもある(らしい)が
一般的とは言いがたい。 - 779 ：デフォルトの名無しさん：2012/03/24(土) 21:59:34.64
- >>778
内容じゃなく国語的に誤解されてるな。
>前方への条件分岐は、「分岐しない」と予測される、とオマエ以外の全員が言っている。
if( xx ) throw xxx;
throwなんて実行するケース殆ど無いんだから基本if実行しないってのは同じ話。
矛盾してないでしょ。
まず分岐予測が複雑になってるって話はしてないよ。
投棄実行については投棄実行を考慮した上での静的予測方法があるでしょという話。 - 780 ：デフォルトの名無しさん：2012/03/24(土) 22:04:11.41
- >>779
だから、ifの内部は「実行すると予測される」んだよ、バーカ - 782 ：デフォルトの名無しさん：2012/03/24(土) 22:06:41.25
- せめて正しい漢字使えよ。
一度なら単なる変換ミスとして納得できるけど
繰り返しているってことは、別の意味に捉えているとしか思えない。 - 783 ：デフォルトの名無しさん：2012/03/24(土) 22:09:32.88
- >>780
お前バカだろ
みんなアセンブリ前提で言ってんだよ
jze label if() {
・・・処理・・・
labeli } - 789 ：デフォルトの名無しさん：2012/03/24(土) 22:48:33.55
- 投棄実行については誤解してたわ。
2つの分岐を両方実行して実際実行対象にならなかった方の結果を破棄するものだと思ってた。 - 792 ：デフォルトの名無しさん：2012/03/24(土) 23:01:04.27
- 一応。
突然returnやthrowが出てくるのが
if (xx) return
という意味じゃないか、というのも勝手に俺が頭の中で補って想像しただけで
実際には何の説明も無く(ifの多くがreturnやthrowというのにも同意しにくい)
唐突な「rerturnやthrow」「すっ飛ばす」を必死に理解しようとしたのがそもそもの間違いかもね。 - 794 ：デフォルトの名無しさん：2012/03/24(土) 23:04:39.09
- >>792
>>779で補足だしてるだろしつこいわ - 803 ：デフォルトの名無しさん：2012/03/25(日) 16:12:43.94
- インテルの最適化マニュアルだと
＞インテルPentiumM??プロセッサー、インテルCoreSolo??プロセッサー、インテルCoreDuoプロセッサーは、
＞ジャンプの向きに従った条件分岐を静的には予測しない。これらのプロセッサーでは、
＞すべての条件分岐は、最初に発生したときでも動的に予測される。
と書いてあって、wikiで調べたらPenM以降は広域分岐予測を取り入れた関係で静的予測はしなくなったみたいだね
http://ja.wikipedia.org/wiki/%E5%88%86%E5%B2%90%E4%BA%88%E6%B8%AC
>>768の
＞PM,Core2はランダム
というよりも、「前に実行した別の分岐命令の結果も影響する」とした方が適切みたいだ
分岐予測に関して
http://news.mynavi.jp/column/architecture/index.html
の第167回からの解説が参考になるよ
http://toro.2ch.net/test/read.cgi/tech/1130349336/l50/../人気ブログランキングへ
