【C++】高速化手法【SSE】2 [転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
C++やインラインアセンブラ、SSEなどによる高速化の手法
について語りましょう。
前スレ
【C++】高速化手法【SSE】
http://peace.2ch.net/test/read.cgi/tech/1130349336/ >>249
一時は自動プリフェッチの性能が向上してあまりprefetchの意味がない状態が続いていたけど、
AVX512ともなると1ページ分のデータをループ64回で消費しちゃうんだよな…
DRAMのCASレイテンシをCPUクロックで換算すると結構長いからね。 え?AVX512は手書きprefetchのほうが性能出る?
これまではハードウェアプリフェッチが超優秀で、手書きprefetchはむしろオーバーヘッドになって遅くなる感じだったんだけど。 prefetchはハードウェアにまかせて手書きでclflush入れるのが一番いい感じなんだけど。こんなケースは少数派なのかな。 xeonでavx命令使うと過熱防止のため1ms間、動作クロック下げるなんて聞いてないよ〜(>∀<) ☆ 日本の、改憲を行いましょう。現在、衆議員と参議院の
両院で、改憲議員が3分の2を超えております。
『憲法改正国民投票法』、でググってみてください。国会の発議は
すでに可能です。平和は勝ち取るものです。お願い致します。☆☆ 僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
YF4RO 過熱してなくても1ms間、強制的にクロック下げるん? >>257、そうみたいなんですよ
https://pc.watch.impress.co.jp/img/pcw/docs/665/641/html/14.png.html
> AVX命令が実行されるときに、CPUはAVXベースで定義されている
> クロック周波数に一時的に下がって実行し、実行終了後元のベースクロックに戻る
> AVX命令の実行完了後1ms程度で通常(非AVX)動作モードに復帰 AVXが有効な処理なら微妙にクロックが落ちようがどうでもいい クロックが高いのが目的じゃなくて
処理が速いのが目的
その辺がよくわかってないアホがいるみたい Programmable Calculation Unit (嘘) XEON、AVX-512だとさらにクロック下がるぞ
コア数多いとさらにクロック低下するでw
Platinum 8180M 28C 2.5GHz -> 2.1GHz(AVX2) -> 1.7GHz(AVX-512)
Platinum 8153 16C 2.0GHz -> 1.6GHz(AVX2) -> 1.2GHz(AVX-512) そもそも4倍の量が同時に計算できるわけだから
クロックが半分になっても元は取れる クロックが実際は半分にならないから
メリットは高速化 これsum1()とsum2()でだいぶスピード違うんだが、みんな知ってた?
#include<vector>
#include<iostream>
using namespace std;
class Tree{
public:
long long i;
vector<Tree> v;
Tree(){i=0;}
long long sum1(){
long long x=i;
for(vector<Tree>::iterator p=v.begin();p!=v.end();++p)x+=p->sum1();
return x;}
long long sum2(){
long long x=i;
for(auto p:v)x+=p.sum2();
return x;}
};
void big_tree(Tree *t,int d){
t->i=d;
if(d<=0)return;
t->v.push_back(Tree());
t->v.push_back(Tree());
big_tree(&(t->v[0]),d-1);
big_tree(&(t->v[1]),d-1);}
int main(){
Tree t;
big_tree(&t,20);
cout<<t.sum1()<<endl;
cout<<t.sum2()<<endl;
} そりゃ、やってることが違うんだから
同じにしたけりゃ sum2 で for (auto& p: v) にしてみ うお、autoってこんな書き方も出来るのかよw
勉強になりました。 結果は同じだろ? 鬼のように発生するコピーのためにメモリ不足で死なない限りは。 C++は、書いた通りに実行されるだけ。
高速な処理が必要なら、そう実行されるように実装しないと。 まるでC++コンパイラは最適化しないとかデタラメな言い分けだな。 何のためにコピーしてるん? 使い方間違ってんじゃね? reserveせずのpush_backしまくるバカのことじゃね? push_backしまくってもそれほどパフォーマンスは悪化しないように出来てるはずだが
コピーしまくりっていうんだから関数で値渡ししてるとかじゃないか?
いずれにしろC++自体の問題ではない データの並び順やアルゴリズム、...
この辺がパフォーマンスに大きな影響を与える
コンパイラの最適化なんぞ知れてる
その辺を最適化したければガシガシアセンブラだが
その前にいくらでもやることがあるのが普通 メインメモリが相対的に遅くなってきてるので
データの並びは非常に重要
大きなデータはディスクアクセスのような感覚で扱わないとダメ 突っ込みどころもあるが1年前のレスに真面目に返答してるおまえを評価する。 x おまえ
o おまえら
って書こうとしたが
同じ人だった orz 組み込み関数でSIMD命令駆使すれば、しっかり高速化されてキモティー! >>292
アセンブラを使わなくても速度チューニングネタはたくさんあるが
当然最後の手段としてはアセンブラは有効
小さいループに処理が集中してるような処理は
特に効果的
下手くそがアセンブラに手を出すと逆に遅くなったりもするけど >>292
急にどうしたw
レジスタ割り当て面倒くさいから、Intrinsics使うの普通だぞ >>295
>>286が
>コンパイラの最適化なんぞ知れてる
>その辺を最適化したければガシガシアセンブラだが
とか書いてたから
この人10年くらい時間が止まってるよね
64bitと32bitじゃレジスタの数も違うし、SIMDの新命令に対応させるたびに
レジスタ割り付けが全く変わってしまうこともあるのにアセンブラって…
AVXなら3オペランドも使えるから、コンパイラに任せてもコードの質は低下しにくくなってるはず 費用対効果を考えればIntrinsicsでも良いけど
究極の最適化はアセンブラしか無い
IACAを使ったり実測したりしながらパズルする
処理が非常に単純で速度の求められる小規模DSPなんかでも
いまだにそういう開発をする >>297
IACA=Intel Architecture Code Analyzer
ですよね。 SIMDを覚えたての初心者はこんなコードを書きやすい
典型的な糞コード
ループ {
sum = _mm_add_ps(sum, data[i]);
}
>>299
そうです >>298
CPU, GPU, FPGA
それぞれ得意分野が違うから GPUユニットはCPUに乗っけたのだから後はFPGAも乗っけるだけ。
アルテラは既に買収済みだしな。 スパコン分野じゃ固定の計算式はFPGAが一番効率的。そういう意味で地球シミュレータや京はゴミ。
スパコンが必要な分野でCPUのような汎用性などいらない。 今度はスパコンが出て来たか
関わったこともないだろうに
スーパーコンピューターこそ汎用性が必要
ベクトルコンピューターが消えたのも
より汎用性を重視するから
スーパーコンピューターの世界でFPGAが求められてるなら
当然スーパーFPGAが流行ってないと辻褄が合わないわけだけど
流行ってないね 何を言ってるからよく分からないなぁ。
特定の式を大量に速く計算したいという要望に対してなんで汎用性が出てくるの?
汎用性スパコンが1億なら同じ性能で1000万で達成できるんだよ。
しかも汎用性のために可用性が落ちるとか話にならないよ。京見れば分かるでしょ。 FPGAとかスーパーコンピューターとか自分専用とか
具体的な処理を何も語ってないのによくもまあ勝手に前提を作るよなあ
ここはソフトの最適化のスレなんだけど FPGAなんかで妥協しないでASICでも作れば良いよ FPGAだってプログラムでコーディングするんだが・・・。勝手な前提作ってるのはおまえじゃん。
というかSSEでの高速化がOKなら、GPGPU、FPGAもOKだろう。 1年もレスが無かった過疎スレになんでこんな必死な自治厨がいるのだろうw
前スレも10年かけて1スレ消費したんだぞw
おまえは何者だw ID:EqcpRCSG = >>311 = >>313 か?
こんな過疎スレで布教ってw マジおまえここの住人じゃないんだな。 >>312
前に64bitで絶対アドレス使えって書いて突っ込み受けたらファビョってたのいたでしょ
あれと同一人物っぽいんだよなあ
>究極の最適化はアセンブラしか無い
とか書くところとか
午後のこ〜だの開発者たちが動画コーデックの開発しなかったのだって、
MMXは除外しても、SSE2、SSE3、SSSE3、SSE4、SSE4.1、AVX、AVX2、AVX512に加えて、
64bitでは一気に種類が2倍と、次々と登場する新命令ごとに最速のルーチン用意していく手間と、
コードが異なるために特定のCPUでしか発現しないバグがでるリスクが増すこと考えたら、
最速に拘るのが現実的ではなくなったんだよ
彼らとしては妥協したコード書く気はなかっただろうし、興味が失せるのも仕方ないのかもね
AVISynthもインラインアセンブラ使ったプラグインだらけで64bit化に対応できずに放置されてたのが
相当あったけど、自分も64bit化やった経験からも、今更初心者にアセンブラ使えなんて教えんなと言いたい 初心者ならIntrinsicsなんか使わないで素直に汎用性のあるC++で書くかライブラリを使えばいいよ
ここは高速化手法スレだから高速なコードであることは重要
Intrinsicsよりアセンブラの方が高速に書けるのは自明なのでアセンブラの話題は当然出てくる Intrinsicsで32bit/64bitの共通化は出来ても
新命令がでたらどうせ作り直しだよ
新命令に最適化しないならそのままでいいよ
「新命令対応」て謳うのが目的じゃなければ
SSEからAVXの移植もレーン縛りで苦労しただろ?
単純に置き換えなんて出来ない
128bitのまま単に3オペとレジスタ数だけなら簡単だけど
AVX512も同じ
マスクレジスタや新命令を使うなら書き直し アセンブラ狂信者じゃない
Intrinsicsも使う
極限な最適化にはアセンブラが必要ってだけ
まあ当然だ どうせ今後は32bit向けの最適化なんかやらんだろ
だとすると手間の差はレジスタ管理くらい >>320
>だとすると手間の差はレジスタ管理くらい
こんなこと書くようだと大したコードは書けないな
レジスタ割り付けの妙味と面倒さを知らないのなら、別に組み込み関数で書いても構わないだろ >>321
レジスタ割り付けの妙味www
さほど時間をかけなくてもコンパイラよりマシなのは作れるよ
そもそもIntrinsicsの時点でもレジスタ数削減は考えるべきであって
何も考えなきゃIntrinsicsだろうがアセンブラだろうが遅い 詳しい自信があるなら
とりあえず問題ありまくりな>>300の問題点でも語ってみようか SIMDの一番簡単とも思えるこんなコードでも
最適化に関して語れることは山ほどある >>322
やっぱこいつ絶対アドレス君だw
妙味の部分に草生やすってことは大したコード書いてない証拠みたいなもんだよ
コンパイラより1%速くなっただけでもドヤ顔するタイプだろ 絶対アドレス?
一番アクセスが速いのはスタック
ほぼ確実にL1キャッシュにある
一等地 アドレス含め、
デカい即値は色々と遅くなる要素だぞ 300 みたいなことはこのスレの本来の住民なら誰でも知ってるから
いちいち講釈垂れるのはスレの無駄遣いだからやらないだけ
FPGA だって互換性気にしなければオリジナルの CPU の IP 書けば済む話で
少なくともこの板でやる話ではない >>329
>>300にいろんな要素が詰まってるわけだけど
どの程度わかるかな? >>315
>MMXは除外しても、SSE2、SSE3、SSSE3、SSE4、SSE4.1、AVX、AVX2、AVX512に加えて、
>64bitでは一気に種類が2倍と、次々と登場する新命令ごとに最速のルーチン用意していく手間と、
知らなくてもいいことかもしれないけど、これはアセンブラ作者泣かせでもあったりする。
命令数が多すぎるので手作業での入力は例えテーブル方式を採用していても無理が有り、
インストラクションセットの表を自動的にテーブルに変換するようなプログラムをしなくては
ならなくなってきている。 >>300は非常に良い教材だよ
これだけで語れることは山ほどある
「誰でも知ってる」なんて言う人は
ほとんど何も知らない初心者だけ
>>332
全てのCPUに対して最適化したコードを書く人なんていないだろ
せいぜい128bit, 256bit, 512bit の3バージョンくらい
32bit 512bit なんていらんだろうし
マーケティング上の理由で作らされてる人がいるのか?
それなら御愁傷様
本当に最適化するなら対応命令だけじゃダメ
IceLakeはAVX512が遅いし
AMDも昔はAVXがとても遅い >>333
アセンブラ=アセンブリ言語を処理してマシン語に変換するコンパイラ
の話。 前半からアセンブリ言語での記述の話だと思ってしまった
命令数めちゃくちゃ多いよね
多いだけじゃなくて複雑にもなってる
{k1} とか {z} とか
まあそれでも(高級言語の)コンパイラを作るよりははるかに楽だろうけど >>326
前にアセンブラスレでこんなこと書いてた変なのがいたんだよ
>実際には問題がある。なぜなら、そんなにアドレスが大きいと、さっきから話題の
>mov al, my_mojiretu[rbx]
>という命令が使えなくなるからだ。
とか、
>RIP相対32bitdispだとアクセスできない場合が出てくる
>シンボルがRIP相対2GBに制限されるなどはあくまでCコンパイラの制限であって
>アセンブラはその制限を受けない
ちょっと考えれば64bitなのに2GB制限するオプションとか使ってDLLも作れなくなるような
記法が推奨されてるはずないよな
それで複数の人から突っ込まれたら、誤りを認めて引っ込めばいいものを、
ファビョって連投しまくるから、皆呆れて無視したってことがあったんだよ
挙句にこんなことまで言い出したり
>自分は 64BIT 用C/C++コンパイラをインストールして無いので、試せません。
>>326だってこいつの言ってることはおかしいと思うだろ? >>336
その人は、64BIT命令にとても詳し過ぎてみんなが理解できなかったようだ。 >>338
Microsoftの人より頭いいんだw
でも連投してるときはあまり余裕無さそうだったよw >>339
MSの人より頭が言いなんて、当たり前じゃない。
日本人をなめてはいけない。 純粋に技術競争になったら、日本は絶対にアメリカに勝つ。
いつもそうだったし、IT分野でもそう。
問題はアメリカ人は自分が負けそうになると、圧力をかけて壊してくることだ。 >>341
そういう考え方情けないわ
お前がまず手本を示して見ろよ >>336
そこだけ抜き出しても何が言いたいのかわかりません
スレタイとは関係なく
ただ人をバカにするためだけの書き込みなら
感心しない >>342
そうそう
40〜50行程度の32bitSSEの自慢のコード片を晒せば大体の実力は判るんじゃないかな
でもね、自分が本気で最適化する時は、IACAの分析結果じゃいい加減すぎて役に立たないから
人力で計算してたんだよね
社外に秘密にしたいパイプラインの実装の詳細を気前よくツールに実装するはずないよね
だから、IACAを使って最適化してるのを自慢してる辺り、あまり期待はしてないけどね IACAの使い方間違ってないか?
自力で計算するための情報を手っ取り早く得る為の物だぞ >>342
IT関連は狡猾な人が多いので、アイデアだけ真似されるので完成するまでは
公開しない。 >>344
40〜50行程度になる題材があればコードを書くよ
今更32bit SSEってのも
時代についていってない感じでイマイチだけど
最適化はその時代のCPU向けでいいのかな? >>341
IT分野で日本が技術力で勝ってると思ってるの?
頭がお花畑で良いねえ ■ このスレッドは過去ログ倉庫に格納されています