TOP カテ一覧 スレ一覧 100〜終まで 2ch元 削除依頼
【GPGPU】くだすれCUDAスレ part8【NVIDIA】
くだすれPython(超初心者用) その38
音声合成プログラムを作りる
2進数や16進数を覚える意味がわからない
【会津】パソコン甲子園2004【若松】
Rubyについて（アンチ専用） Part005
【えっ】Perlに未来はあるのか？【終わり？】
●●●●TCL/TKなら俺に聞け 4●●●●
【PHP】下らねぇ質問はここに書き込みやがれ 2
+ JavaScript の質問用スレッド vol.125 +
【C++】高速化手法【SSE】2
- 1 ：2015/05/21 〜 最終レス ：2020/03/25
- C++やインラインアセンブラ、SSEなどによる高速化の手法
について語りましょう。
前スレ
【C++】高速化手法【SSE】
http://peace.2ch.sc/test/read.cgi/tech/1130349336/
- 2 ：
- >>1乙。
10年の時を経て2スレ目に突入、おめでとう。
- 3 ：
- 1スレ10年も掛かったのかwww
compiler intrinsicsの普及と、x64ではインラインアセンブラが使えなくなったのが
またSIMDの再普及に繋がる気がする
SSE3、SSE4、AVX、AVX2、FMAと言った新しい命令も増えているのも理由の一つか
- 4 ：
- それとこれテンプレに入れるか
次スレ今度いつになるか分からないしなｗｗ
http://www.officedaytime.com/tips/simd.html
- 5 ：
- あと面白そうなところはここか
https://github.com/herumi/x86opti
- 6 ：
- 10年ｗｗｗｗ
- 7 ：
- マルチコアによるマルチスレッド化の方がずっと楽だから、難しいSIMDプログラミングはいまいち
はやらないのかな
- 8 ：
- SIMDは作るのは難しいが、一度作ってしまうと、関数の中に封じ込めることが出来るので、
後からの使い勝手自体はマルチスレッドよりも良いんだがな。ライブラリ化もただの関数なので問題ない。
マルチスレッドだと関数の中だけで閉じなくて、アプリ全体の設計の部分まで話が広がるので、
機能単位でライブラリ化するのが難しく、簡単に使いまわせない。
ま、SIMDはライブラリ化しやすいから、多くのものが既にライブラリ化されてて、
ほとんどの人はそれを使うだけですむので、自分で書く必要性が少なくて、
故に過疎りやすいってのもあると思うがね。
- 9 ：
- SIMD化はコンパイラに任せるのが得策。
アルゴリズム改善がどこもできなくなってからでいい。
- 10 ：
- 前スレの8bit単位の乗算とか、そういう頻繁にありそうなケースに対応した命令を用意してくれないと、
間口広がんないよ･･･。
- 11 ：
- 8/16bitぐらいのIndex範囲でテーブル引きしれくれる命令がほしいわ
8bit演算するにも無駄なシャッフルしなくても良い命令がそろったのがSSE4辺りで
さらにAMDが未対応みたいな期間長すぎたな
- 12 ：
- 命令に対応してたってそれを実行するユニットがそれ相応に強化されてなければ大して効果ないよ
- 13 ：
- 並列計算が実装されてないか、使っても遅いとき、通常の演算で並列できないか?
(a0 + a1X + a2X^2 + a3X^3) ( s + tX) のXの1乗、3乗を取り出すことで、
- 14 ：
- 途中送信した。
上のXの項は、t a0 + s a1
上のX^3の項は、t a2 + s a3
Xをたとえば2^10や2^16と取り、下位からの桁上りがないとすると、ビット演算でデータ取り出せる。
- 15 ：
- >>13>>14を実装して並列計算の叩き台を作った。微妙に速度アップした。結果が正しくないが計算量は正しいはず。
#include <iostream>
#include <time.h>
using namespace std;
#define N (1<<18)
void initdata(unsigned char *a, int range){ for(int n=0; n<2*range; n+=2) { a[n]=rand()%256; a[n+1]=rand()%256; }}
#define cal(x,y,s) {x=(x*s + y*(255-s))&255; y=(y*s + x*(255-s))&255;}
void test(unsigned char *a) {
for(int n=0; n<2*N; n+=2) {
unsigned char x=a[n], y=a[n+1];
for(int s=1; s<255; s++) cal(x,y,s); for(int s=1; s<255; s++) cal(x,y,s); for(int s=1; s<255; s++) cal(x,y,s); for(int s=1; s<255; s++) cal(x,y,s);
a[n]=x; a[n+1]=y; }}
// (a0 + a1X + a2X^2 + a3X^3) ( 255-s + sX) Xの項は、s*a0 + (255-s)*a1 X^3の項は、s*a2 + (255-s)*a3
#define dset(x,y) (x) + ((y)<<8) + ((y)<<16) + ((x)<<24);
#define cal2(x,s) { x *= ( s + ((255-s)<<8) ); unsigned char c=(x>>8)&255, d=(x>>24)&255; x = dset(c,d); }
void test2(unsigned char *a) {
for(int n=0; n<2*N; n+=2) {
unsigned int x = dset(a[n], a[n+1]);
for(int s=1; s<255; s++) cal2(x,s); for(int s=1; s<255; s++) cal2(x,s); for(int s=1; s<255; s++) cal2(x,s); for(int s=1; s<255; s++) cal2(x,s);
a[n]=(x>>8)&255; a[n+1]=(x>>24)&255; }}
int main() {
unsigned char *a = new unsigned char [2*N],*b = new unsigned char [2*N];
initdata(a, N); memcpy(b,a,2*N);
cout<<"memcmp(a,b):"<<(memcmp(a,b,2*N)?"false":"true")<<endl;
unsigned long t=clock(); test(a); t=clock()-t; cout<<t<<endl;
t=clock(); test2(b); t=clock()-t; cout<<t<<endl;
cout<<"memcmp(a,b):"<<(memcmp(a,b,2*N)?"false":"true")<<endl;
return 0; }
- 16 ：
- 前スレ終わりごろのビットマップ合成の話だが、結果的にはスカラ版と比較して
5倍程度に収まっていたが、初期はスカラ版より遅い結果しか出せていなかった。
スカラ版と等速なら話はわかるが、
なぜ遅くなるのか?
俺も似たようなこと遭遇した記憶はあるが
詳細が思い出せない。
- 17 ：
- SIMD関連はまず命令の実行に都合のいいようにデータを作成するのと
結果を取り出すのに時間がかかるからじゃね？
それとSSEレジスタは128bitなので1処理当たり32bit使うと4並列にしかならない
AVX/AVX2なら256bitなのでこちらの方が速度が上がると思う
- 18 ：
- >>16
構造体へのコピーをスカラで何倍もの時間かけてやってたから
本体処理が4秒が1秒に縮まったところでセットアップに5秒かかってたら意味がない
ボトルネックを解消するつもりでSIMDを使ったつもりが新たな別のボトルネックを作ってました
しかもなんで遅くなったのか使った本人が認識してないというの。
- 19 ：
- つまりSIMDレジスタで計算する為に
スカラ以上に命令を使った為
遅くなったということか。
前スレの968では見直ししたが2倍ほど遅いと言っていた。
本来4倍になるはずが1/2倍、
8倍も遅くなるなんてありえるか?
根本的に何か問題があるとしか
思えん。
- 20 ：
- あんなのソースコード見ればボトルネックがどこにあるか一発でわかるだろ
見ただけでわからんやつは向いてないよ
- 21 ：
- 「ハッカーのたのしみ」とかの良著をよく読むことをすすめるよ
並列化アルゴリズムに理解のないやつがいきなりSSEやAVX使っても不幸にしかならない
- 22 ：
- 然しものSIMDも、まったくオーバーヘッドがないわけじゃぁない。
SIMDに演算させるためのデータ構造整えなんかの命令分がオーバーヘッドになる。
これを最小に抑えつつ、SIMDの並列演算性能を活かすのが腕の見せ所よ。
- 23 ：
- メモリクソ余ってんだから最初からSIMD前提なデータ構造強制できりゃいいのになぁ
- 24 ：
- すいません。以下のようなことがやりたいのですがどうするのが一番いいですか。
void up_index(short a[16],short b[16])
{
- 25 ：
- すいません。途中で書き込みました。
avx2でお願いします。
void up_index(short a[16],short b[16])
{
for(int i=0;i<15;i++)
{
b[i]=a[i+1];
}
b[15]=0;
}
void down_index(short a[16],short b[16])
{
b[0]=0;
for(int i=1;i<16;i++)
{
b[i]=a[i-1];
}
}
- 26 ：
- void up_index(short a[16],short b[16])
{
__m256i mask = _mm256_setr_epi16(
0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF,
0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF,
0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF,
0xFFFF, 0xFFFF, 0xFFFF, 0x0000
);
__m256i x = _mm256_loadu_si256((__m256i*)a[1])
x = _mm256_and_si256(x, mask);
_mm256_storeu_si256((__m256i*)b, x);
}
あとわかるよな？
- 27 ：
- ミスった
__m256i x = _mm256_loadu_si256((__m256i*)&a[1]);
- 28 ：
- >>__m256i x = _mm256_loadu_si256((__m256i*)a[1])
領域外(a[16])を参照してるような…
ゴミが入るだけだから気にしなくていいってことですか？
- 29 ：
- うごいてるっぽいので気にしないことにします。
ありがとうございました。
- 30 ：
- ページ境界跨がなきゃ平気
- 31 ：
- >>ページ境界跨がなきゃ平気
跨ぐとどうなるんでしょうか。
突然プログラムがあぼーんすることも覚悟しなきゃいけないってことですか？
- 32 ：
- アクセス違反例外で停止するわな
- 33 ：
- https://software.intel.com/sites/products/documentation/doclib/iss/2013/compiler/cpp-lin/GUID-F4DA723A-DEB9-42D8-82FF-72553EB24273.htm
ここによるとアラインされてなくてもいけるcompiler intrinsicsだわな
アラインが必要なのは
https://software.intel.com/sites/products/documentation/doclib/iss/2013/compiler/cpp-lin/GUID-29CB35FA-F50D-4F6E-88B6-D3A1D83BE311.htm
こっちの方だ
_mm256_load_si256()
ただ当然境界がズレている所は2回ほど読むだろうから速度を気にするのなら
最初から_mm256_load_si256()を使ってデータの配置もアライメント通りにしとくのに限る
配列だと__attribute__((aligned(16)))を付けて置くといいわな
- 34 ：
- おっと間違えた
__attribute__((aligned(32)))
- 35 ：
- 別にアライメントの話じゃないし。
つうか領域外読み込んでも
落ちないからOKとか
それはないから
- 36 ：
- 上下128ビット跨いだシフトが簡単にできないから
ミスアラインロード使わないとめんどくさいんだよねー
void up_index(short a[16],short b[16])
{
__m256i x = _mm256_load_si256((__m256i*)a);
__m128i u = mm_mm256_extracti128_si256(x, 1);
x = _mm256_alignr_epi8( x, _mm256_castsi128_si256(u), 14);
_mm256_store_si256((__m256i*)b, x);
}
- 37 ：
- __m128i u = _mm256_extractf128_si256(x, 1);
みすった
- 38 ：
- 16 x 16 だと結構オーバヘッド覚悟しなきゃいけないみたいですね。
11 x 11 なら128ビットに納まるから上下左右１ビットシフト高速にできますかね？
- 39 ：
- ビットボードでも作ってるの？
11ビットとかかえって扱いづらいからやめとき？pslldq/psrldqは8ビット単位だからいろいろ面倒だぞ
16x16でもvextractf128＋vpalignrの2命令ですむんんだからそれが一番無難
2のべき乗のほうが扱いやすい
- 40 ：
- 11 x 11 だと右端と左端がつながっちゃうか。
- 41 ：
- >>39
はい、まさにビットボードです。
9 x 9 あれば囲碁9路盤が作れます。
やっぱ2のべき乗ですかね〜。
- 42 ：
- SIMDとか並列プログラムは
各要素間の関連が薄けりゃ薄いほど良い
相関ゼロなら100%の性能が出せるが
逆なら劣化する。
要はお前のプランはSIMD向きじゃねえんだよ。
スカラで組めカス。
- 43 ：
- なんでよ、ビットボードにSIMD使おうと考えるのは自然だろ。
- 44 ：
- 上下128ビットの入れ替えが面倒なら、1レジスタで1ボードじゃなくて2レジスタで2ボードみたいな割り当てもアリかな
- 45 ：
- 19x19は？
- 46 ：
- １レジスタに１ボードのらないで２レジスタに２ボードのる状況が想像できない。
- 47 ：
- me too
碁盤の19x19なら1列32ビットに割り当てて128ビットの4x5レジスタじゃいかんのか？
256ビットなら3レジスタか。ちと苦しいな
- 48 ：
- 64ビットごとに19x3という割り当てもありか
- 49 ：
- さて、そろそろ団子が実験結果を公開してくれる頃だと思うんだが……
ソース書けた？
- 50 ：
- 俺囲碁のルールすら知らんが？
- 51 ：
- 結局SSEとかの機械語でやる以外にC++には高速化の手段がないの？(´･ω･｀)
後、変なclassを使わないとか？(´･ω･｀)
- 52 ：
- クラスで遅くなるとか迷信でしょ
- 53 ：
- 今はSIMDがあるから
かろうじてC++使ってるけど
他で行けるようになったら
捨てると思う
- 54 ：
- クラスを使うから遅くなるんじゃなくて、動的なポリモーフィズムを実現するための仮想関数テーブルや
あるいは過剰にコンストラクタ呼び出しで遅くなる。
- 55 ：
- >>53
C++と同程度の速度がでる言語って何よ？
- 56 ：
- いやーそんなん無いけどさー
己が納得出来れば良い訳よ
vector4クラスとかあって
最適化コンパイルでSIMD使いますよ〜
で良い。所詮趣味だし俺はそれで乗り換え出来る。
今はfortranやC++以外にはそれすらも無いからな
- 57 ：
- 過度なオブジェクト指向（笑）やめればC++でもアセンブラに迫る高効率のコード書けますよ
- 58 ：
- 最近はCとアセンブラを比較することも少なくなったろうな。
数学ライブラリなんかはまだアセンブラで書いてんのかねぇ。
- 59 ：
- >>57
おっさんおっさん、それってCとして使うってのとほぼ同じ意味なんじゃ……？
- 60 ：
- 演算子オーバーロードやテンプレートがCにあるならそうだね
どの程度の抽象化までならオーバーヘッドが生じないかはdvec.hあたりのIntel謹製クラスライブラリ見ればわかるでしょ
- 61 ：
- スレ立てるまででもない質問じゃない質問ってどんなの？
- 62 ：
- え？そこらへん使ってもアセンブラに迫る高効率のコード吐き出してくれるの？
- 63 ：
- コンパイラ舐めんなw
- 64 ：
- >>62
C にはない C++ のオーバーヘッドは、例外と仮想関数呼び出しのための関数テーブルアクセスと dynamic_cast<>()。
それらを使わなければ、型チェックの厳しい C として使える。
演算子オーバーロードは変な名前の関数を呼び出してるだけ。
コンストラクタとか（非仮想）デストラクタは C で同じ作法で作ったのと一緒。
最適化で言うと、俺の環境だと this を restrict として扱わないので、
this->func() を func( this ) にするとか人力で最適化されやすくしないといけないことがある。
- 65 ：
- >this->func() を func( this ) にするとか
まじで？
- 66 ：
- あとはMSVCだとthisポインタをECXで渡すけどSSE*ってECXを暗黙にdestinationとして扱う命令あるじゃん
- 67 ：
- みんgwでsse2つかってみたけど全然早くならないorz
何か間違ってんのかな？
- 68 ：
- github晒しておくと構いたがりがどこがおかしいのか指摘してくれるよ
- 69 ：
- githubってよく知らないんだよなぁ。
イケてるギークはつかってるらしいが。
これを機にやってみるか…
- 70 ：
- http://www.age2.tv/rd05/src/up9736.zip.html
githubはとりあえず置いといて、ソースうｐします。
物は囲連星というゲームの９路盤のAIです。
makefileが入ってるのでbenchmark.exeをmakeしてみてください。
うちのPC(core i7 4790)で40秒くらいで終わるベンチマークができます。
ベンチの内容はAIが３手プレイします。
SSE2で最適化したいクラスはPointSetというクラスで、
128bitつかって 10 x 10 のビットボードを実装しています。
SSE2化してみましたが速くなりませんでした。
スレの皆さん最適化よろしくお願いします。
- 71 ：
- SSEって最適化できてもせいぜい20%アップ程度の気がするな。
アルゴリズムの見直しとか、CPU演算以外とかはやりきってるか?
- 72 ：
- ちなみにmakefileは依存関係全然考慮してないので毎回クリーンしてくださいｗ
コンパイラは64bit MinGWです。
- 73 ：
- オッとリロードしてなかった。
>>71
アルゴリズム見直しで速くなるのが一番いいんですけどね〜
なかなかアイディアが湧かないのでとりあえず手っ取り早いSSEを試してみたいです。
- 74 ：
- >>73
i7 4790ならAVX2やiGPGPUで速くしたほうがいいんじゃないのか？
データ並列に適していないのにSIMDにしてもたいして速くならないと思うけど
いまの適している？
- 75 ：
- 128bitで一つのビットボードになっていてもろandとかorとかandnotとかさせるので
SSE2で速くなるかなと思ったんですが。
AVX2は256bitですよね？どうやって適応させるか難しいです。
iGPGPUは使い方しらないorz
- 76 ：
- iGPGPUとか全然ダメ。
並列処理向きな処理でも激遅。
最低でもメモリ空間共有がサポートされなきゃゴミ。
- 77 ：
- >>70はピンポイントでSSE化したい所、出来そうな所だけピックアップしてくれよ。
これでは解析が手間。
- 78 ：
- ボトルネックがピンポイントで分かってないからこそ遅いのでは？
- 79 ：
- >>77
SSE化できそうなところはPointSetというクラスですが、
じつはもうSSE化してます。
でも速くなんなかった。
なぜ速くならなかったか教えていただけると助かります。
>>78
PointSetボトルネックになってないんですかね。
結構使ってるはずなんですが。
- 80 ：
- 関数ごとのプロファイルとってみて総実行時間を見てみるといいよ
並列化できない（と思ってる）ところが最大のボトルネックになってるなら他をいじってもどうしようもない
- 81 ：
- 最適化ってのはボトルネックになってるところ測定してからやるもんだぞ
- 82 ：
- なんか性能測りたい関数がインライン展開されちゃって測れないっぽいT△T
- 83 ：
- だから計測しろって
- 84 ：
- ビットフィールドの立ってるビット数える関数をSSE4.2のpopcnt使ったらえらい速くなったんだが？
- 85 ：
- ちょっと出かけます。
夕方には帰ってくる。
- 86 ：
- 気を付けてな
- 87 ：
- ちょっと伺いたいんですがavxまでで8bit(1byte)の中で上半分、下半分を取り出すのはありますか？
avx2までいくとpextというmaskをとった部分のビットだけ抽出するのはあるようなんですが・・・
- 88 ：
- pextというとBMI2かね
汎用レジスタでの話ならシフトとandじゃダメな理由があるのかね
連続したnビットを取り出したいだけならレイテンシの長い(3clk)pextを使う価値があまりない
mov eax, 0fh
mov edx, f0h
pext eax, esi, eax
pext edx, esi, edx
5クロック
mov eax, esi
mov edx, esi
shr edx, 4
and eax, 0fh
and edx, 0fh
3クロック、movが消えるなら2クロック
- 89 ：
- >>88
なるほど！ありがとうございます
- 90 ：
- どういう並びにしたいの？
こういう意味？
http://stackoverflow.com/questions/12795462/how-do-i-extract-32-x-4-bit-from-16-x-8-bit-m128i-value
- 91 ：
- >>90
ちょうどこんな感じです！
このソースみたいにlowerとupperを取り出して返す関数つくろうと思ってました
下4bitはそのまま0xfでmaskして、上4bitは4bitシフトしてからmaskなのでこのコードで行けそうです
ありがとうございます
- 92 ：
- え？
movzx eax, al
shr eax, 4
じゃいかんのか？
- 93 ：
- どうしてもSIMD使いたいんだとさ
クロック数がかえって増えようとも
- 94 ：
- いえアセンブリがわからないだけです！
>>92でいけるのならやってみます！ありがとうございます！
- 95 ：
- gprofの結果ビットボードを座標のベクタに変換する関数PointSet::toVector()が時間かかってることが分かった。
すまん、ちょっと飯食ってくる。
- 96 ：
- 大概は思わぬところでサイクルを食ってるもんだ。
食うのは飯だけにしたいものだな。
- 97 ：
- PointSet::toVector()は一回最適化試みた箇所なんだよなぁ
正直これ以上アイディアうかばん。
- 98 ：
- なにをしてるか知らないがここが時間食ってる。
8ビットや16ビットで区切って計算結果を配列に入れといて利用するとかできないか?
int size()const
{
int res=0;
unsigned long long i;
i = u.table[0];
while (i)
{
++res;
i = (i - 1)&i;
}
i = u.table[1];
while (i)
{
++res;
i = (i - 1)&i;
}
return res;
}
- 99 ：
- あとここも。
32bitでの実行だが。
int get(Point p)const
{
// return !((*this) & x_line[p.x()] & y_line[p.y()]).empty();
return (table[p.y() & 1] >> (p.x() + (p.y() >> 1) * 10)) & 1;
}
- 100 ：
- 立ってるビット数が多いときはその数え方だと時間喰いそう
- 101 ：
- >>98
レスありがとうございます。
そこはビットボードのビットが立ってる数を数えています。
SSE4.2のpopcntに置き換えたら大分速くなりました。
>>99
そこはビットボードの座標pのビットが立ってるかどうか返す関数ですね。
正直そこはそれ以上最適化できないと思ってますが、うまい手ありますかね。
- 102 ：
- ちなみに>>92は
(unsigned char)n >> 4
でいける
- 103 ：
- >>102
なるほど！
ちなみにシフト操作て5bitシフトならCPUのサイクル数5倍になるとかあるんですか？
- 104 ：
- 8ビット時代じゃねそれ
別にシフトの変量でサイクル数は変わらんよ
- 105 ：
- >>104
ありがとうございます
では積極的に使っていきます！
- 106 ：
- 今のCPUはバレルシフタで1クロックじゃね
- 107 ：
- 386からは一発だな
その代わりマスクがかかる
286ま命令はあったがマイクロコード
8086はCLで回数指定以外、多ビットシフト命令が無かった
はず
- 108 ：
- cpuの命令セットて全部アセンブラに還元されるんですか？
もしそうなら命令セットてアセンブラで作ったライブラリみたいなものですよね？
- 109 ：
- アセンブラとCPU命令と機械語は一対一対応で見かけだけの違いだろ。
より人間よりの記法がアセンブラ。
- 110 ：
- ライブラリ？
- 111 ：
- アセンブラに、1語で複数インストラクションに対応する組み込み済みマクロはよくあるね。
ユーザーにとっては見かけ上機械語のニモニックと変わらん
- 112 ：
- マイクロコードからビルドされた
ライブラリだな。
- 113 ：
- シフト命令がサイクル数変わらずって事は
もしや乗算命令も……？
- 114 ：
- 乗算も1クロックだよ。かくして除算の遅さが際立つ。
- 115 ：
- 3くらいじゃなかったか？
- 116 ：
- 乗算回路って素朴な筆算より効率的な回路存在するの？
- 117 ：
- 効率て何？
回路規模？
速度とアルゴリズムのシンプルさなら表引きだけどな。
- 118 ：
- 表引きて何バイトの表用意するつもり？
- 119 ：
- >>109
ニーモニックとオペコードは一対一とは限らないよ。
- 120 ：
- >>76
http://blogs.msdn.com/b/nativeconcurrency/archive/2013/07/08/shared-memory-support-in-c-amp-introduction.aspx
- 121 ：
- >>116
まあ筆算は筆算だけどね、boothのアルゴリズムとかwallace treeとか調べてみるといいと思うよ
- 122 ：
- >>76は今の時点だとあたってるように思えるなあ
CPUと頻繁にデータやり取りしたり、十分長い時間計算させるのでなければオーバーヘッド大きすぎるし
- 123 ：
- pcooがいいかboostがいいかって話もここでいいの？
- 124 ：
- 高速化手法の話でなければ、
C/C++のライブラリ総合スレ
http://peace.2ch.sc/test/read.cgi/tech/1312906327/
- 125 ：
- どもです
- 126 ：
- >>109
嘘こけ。
アドレッシングモード一つとっても一意には対応していない。
- 127 ：
- ☆ 日本の核武装は早急に必須ですわ。☆
総務省の『憲法改正国民投票法』、でググってみてください。
日本国民の皆様方、2016年7月の『第24回 参議院選挙』で、日本人の悲願である
改憲の成就が決まります。皆様方、必ず投票に自ら足を運んでください。お願い致します。
- 128 ：
- >>116
いろいろとある
筆算方式だと桁数が倍になれば計算時間や回路規模が４倍になるけど、
３倍で済む方法もあるし、
２倍ちょっとで済む方法もある。
- 129 ：
- >>127
「米国におしつけられた憲法」「日本人悲願の」といいつつ
米の意向による改憲だけどな
さすが米国の金で設立された米の利益代表団体自民党、国民を騙すのに躊躇ないぜ
- 130 ：
- intelの乗算がスループットが1clock、レイテンシが3clock。
どうやったら3clockで計算が終わるん？
- 131 ：
- むしろどうやって乗算を3clockに分割しているのかが気になる
- 132 ：
- Load
Multiply
Store
- 133 ：
- そこまでやるんかい
- 134 ：
- テーブル参照で済ませてんのかな？
教えて、だんごの人！
- 135 ：
- Load, Storeは別でしょ
乗算は
53bit x 53bit の整数乗算
106bitから53bitへの丸め
指数部分の計算
などが必要
この中で53bit x 53bitが一番時間がかかる
３つに分けるとしたらたとえば
1. 53bit x 20bit
2. 前の結果 + 53bit x 20bit
3. 前の結果 + 53bit x 13bit, 丸め, 指数計算
とか
- 136 ：
- テーブルは割り算では使うけど、掛け算は使わないと思う
- 137 ：
- 運転手が自動車のエンジンの内部構造を知る必要はない
車を動かすだけの最低限の知識さえあればいい
- 138 ：
- 内部構造を知る事による運転技術の向上の可能性を否定出来ない。 (英訳せよ
- 139 ：
- 速いレーシングドライバーやライダーというものは、エンジンの内部構造だけではなく、
フレームの特性から、タイヤマネージメント、そしてメンタルをコントロールするための心理学まで詳しい。
- 140 ：
- そりゃメカニックに指示を出さなきゃならないからな
- 141 ：
- >>139
ペーパーテストでリアウイングを立てる効果を問われて
スポンサーロゴがよく見えるって答えたF1ドライバーが
ワールドチャンピオンになったぞ。
- 142 ：
- これマジ？
65 名前：Socket774[sage] 投稿日：2015/11/22(日) 00:16:33.62 ID:0X8V8J8N [1/2]
>>16 の続き
調べたらいろいろとわかってきました。
非常に長い間(2ms程度でばらつきあり)書き換えていないレジスタを使用すると
レイテンシが1増加するようです
以下は私の予想
2msといえばWindowsのスレッドのタイムスライス値のオーダーなので、
XSAVE/XRSTORあたりにエラッタがあると予想
XRSTOR以降値を更新してないレジスタを使用するとレイテンシが1増えてしまう
通常2msも同じ値を保持することはマレなので特に大きな問題とはとらえられていない
が、Broadwellで直っているのでintelはこの問題を認識はしているのでしょう
----
発生することを確認した命令
vaddpd, vsubpd, vaddsubpd, vmulpd, fma***pd
vaddps, vsubps, vaddsubps, vmulps, fma***ps
(128bitでも256bitでも)
発生しないことを確認した命令 :
addpd, subpd, addsubpd, mulpd
addps, subps, addsubps, mulps
vandpd, vorpd, vpand, vpor
発生することを確認したプロセッサ : Haswell
発生しないことを確認したプロセッサ : SandyBridge, IvyBridge, Broadwell
- 143 ：
- >>141
マジか！ｗ
- 144 ：
- 頭のいい人はユーモアのセンスもあるってことか
- 145 ：
- ぶんぶ〜ん
- 146 ：
- haswellはほんとエラッタが多くしかも不安定。
- 147 ：
- 恥well
- 148 ：
- haswellってなーに
- 149 ：
- 電源回路の一部をCPUに乗っけてノイズ乗りまくり不安定になった馬鹿設計のCPU。
- 150 ：
- させん 理解出来ませんw これでも工学部卒orz
暫くROMります。
- 151 ：
- intel の主力 CPU製品の世代・バージョンを表すコード名だよ
セレロンとか Core7 とか商品名に隠れて見えにくくされてる
ちなみに現行最新は broadwell に替わってるらしい
- 152 ：
- 最新は第6世代のSkylakeだよ
Broadwellは第5世代
- 153 ：
- みなさんHWもつおいんですね
- 154 ：
- しかしインテルの話題ばかりですね
AMDがかわいそう
- 155 ：
- 単にAMD64が素晴らしすぎて、最適化の必要がないからです。
- 156 ：
- 素晴らしいかどうかは兎も角、最適化の必要がないのは同意。
だってみかけねぇもんw
- 157 ：
- haswell、amd64知らないっておまえらゆとりすぎだろ、おい。
and64っていわゆるx64命令セットのことだ。AMDのCPUのことじゃない。
- 158 ：
- AMD64って3DNowのことだが(失笑)
- 159 ：
- そうかそうか、Intelは3DNowの後追いをしたのか
情けないな
- 160 ：
- AMDはx86互換の64bitCPUを早い段階で提唱したのが最大の功績
MSもそれに乗っかった
Intelまかせだったら64bit環境のコンシューマへの普及が遅れていたか
満足なものにならなかった可能性がある
IntelはItaniumとかいう普通の人からしたらゴミな物を売りたかっただろうし
将来的にはIA-64に置き換えるつもりだったらしいが
未だに32bitアプリが溢れていることを考えると互換を切るのは良くなかった
一応激遅のx86エミュレーションは付いていたが
互換で食っていた会社の癖に互換を切り捨てるとは何事ぞ
- 161 ：
- 互換切っちゃいけねえのは当然かもしんないけど
未だに4bitだか8bitのCPUに由来する制限や設計の歪みを引き継ぎ続けるのもなぁ……
カウンタレジスタとしてはRCXしか使えませんとかあまりにもウンコすぎる
- 162 ：
- そんなん先読みやら最適化の都合じゃないの？
それに互換ぶっ壊していいのなら ARM にしちゃいなよ
- 163 ：
- 64bit化の時が、唯一のx86系命令のエンコードを変えるチャンスだった
汎用レジスタは16個に増えたけど、それ以外はしょぼいまま継ぎ足し継ぎ足しのエンコード
命令が複雑すぎるし効率的じゃないし汎用整数命令が2オペランドのままだし
汎用レジスタ数増大
2SRC, 1DEST の非破壊演算
3オペランドの自由論理演算
アドレス計算用の簡易で高速な積和命令追加 (いまだLEAが重要命令って異常だろ)
乗算除算命令のレジスタ縛り削除
フラグ未使用の演算増加 or フラグの多重化
一応ちまちまは増えてるけどそんなんじゃダメ
一気に増やさないと使われないから意味がない
- 164 ：
- 一切のしがらみを解き放って、ゼロベースで命令セットを設計したら、
どれくらいの性能を叩きだせるんだろうか？
- 165 ：
- >>163の発想で出来上がったのがItanium
- 166 ：
- メニーコア系だな
GPUとCPUとDSPの良いところ取り
GPUとCPUは区別がなくなる
デコーダーやスケジューラーは極力小さく、
演算器と入出力に大きく回路を割く
- 167 ：
- Itaniumの失敗は、
x86を軽視した
コンパイル時最適化がCPUの進化に合わなかった
こんな感じか？
- 168 ：
- どっちかというとマーケティング的要因の方が大きかったかと
- 169 ：
- 並列化は並列化できないクリティカルパスで行き詰る
パンの製造ラインをいくら増やそうが1つのパンの一次発酵と二次発酵を同時にできないのと同じ。
- 170 ：
- その為に非対称メニーコアとかいう考えもあるけど...
今ある重い処理の多くは並列化可能でしょ
- 171 ：
- で団子の案は？
- 172 ：
- skylakeでipc伸びたで
- 173 ：
- 決して順序が決まってる処理を同時並列化することはできない
- 174 ：
- >>166
Cellやﾗﾗﾋﾞの方向性かな？
いずれにせよ、プログラマがどこまでしんどい重いするかも重要やね。
- 175 ：
- 条件分岐あるからクリティカルパスも変動するから、消費電力を対価に投棄実行できなくもないよ。
- 176 ：
- >>172
超微妙にな
VADDPDはなぜかレイテンシーが増えたけど
- 177 ：
- >>173
順序が決まっている処理は順序が決まっている
あたりまえじゃん
- 178 ：
- ハードの設計の努力を知らない下衆が偉そうに語ることは何一つないのよ
与えられたものをうまく使う方法だけ考えればいい
- 179 ：
- クリティカルパスってそんな問題になるかなぁ。
コア数が１万とかになったら大問題かもしれんが、
コア数４とかじゃあんまり問題に成らなくね。
- 180 ：
- 最近の事情は良く知らないんだけど
IntelのCPUでGPU内臓じゃないのってあるの？
サーバー用じゃなく
- 181 ：
- >>180
http://ark.intel.com/ja/compare/82930,82931,82932
- 182 ：
- ちょっと一般向けとは言いがたいね
しかもHaswellだし
個人的にGPUはグラボ刺すからCPUに内蔵してほしくないんだよなぁ
GPU無しで、その分値段を落としたモデルがほしい
- 183 ：
- ちなみに今どきのGPU内臓CPUの、CPU対GPUのダイ比ってどれぐらいなんだろう
http://pc.watch.impress.co.jp/img/pcw/docs/726/778/html/05.jpg.html
を見る限り左のほうにあるの、全部GPU関係でしょ
必要ないんだけどなぁ
- 184 ：
- >>178
一番偉そうな下衆がなんか書いてるwww
- 185 ：
- GPUユニットは並列演算に利用できるのにそれが必要ない用途ねぇ。
Xeonでいいはずなのにキャッシュもメモリ帯域もコア数も必要ないってことですよねぇ。
結局、内臓GPU必要ないってことはゲーム用途でしょうねぇ。
- 186 ：
- >>179
クリティカルパスってコア数が少ない方がループ回数が増えるから影響が大きくなると思うけどな
クリティカルセクションと勘違いしてない？
この話の流れでクリティカルパスがでてくるのがおかしいんだよ
アウトオブオーダにしろ、VLIWやメイニーコアにしろ、クリティカルパスの問題は一緒
違いがあるのは並列化の粒度でしょ
小さい粒度のはOoO、大きなのはメイニーコアが適していて、静的な並列化は中途半端だったということ
- 187 ：
- ディスパッチ＆リダクションのコストを軽視してるな
- 188 ：
- 同じコア性能なら多いほうが多い、それは当たり前だ
しかし低性能なコアを複数並べれば高機能なコアより常に速いというのは幻想
KNCのボトルネックがまさにイニシャル処理で、KNC側でやると遅いから大体ホスト側にやらせることになる
- 189 ：
- また的外れなこと言ってる
団子って周りから人の話聞いてないって言われないか？
OoOはCPU内でディスパッチやリダクションしてる為に熱的に限界を迎えて
性能があげられなくなったからメイニーコアやGPUの方向性が出てきたんでしょ
用途によって向き不向きがあるから棲み分けするようになって、今はその匙加減を
調整してる状況なんだろうな
CELLみたいにバランスの悪いのは結局は残れないってことなんだろうね
- 190 ：
- リダクションは変だったな、リタイアメントだわ
- 191 ：
- GPUユニットより柔軟性の高いSIMD演算器を高速なローカルストレージと一緒にCPUに内蔵させたい
GPGPU無駄多すぎ
- 192 ：
- 個人的にはSIMDが1024-wayとかになったら面白いんだが
サーバー用としてはメニーコアの方が相性が良いので
そういう流れにはならないだろうが
- 193 ：
- ベクトルコンピューターがそんな感じだった
ベクトル化出来ない処理は急激に遅くなるから、
今はコア数とバランス良くって方向になってる
AVXが8way
AVX512が16way
Geforceが32way
Radeonが64way
最高でも64wayあたりに落ち着くのでは？
- 194 ：
- >>191
SIMD、柔軟性高いかなぁ？
データの並びとか気を付けないといけないし、プレディケーションもプログラマが書かないとできない。
非アライメントのペナルティが軽減されたのは有難いけど、
せめてプレディケーションくらいはGPUのようにHWでサポートしてほしいなぁ。
- 195 ：
- コストの掛かるOoOでもSIMDにすれば相対的にコストが下がるというのもあるし
マスク演算ができるようになればプリディケードとブランチをプログラマが選べるようになる
インテルが目指してる方向は手堅いものだと思うな
- 196 ：
- 早く1024bit SIMD実装してほしいぜ。
囲碁の処理が速くなりそう。
碁盤は19 x 19だから512bitだと微妙なんだよな。
- 197 ：
- ハードウェアベクタをあまり長くしても大半のアプリケーションで無駄が出るだけだろ。
GPUのやりかたが落としどころとしてベストだと思うがな。
- 198 ：
- ここはC++の高速手法でよろしいのですよね・・・
- 199 ：
- いや、C++に限らないんじゃない？
スレタイの【C++】や【SSE】ってのは主な手段であって、
GPUやFPGAだって立派な高速化手段だ。
- 200 ：
- >>197
GPUで速くなる処理はベクタ長アップでも確実に速くなるよ
- 201 ：
- 失礼しました かなり低レベルのスレだったのですね。
- 202 ：
- （技術力が）
- 203 ：
- >>189-190
みたいな頓珍漢なこというお前の言うことははなから聞く気はない
- 204 ：
- >>201
上位の高速化も該当するから是非話題振ってね。
JITなんかもOK！
- 205 ：
- >>203
命令レベルの並列化にしろマルチプロセッサでの並列化にしろ
クリティカルパスじゃない部分を見つけて並列化してるという点では一緒で
並列化のアプローチの仕方が違ってるだけなのは理解してるんでしょ？
命令レベルの並列化であるOoOの方が直接的にクリティカルパスの影響を受けて
並列化が並列化が制限されるようになったからハイパースレッディングが投入されたのに
メイニーコアでクリティカルパスが問題になるって言い方は引っかかるんだよ
- 206 ：
- 【 オンラインTCGエディター 】 >>1
デュエル・マスターズ的な非電源TCGの 《 オンライン化ツクール系ソフト 》 制作の企画。
例えば、ガチンコ・ジャッジを直ぐにでも導入できる機能を持っておりながら、
当面それを扱わず単純化させておいて、事後的に導入拡張する際に当該システムを
ブロック構造の組み合わせで後付け挿入できるように予めシステム化してあるソフト（エディター）。
既存の非電源TCGを劣らずに再現できるならば大概のニーズに応えられる筈。
バトスピ、ヴァンガ、ウィクロス、ポケカ、デジモン、ゼクス、モンコレ、ガンダム・ウォー、ライブオン、ディメンション・ゼロ、カードヒーロー、シャーマン・キングなど
のシステムを完全再現できるように設計するけど、他に此のTCGの此のシステムは再現希望とか有ったら書いて。
マジック：ザ・ギャザリングの全システムを完全に再現するのは無理だから、此れだけは必用だ！って部分のみリクエストして。
WEB通信での対戦は、個vs個、多数乱戦、チームvsチーム、個vsチームを可能な仕様とする方針。
設計思想は 《 RPGツクール 》 が良いかな？ 他に、優れたエディター有ったら挙げてみて。
個人や企業などのベンダーが提示する開発費（見積もり）で折り合えば、発注する。
↓
エディター群から基本コンセプトを絞り込む（もちろんオリジナルで優れた新ネタが有れば導入する）。
↓
遊戯王OCGに関しては、タッグフォース、ADS、デュエルオンラインを発注先ベンダーに研究させる。
なるべく前述３つで可能な再現は全て実装させる方向を目指す。 まぁ努力する・・・
バトスピ、ヴァンガ、バディ、デュエマなど発売済みゲームソフトが存在してるケースはベンダーに研究させる。
↓
各社TCGを再現するテストプレイ ⇒ 更に改良や修正。
↓
機能制限した下位版を５万円以上で発売 ＋ デュエリ−グ用に改造した上位版でサーバー稼動＝営業開始。
↑
下位版の改造および商用利用には、別途で当社との契約が必要。
さ〜て、製作ベンダー見つけよっと！ｗｗ（ｸｽ
http://wc2014.2ch.sc/test/read.cgi/entrance2/1449039272/-18
- 207 ：
- メイニーってどこの田舎訛りだよ
- 208 ：
- さすがに[?]をエイと発音するのは苦しいぞ
実はmainie coreという架空世界のCPUの話をしているという可能性もあるけどな
学の無い語るに値しない人間なんだろう
- 209 ：
- >>207
そうそう、気になって仕方なかったんだよ。
- 210 ：
- 世界で唯一の稀有な存在かもしれねえぜ…
- 211 ：
- 煽りじゃなくてぐうの音もでないような真実を突きつけてこそじゃねえかな
- 212 ：
- メイニーコアってなんぞｗ
- 213 ：
- 逝ってるさん マンセー
- 214 ：
- 母国語英語、第二母国語C++と日本語な俺からするとMulti-をマルチって言うのも違和感あるけどな
- 215 ：
- やっぱりこの板の住民は英語でレスする方が楽な感じですか？
苦手過ぎる…
- 216 ：
- どこに英語のレスがあるんだ
- 217 ：
- だからメイニーコアってなんだよｗ
- 218 ：
- メニイコアならよかったのにな
- 219 ：
- 匿名通信（Tor、i2p等）ができるファイル共有ソフトBitComet（ビットコメット）みたいな、
BitTorrentがオープンソースで開発されています
言語は何でも大丈夫だそうなので、P2P書きたい！って人居ませんか？
Covenantの作者（Lyrise）がそういう人と話したいそうなので、よろしければツイートお願いします
https://twitter.com/Lyrise_al
ちなみにオイラはCovenantの完成が待ち遠しいプログラミングできないアスペルガーｗ
The Covenant Project
概要
Covenantは、純粋P2Pのファイル共有ソフトです
目的
インターネットにおける権力による抑圧を排除することが最終的な目標です。 そのためにCovenantでは、中央に依存しない、高効率で検索能力の高いファイル共有の機能をユーザーに提供します
特徴
Covenant = Bittorrent + Abstract Network + DHT + (Search = WoT + PoW)
接続は抽象化されているので、I2P, Tor, TCP, Proxy, その他を利用可能です
DHTにはKademlia + コネクションプールを使用します
UPnPによってポートを解放することができますが、Port0でも利用可能です(接続数は少なくなります)
検索リクエスト、アップロード、ダウンロードなどのすべての通信はDHT的に分散され、特定のサーバーに依存しません
ｇ
- 220 ：
- 書いて
- 221 ：
- 書いて
- 222 ：
- なんかない？
- 223 ：
- １次キャッシュに収まるスレッドを沢山作りたいとき、ＳＳＥやらＡＶＸ
のレジスタをメモリ代わりに使うのとメモリ直でアクセスするのとどっちが
キャッシュ乱さずに動くかな。
３次キャッシュは使いたくないし、２次キャッシュもスレッド切り替えだけに
消費させたいし。
- 224 ：
- >>223
理論的にはレジスタを使うほうが乱さないだろうけど、
コンパイラやプロセッサがどうするかは動かしてみないと分からないだろうね。
- 225 ：
- レジスタに収まるならレジスタの方が良いに決まってる
- 226 ：
- 1次キャッシュに収まるなら他のキャッシュなんて気にする必要は無いと思うんだが
普通のOSで普通のコードを動かすなら、スレッド切り替えによるオーバーヘッドなんて無視できるレベルだし
そんなことを心配するよりも、肝心なコードを気にしようよ
いろんなテクニックを知ってるからコードをアップしてくれれば、小さいループならお役にたてるかも知れない
- 227 ：
- ロングパスだったorz
- 228 ：
- 最近ニコニコ動画に上がってる経済シミュ、生態シミュ動画の人の高速化手法がすごい
- 229 ：
- どんな高速化手法なんだい？
- 230 ：
- std::copyってsimd化などの最適化って既にされてるのかな？
sse_copy()とか自作したとして
効果は期待出来る？
- 231 ：
- sse_copyとやらはmemcpy、memmoveと何が違うの？
- 232 ：
- 名前的に、SSEの128bitレジスタを使ってのコピーだろう
memcpyとmemmoveの違いはぐぐればすぐわかる
- 233 ：
- じゃなくて、自作しようとしているSSEでコピーするであろう「sse_copy」と
標準で用意されている「memcpy、memmove」←両方合わせて、とで
何が違うの？という話
当たり前だがmemcpyはCPUがSIMDに対応していれば使うし
カリカリにチューニングしてあるわけだが
sse_copyなど要るの？
- 234 ：
- memcpyはC言語の関数だったか
存在を忘れてた
こいつは最適化入ってるのね
これ使えば良さそうだ
そうする、どうもです
- 235 ：
- 条件にもよるがmemcpyあたりはコンパイラ自身がインライン展開したりする
- 236 ：
- std::copy使っておけばPODならmemcpyかmemmove使うんじゃないの
VS2017のやつはmemmove使ってるな
- 237 ：
- copyrect
- 238 ：
- 謎の速度低下で悩んでいたが、キャッシュレイアウトって重要だな。
AVX512で一部分だけ値更新したい時、16バイト読み込んでその位置に64バイト書き戻すようなケース。
そのまま16バイト読み込みで実装すると、読み込み時に16バイト分しかキャッシュがないので、書き込む時に64バイトに拡張というか再配置されて遅くなる。
最初から64バイトで読み出すと、サイズが変化しないので遅くならない。
ついつい、読み出し量が少ない方が速いに違いないと思い込んでしまう罠。
- 239 ：
- パーシャルライトって奴だな
キャッシュにも有効なのか
昔のPenProの頃の8/16bitレジスタへの書き込み後の32bit読み出しとか
HDDが2T超える頃の4Kセクタのパーティションでの位置ずれとか
信じられないほど遅くなる要因になるもんな
- 240 ：
- え、memcpy()とかstd::copy()ってSIMD使うん？？
vectorのコピー遅いから困ってて、カリカリとSIMDで書こうかと思ってたんやけど、手間省けるわ。
- 241 ：
- コピーが遅いから困っててと言うけれど
どうやって遅いと結論づけたのですか？
本来なら16ms完了するはずなのに29msもかかってしまっている！
とかわかるんですか？
- 242 ：
- ああ、いえいえ、言い方が悪かったですが、
処理時間に占めるコピーの割合が増えてきたので、高速化したいなぁ、と思っただけです。
- 243 ：
- rep movsbが糞速い
https://srad.jp/~miyuri/journal/569822/
＞＞REP MOVSはマイクロコードで実装されていて、最初にコピーサイズを見て適するコピーアルゴリズムを決めるセットアップ処理を行なってから
＞＞実際のコピー処理を始めるようになっている。そのため小さいサイズのコピーではセットアップ時間のオーバーヘッドが無視できないが
＞＞コピーサイズ(適度に大きいサイズ)とアラインメントの要件とプロセッサの世代の条件を満たすとそこそこの性能が出る。
＞
＞＞プロセッサの世代によって展開されるマイクロプログラムが変わり最適化の度合いも変わってくると。
＞＞第1世代Core i以降のプロセッサのREP MOVSのマイクロコードは比較的速い。
デコード済みの命令をキャッシュ出来るようになったから、マイクロコード展開命令でも最適化が行われるようになってるみたいだよ。
- 244 ：
- メモリのレイテンシ、スループットやキャッシュサイズに依存するんだから
ブロック転送命令の最適化は無駄な努力だとインテルは思ってんだろう。
- 245 ：
- Visual Studio 2017 で
memcpyを調べてみた
x86は rep movs
x64は vmovups 128bit 2パラ16アンロール
オプションでAVX2命令を使うようにしてもかわらず
vmovaps 256bit/512bitの方が速いから
頻繁に使うなら自作した方が良い
- 246 ：
- >>238
キャッシュ可な領域はキャッシュライン単位でDRAMの読み書きが行われるはずだから
キャッシュは関係ないでしょ。
- 247 ：
- >>246
アライメントのほうだったかも。
境界跨いで更新する時、あらかじめ更新サイズで読み出しておけば、全領域使用可能状態になるが、読み出し半分だと残り分キャッシュ要求発生して遅くなると。
- 248 ：
- >>247
一定のストライドで読み込んでいれば自動プリフェッチで早めにキャッシュに取り込まれる可能性もあるけど、
DRAMの帯域を圧迫しないようにページ境界をまたいでは機能しないようになってるはずだったので、
AVX512のベクタ長だと、何サイクルか先のループで使うデータをプリフェッチで要求した方がいいかも。
- 249 ：
- >>248
ありがとう。すでに別件でPrefetchもやってみてるけど、AVX512だとかなり効果があった。
- 250 ：
- >>249
一時は自動プリフェッチの性能が向上してあまりprefetchの意味がない状態が続いていたけど、
AVX512ともなると1ページ分のデータをループ64回で消費しちゃうんだよな…
DRAMのCASレイテンシをCPUクロックで換算すると結構長いからね。
- 251 ：
- え？AVX512は手書きprefetchのほうが性能出る？
これまではハードウェアプリフェッチが超優秀で、手書きprefetchはむしろオーバーヘッドになって遅くなる感じだったんだけど。
- 252 ：
- prefetchはハードウェアにまかせて手書きでclflush入れるのが一番いい感じなんだけど。こんなケースは少数派なのかな。
- 253 ：
- xeonでavx命令使うと過熱防止のため1ms間、動作クロック下げるなんて聞いてないよ〜(＞∀＜)
- 254 ：
- >>253
本末転倒やなw
- 255 ：
- ☆ 日本の、改憲を行いましょう。現在、衆議員と参議院の
両院で、改憲議員が３分の２を超えております。
『憲法改正国民投票法』、でググってみてください。国会の発議は
すでに可能です。平和は勝ち取るものです。お願い致します。☆☆
- 256 ：
- 僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
YF4RO
- 257 ：
- 過熱してなくても1ms間、強制的にクロック下げるん？
- 258 ：
- >>257、そうみたいなんですよ
https://pc.watch.impress.co.jp/img/pcw/docs/665/641/html/14.png.html
> AVX命令が実行されるときに、CPUはAVXベースで定義されている
> クロック周波数に一時的に下がって実行し、実行終了後元のベースクロックに戻る
> AVX命令の実行完了後1ms程度で通常(非AVX)動作モードに復帰
- 259 ：
- 1msってペナルティ、デカすぎやろ
- 260 ：
- AVXが有効な処理なら微妙にクロックが落ちようがどうでもいい
- 261 ：
- クロックが高いのが目的じゃなくて
処理が速いのが目的
その辺がよくわかってないアホがいるみたい
- 262 ：
- なんか知らんがPCUの動作速度だろ。
- 263 ：
- CPU?
- 264 ：
- Programmable Calculation Unit (嘘)
- 265 ：
- どうせならUも工夫しろよ
- 266 ：
- 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)
- 267 ：
- さすがに下がり過ぎｗ
- 268 ：
- HHG
- 269 ：
- HHG
- 270 ：
- そもそも4倍の量が同時に計算できるわけだから
クロックが半分になっても元は取れる
- 271 ：
- だね
- 272 ：
- 同じクロックで2倍の効率との違いは消費電力？
- 273 ：
- クロックが実際は半分にならないから
メリットは高速化
- 274 ：
- これ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;
}
- 275 ：
- そりゃ、やってることが違うんだから
同じにしたけりゃ sum2 で for (auto& p: v) にしてみ
- 276 ：
- うお、autoってこんな書き方も出来るのかよｗ
勉強になりました。
- 277 ：
- 結果も違うんじゃね
ちゃんと中身観たか
- 278 ：
- 結果は同じだろ? 鬼のように発生するコピーのためにメモリ不足で死なない限りは。
- 279 ：
- C++は高速化に向かいないといういい見本だ。
- 280 ：
- C++は、書いた通りに実行されるだけ。
高速な処理が必要なら、そう実行されるように実装しないと。
- 281 ：
- まるでC++コンパイラは最適化しないとかデタラメな言い分けだな。
- 282 ：
- vectorとか激しくコピーしすぎ
- 283 ：
- 何のためにコピーしてるん？ 使い方間違ってんじゃね？
- 284 ：
- reserveせずのpush_backしまくるバカのことじゃね？
- 285 ：
- push_backしまくってもそれほどパフォーマンスは悪化しないように出来てるはずだが
コピーしまくりっていうんだから関数で値渡ししてるとかじゃないか？
いずれにしろC++自体の問題ではない
- 286 ：
- データの並び順やアルゴリズム、...
この辺がパフォーマンスに大きな影響を与える
コンパイラの最適化なんぞ知れてる
その辺を最適化したければガシガシアセンブラだが
その前にいくらでもやることがあるのが普通
- 287 ：
- メインメモリが相対的に遅くなってきてるので
データの並びは非常に重要
大きなデータはディスクアクセスのような感覚で扱わないとダメ
- 288 ：
- ちゃんとキャッシュサイズや階層を意識する
- 289 ：
- 突っ込みどころもあるが1年前のレスに真面目に返答してるおまえを評価する。
- 290 ：
- x おまえ
o おまえら
って書こうとしたが
同じ人だった orz
- 291 ：
- 御評価、有難う御座います
- 292 ：
- プログラムを高速化する話
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ではインラインアセンブラも使えないコンパイラがあるし、関数呼び出しや例外処理の
書き方も変わってしまっているので移植性が低いよ
- 293 ：
- 組み込み関数でSIMD命令駆使すれば、しっかり高速化されてキモティー！
- 294 ：
- >>292
アセンブラを使わなくても速度チューニングネタはたくさんあるが
当然最後の手段としてはアセンブラは有効
小さいループに処理が集中してるような処理は
特に効果的
下手くそがアセンブラに手を出すと逆に遅くなったりもするけど
- 295 ：
- >>292
急にどうしたｗ
レジスタ割り当て面倒くさいから、Intrinsics使うの普通だぞ
- 296 ：
- >>295
>>286が
＞コンパイラの最適化なんぞ知れてる
＞その辺を最適化したければガシガシアセンブラだが
とか書いてたから
この人10年くらい時間が止まってるよね
64bitと32bitじゃレジスタの数も違うし、SIMDの新命令に対応させるたびに
レジスタ割り付けが全く変わってしまうこともあるのにアセンブラって…
AVXなら3オペランドも使えるから、コンパイラに任せてもコードの質は低下しにくくなってるはず
- 297 ：
- 費用対効果を考えればIntrinsicsでも良いけど
究極の最適化はアセンブラしか無い
IACAを使ったり実測したりしながらパズルする
処理が非常に単純で速度の求められる小規模DSPなんかでも
いまだにそういう開発をする
- 298 ：
- FPGAで専用回路組んだ方が手っ取り早い
- 299 ：
- >>297
IACA=Intel Architecture Code Analyzer
ですよね。
- 300 ：
- SIMDを覚えたての初心者はこんなコードを書きやすい
典型的な糞コード
ループ {
sum = _mm_add_ps(sum, data[i]);
}
>>299
そうです
- 301 ：
- >>298
CPU, GPU, FPGA
それぞれ得意分野が違うから
- 302 ：
- GPUユニットはCPUに乗っけたのだから後はFPGAも乗っけるだけ。
アルテラは既に買収済みだしな。
- 303 ：
- FPGAに夢見すぎじゃね？
- 304 ：
- スパコン分野じゃ固定の計算式はFPGAが一番効率的。そういう意味で地球シミュレータや京はゴミ。
スパコンが必要な分野でCPUのような汎用性などいらない。
- 305 ：
- 今度はスパコンが出て来たか
関わったこともないだろうに
スーパーコンピューターこそ汎用性が必要
ベクトルコンピューターが消えたのも
より汎用性を重視するから
スーパーコンピューターの世界でFPGAが求められてるなら
当然スーパーFPGAが流行ってないと辻褄が合わないわけだけど
流行ってないね
- 306 ：
- 何を言ってるからよく分からないなぁ。
特定の式を大量に速く計算したいという要望に対してなんで汎用性が出てくるの？
汎用性スパコンが1億なら同じ性能で1000万で達成できるんだよ。
しかも汎用性のために可用性が落ちるとか話にならないよ。京見れば分かるでしょ。
- 307 ：
- 自分専用ならTSSにする必要もないしな
- 308 ：
- FPGAとかスーパーコンピューターとか自分専用とか
具体的な処理を何も語ってないのによくもまあ勝手に前提を作るよなあ
ここはソフトの最適化のスレなんだけど
- 309 ：
- FPGAなんかで妥協しないでASICでも作れば良いよ
- 310 ：
- FPGAだってプログラムでコーディングするんだが・・・。勝手な前提作ってるのはおまえじゃん。
というかSSEでの高速化がOKなら、GPGPU、FPGAもOKだろう。
- 311 ：
- スレタイ
他のスレへどうぞ
- 312 ：
- 1年もレスが無かった過疎スレになんでこんな必死な自治厨がいるのだろうw
前スレも10年かけて1スレ消費したんだぞw
おまえは何者だw
- 313 ：
- 突然カテ違いのFPGAなんか布教し始めるから
- 314 ：
- ID:EqcpRCSG = >>311 = >>313 か？
こんな過疎スレで布教ってw マジおまえここの住人じゃないんだな。
- 315 ：
- >>312
前に64bitで絶対アドレス使えって書いて突っ込み受けたらファビョってたのいたでしょ
あれと同一人物っぽいんだよなあ
＞究極の最適化はアセンブラしか無い
とか書くところとか
午後のこ〜だの開発者たちが動画コーデックの開発しなかったのだって、
MMXは除外しても、SSE2、SSE3、SSSE3、SSE4、SSE4.1、AVX、AVX2、AVX512に加えて、
64bitでは一気に種類が2倍と、次々と登場する新命令ごとに最速のルーチン用意していく手間と、
コードが異なるために特定のCPUでしか発現しないバグがでるリスクが増すこと考えたら、
最速に拘るのが現実的ではなくなったんだよ
彼らとしては妥協したコード書く気はなかっただろうし、興味が失せるのも仕方ないのかもね
AVISynthもインラインアセンブラ使ったプラグインだらけで64bit化に対応できずに放置されてたのが
相当あったけど、自分も64bit化やった経験からも、今更初心者にアセンブラ使えなんて教えんなと言いたい
- 316 ：
- 初心者ならIntrinsicsなんか使わないで素直に汎用性のあるC++で書くかライブラリを使えばいいよ
ここは高速化手法スレだから高速なコードであることは重要
Intrinsicsよりアセンブラの方が高速に書けるのは自明なのでアセンブラの話題は当然出てくる
- 317 ：
- アセンブラ狂信者はお前だけだよ
- 318 ：
- Intrinsicsで32bit/64bitの共通化は出来ても
新命令がでたらどうせ作り直しだよ
新命令に最適化しないならそのままでいいよ
｢新命令対応｣て謳うのが目的じゃなければ
SSEからAVXの移植もレーン縛りで苦労しただろ？
単純に置き換えなんて出来ない
128bitのまま単に3オペとレジスタ数だけなら簡単だけど
AVX512も同じ
マスクレジスタや新命令を使うなら書き直し
- 319 ：
- アセンブラ狂信者じゃない
Intrinsicsも使う
極限な最適化にはアセンブラが必要ってだけ
まあ当然だ
- 320 ：
- どうせ今後は32bit向けの最適化なんかやらんだろ
だとすると手間の差はレジスタ管理くらい
- 321 ：
- >>320
＞だとすると手間の差はレジスタ管理くらい
こんなこと書くようだと大したコードは書けないな
レジスタ割り付けの妙味と面倒さを知らないのなら、別に組み込み関数で書いても構わないだろ
- 322 ：
- >>321
レジスタ割り付けの妙味www
さほど時間をかけなくてもコンパイラよりマシなのは作れるよ
そもそもIntrinsicsの時点でもレジスタ数削減は考えるべきであって
何も考えなきゃIntrinsicsだろうがアセンブラだろうが遅い
- 323 ：
- 詳しい自信があるなら
とりあえず問題ありまくりな>>300の問題点でも語ってみようか
- 324 ：
- SIMDの一番簡単とも思えるこんなコードでも
最適化に関して語れることは山ほどある
- 325 ：
- >>322
やっぱこいつ絶対アドレス君だｗ
妙味の部分に草生やすってことは大したコード書いてない証拠みたいなもんだよ
コンパイラより1%速くなっただけでもドヤ顔するタイプだろ
- 326 ：
- 絶対アドレス？
一番アクセスが速いのはスタック
ほぼ確実にL1キャッシュにある
一等地
- 327 ：
- アドレス含め、
デカい即値は色々と遅くなる要素だぞ
- 328 ：
- プログラムで勝負する？
- 329 ：
- 300 みたいなことはこのスレの本来の住民なら誰でも知ってるから
いちいち講釈垂れるのはスレの無駄遣いだからやらないだけ
FPGA だって互換性気にしなければオリジナルの CPU の IP 書けば済む話で
少なくともこの板でやる話ではない
- 330 ：
- もっとレベルの高い話をお願いします
- 331 ：
- >>329
>>300にいろんな要素が詰まってるわけだけど
どの程度わかるかな？
- 332 ：
- >>315
>MMXは除外しても、SSE2、SSE3、SSSE3、SSE4、SSE4.1、AVX、AVX2、AVX512に加えて、
>64bitでは一気に種類が2倍と、次々と登場する新命令ごとに最速のルーチン用意していく手間と、
知らなくてもいいことかもしれないけど、これはアセンブラ作者泣かせでもあったりする。
命令数が多すぎるので手作業での入力は例えテーブル方式を採用していても無理が有り、
インストラクションセットの表を自動的にテーブルに変換するようなプログラムをしなくては
ならなくなってきている。
- 333 ：
- >>300は非常に良い教材だよ
これだけで語れることは山ほどある
｢誰でも知ってる｣なんて言う人は
ほとんど何も知らない初心者だけ
>>332
全てのCPUに対して最適化したコードを書く人なんていないだろ
せいぜい128bit, 256bit, 512bit の3バージョンくらい
32bit 512bit なんていらんだろうし
マーケティング上の理由で作らされてる人がいるのか？
それなら御愁傷様
本当に最適化するなら対応命令だけじゃダメ
IceLakeはAVX512が遅いし
AMDも昔はAVXがとても遅い
- 334 ：
- >>333
アセンブラ=アセンブリ言語を処理してマシン語に変換するコンパイラ
の話。
- 335 ：
- 前半からアセンブリ言語での記述の話だと思ってしまった
命令数めちゃくちゃ多いよね
多いだけじゃなくて複雑にもなってる
{k1} とか {z} とか
まあそれでも(高級言語の)コンパイラを作るよりははるかに楽だろうけど
- 336 ：
- >>326
前にアセンブラスレでこんなこと書いてた変なのがいたんだよ
＞実際には問題がある。なぜなら、そんなにアドレスが大きいと、さっきから話題の
＞mov al, my_mojiretu[rbx]
＞という命令が使えなくなるからだ。
とか、
＞RIP相対32bitdispだとアクセスできない場合が出てくる
＞シンボルがRIP相対2GBに制限されるなどはあくまでCコンパイラの制限であって
＞アセンブラはその制限を受けない
ちょっと考えれば64bitなのに2GB制限するオプションとか使ってDLLも作れなくなるような
記法が推奨されてるはずないよな
それで複数の人から突っ込まれたら、誤りを認めて引っ込めばいいものを、
ファビョって連投しまくるから、皆呆れて無視したってことがあったんだよ
挙句にこんなことまで言い出したり
＞自分は 64BIT 用C/C++コンパイラをインストールして無いので、試せません。
>>326だってこいつの言ってることはおかしいと思うだろ？
- 337 ：
- 初心者スレなんかあったのか。乗り遅れたぜ。
- 338 ：
- >>336
その人は、64BIT命令にとても詳し過ぎてみんなが理解できなかったようだ。
- 339 ：
- >>338
Microsoftの人より頭いいんだｗ
でも連投してるときはあまり余裕無さそうだったよｗ
- 340 ：
- >>339
MSの人より頭が言いなんて、当たり前じゃない。
日本人をなめてはいけない。
- 341 ：
- 純粋に技術競争になったら、日本は絶対にアメリカに勝つ。
いつもそうだったし、IT分野でもそう。
問題はアメリカ人は自分が負けそうになると、圧力をかけて壊してくることだ。
- 342 ：
- >>341
そういう考え方情けないわ
お前がまず手本を示して見ろよ
- 343 ：
- >>336
そこだけ抜き出しても何が言いたいのかわかりません
スレタイとは関係なく
ただ人をバカにするためだけの書き込みなら
感心しない
- 344 ：
- >>342
そうそう
40〜50行程度の32bitSSEの自慢のコード片を晒せば大体の実力は判るんじゃないかな
でもね、自分が本気で最適化する時は、IACAの分析結果じゃいい加減すぎて役に立たないから
人力で計算してたんだよね
社外に秘密にしたいパイプラインの実装の詳細を気前よくツールに実装するはずないよね
だから、IACAを使って最適化してるのを自慢してる辺り、あまり期待はしてないけどね
- 345 ：
- なんで32bitSSE？
- 346 ：
- IACAの使い方間違ってないか？
自力で計算するための情報を手っ取り早く得る為の物だぞ
- 347 ：
- >>342
IT関連は狡猾な人が多いので、アイデアだけ真似されるので完成するまでは
公開しない。
- 348 ：
- >>344
40〜50行程度になる題材があればコードを書くよ
今更32bit SSEってのも
時代についていってない感じでイマイチだけど
最適化はその時代のCPU向けでいいのかな？
- 349 ：
- >>341
IT分野で日本が技術力で勝ってると思ってるの？
頭がお花畑で良いねえ
- 350 ：
- >>349
多くは無いが個人レベルでは勝てる人はいる。
- 351 ：
- 量子コンピューターに日本人の名前がクレジットされる可能性は高い。
一方、○○互換のソフトウェアはほぼ100%が中国発。
一見欧州製のように見えてもほぼほぼ中国。
人工知能に中国人の名前がクレジットされる可能性は相当高い。
- 352 ：
- >>350
なんだその無意味な主張
- 353 ：
- おそらく世界最初の人工知能は春麗とかいう名前になる。
- 354 ：
- >>352
日本の平均レベルが低いからといって、このスレに来ている人全員のレベルが
低いことにはならないということだよ。
- 355 ：
- 日本とアメリカの技術力の比較の話から
なんで個人の能力に話をすり替える？
- 356 ：
- >>355
日本では、かつては半導体業界に優秀な人が集まっていた。
その当時、日本を引っ張っていたのは平均レベルの人達ではなかったんだよ。
自分の周りの平均以下のプログラマを見て、それが日本を代表するプログラマの
レベルだと思ってもらっては困る。
- 357 ：
- しかも
勝てる人もいる
って
アメリカのトップに勝つ人がいるって言うなら多少の意味はあるけど
- 358 ：
- 様は、生まれつきのIQや理解力や記憶力の話だ。
努力とかじゃない。純粋のそういうものを比較すれば、日本のTOP層は
MSのTOP層と互角に戦える。
- 359 ：
- >>357
TOPに勝てる人は要るよ。数学オリンピックとか見ていたら分かる。
- 360 ：
- IQ、理解力、記憶力
技術力からずいぶんと話題が変わって来たね
- 361 ：
- >>359
想像じゃなくて具体的に示してください
数学オリンピックって
俺も出たけどね
そんな高校生の遊びと技術力を同一視しないで
- 362 ：
- >>361
あなたは数学ヲタクなだけでプログラミングが出来ないから
生意気なことを言ってるのか？
- 363 ：
- だからプログラムで勝負しようって言ってるのに
- 364 ：
- 本当に地数学オリンピックに出られるなら、プログラミングなんてアホみたいに
簡単なはずだ。嘘なんじゃないか。
- 365 ：
- >>363
プログラミングは勝負の世界ではなく、お金の世界だ。
金儲けの手段。数学がそんなに出来りゃ学者にでもなればいい。
コンピュータ系の教授なら簡単になれるはずだ。
- 366 ：
- 勘違いしてる人がいるようだが、本当に数学オリンピックに出るような人は、
いろいろなことが出来て、プログラミングなんて簡単に出来てしまう。
実例で行けば語学も堪能で13ヶ国語がぺらぺら立ったりする人までいる。
実際、数学オリンピックに出られるような人は、自分でもそれが分かる。
何もかも簡単に理解できるのだ。
- 367 ：
- 単なる局所的な最適化、高速化
と
コーディング
と
ソフト開発
は全然違うから
>>365
じゃあ収入で勝負するか？
- 368 ：
- >>366
夢見すぎじゃね？
- 369 ：
- >>368
そんなことない。数学は頭脳の頂点にあるので、本当に何でも出来る。
- 370 ：
- 数学の天才が本気で高速化したコード
興味があるなら素直にそういえば良いのに
- 371 ：
- >>370
そんなのには興味ない。
俺も天才だし。
- 372 ：
- 勝負から逃げる天才www
- 373 ：
- >>372
金にならない勝負はしない。
- 374 ：
- 金にならない落書きが趣味なのに？
- 375 ：
- >>374
掲示板書き込みは、頭を使わないので簡単に出来るので全然違う。
他の人が思ってるように検索して調べることもしてない。
記憶に頼って書いてるだけなので簡単。一人には高度に見えるかも
しれないが、頭は停止状態で書いている。掲示板書き込みは頭の休憩。
プログラミングの勝負などは脳のフル活動が必要になるので
絶対にしたくない。特に天才の脳はフル活動すると疲れる。凡人とは違う
かも知れない。
- 376 ：
- >>375
誤：記憶に頼って書いてるだけなので簡単。一人には高度に見えるかも
正：記憶に頼って書いてるだけなので簡単。一般人には高度に見えるかも
ちなみに誤字脱字が多いのも、頭を休めながらテキトーに書いているからだ。
長文だから必死に書いている事は無い。キーボードはスラスラ打てるから。
一般人には分からないだろう。
- 377 ：
- 数オリに幻想を抱いてるようじゃ
能力も知れてる
でもびっくりするくらい数学を知らない人もいるよね
自信満々でアップした行列の掛け算のコード
実は行列の掛け算を知らなくて掛け算になってないとか
- 378 ：
- >>377
数学オリンピックは、出るだけでも少なくとも東大や、東大の大学院に入るより
ずっと難しい。マイクロソフトに入社するよりも難しい。
ハーバードやMITよりもずっと難しい。
工学系の教授になるよりも難しい。
- 379 ：
- 昔いた団子とかいうコテの話
- 380 ：
- >>378
それを俺に言ってどうするの？
俺のファンか？
- 381 ：
- >>380
本当にそんなに頭がいいなら、どっかの教授にでもなったらいいでしょう。
こんなところで人を馬鹿にしてはいけません。
- 382 ：
- 虚言癖だと思われてるだけだろ
- 383 ：
- まあなんでもいいや
話をスレタイに戻そうぜ
とりあえず天才の>>381
>>300のコードの問題点と修正コードをよろしくね
- 384 ：
- >>382
俺は虚言ではない。
俺が嘘をついていると思ってるから、嘘で対抗しているの？
それは間違い。
- 385 ：
- >>383
SIMD命令には詳しく無いので、検索して調べないといけないのでやりません。
ここは頭を休める場所として使っているので、頭を使うことは出来ないのです。
- 386 ：
- 実は、高IQ者が休憩時間に簡単なおしゃべりのつもりで言っていることが、
一般人には、高度すぎて勝負をしてきていると思ったりする可能性があります。
こういうことでギフテッドは一般の学校でトラブルになり易いのです。
本人は勝負のつもりではなく、とても簡単に言っているのです。一般人は、
勝負だと受け止めます。これが軋轢になるのです。
- 387 ：
- じゃあ何に詳しいんだ？
別に頭を使うようなコードでもないけどねえ
単なる知識の問題
考慮すべき内容は大きく分けて5個
- 388 ：
- >>386
スレタイ
- 389 ：
- 技術的内容を1個も語らずに消えたか
文系君かな？
- 390 ：
- マウンティング合戦で過疎スレを伸ばさないでくれよ。
質問攻めして相手の揚げ足取りって馬鹿左翼みたいだし。
ループ {
sum = _mm_add_ps(sum, data[i]);
}
について語れるなら結論だけ書いてOKだよ。
- 391 ：
- >>329が答えてくれるよ
- 392 ：
- ・レイテンシとスループット
・メモリ帯域
・CPUと搭載命令
・演算の順番と精度
・処理の構成
SIMDの一番簡単とも思えるこのコードで
このくらい語れることはある
- 393 ：
- ・アラインメントと端数処理
これも
- 394 ：
- ・レイテンシとスループット
ADDPSは多くのCPUで
レイテンシ 3〜4クロック
スループット 0.5クロック/命令
(メモリリードもL1にデータがあれば0.5)
このコードは、
前の演算結果を使うので
このままだと1回のループに3〜4クロックかかってしまう
スループットを生かすには8個並列にする
ループ {
sum0 = _mm_add_ps(sum0, data[0]);
sum1 = _mm_add_ps(sum1, data[1]);
sum2 = _mm_add_ps(sum2, data[2]);
sum3 = _mm_add_ps(sum3, data[3]);
sum4 = _mm_add_ps(sum4, data[4]);
sum5 = _mm_add_ps(sum5, data[5]);
sum6 = _mm_add_ps(sum6, data[6]);
sum7 = _mm_add_ps(sum7, data[7]);
data += 8;
}
32bitコードでもSIMDレジスタが8個あるので
コンパイラはsumをレジスタに割り当ててくれることが期待できる
(一応確認する)
- 395 ：
- ・メモリ帯域 / 処理の構成
このコードの性能が生かせるのは、
データがL1にある場合
メインメモリは非常に遅いので
大きなデータにこのループを使うと
ほとんど待ち時間になってしまう
(HTTなら他方のスレッドが動き放題)
小さなデータで頻繁に呼ばれるのであれば意味があるが(例えば低レイテンシが要求されるオーディオ処理)
大きなデータの場合はほとんどがメモリアクセス時間になってしまう
L1やL2に入るようにこまめにサイズを区切りながら処理をするとか
他の処理も合わせてループにすれば
メインメモリの帯域による性能劣化を減らす事が出来る
なのでこのループ自体の存在をまずは疑問視しよう
- 396 ：
- ・CPUと搭載命令
128bit命令は古い
パフォーマンスが重要であれば
より性能のある256bit命令、512bit命令を使う
その為に、搭載命令を判別すること
・アラインメントと端数処理
メモリはキャッシュ境界をまたがない場合に性能が出る
今回の場合はデータが1個なので
前側端数と後側端数をゆっくり処理して
それ以外を高速なコードで処理をする
・演算順と演算精度
演算の順番で精度が悪化することがあるので注意
今回のコードは順番に足していくが
これは精度が悪化する順番である
(2^24個を超える個数の1を加え続ける事を考えると分かりやすい)
- 397 ：
- このくらいを把握していれば初心者を卒業できます
- 398 ：
- >>397
お前が初心者なのは良く分かった
- 399 ：
- はいはい
- 400 ：
- >>397
なるほどね。かなり勉強になりました。
こんだけ簡潔に日本語で説明されているものは、そう簡単には
ネット検索では見つけられないんじゃないかと思います。
SIMD命令には詳しく有りませんが、ちゃんとレイテンシのことまで
考えないと真価を発揮できないようですね。
知りませんけど、Intelコンパイラでもここまでは自動最適化で
やってくれないかもしれませんね。実際どうなのかお聞きしてみたいものですが。
実はコンパイラの最適化というものは、コンパイラ作者自身はやりたいと思っていても、
実際にコンピュータに自動的にやらせるのは結構大変なものなのです。
細かな注意点が沢山あるためです。最大の問題は、レジスタが無限に
あるわけではないことと、特定のレジスタにしか対応していないマシン語が
あることから来ます。もう一つは、さまざまな型やサイズの変数があるために、
色々なパターンに対応するのが難しいことにあります。
そういうこととに加えてレイテンシの自動配慮などを行おうとすると、最適化を
自動的に行うコードは非常に複雑で膨大な量になるのです。
また、今のCPUには、レジスタは16本くらいと結構沢山有るので、レジスタが不足した
場合の処理は、滅多にテストできません。そのため、その最適化処理はなかなか
テストできないのです。ですので、生半可なテストでは間違いが含まれていても
分からないままコンパイラを出荷してしまう事がありえます。敢えてレジスタが3本しか
使えないようにした状態でコンパイラをテストしたりする方法も一つの手です。
または、テストを余りしなくても明らかに正しいことが分かるようにコーディングする
ことです。しかし、それは余り簡単なことでは有りません。
- 401 ：
- >>400
最適化に関して。
例えば、最適化は、色々なパターンの最適化をどのような順序で施すかによって、
最終コードの質が変わってくることがあります。というのは、人間にとっては
割と大丈夫なのですが、コンパイラにとっては、非常に複雑でそれ以上最適化
できないようなコードに見える状態に陥ってしまうことがあるからです。
普通は、少しずつ良いコードになるよな修正を何度も何度も繰り返して、それ以上
良いコードになる方法が分からなくなった時点で最適化が終わります。
ところが、いったん、悪いコードにしてから、もう一度最適化をしてみると、
最後のコードは良いコードになる場合があります。このような最適化は人間には
余り難しくないのですが、コンパイラにとっては大変なのです。
なぜなら、悪いコードになってもいい事を許しだすと、オセロの先読みの min, max
方の様な試行錯誤型の人工知能的なものが必要になるのですが、そのような最適化は、
普段は余り効果を発揮しにくいのに、処理時間が膨大になるためです。
人間は、一度最適化したコードは、何年もそのまま使います。ところが、コンパイラは、
10分に一度くらいは、ビルドし直します。ですので、最適化にかけられる時間が違うのです。
CPUが人間より速くても、このような事情があるので、人間より良いコードを出すのは
案外難しいのです。
- 402 ：
- 長いんだよ
- 403 ：
- 最適化に関して
案外難しいのです。
- 404 ：
- アルゴリズムの最適化なら組み込み関数でもできる
なのに、アセンブラを使う理由があるのかって話なのに、なんで組み込み関数のサンプルなんだ？
自慢のコード片ってのは、アセンブラで書いたのに決まってるでしょ
言い争いしてたどっちが>>316なんだ？
- 405 ：
- ｢究極の最適化はアセンブラしかない｣
これに反対する人はいないよな？
SIMDの高速化でIntrinsicsに対しての話
アルゴリズムの最適化？
そんなものIntrinsicsを使う必要すら無い
- 406 ：
- 実際の開発現場では
(アセンブラではなくて)Intrinsicsを使うことが多い
これも別に誰も反対していない
- 407 ：
- 君はいったい誰と戦っているの？
- 408 ：
- >>405
なんかあんたの主張はずれてんだよな
本当に「究極」を求めるのなら、自分も>>298が書いてるように、何もCPUのソフトウェアに
限定せずFPGAでもなんでも使えばいいと思う
Googleだって、TensorFlow専用のプロセッサを開発して運用してる
組み込み関数の利点としては、32bit・64bit、SSE・AVXへの変更はコンパイラのオプションだけで可能ってこと
XMMでも多少は速くなるのと、AVX2やAVX512への移植もインラインアセンブラからよりははるかにしやすい
Microsoftが64bit版VCでインラインアセンブラを廃止したのは賢明だと思う
アセンブリの致命的な欠点は、アルゴリズム上の変数とレジスタが一対一で対応しないことで、
上のsum1みたいな名前付きの変数でないことと、常にどのレジスタがどの変数を保持しているか追跡しなきゃならない
それに、インラインアセンブラが使えないコンパイラだと、インライン関数やOpenMPも使いづらい
シングルスレッドで1%速くなるよりOpenMPで手軽にマルチスレッド化した方が、よりお手軽に速くなる
それでもアセンブリを使いたいっていうなら、オープンソースでないか、組み込み関数より
最低でも5%、できれば10%以上速くなる時にして欲しい
世の中にはインラインアセンブラで書かれたがために64bitで動かせずに放置されたオープンソースの
プロジェクトが結構あるんだよ（特にAVISynthなどの動画フィルタプラグインとか、オープンソースではないけど、
Aviutlも作者がインラインアセンブラ？を使いまくったせいで64bit化出来ずにいる）
- 409 ：
- >>408
横からだけど、最後の方はわかるけどコンパイラオプションのは組み込み関係ないし
単一の浮動小数点演算をSSEのレジスタ使うだけっしょ
あとハードの制約を外すんならSSEだのAVXだの選択肢に入らんでしょ
一般のPCにみんなついてるGPUだって使えるんだから
CPUの拡張命令を使うのはそれなりにハードの制約があるからだ
- 410 ：
- ここはCPUの高速化のスレだから
GPUやFPGAの話は他で
- 411 ：
- BigInt用のSIMDがあったな
- 412 ：
- >>409
64bitはコンパイラオプションではなかったけど、わざわざ各バージョン向けのコードを用意しなくても
開発環境でまとめてビルドできるでしょ
>>410
たかがアセンブリで書いたくらいで「究極」なんてドヤ顔すんなってこと
頭のいいGoogleの人達は専用プロセッサを開発する選択をした
そこまで自信があるのなら、40〜50行程度の32bitSSEのアセンブリで書かれた自慢のコード片を晒してみたら？
- 413 ：
- >>1読めよ。
- 414 ：
- >>413
「弘法筆を選ばず」って諺があるように、本当に才能のある人はわざわざ手段限定してドヤ顔したりしないだろ
せこいマウント合戦繰り広げてたの見てると、器の小ささを感じてしまうんだよな
そんなの恥ずかしいから止めとけよ
それより、エレガントなコード片晒した方がかっこいいぞ
- 415 ：
- Intelは、何年も前からパラレル・ユニバースってキャッチフレーズで細粒度のマルチスレッディングを
推進していて、Threading Building Block（TBB）とかOpenMPなんかを使って並列化で速度を稼げと言ってる
現在では、IntelのIPPやMKLもフリー化されて、定番の処理は予め用意されてる
動画処理なんかでも、フィルタやフレーム別に複数のバッファを用意してマルチスレッド化してると
スループットを稼ぐようになってるので、最適化が甘くてもハイパースレッディングで実行ユニットは埋められる
GPUで計算する場合はライブラリ呼び出しだし、64bitでインラインアセンブラを使えるIntelのコンパイラは
700ドル以上するし、GCCのasmは癖が強すぎてMASMやNASMへの移植の障害になるほど
そういうことで、現在では「アセンブリで究極の最適化」なんて、時代に取り残された年寄りの妄言みたいな
状態になってるから、組み込み関数使って保守性をよくしておけばいい
- 416 ：
- マルチスレッド化してスループットを稼ぐようになってるので
- 417 ：
- Pen4の失敗で何を学習したんだか
- 418 ：
- 熱湯バーストか･･･
- 419 ：
- >>417
NetBurstと違って、スパコンの主流が数千から数十万コア以上の超並列マシンになって
そろそろ20年近く経つのに、まだこんなこと言ってるのがいるんだな
よくまあ、これで最適化を語ってたものだ
- 420 ：
- なんでPen4なんかを持ち出すのか引っかかってたけど、もしかしてNehalem以降のCPUで
ハイパースレッディングが復活してるのも知らなかったとか？
>>286や>>287で
＞コンパイラの最適化なんぞ知れてる
＞その辺を最適化したければガシガシアセンブラだが
とか書いてたのがおかしいと思ったんだよな
シングルスレッドでしか動かないCPUなんかで、
HaswellやSkylake、IceLakeみたいな実行部の強化をするはずないだろ
OpenMPやTBBでマルチスレッド化すればベクタ化は組み込み関数でも十分だし、
メモリアクセスがネックになってるのに、どうしてマルチスレッドによる並列化に言及しないのか不思議だったんだよな
- 421 ：
- スレッド分けももちろん重要です
まあ安直にOpenMPでも良いんですが
これも究極はスクラッチ
スーパーコンピューターと違って
普通のPCだとせいぜいHTTとマルチコアなので
まあそれほど複雑ではないですが
>>300の例だと、
演算ポートもロードポートもガラガラなので
HTTは非常に有効です
データがL1にあれば性能はほぼ倍になります
一方>>394の場合は演算ポートもロードポートもフルに使ってるので、
HTTの効果はありません
汎用整数命令や整数ベクタを使うスレッドに分けてあげましょう
まとまった単純な処理でHTTの効果が大きい物は
ポートがスカスカな糞コードですね
メモリ帯域で大きく性能が変わるコードも糞コード
これは>>395の通り
- 422 ：
- スレッドの分け方はこのスレの趣旨とは違いそうなのでこの辺で
- 423 ：
- > NetBurstと違って、スパコンの主流が数千から数十万コア以上の超並列マシンになってそろそろ20年近く経つ
というかこの人は何を言ってるのだろう。
スパコンなんて40年以上前から並列処理の性能ということも知らんとかまだ子供か学生かな？
当時のPen4のことも全然知らないんじゃないだろうか。NetBurstとスパコン比べて何が言いたかったのだろう。
- 424 ：
- ちょいとメンテがてらにmasm弄ってるんだけど、
mov r/m64, imm32 形式のバイナリ吐かせる記述方法がわからん。
- 425 ：
- 自己レスになるが、符号付き与えると符号拡張されるようだった
mov rax, -1
↓これと同じ結果
mov rax, 0FFFFFFFFFFFFFFFFh
VS2019だと
return 0xFFFFFFFFFFFFFFFF;
これが最適化されてコンパクトになっていたという話。やっぱアセンブラめんどい。
- 426 ：
- ICC 19.1って32bitで最適化してビルドすると、コード生成の拡張命令でSSE2やAVX未満を指定してもAVXのコード吐き出す事がある謎の仕様があって困る。というかたぶんバグ。
できあがったコードに正常でない無効なオペランドが含まれたり要はぶっ壊れてる。
これを回避するには、最適化 /Od 無効で任意の拡張命令を指定するとAVXが含まれずに正常なコードになるが、最適化はたぶんされていないだろうな・・・。
古い環境作ってレガシー用のビルド環境まだ要るんかなあ。
- 427 ：
- そりゃヒドイなw
- 428 ：
- さすがにバグレポート送るべき
再現できるコードとその時のオプションを添えて
とはいえ、既に世界の誰かが同じことをやっている可能性は大
- 429 ：2020/03/25
- 謎のAVX出力は_mulx_u32が原因だった。
てっきりただの乗算と思いきや、これBMI2つまりAVX2の命令セット世代なんですね。
おそらくベクトル化を試みるかをした時、コンパイラ内部の命令セットのフラグがAVX2に上書きされて処理がおかしくなっていると予想。
今回の問題が無かったにせよ、非AVX2環境では動かないコードになっていたので自分のバグでもあるが、普通に動く場合もあるので注意がいる。
コーディングスタイルにこだわるスレ
次世代言語18 Go Rust Elixir Kotlin TypeScript
【Scheme】Schemeインタプリタ Mosh Part1【Lisp】
CORBAなら俺に聞け
Android Studio 2
【えっ】Perlに未来はあるのか？【終わり？】
VBSで便利なプログラムを作れスレ 2
☆★Java質問･相談スレッド181★★
プログラムに詳しくなりたい
LLにおける関数型プログラミング
--------------------
【中世剣戟ACT】MORDHAU part3
◆◆◆関西版：デパートの美術展を楽しもう（8）◆
【バーチャルYouTuber】.LIVEアイドル部アンチスレ#10805【アップランド】
【AKB48】村山彩希応援スレ☆50【ゆいりー】
軍事板強制ID制式採用投票スレッド
全然かみあわないのに話が進むスレ Part168
【晒し】イラスト系違反者晒しスレ2019/5/10【メルカリ・ヤフオク等】
【ノロ】次亜塩素酸水【コロナ】
【SEGA】オンゲキ Part.6
【実業家】孫正義氏「やりましょう。マスク１００万枚寄付します。」
新潟のゲーセン事情74
移籍・レンタル・戦力外「ら」スレ Part12806
ゲームオブスローンズの8シーズン半分見終わったんだがクソオモロイやんけ
安倍晋三「コロナ犠牲者のご冥福をお祈りする」⇒六本木の米沢牛で有名な高級鉄板焼き屋さんで、２時間も滞在し舌鼓！ [455169849]
大阪名物スーパー「玉出」のモーニングセットが１００円で凄い [816970601]
【聖龍】今治スネップ92【軍団】
エジプト旅行 Part26
★ヤサシケンジについて語るスレ7
雑談 ラストピリオド -終わりなき螺旋の物語-
最萌支援のあれこれを話すスレ 22
TOP カテ一覧 スレ一覧 100〜終まで 2ch元 削除依頼
