【C++】高速化手法【SSE】2 [転載禁止]©2ch.net

**デフォルトの名無しさん** · 2015/05/21(木) 01:53:58.15

C++やインラインアセンブラ、SSEなどによる高速化の手法
について語りましょう。

前スレ
【C++】高速化手法【SSE】
http://peace.2ch.net/test/read.cgi/tech/1130349336/

**デフォルトの名無しさん** · 2015/05/21(木) 01:55:23.61

>>1乙。

10年の時を経て2スレ目に突入、おめでとう。

**デフォルトの名無しさん** · 2015/05/21(木) 02:00:37.40

1スレ10年も掛かったのかwww

compiler intrinsicsの普及と、x64ではインラインアセンブラが使えなくなったのが
またSIMDの再普及に繋がる気がする

SSE3、SSE4、AVX、AVX2、FMAと言った新しい命令も増えているのも理由の一つか

**デフォルトの名無しさん** · 2015/05/21(木) 02:02:04.95

それとこれテンプレに入れるか
次スレ今度いつになるか分からないしなｗｗ

http://www.officedaytime.com/tips/simd.html

**デフォルトの名無しさん** · 2015/05/21(木) 02:07:04.14

あと面白そうなところはここか

https://github.com/herumi/x86opti

**デフォルトの名無しさん** · 2015/05/21(木) 03:57:50.11

10年ｗｗｗｗ

**デフォルトの名無しさん** · 2015/05/21(木) 13:51:48.66

マルチコアによるマルチスレッド化の方がずっと楽だから、難しいSIMDプログラミングはいまいち
はやらないのかな

**デフォルトの名無しさん** · 2015/05/21(木) 19:18:14.97

SIMDは作るのは難しいが、一度作ってしまうと、関数の中に封じ込めることが出来るので、
後からの使い勝手自体はマルチスレッドよりも良いんだがな。ライブラリ化もただの関数なので問題ない。
マルチスレッドだと関数の中だけで閉じなくて、アプリ全体の設計の部分まで話が広がるので、
機能単位でライブラリ化するのが難しく、簡単に使いまわせない。
ま、SIMDはライブラリ化しやすいから、多くのものが既にライブラリ化されてて、
ほとんどの人はそれを使うだけですむので、自分で書く必要性が少なくて、
故に過疎りやすいってのもあると思うがね。

**デフォルトの名無しさん** · 2015/05/21(木) 19:30:58.21

SIMD化はコンパイラに任せるのが得策。
アルゴリズム改善がどこもできなくなってからでいい。

**デフォルトの名無しさん** · 2015/05/21(木) 20:29:21.14

前スレの8bit単位の乗算とか、そういう頻繁にありそうなケースに対応した命令を用意してくれないと、
間口広がんないよ･･･。

**デフォルトの名無しさん** · 2015/05/21(木) 20:45:29.77

8/16bitぐらいのIndex範囲でテーブル引きしれくれる命令がほしいわ

8bit演算するにも無駄なシャッフルしなくても良い命令がそろったのがSSE4辺りで
さらにAMDが未対応みたいな期間長すぎたな

**デフォルトの名無しさん** · 2015/05/22(金) 01:51:48.18

命令に対応してたってそれを実行するユニットがそれ相応に強化されてなければ大して効果ないよ

**デフォルトの名無しさん** · 2015/05/23(土) 18:03:12.07

並列計算が実装されてないか、使っても遅いとき、通常の演算で並列できないか?

(a0 + a1X + a2X^2 + a3X^3) ( s + tX)　のXの1乗、3乗を取り出すことで、

**デフォルトの名無しさん** · 2015/05/23(土) 18:08:24.46

途中送信した。
上のXの項は、t a0 + s a1
上のX^3の項は、t a2 + s a3

Xをたとえば2^10や2^16と取り、下位からの桁上りがないとすると、ビット演算でデータ取り出せる。

**デフォルトの名無しさん** · 2015/05/23(土) 19:52:22.42

>>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; }

**デフォルトの名無しさん** · 2015/05/27(水) 11:09:42.07

前スレ終わりごろのビットマップ合成の話だが、結果的にはスカラ版と比較して
5倍程度に収まっていたが、初期はスカラ版より遅い結果しか出せていなかった。
スカラ版と等速なら話はわかるが、
なぜ遅くなるのか?
俺も似たようなこと遭遇した記憶はあるが
詳細が思い出せない。

**デフォルトの名無しさん** · 2015/05/27(水) 13:45:50.89

SIMD関連はまず命令の実行に都合のいいようにデータを作成するのと
結果を取り出すのに時間がかかるからじゃね？
それとSSEレジスタは128bitなので1処理当たり32bit使うと4並列にしかならない
AVX/AVX2なら256bitなのでこちらの方が速度が上がると思う

**デフォルトの名無しさん** · 2015/05/27(水) 15:22:12.59

>>16
構造体へのコピーをスカラで何倍もの時間かけてやってたから
本体処理が4秒が1秒に縮まったところでセットアップに5秒かかってたら意味がない

ボトルネックを解消するつもりでSIMDを使ったつもりが新たな別のボトルネックを作ってました
しかもなんで遅くなったのか使った本人が認識してないというの。

**デフォルトの名無しさん** · 2015/05/27(水) 18:10:04.45

つまりSIMDレジスタで計算する為に
スカラ以上に命令を使った為
遅くなったということか。
前スレの968では見直ししたが2倍ほど遅いと言っていた。
本来4倍になるはずが1/2倍、
8倍も遅くなるなんてありえるか?
根本的に何か問題があるとしか
思えん。

**デフォルトの名無しさん** · 2015/05/27(水) 19:09:25.21

あんなのソースコード見ればボトルネックがどこにあるか一発でわかるだろ
見ただけでわからんやつは向いてないよ

**デフォルトの名無しさん** · 2015/05/27(水) 19:11:41.34

「ハッカーのたのしみ」とかの良著をよく読むことをすすめるよ
並列化アルゴリズムに理解のないやつがいきなりSSEやAVX使っても不幸にしかならない

**デフォルトの名無しさん** · 2015/05/27(水) 19:52:40.39

然しものSIMDも、まったくオーバーヘッドがないわけじゃぁない。
SIMDに演算させるためのデータ構造整えなんかの命令分がオーバーヘッドになる。
これを最小に抑えつつ、SIMDの並列演算性能を活かすのが腕の見せ所よ。

**デフォルトの名無しさん** · 2015/05/29(金) 18:33:22.93

メモリクソ余ってんだから最初からSIMD前提なデータ構造強制できりゃいいのになぁ

**デフォルトの名無しさん** · 2015/06/08(月) 22:06:48.16

すいません。以下のようなことがやりたいのですがどうするのが一番いいですか。

void up_index(short a[16],short b[16])
{

**デフォルトの名無しさん** · 2015/06/08(月) 22:12:29.64

すいません。途中で書き込みました。
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];
}
}

**,,・´∀｀・,,）っ-○○○** · 2015/06/08(月) 22:54:29.21

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);
}

あとわかるよな？

**,,・´∀｀・,,）っ-○○○** · 2015/06/08(月) 22:55:00.93

ミスった
__m256i x = _mm256_loadu_si256((__m256i*)&a[1]);

**デフォルトの名無しさん** · 2015/06/08(月) 23:02:02.79

>>__m256i x = _mm256_loadu_si256((__m256i*)a[1])
領域外(a[16])を参照してるような…
ゴミが入るだけだから気にしなくていいってことですか？

**デフォルトの名無しさん** · 2015/06/08(月) 23:58:10.30

うごいてるっぽいので気にしないことにします。
ありがとうございました。

**,,・´∀｀・,,）っ-○○○** · 2015/06/09(火) 00:11:30.65

ページ境界跨がなきゃ平気

２５ · 2015/06/09(火) 00:47:54.26

>>ページ境界跨がなきゃ平気
跨ぐとどうなるんでしょうか。
突然プログラムがあぼーんすることも覚悟しなきゃいけないってことですか？

**デフォルトの名無しさん** · 2015/06/09(火) 02:10:05.37

アクセス違反例外で停止するわな

**デフォルトの名無しさん** · 2015/06/09(火) 02:26:12.65

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)))を付けて置くといいわな

**デフォルトの名無しさん** · 2015/06/09(火) 02:26:58.58

おっと間違えた

__attribute__((aligned(32)))

**デフォルトの名無しさん** · 2015/06/09(火) 08:01:24.58

別にアライメントの話じゃないし。
つうか領域外読み込んでも
落ちないからOKとか
それはないから

**,,・´∀｀・,,）っ-○○○** · 2015/06/09(火) 10:18:10.60

上下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);
}

**,,・´∀｀・,,）っ-○○○** · 2015/06/09(火) 10:19:22.92

　__m128i u = _mm256_extractf128_si256(x, 1);

みすった

25 · 2015/06/09(火) 21:40:12.66

16 x 16 だと結構オーバヘッド覚悟しなきゃいけないみたいですね。
11 x 11 なら128ビットに納まるから上下左右１ビットシフト高速にできますかね？

**,,・´∀｀・,,）っ-○○○** · 2015/06/09(火) 21:47:54.51

ビットボードでも作ってるの？

11ビットとかかえって扱いづらいからやめとき？pslldq/psrldqは8ビット単位だからいろいろ面倒だぞ
16x16でもvextractf128＋vpalignrの2命令ですむんんだからそれが一番無難
2のべき乗のほうが扱いやすい

**デフォルトの名無しさん** · 2015/06/09(火) 21:51:07.26

11 x 11 だと右端と左端がつながっちゃうか。

**デフォルトの名無しさん** · 2015/06/09(火) 21:55:17.24

>>39
はい、まさにビットボードです。
9 x 9 あれば囲碁9路盤が作れます。
やっぱ2のべき乗ですかね～。

**デフォルトの名無しさん** · 2015/06/09(火) 22:00:22.26

SIMDとか並列プログラムは
各要素間の関連が薄けりゃ薄いほど良い
相関ゼロなら100%の性能が出せるが
逆なら劣化する。
要はお前のプランはSIMD向きじゃねえんだよ。
スカラで組めカス。

**デフォルトの名無しさん** · 2015/06/09(火) 22:11:17.04

なんでよ、ビットボードにSIMD使おうと考えるのは自然だろ。

**,,・´∀｀・,,）っ-○○○** · 2015/06/09(火) 22:34:23.52

上下128ビットの入れ替えが面倒なら、1レジスタで1ボードじゃなくて2レジスタで2ボードみたいな割り当てもアリかな

**デフォルトの名無しさん** · 2015/06/11(木) 06:33:32.55

19x19は？

**デフォルトの名無しさん** · 2015/06/11(木) 17:55:12.67

１レジスタに１ボードのらないで２レジスタに２ボードのる状況が想像できない。

**,,・´∀｀・,,）っ-○○○** · 2015/06/11(木) 21:11:39.78

me too

碁盤の19x19なら1列32ビットに割り当てて128ビットの4x5レジスタじゃいかんのか？
256ビットなら3レジスタか。ちと苦しいな

**,,・´∀｀・,,）っ-○○○** · 2015/06/11(木) 21:17:03.34

64ビットごとに19x3という割り当てもありか

**デフォルトの名無しさん** · 2015/06/13(土) 04:02:16.52

さて、そろそろ団子が実験結果を公開してくれる頃だと思うんだが……
ソース書けた？

**,,・´∀｀・,,）っ-○○○** · 2015/06/13(土) 06:50:53.32

俺囲碁のルールすら知らんが？

**デフォルトの名無しさん** · 2015/06/22(月) 09:21:43.06

結局SSEとかの機械語でやる以外にC++には高速化の手段がないの？(´･ω･｀)
後、変なclassを使わないとか？(´･ω･｀)

**デフォルトの名無しさん** · 2015/06/22(月) 16:45:31.61

クラスで遅くなるとか迷信でしょ

**デフォルトの名無しさん** · 2015/06/22(月) 16:51:45.79

今はSIMDがあるから
かろうじてC++使ってるけど
他で行けるようになったら
捨てると思う

**,,・´∀｀・,,）っ-○○○** · 2015/06/22(月) 16:56:25.34

クラスを使うから遅くなるんじゃなくて、動的なポリモーフィズムを実現するための仮想関数テーブルや
あるいは過剰にコンストラクタ呼び出しで遅くなる。

**デフォルトの名無しさん** · 2015/06/22(月) 19:26:36.11

>>53
C++と同程度の速度がでる言語って何よ？

**デフォルトの名無しさん** · 2015/06/22(月) 19:59:05.05

いやーそんなん無いけどさー
己が納得出来れば良い訳よ
vector4クラスとかあって
最適化コンパイルでSIMD使いますよ～
で良い。所詮趣味だし俺はそれで乗り換え出来る。
今はfortranやC++以外にはそれすらも無いからな

**,,・´∀｀・,,）っ-○○○** · 2015/06/22(月) 20:04:38.95

過度なオブジェクト指向（笑）やめればC++でもアセンブラに迫る高効率のコード書けますよ

**デフォルトの名無しさん** · 2015/06/22(月) 21:19:49.22

最近はCとアセンブラを比較することも少なくなったろうな。
数学ライブラリなんかはまだアセンブラで書いてんのかねぇ。

**デフォルトの名無しさん** · 2015/06/22(月) 23:07:11.77

>>57
おっさんおっさん、それってCとして使うってのとほぼ同じ意味なんじゃ……？

**,,・´∀｀・,,）っ-○○○** · 2015/06/22(月) 23:15:07.42

演算子オーバーロードやテンプレートがCにあるならそうだね
どの程度の抽象化までならオーバーヘッドが生じないかはdvec.hあたりのIntel謹製クラスライブラリ見ればわかるでしょ

**マ○コデラックス** · 2015/06/23(火) 23:58:04.32

スレ立てるまででもない質問じゃない質問ってどんなの？

**デフォルトの名無しさん** · 2015/06/26(金) 04:43:42.68

え？そこらへん使ってもアセンブラに迫る高効率のコード吐き出してくれるの？

**デフォルトの名無しさん** · 2015/06/26(金) 09:20:27.34

コンパイラ舐めんなw

**デフォルトの名無しさん** · 2015/06/26(金) 13:07:25.04

>>62
C にはない C++ のオーバーヘッドは、例外と仮想関数呼び出しのための関数テーブルアクセスと dynamic_cast<>()。
それらを使わなければ、型チェックの厳しい C として使える。
演算子オーバーロードは変な名前の関数を呼び出してるだけ。
コンストラクタとか（非仮想）デストラクタは C で同じ作法で作ったのと一緒。

最適化で言うと、俺の環境だと this を restrict として扱わないので、
this->func() を func( this ) にするとか人力で最適化されやすくしないといけないことがある。

**デフォルトの名無しさん** · 2015/06/26(金) 18:56:22.95

>this->func() を func( this ) にするとか

まじで？

**,,・´∀｀・,,）っ-○○○** · 2015/06/26(金) 23:08:38.05

あとはMSVCだとthisポインタをECXで渡すけどSSE*ってECXを暗黙にdestinationとして扱う命令あるじゃん

**デフォルトの名無しさん** · 2015/07/04(土) 19:14:20.94

みんgwでsse2つかってみたけど全然早くならないorz
何か間違ってんのかな？

**,,・´∀｀・,,）っ-○○○** · 2015/07/04(土) 20:06:47.25

github晒しておくと構いたがりがどこがおかしいのか指摘してくれるよ

**デフォルトの名無しさん** · 2015/07/04(土) 20:23:55.16

githubってよく知らないんだよなぁ。
イケてるギークはつかってるらしいが。
これを機にやってみるか…

◆kXDiHQuNQ2 · 2015/07/04(土) 22:33:31.72

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化してみましたが速くなりませんでした。

スレの皆さん最適化よろしくお願いします。

**デフォルトの名無しさん** · 2015/07/04(土) 22:42:47.73

SSEって最適化できてもせいぜい20%アップ程度の気がするな。
アルゴリズムの見直しとか、CPU演算以外とかはやりきってるか?

**デフォルトの名無しさん** · 2015/07/04(土) 22:49:03.16

ちなみにmakefileは依存関係全然考慮してないので毎回クリーンしてくださいｗ
コンパイラは64bit MinGWです。

**デフォルトの名無しさん** · 2015/07/04(土) 22:51:51.53

オッとリロードしてなかった。
>>71
アルゴリズム見直しで速くなるのが一番いいんですけどね～
なかなかアイディアが湧かないのでとりあえず手っ取り早いSSEを試してみたいです。

**デフォルトの名無しさん** · 2015/07/04(土) 23:13:48.96

>>73
i7 4790ならAVX2やiGPGPUで速くしたほうがいいんじゃないのか？
データ並列に適していないのにSIMDにしてもたいして速くならないと思うけど
いまの適している？

**デフォルトの名無しさん** · 2015/07/04(土) 23:23:18.20

128bitで一つのビットボードになっていてもろandとかorとかandnotとかさせるので
SSE2で速くなるかなと思ったんですが。
AVX2は256bitですよね？どうやって適応させるか難しいです。
iGPGPUは使い方しらないorz

**デフォルトの名無しさん** · 2015/07/04(土) 23:28:34.72

iGPGPUとか全然ダメ。
並列処理向きな処理でも激遅。
最低でもメモリ空間共有がサポートされなきゃゴミ。

**デフォルトの名無しさん** · 2015/07/05(日) 01:38:21.45

>>70はピンポイントでSSE化したい所、出来そうな所だけピックアップしてくれよ。
これでは解析が手間。

**,,・´∀｀・,,）っ-○○○** · 2015/07/05(日) 06:57:39.74

ボトルネックがピンポイントで分かってないからこそ遅いのでは？

◆kXDiHQuNQ2 · 2015/07/05(日) 08:14:07.41

>>77
SSE化できそうなところはPointSetというクラスですが、
じつはもうSSE化してます。
でも速くなんなかった。

なぜ速くならなかったか教えていただけると助かります。

>>78
PointSetボトルネックになってないんですかね。
結構使ってるはずなんですが。

**,,・´∀｀・,,）っ-○○○** · 2015/07/05(日) 08:44:17.99

関数ごとのプロファイルとってみて総実行時間を見てみるといいよ
並列化できない（と思ってる）ところが最大のボトルネックになってるなら他をいじってもどうしようもない

**デフォルトの名無しさん** · 2015/07/05(日) 09:42:48.10

最適化ってのはボトルネックになってるところ測定してからやるもんだぞ

**デフォルトの名無しさん** · 2015/07/05(日) 10:22:22.43

なんか性能測りたい関数がインライン展開されちゃって測れないっぽいT△T

**デフォルトの名無しさん** · 2015/07/05(日) 10:47:06.39

だから計測しろって

**デフォルトの名無しさん** · 2015/07/05(日) 10:50:19.25

ビットフィールドの立ってるビット数える関数をSSE4.2のpopcnt使ったらえらい速くなったんだが？

**デフォルトの名無しさん** · 2015/07/05(日) 10:59:07.88

ちょっと出かけます。
夕方には帰ってくる。

**デフォルトの名無しさん** · 2015/07/05(日) 11:07:32.33

気を付けてな

**デフォルトの名無しさん** · 2015/07/05(日) 11:49:59.66

ちょっと伺いたいんですがavxまでで8bit(1byte)の中で上半分、下半分を取り出すのはありますか？
avx2までいくとpextというmaskをとった部分のビットだけ抽出するのはあるようなんですが・・・

**デフォルトの名無しさん** · 2015/07/05(日) 13:52:49.93

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クロック

**デフォルトの名無しさん** · 2015/07/05(日) 13:55:24.70

>>88
なるほど！ありがとうございます

**デフォルトの名無しさん** · 2015/07/05(日) 14:06:01.88

どういう並びにしたいの？
こういう意味？
http://stackoverflow.com/questions/12795462/how-do-i-extract-32-x-4-bit-from-16-x-8-bit-m128i-value

**デフォルトの名無しさん** · 2015/07/05(日) 14:43:20.51

>>90
ちょうどこんな感じです！
このソースみたいにlowerとupperを取り出して返す関数つくろうと思ってました

下4bitはそのまま0xfでmaskして、上4bitは4bitシフトしてからmaskなのでこのコードで行けそうです
ありがとうございます

**,,・´∀｀・,,）っ-○○○** · 2015/07/05(日) 15:10:55.88

え？

movzx eax, al
shr eax, 4

じゃいかんのか？

**デフォルトの名無しさん** · 2015/07/05(日) 15:14:44.70

どうしてもSIMD使いたいんだとさ
クロック数がかえって増えようとも

**デフォルトの名無しさん** · 2015/07/05(日) 16:55:23.92

いえアセンブリがわからないだけです！
>>92でいけるのならやってみます！ありがとうございます！

**デフォルトの名無しさん** · 2015/07/05(日) 17:09:15.78

gprofの結果ビットボードを座標のベクタに変換する関数PointSet::toVector()が時間かかってることが分かった。
すまん、ちょっと飯食ってくる。

**デフォルトの名無しさん** · 2015/07/05(日) 17:14:58.64

大概は思わぬところでサイクルを食ってるもんだ。
食うのは飯だけにしたいものだな。

**デフォルトの名無しさん** · 2015/07/05(日) 19:12:24.15

PointSet::toVector()は一回最適化試みた箇所なんだよなぁ
正直これ以上アイディアうかばん。

**デフォルトの名無しさん** · 2015/07/05(日) 19:48:59.00

なにをしてるか知らないがここが時間食ってる。
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;
}

**デフォルトの名無しさん** · 2015/07/05(日) 19:54:28.58

あとここも。
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;
}

**デフォルトの名無しさん** · 2015/07/05(日) 19:58:51.19

立ってるビット数が多いときはその数え方だと時間喰いそう

**デフォルトの名無しさん** · 2015/07/05(日) 20:02:29.73

>>98
レスありがとうございます。
そこはビットボードのビットが立ってる数を数えています。
SSE4.2のpopcntに置き換えたら大分速くなりました。

>>99
そこはビットボードの座標pのビットが立ってるかどうか返す関数ですね。
正直そこはそれ以上最適化できないと思ってますが、うまい手ありますかね。

**,,・´∀｀・,,）っ-○○○** · 2015/07/05(日) 22:27:19.60

ちなみに>>92は
(unsigned char)n >> 4
でいける

**デフォルトの名無しさん** · 2015/07/05(日) 23:55:30.55

>>102
なるほど！
ちなみにシフト操作て5bitシフトならCPUのサイクル数5倍になるとかあるんですか？

**,,・´∀｀・,,）っ-○○○** · 2015/07/06(月) 00:06:48.57

8ビット時代じゃねそれ
別にシフトの変量でサイクル数は変わらんよ

**デフォルトの名無しさん** · 2015/07/06(月) 00:08:37.50

>>104
ありがとうございます
では積極的に使っていきます！

**デフォルトの名無しさん** · 2015/07/06(月) 00:15:26.05

今のCPUはバレルシフタで1クロックじゃね

**デフォルトの名無しさん** · 2015/07/06(月) 09:26:17.06

386からは一発だな
その代わりマスクがかかる

286ま命令はあったがマイクロコード
8086はCLで回数指定以外、多ビットシフト命令が無かった

はず

**デフォルトの名無しさん** · 2015/07/06(月) 17:03:51.46

cpuの命令セットて全部アセンブラに還元されるんですか？
もしそうなら命令セットてアセンブラで作ったライブラリみたいなものですよね？

**デフォルトの名無しさん** · 2015/07/06(月) 17:18:20.33

アセンブラとCPU命令と機械語は一対一対応で見かけだけの違いだろ。
より人間よりの記法がアセンブラ。

**デフォルトの名無しさん** · 2015/07/06(月) 17:19:36.84

ライブラリ？

**デフォルトの名無しさん** · 2015/07/06(月) 18:59:39.73

アセンブラに、1語で複数インストラクションに対応する組み込み済みマクロはよくあるね。
ユーザーにとっては見かけ上機械語のニモニックと変わらん

**デフォルトの名無しさん** · 2015/07/07(火) 12:45:53.44

マイクロコードからビルドされた
ライブラリだな。

**デフォルトの名無しさん** · 2015/07/16(木) 18:53:32.86

シフト命令がサイクル数変わらずって事は
もしや乗算命令も……？

**デフォルトの名無しさん** · 2015/07/17(金) 00:15:18.58

乗算も1クロックだよ。かくして除算の遅さが際立つ。

**デフォルトの名無しさん** · 2015/07/17(金) 03:37:00.44

3くらいじゃなかったか？

**デフォルトの名無しさん** · 2015/07/20(月) 17:52:21.46

乗算回路って素朴な筆算より効率的な回路存在するの？

**デフォルトの名無しさん** · 2015/07/21(火) 08:40:49.05

効率て何？
回路規模？
速度とアルゴリズムのシンプルさなら表引きだけどな。

**デフォルトの名無しさん** · 2015/07/21(火) 12:54:25.50

表引きて何バイトの表用意するつもり？

**デフォルトの名無しさん** · 2015/07/21(火) 13:57:35.38

>>109
ニーモニックとオペコードは一対一とは限らないよ。

**デフォルトの名無しさん** · 2015/07/21(火) 23:36:30.91

>>76
http://blogs.msdn.com/b/nativeconcurrency/archive/2013/07/08/shared-memory-support-in-c-amp-introduction.aspx

**デフォルトの名無しさん** · 2015/07/22(水) 01:54:32.08

>>116
まあ筆算は筆算だけどね、boothのアルゴリズムとかwallace treeとか調べてみるといいと思うよ

**デフォルトの名無しさん** · 2015/07/29(水) 01:28:21.81

>>76は今の時点だとあたってるように思えるなあ
CPUと頻繁にデータやり取りしたり、十分長い時間計算させるのでなければオーバーヘッド大きすぎるし

**デフォルトの名無しさん** · 2015/10/01(木) 15:36:21.06

pcooがいいかboostがいいかって話もここでいいの？

**デフォルトの名無しさん** · 2015/10/01(木) 16:47:08.19

高速化手法の話でなければ、
C/C++のライブラリ総合スレ
http://peace.2ch.net/test/read.cgi/tech/1312906327/

**デフォルトの名無しさん** · 2015/10/01(木) 18:32:50.19

どもです

**デフォルトの名無しさん** · 2015/10/03(土) 22:48:54.48

>>109
嘘こけ。
アドレッシングモード一つとっても一意には対応していない。

**デフォルトの名無しさん** · 2015/10/23(金) 09:29:13.47

☆ 日本の核武装は早急に必須ですわ。☆
総務省の『憲法改正国民投票法』、でググってみてください。
日本国民の皆様方、2016年7月の『第24回参議院選挙』で、日本人の悲願である
改憲の成就が決まります。皆様方、必ず投票に自ら足を運んでください。お願い致します。

**デフォルトの名無しさん** · 2015/11/18(水) 22:46:47.01

>>116
いろいろとある
筆算方式だと桁数が倍になれば計算時間や回路規模が４倍になるけど、
３倍で済む方法もあるし、
２倍ちょっとで済む方法もある。

**デフォルトの名無しさん** · 2015/11/23(月) 15:07:59.69

>>127
「米国におしつけられた憲法」「日本人悲願の」といいつつ
米の意向による改憲だけどな
さすが米国の金で設立された米の利益代表団体自民党、国民を騙すのに躊躇ないぜ

**デフォルトの名無しさん** · 2015/11/23(月) 17:35:17.53

intelの乗算がスループットが1clock、レイテンシが3clock。
どうやったら3clockで計算が終わるん？

**デフォルトの名無しさん** · 2015/11/23(月) 17:50:28.72

むしろどうやって乗算を3clockに分割しているのかが気になる

**デフォルトの名無しさん** · 2015/11/24(火) 13:23:40.31

Load
Multiply
Store

**デフォルトの名無しさん** · 2015/11/24(火) 15:12:53.74

そこまでやるんかい

**デフォルトの名無しさん** · 2015/11/24(火) 19:32:05.64

テーブル参照で済ませてんのかな？
教えて、だんごの人！

**デフォルトの名無しさん** · 2015/11/24(火) 21:52:15.52

Load, Storeは別でしょ
乗算は
53bit x 53bit の整数乗算
106bitから53bitへの丸め
指数部分の計算
などが必要
この中で53bit x 53bitが一番時間がかかる

３つに分けるとしたらたとえば
1. 53bit x 20bit
2. 前の結果 + 53bit x 20bit
3. 前の結果 + 53bit x 13bit, 丸め, 指数計算
とか

**デフォルトの名無しさん** · 2015/11/24(火) 21:53:14.32

テーブルは割り算では使うけど、掛け算は使わないと思う

**,,・´∀｀・,,）っ-○○○** · 2015/11/25(水) 02:03:47.62

運転手が自動車のエンジンの内部構造を知る必要はない
車を動かすだけの最低限の知識さえあればいい

**デフォルトの名無しさん** · 2015/11/25(水) 04:32:17.38

内部構造を知る事による運転技術の向上の可能性を否定出来ない。 (英訳せよ

**デフォルトの名無しさん** · 2015/11/25(水) 08:50:00.26

速いレーシングドライバーやライダーというものは、エンジンの内部構造だけではなく、
フレームの特性から、タイヤマネージメント、そしてメンタルをコントロールするための心理学まで詳しい。

**デフォルトの名無しさん** · 2015/11/25(水) 11:35:26.47

そりゃメカニックに指示を出さなきゃならないからな

**デフォルトの名無しさん** · 2015/11/25(水) 16:07:40.71

>>139
ペーパーテストでリアウイングを立てる効果を問われて
スポンサーロゴがよく見えるって答えたF1ドライバーが
ワールドチャンピオンになったぞ。

**デフォルトの名無しさん** · 2015/11/25(水) 16:08:46.62

これマジ？

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

**デフォルトの名無しさん** · 2015/11/25(水) 20:25:16.25

>>141
マジか！ｗ

**デフォルトの名無しさん** · 2015/11/25(水) 23:05:14.13

頭のいい人はユーモアのセンスもあるってことか

**デフォルトの名無しさん** · 2015/11/26(木) 00:37:39.38

ぶんぶ～ん

**デフォルトの名無しさん** · 2015/11/26(木) 11:16:56.37

haswellはほんとエラッタが多くしかも不安定。

**デフォルトの名無しさん** · 2015/11/26(木) 21:49:54.17

恥well

**デフォルトの名無しさん** · 2015/11/27(金) 00:11:49.01

haswellってなーに

**デフォルトの名無しさん** · 2015/11/27(金) 00:58:51.08

電源回路の一部をCPUに乗っけてノイズ乗りまくり不安定になった馬鹿設計のCPU。

**デフォルトの名無しさん** · 2015/11/27(金) 01:32:59.31

させん　理解出来ませんw これでも工学部卒orz
暫くROMります。

**デフォルトの名無しさん** · 2015/11/29(日) 17:12:51.03

intel の主力 CPU製品の世代・バージョンを表すコード名だよ
セレロンとか Core7 とか商品名に隠れて見えにくくされてる
ちなみに現行最新は broadwell に替わってるらしい

**デフォルトの名無しさん** · 2015/11/30(月) 05:38:13.03

最新は第6世代のSkylakeだよ
Broadwellは第5世代

**デフォルトの名無しさん** · 2015/11/30(月) 06:10:56.08

みなさんHWもつおいんですね

**デフォルトの名無しさん** · 2015/11/30(月) 13:05:08.68

しかしインテルの話題ばかりですね
AMDがかわいそう

**デフォルトの名無しさん** · 2015/11/30(月) 14:57:41.28

単にAMD64が素晴らしすぎて、最適化の必要がないからです。

**デフォルトの名無しさん** · 2015/12/01(火) 09:29:42.23

素晴らしいかどうかは兎も角、最適化の必要がないのは同意。
だってみかけねぇもんw

**デフォルトの名無しさん** · 2015/12/01(火) 09:39:53.24

haswell、amd64知らないっておまえらゆとりすぎだろ、おい。
and64っていわゆるx64命令セットのことだ。AMDのCPUのことじゃない。

**デフォルトの名無しさん** · 2015/12/01(火) 13:04:48.47

AMD64って3DNowのことだが(失笑)

**デフォルトの名無しさん** · 2015/12/01(火) 13:06:30.50

そうかそうか、Intelは3DNowの後追いをしたのか
情けないな

**デフォルトの名無しさん** · 2015/12/01(火) 13:22:36.19

AMDはx86互換の64bitCPUを早い段階で提唱したのが最大の功績
MSもそれに乗っかった
Intelまかせだったら64bit環境のコンシューマへの普及が遅れていたか
満足なものにならなかった可能性がある
IntelはItaniumとかいう普通の人からしたらゴミな物を売りたかっただろうし
将来的にはIA-64に置き換えるつもりだったらしいが
未だに32bitアプリが溢れていることを考えると互換を切るのは良くなかった
一応激遅のx86エミュレーションは付いていたが
互換で食っていた会社の癖に互換を切り捨てるとは何事ぞ

**デフォルトの名無しさん** · 2015/12/01(火) 16:31:29.60

互換切っちゃいけねえのは当然かもしんないけど
未だに4bitだか8bitのCPUに由来する制限や設計の歪みを引き継ぎ続けるのもなぁ……
カウンタレジスタとしてはRCXしか使えませんとかあまりにもウンコすぎる

**デフォルトの名無しさん** · 2015/12/01(火) 17:19:11.09

そんなん先読みやら最適化の都合じゃないの？

それに互換ぶっ壊していいのなら ARM にしちゃいなよ

**デフォルトの名無しさん** · 2015/12/01(火) 20:49:07.03

64bit化の時が、唯一のx86系命令のエンコードを変えるチャンスだった
汎用レジスタは16個に増えたけど、それ以外はしょぼいまま継ぎ足し継ぎ足しのエンコード
命令が複雑すぎるし効率的じゃないし汎用整数命令が2オペランドのままだし

汎用レジスタ数増大
2SRC, 1DEST の非破壊演算
3オペランドの自由論理演算
アドレス計算用の簡易で高速な積和命令追加 (いまだLEAが重要命令って異常だろ)
乗算除算命令のレジスタ縛り削除
フラグ未使用の演算増加 or フラグの多重化

一応ちまちまは増えてるけどそんなんじゃダメ
一気に増やさないと使われないから意味がない

**デフォルトの名無しさん** · 2015/12/01(火) 21:11:09.22

一切のしがらみを解き放って、ゼロベースで命令セットを設計したら、
どれくらいの性能を叩きだせるんだろうか？

**,,・´∀｀・,,）っ-○○○** · 2015/12/01(火) 21:16:38.38

>>163の発想で出来上がったのがItanium

**デフォルトの名無しさん** · 2015/12/01(火) 21:23:08.46

メニーコア系だな
GPUとCPUとDSPの良いところ取り
GPUとCPUは区別がなくなる
デコーダーやスケジューラーは極力小さく、
演算器と入出力に大きく回路を割く

**デフォルトの名無しさん** · 2015/12/01(火) 21:26:16.98

Itaniumの失敗は、
x86を軽視した
コンパイル時最適化がCPUの進化に合わなかった
こんな感じか？

**デフォルトの名無しさん** · 2015/12/01(火) 21:27:03.93

どっちかというとマーケティング的要因の方が大きかったかと

**,,・´∀｀・,,）っ-○○○** · 2015/12/01(火) 21:28:26.40

並列化は並列化できないクリティカルパスで行き詰る
パンの製造ラインをいくら増やそうが1つのパンの一次発酵と二次発酵を同時にできないのと同じ。

**デフォルトの名無しさん** · 2015/12/01(火) 21:39:52.86

その為に非対称メニーコアとかいう考えもあるけど...
今ある重い処理の多くは並列化可能でしょ

**デフォルトの名無しさん** · 2015/12/01(火) 21:44:54.96

で団子の案は？

**デフォルトの名無しさん** · 2015/12/01(火) 21:47:11.88

skylakeでipc伸びたで

**,,・´∀｀・,,）っ-○○○** · 2015/12/01(火) 21:47:21.62

決して順序が決まってる処理を同時並列化することはできない

**デフォルトの名無しさん** · 2015/12/01(火) 21:48:08.42

>>166
Cellやﾗﾗﾋﾞの方向性かな？
いずれにせよ、プログラマがどこまでしんどい重いするかも重要やね。

**デフォルトの名無しさん** · 2015/12/01(火) 21:49:36.60

条件分岐あるからクリティカルパスも変動するから、消費電力を対価に投棄実行できなくもないよ。

**デフォルトの名無しさん** · 2015/12/01(火) 22:00:04.59

>>172
超微妙にな
VADDPDはなぜかレイテンシーが増えたけど

**デフォルトの名無しさん** · 2015/12/01(火) 22:01:37.59

>>173
順序が決まっている処理は順序が決まっている
あたりまえじゃん

**,,・´∀｀・,,）っ-○○○** · 2015/12/01(火) 22:21:53.65

ハードの設計の努力を知らない下衆が偉そうに語ることは何一つないのよ
与えられたものをうまく使う方法だけ考えればいい

**デフォルトの名無しさん** · 2015/12/01(火) 22:22:38.64

クリティカルパスってそんな問題になるかなぁ。
コア数が１万とかになったら大問題かもしれんが、
コア数４とかじゃあんまり問題に成らなくね。

**デフォルトの名無しさん** · 2015/12/01(火) 22:27:59.76

最近の事情は良く知らないんだけど
IntelのCPUでGPU内臓じゃないのってあるの？
サーバー用じゃなく

**,,・´∀｀・,,）っ-○○○** · 2015/12/01(火) 22:30:35.15

>>180
http://ark.intel.com/ja/compare/82930,82931,82932

**デフォルトの名無しさん** · 2015/12/01(火) 22:57:39.27

ちょっと一般向けとは言いがたいね
しかもHaswellだし
個人的にGPUはグラボ刺すからCPUに内蔵してほしくないんだよなぁ
GPU無しで、その分値段を落としたモデルがほしい

**デフォルトの名無しさん** · 2015/12/01(火) 23:21:24.20

ちなみに今どきのGPU内臓CPUの、CPU対GPUのダイ比ってどれぐらいなんだろう
http://pc.watch.impress.co.jp/img/pcw/docs/726/778/html/05.jpg.html
を見る限り左のほうにあるの、全部GPU関係でしょ
必要ないんだけどなぁ

**デフォルトの名無しさん** · 2015/12/02(水) 00:01:13.31

>>178
一番偉そうな下衆がなんか書いてるwww

**デフォルトの名無しさん** · 2015/12/02(水) 00:34:39.84

GPUユニットは並列演算に利用できるのにそれが必要ない用途ねぇ。
Xeonでいいはずなのにキャッシュもメモリ帯域もコア数も必要ないってことですよねぇ。
結局、内臓GPU必要ないってことはゲーム用途でしょうねぇ。

**デフォルトの名無しさん** · 2015/12/02(水) 04:57:08.43

>>179
クリティカルパスってコア数が少ない方がループ回数が増えるから影響が大きくなると思うけどな
クリティカルセクションと勘違いしてない？

この話の流れでクリティカルパスがでてくるのがおかしいんだよ
アウトオブオーダにしろ、VLIWやメイニーコアにしろ、クリティカルパスの問題は一緒
違いがあるのは並列化の粒度でしょ
小さい粒度のはOoO、大きなのはメイニーコアが適していて、静的な並列化は中途半端だったということ

**,,・´∀｀・,,）っ-○○○** · 2015/12/02(水) 06:15:06.45

ディスパッチ＆リダクションのコストを軽視してるな

**,,・´∀｀・,,）っ-○○○** · 2015/12/02(水) 06:21:53.98

同じコア性能なら多いほうが多い、それは当たり前だ
しかし低性能なコアを複数並べれば高機能なコアより常に速いというのは幻想

KNCのボトルネックがまさにイニシャル処理で、KNC側でやると遅いから大体ホスト側にやらせることになる

**デフォルトの名無しさん** · 2015/12/02(水) 12:21:50.26

また的外れなこと言ってる
団子って周りから人の話聞いてないって言われないか？

OoOはCPU内でディスパッチやリダクションしてる為に熱的に限界を迎えて
性能があげられなくなったからメイニーコアやGPUの方向性が出てきたんでしょ
用途によって向き不向きがあるから棲み分けするようになって、今はその匙加減を
調整してる状況なんだろうな
CELLみたいにバランスの悪いのは結局は残れないってことなんだろうね

**デフォルトの名無しさん** · 2015/12/02(水) 12:27:00.90

リダクションは変だったな、リタイアメントだわ

**デフォルトの名無しさん** · 2015/12/02(水) 14:17:02.16

GPUユニットより柔軟性の高いSIMD演算器を高速なローカルストレージと一緒にCPUに内蔵させたい
GPGPU無駄多すぎ

**デフォルトの名無しさん** · 2015/12/02(水) 15:49:04.71

個人的にはSIMDが1024-wayとかになったら面白いんだが
サーバー用としてはメニーコアの方が相性が良いので
そういう流れにはならないだろうが

**デフォルトの名無しさん** · 2015/12/02(水) 19:05:39.75

ベクトルコンピューターがそんな感じだった
ベクトル化出来ない処理は急激に遅くなるから、
今はコア数とバランス良くって方向になってる

AVXが8way
AVX512が16way
Geforceが32way
Radeonが64way
最高でも64wayあたりに落ち着くのでは？

**デフォルトの名無しさん** · 2015/12/02(水) 19:13:57.66

>>191
SIMD、柔軟性高いかなぁ？
データの並びとか気を付けないといけないし、プレディケーションもプログラマが書かないとできない。
非アライメントのペナルティが軽減されたのは有難いけど、
せめてプレディケーションくらいはGPUのようにHWでサポートしてほしいなぁ。

**デフォルトの名無しさん** · 2015/12/02(水) 20:17:39.20

コストの掛かるOoOでもSIMDにすれば相対的にコストが下がるというのもあるし
マスク演算ができるようになればプリディケードとブランチをプログラマが選べるようになる
インテルが目指してる方向は手堅いものだと思うな

**デフォルトの名無しさん** · 2015/12/02(水) 20:53:25.97

早く1024bit SIMD実装してほしいぜ。
囲碁の処理が速くなりそう。
碁盤は19 x 19だから512bitだと微妙なんだよな。

**デフォルトの名無しさん** · 2015/12/02(水) 21:01:41.94

ハードウェアベクタをあまり長くしても大半のアプリケーションで無駄が出るだけだろ。
GPUのやりかたが落としどころとしてベストだと思うがな。

**デフォルトの名無しさん** · 2015/12/02(水) 21:24:30.33

ここはC++の高速手法でよろしいのですよね・・・

**デフォルトの名無しさん** · 2015/12/02(水) 21:29:46.57

いや、C++に限らないんじゃない？
スレタイの【C++】や【SSE】ってのは主な手段であって、
GPUやFPGAだって立派な高速化手段だ。

**デフォルトの名無しさん** · 2015/12/02(水) 21:52:10.30

>>197
GPUで速くなる処理はベクタ長アップでも確実に速くなるよ