X
【C++】高速化手法【SSE】2 [転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
0256デフォルトの名無しさん
垢版 |
2018/05/23(水) 20:32:42.01ID:Au5e7VGg
僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法　モニアレフヌノ』

YF4RO
0261デフォルトの名無しさん
垢版 |
2018/06/09(土) 12:21:09.00ID:6JxGr/md
クロックが高いのが目的じゃなくて
処理が速いのが目的

その辺がよくわかってないアホがいるみたい
0266デフォルトの名無しさん
垢版 |
2018/06/13(水) 06:44:44.44ID:sIzYe/Rc
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)
0268デフォルトの名無しさん
垢版 |
2018/07/04(水) 22:24:56.45ID:gFgZc5FG
HHG
0270デフォルトの名無しさん
垢版 |
2018/07/12(木) 17:41:30.02ID:JTIrQoQb
そもそも4倍の量が同時に計算できるわけだから
クロックが半分になっても元は取れる
0274デフォルトの名無しさん
垢版 |
2018/10/24(水) 21:06:49.85ID:mVtKb6jM
これ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;
}
0275デフォルトの名無しさん
垢版 |
2018/10/24(水) 22:27:31.88ID:2t/OeFdE
そりゃ、やってることが違うんだから
同じにしたけりゃ sum2 で for (auto& p: v) にしてみ
0277デフォルトの名無しさん
垢版 |
2018/10/25(木) 11:47:46.18ID:5Cy/pQlU
結果も違うんじゃね
ちゃんと中身観たか
0278デフォルトの名無しさん
垢版 |
2018/10/25(木) 17:06:36.77ID:+VSq1LXv
結果は同じだろ? 鬼のように発生するコピーのためにメモリ不足で死なない限りは。
0280デフォルトの名無しさん
垢版 |
2018/10/25(木) 19:41:56.48ID:u+frCiwH
C++は、書いた通りに実行されるだけ。
高速な処理が必要なら、そう実行されるように実装しないと。
0282デフォルトの名無しさん
垢版 |
2018/10/26(金) 16:39:17.96ID:8hqqerJ0
vectorとか激しくコピーしすぎ
0285デフォルトの名無しさん
垢版 |
2019/11/09(土) 12:43:46.37ID:nG1HKTzx
push_backしまくってもそれほどパフォーマンスは悪化しないように出来てるはずだが
コピーしまくりっていうんだから関数で値渡ししてるとかじゃないか？

いずれにしろC++自体の問題ではない
0286デフォルトの名無しさん
垢版 |
2019/11/09(土) 12:46:29.28ID:nG1HKTzx
データの並び順やアルゴリズム、...
この辺がパフォーマンスに大きな影響を与える

コンパイラの最適化なんぞ知れてる
その辺を最適化したければガシガシアセンブラだが
その前にいくらでもやることがあるのが普通
0287デフォルトの名無しさん
垢版 |
2019/11/09(土) 12:48:19.04ID:nG1HKTzx
メインメモリが相対的に遅くなってきてるので
データの並びは非常に重要
大きなデータはディスクアクセスのような感覚で扱わないとダメ
0289デフォルトの名無しさん
垢版 |
2019/11/09(土) 21:44:34.74ID:GgGliPcL
突っ込みどころもあるが1年前のレスに真面目に返答してるおまえを評価する。
0290デフォルトの名無しさん
垢版 |
2019/11/10(日) 12:14:45.63ID:7BQWwZ6D
x おまえ
o おまえら

って書こうとしたが
同じ人だった orz
0292デフォルトの名無しさん
垢版 |
2019/11/11(月) 20:31:51.81ID:mj2unNmc
プログラムを高速化する話
https://www.slideshare.net/KMC_JP/ss-45855264

コンパイラでベクトル化されやすいコードの書き方
https://jp.xlsoft.com/documents/intel/compiler/17/for_17_win_lin/GUID-D284C1EE-BFA4-4EA3-BB67-4A3E5D50199F.html

Intel Intrinsics Guide
https://software.intel.com/sites/landingpage/IntrinsicsGuide/

メモリアクセスが相対的に遅くなってるってことは、人間が組み込み関数使って最適化すれば
別にアセンブラなんて使わなくてもいいってこと
それに、64bitではインラインアセンブラも使えないコンパイラがあるし、関数呼び出しや例外処理の
書き方も変わってしまっているので移植性が低いよ
0294デフォルトの名無しさん
垢版 |
2019/11/12(火) 13:18:01.61ID:TlWEsNqa
>>292
アセンブラを使わなくても速度チューニングネタはたくさんあるが
当然最後の手段としてはアセンブラは有効

小さいループに処理が集中してるような処理は
特に効果的

下手くそがアセンブラに手を出すと逆に遅くなったりもするけど
0296デフォルトの名無しさん
垢版 |
2019/11/13(水) 00:56:22.92ID:AZXdI1I6
>>295
>>286が
＞コンパイラの最適化なんぞ知れてる
＞その辺を最適化したければガシガシアセンブラだが
とか書いてたから
この人10年くらい時間が止まってるよね
64bitと32bitじゃレジスタの数も違うし、SIMDの新命令に対応させるたびに
レジスタ割り付けが全く変わってしまうこともあるのにアセンブラって…
AVXなら3オペランドも使えるから、コンパイラに任せてもコードの質は低下しにくくなってるはず
0297デフォルトの名無しさん
垢版 |
2019/11/13(水) 10:22:08.98ID:EqcpRCSG
費用対効果を考えればIntrinsicsでも良いけど

究極の最適化はアセンブラしか無い
IACAを使ったり実測したりしながらパズルする

処理が非常に単純で速度の求められる小規模DSPなんかでも
いまだにそういう開発をする
0300デフォルトの名無しさん
垢版 |
2019/11/13(水) 13:05:36.17ID:EqcpRCSG
SIMDを覚えたての初心者はこんなコードを書きやすい
典型的な糞コード

ループ {
sum = _mm_add_ps(sum, data[i]);
}

>>299
そうです
0302デフォルトの名無しさん
垢版 |
2019/11/13(水) 13:21:58.53ID:FP2h74Sh
GPUユニットはCPUに乗っけたのだから後はFPGAも乗っけるだけ。
アルテラは既に買収済みだしな。
0304デフォルトの名無しさん
垢版 |
2019/11/13(水) 16:48:11.25ID:FP2h74Sh
スパコン分野じゃ固定の計算式はFPGAが一番効率的。そういう意味で地球シミュレータや京はゴミ。
スパコンが必要な分野でCPUのような汎用性などいらない。
0305デフォルトの名無しさん
垢版 |
2019/11/13(水) 17:02:40.99ID:EqcpRCSG
今度はスパコンが出て来たか
関わったこともないだろうに

スーパーコンピューターこそ汎用性が必要
ベクトルコンピューターが消えたのも
より汎用性を重視するから

スーパーコンピューターの世界でFPGAが求められてるなら
当然スーパーFPGAが流行ってないと辻褄が合わないわけだけど
流行ってないね
0306デフォルトの名無しさん
垢版 |
2019/11/13(水) 17:18:55.90ID:FP2h74Sh
何を言ってるからよく分からないなぁ。
特定の式を大量に速く計算したいという要望に対してなんで汎用性が出てくるの？
汎用性スパコンが1億なら同じ性能で1000万で達成できるんだよ。
しかも汎用性のために可用性が落ちるとか話にならないよ。京見れば分かるでしょ。
0307デフォルトの名無しさん
垢版 |
2019/11/13(水) 17:37:57.46ID:OceCV+VL
自分専用ならTSSにする必要もないしな
0308デフォルトの名無しさん
垢版 |
2019/11/13(水) 18:11:35.42ID:nB9KorLn
FPGAとかスーパーコンピューターとか自分専用とか
具体的な処理を何も語ってないのによくもまあ勝手に前提を作るよなあ

ここはソフトの最適化のスレなんだけど
0310デフォルトの名無しさん
垢版 |
2019/11/13(水) 18:26:47.86ID:FP2h74Sh
FPGAだってプログラムでコーディングするんだが・・・。勝手な前提作ってるのはおまえじゃん。
というかSSEでの高速化がOKなら、GPGPU、FPGAもOKだろう。
0312デフォルトの名無しさん
垢版 |
2019/11/13(水) 19:23:44.45ID:FP2h74Sh
1年もレスが無かった過疎スレになんでこんな必死な自治厨がいるのだろうw
前スレも10年かけて1スレ消費したんだぞw

おまえは何者だw
0315デフォルトの名無しさん
垢版 |
2019/11/13(水) 19:51:20.51ID:AZXdI1I6
>>312
前に64bitで絶対アドレス使えって書いて突っ込み受けたらファビョってたのいたでしょ
あれと同一人物っぽいんだよなあ
＞究極の最適化はアセンブラしか無い
とか書くところとか

午後のこ〜だの開発者たちが動画コーデックの開発しなかったのだって、
MMXは除外しても、SSE2、SSE3、SSSE3、SSE4、SSE4.1、AVX、AVX2、AVX512に加えて、
64bitでは一気に種類が2倍と、次々と登場する新命令ごとに最速のルーチン用意していく手間と、
コードが異なるために特定のCPUでしか発現しないバグがでるリスクが増すこと考えたら、
最速に拘るのが現実的ではなくなったんだよ
彼らとしては妥協したコード書く気はなかっただろうし、興味が失せるのも仕方ないのかもね

AVISynthもインラインアセンブラ使ったプラグインだらけで64bit化に対応できずに放置されてたのが
相当あったけど、自分も64bit化やった経験からも、今更初心者にアセンブラ使えなんて教えんなと言いたい
0316デフォルトの名無しさん
垢版 |
2019/11/13(水) 20:53:55.20ID:Fqkv69gY
初心者ならIntrinsicsなんか使わないで素直に汎用性のあるC++で書くかライブラリを使えばいいよ

ここは高速化手法スレだから高速なコードであることは重要
Intrinsicsよりアセンブラの方が高速に書けるのは自明なのでアセンブラの話題は当然出てくる
0318デフォルトの名無しさん
垢版 |
2019/11/13(水) 21:12:18.74ID:Fqkv69gY
Intrinsicsで32bit/64bitの共通化は出来ても
新命令がでたらどうせ作り直しだよ

新命令に最適化しないならそのままでいいよ
｢新命令対応｣て謳うのが目的じゃなければ

SSEからAVXの移植もレーン縛りで苦労しただろ？
単純に置き換えなんて出来ない
128bitのまま単に3オペとレジスタ数だけなら簡単だけど

AVX512も同じ
マスクレジスタや新命令を使うなら書き直し
0319デフォルトの名無しさん
垢版 |
2019/11/13(水) 21:13:39.13ID:Fqkv69gY
アセンブラ狂信者じゃない
Intrinsicsも使う

極限な最適化にはアセンブラが必要ってだけ
まあ当然だ
0320デフォルトの名無しさん
垢版 |
2019/11/13(水) 21:19:04.07ID:Fqkv69gY
どうせ今後は32bit向けの最適化なんかやらんだろ
だとすると手間の差はレジスタ管理くらい
0321デフォルトの名無しさん
垢版 |
2019/11/13(水) 21:42:54.67ID:AZXdI1I6
>>320
＞だとすると手間の差はレジスタ管理くらい
こんなこと書くようだと大したコードは書けないな
レジスタ割り付けの妙味と面倒さを知らないのなら、別に組み込み関数で書いても構わないだろ
0322デフォルトの名無しさん
垢版 |
2019/11/13(水) 22:04:42.12ID:RzCRvdkP
>>321
レジスタ割り付けの妙味www
さほど時間をかけなくてもコンパイラよりマシなのは作れるよ
そもそもIntrinsicsの時点でもレジスタ数削減は考えるべきであって
何も考えなきゃIntrinsicsだろうがアセンブラだろうが遅い
0324デフォルトの名無しさん
垢版 |
2019/11/13(水) 22:09:21.49ID:RzCRvdkP
SIMDの一番簡単とも思えるこんなコードでも
最適化に関して語れることは山ほどある
0325デフォルトの名無しさん
垢版 |
2019/11/13(水) 22:22:02.11ID:AZXdI1I6
>>322
やっぱこいつ絶対アドレス君だｗ
妙味の部分に草生やすってことは大したコード書いてない証拠みたいなもんだよ
コンパイラより1%速くなっただけでもドヤ顔するタイプだろ
0326デフォルトの名無しさん
垢版 |
2019/11/13(水) 22:38:51.61ID:RzCRvdkP
絶対アドレス？

一番アクセスが速いのはスタック
ほぼ確実にL1キャッシュにある
一等地
0329デフォルトの名無しさん
垢版 |
2019/11/14(木) 12:00:59.24ID:Owl20mAs
300 みたいなことはこのスレの本来の住民なら誰でも知ってるから
いちいち講釈垂れるのはスレの無駄遣いだからやらないだけ

FPGA だって互換性気にしなければオリジナルの CPU の IP 書けば済む話で
少なくともこの板でやる話ではない
0332デフォルトの名無しさん
垢版 |
2019/11/14(木) 16:17:09.42ID:23v5U+5B
>>315
>MMXは除外しても、SSE2、SSE3、SSSE3、SSE4、SSE4.1、AVX、AVX2、AVX512に加えて、
>64bitでは一気に種類が2倍と、次々と登場する新命令ごとに最速のルーチン用意していく手間と、

知らなくてもいいことかもしれないけど、これはアセンブラ作者泣かせでもあったりする。
命令数が多すぎるので手作業での入力は例えテーブル方式を採用していても無理が有り、
インストラクションセットの表を自動的にテーブルに変換するようなプログラムをしなくては
ならなくなってきている。
0333デフォルトの名無しさん
垢版 |
2019/11/14(木) 18:28:43.14ID:wXs4N2j2
>>300は非常に良い教材だよ
これだけで語れることは山ほどある
｢誰でも知ってる｣なんて言う人は
ほとんど何も知らない初心者だけ

>>332
全てのCPUに対して最適化したコードを書く人なんていないだろ
せいぜい128bit, 256bit, 512bit の3バージョンくらい
32bit 512bit なんていらんだろうし
マーケティング上の理由で作らされてる人がいるのか？
それなら御愁傷様

本当に最適化するなら対応命令だけじゃダメ
IceLakeはAVX512が遅いし
AMDも昔はAVXがとても遅い
0335デフォルトの名無しさん
垢版 |
2019/11/14(木) 19:18:18.01ID:wXs4N2j2
前半からアセンブリ言語での記述の話だと思ってしまった

命令数めちゃくちゃ多いよね
多いだけじゃなくて複雑にもなってる
{k1} とか {z} とか

まあそれでも(高級言語の)コンパイラを作るよりははるかに楽だろうけど
0336デフォルトの名無しさん
垢版 |
2019/11/14(木) 20:19:51.75ID:86Xe+wXL
>>326
前にアセンブラスレでこんなこと書いてた変なのがいたんだよ
＞実際には問題がある。なぜなら、そんなにアドレスが大きいと、さっきから話題の
＞mov　　　al, my_mojiretu[rbx]
＞という命令が使えなくなるからだ。
とか、
＞RIP相対32bitdispだとアクセスできない場合が出てくる
＞シンボルがRIP相対2GBに制限されるなどはあくまでCコンパイラの制限であって
＞アセンブラはその制限を受けない

ちょっと考えれば64bitなのに2GB制限するオプションとか使ってDLLも作れなくなるような
記法が推奨されてるはずないよな
それで複数の人から突っ込まれたら、誤りを認めて引っ込めばいいものを、
ファビョって連投しまくるから、皆呆れて無視したってことがあったんだよ

挙句にこんなことまで言い出したり
＞自分は 64BIT 用C/C++コンパイラをインストールして無いので、試せません。
>>326だってこいつの言ってることはおかしいと思うだろ？
0340デフォルトの名無しさん
垢版 |
2019/11/14(木) 23:52:36.80ID:uioYVx5f
>>339
MSの人より頭が言いなんて、当たり前じゃない。
日本人をなめてはいけない。
0341デフォルトの名無しさん
垢版 |
2019/11/14(木) 23:54:38.25ID:uioYVx5f
純粋に技術競争になったら、日本は絶対にアメリカに勝つ。
いつもそうだったし、IT分野でもそう。
問題はアメリカ人は自分が負けそうになると、圧力をかけて壊してくることだ。
0343デフォルトの名無しさん
垢版 |
2019/11/15(金) 06:20:01.64ID:/dDy1LQy
>>336
そこだけ抜き出しても何が言いたいのかわかりません

スレタイとは関係なく
ただ人をバカにするためだけの書き込みなら
感心しない
0344デフォルトの名無しさん
垢版 |
2019/11/15(金) 07:39:37.60ID:6uJ1WeVS
>>342
そうそう
40〜50行程度の32bitSSEの自慢のコード片を晒せば大体の実力は判るんじゃないかな

でもね、自分が本気で最適化する時は、IACAの分析結果じゃいい加減すぎて役に立たないから
人力で計算してたんだよね
社外に秘密にしたいパイプラインの実装の詳細を気前よくツールに実装するはずないよね
だから、IACAを使って最適化してるのを自慢してる辺り、あまり期待はしてないけどね
0346デフォルトの名無しさん
垢版 |
2019/11/15(金) 08:13:55.97ID:pd2oXw5y
IACAの使い方間違ってないか？
自力で計算するための情報を手っ取り早く得る為の物だぞ
0348デフォルトの名無しさん
垢版 |
2019/11/15(金) 08:41:09.49ID:pd2oXw5y
>>344
40〜50行程度になる題材があればコードを書くよ

今更32bit SSEってのも
時代についていってない感じでイマイチだけど
最適化はその時代のCPU向けでいいのかな？
0351デフォルトの名無しさん
垢版 |
2019/11/15(金) 08:47:47.96ID:/yBuhf/V
量子コンピューターに日本人の名前がクレジットされる可能性は高い。
一方、○○互換のソフトウェアはほぼ100%が中国発。
一見欧州製のように見えてもほぼほぼ中国。
人工知能に中国人の名前がクレジットされる可能性は相当高い。
0353デフォルトの名無しさん
垢版 |
2019/11/15(金) 08:51:56.44ID:/yBuhf/V
おそらく世界最初の人工知能は春麗とかいう名前になる。
0354デフォルトの名無しさん
垢版 |
2019/11/15(金) 08:52:04.36ID:LE7NfU10
>>352
日本の平均レベルが低いからといって、このスレに来ている人全員のレベルが
低いことにはならないということだよ。
0355デフォルトの名無しさん
垢版 |
2019/11/15(金) 08:53:57.40ID:pd2oXw5y
日本とアメリカの技術力の比較の話から
なんで個人の能力に話をすり替える？
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況