2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

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

1 :デフォルトの名無しさん:2015/05/21(木) 01:53:58.15 ID:ZhKmhhGS
C++やインラインアセンブラ、SSEなどによる高速化の手法
について語りましょう。

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

2 :デフォルトの名無しさん:2015/05/21(木) 01:55:23.61 ID:taYfOZ7g
>>1乙。

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

3 :デフォルトの名無しさん:2015/05/21(木) 02:00:37.40 ID:ZhKmhhGS
1スレ10年も掛かったのかwww

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

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

4 :デフォルトの名無しさん:2015/05/21(木) 02:02:04.95 ID:ZhKmhhGS
それとこれテンプレに入れるか
次スレ今度いつになるか分からないしなww

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

5 :デフォルトの名無しさん:2015/05/21(木) 02:07:04.14 ID:ZhKmhhGS
あと面白そうなところはここか

https://github.com/herumi/x86opti

6 :デフォルトの名無しさん:2015/05/21(木) 03:57:50.11 ID:OGLmDH5r
10年wwww

7 :デフォルトの名無しさん:2015/05/21(木) 13:51:48.66 ID:Jx6BJl3J
マルチコアによるマルチスレッド化の方がずっと楽だから、難しいSIMDプログラミングはいまいち
はやらないのかな

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

9 :デフォルトの名無しさん:2015/05/21(木) 19:30:58.21 ID:Ao5A+4wF
SIMD化はコンパイラに任せるのが得策。
アルゴリズム改善がどこもできなくなってからでいい。

10 :デフォルトの名無しさん:2015/05/21(木) 20:29:21.14 ID:taYfOZ7g
前スレの8bit単位の乗算とか、そういう頻繁にありそうなケースに対応した命令を用意してくれないと、
間口広がんないよ・・・。

11 :デフォルトの名無しさん:2015/05/21(木) 20:45:29.77 ID:2/488D5d
8/16bitぐらいのIndex範囲でテーブル引きしれくれる命令がほしいわ

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

12 :デフォルトの名無しさん:2015/05/22(金) 01:51:48.18 ID:pqX01hMi
命令に対応してたってそれを実行するユニットがそれ相応に強化されてなければ大して効果ないよ

13 :デフォルトの名無しさん:2015/05/23(土) 18:03:12.07 ID:1SFlVJvM
並列計算が実装されてないか、使っても遅いとき、通常の演算で並列できないか?

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

14 :デフォルトの名無しさん:2015/05/23(土) 18:08:24.46 ID:1SFlVJvM
途中送信した。
上のXの項は、t a0 + s a1
上のX^3の項は、t a2 + s a3

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

15 :デフォルトの名無しさん:2015/05/23(土) 19:52:22.42 ID:1SFlVJvM
>>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 :デフォルトの名無しさん:2015/05/27(水) 11:09:42.07 ID:f/0uemgN
前スレ終わりごろのビットマップ合成の話だが、結果的にはスカラ版と比較して
5倍程度に収まっていたが、初期はスカラ版より遅い結果しか出せていなかった。
スカラ版と等速なら話はわかるが、
なぜ遅くなるのか?
俺も似たようなこと遭遇した記憶はあるが
詳細が思い出せない。

17 :デフォルトの名無しさん:2015/05/27(水) 13:45:50.89 ID:2yaRNWB+
SIMD関連はまず命令の実行に都合のいいようにデータを作成するのと
結果を取り出すのに時間がかかるからじゃね?
それとSSEレジスタは128bitなので1処理当たり32bit使うと4並列にしかならない
AVX/AVX2なら256bitなのでこちらの方が速度が上がると思う

18 :デフォルトの名無しさん:2015/05/27(水) 15:22:12.59 ID:TYkQbksz
>>16
構造体へのコピーをスカラで何倍もの時間かけてやってたから
本体処理が4秒が1秒に縮まったところでセットアップに5秒かかってたら意味がない

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

19 :デフォルトの名無しさん:2015/05/27(水) 18:10:04.45 ID:1+NR3ImF
つまりSIMDレジスタで計算する為に
スカラ以上に命令を使った為
遅くなったということか。
前スレの968では見直ししたが2倍ほど遅いと言っていた。
本来4倍になるはずが1/2倍、
8倍も遅くなるなんてありえるか?
根本的に何か問題があるとしか
思えん。

20 :デフォルトの名無しさん:2015/05/27(水) 19:09:25.21 ID:VZ6+fhUn
あんなのソースコード見ればボトルネックがどこにあるか一発でわかるだろ
見ただけでわからんやつは向いてないよ

21 :デフォルトの名無しさん:2015/05/27(水) 19:11:41.34 ID:VZ6+fhUn
「ハッカーのたのしみ」とかの良著をよく読むことをすすめるよ
並列化アルゴリズムに理解のないやつがいきなりSSEやAVX使っても不幸にしかならない

22 :デフォルトの名無しさん:2015/05/27(水) 19:52:40.39 ID:21LcoVTJ
然しものSIMDも、まったくオーバーヘッドがないわけじゃぁない。
SIMDに演算させるためのデータ構造整えなんかの命令分がオーバーヘッドになる。
これを最小に抑えつつ、SIMDの並列演算性能を活かすのが腕の見せ所よ。

23 :デフォルトの名無しさん:2015/05/29(金) 18:33:22.93 ID:5gPBcsmJ
メモリクソ余ってんだから最初からSIMD前提なデータ構造強制できりゃいいのになぁ

24 :デフォルトの名無しさん:2015/06/08(月) 22:06:48.16 ID:XUgdS8pG
すいません。以下のようなことがやりたいのですがどうするのが一番いいですか。

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

25 :デフォルトの名無しさん:2015/06/08(月) 22:12:29.64 ID:XUgdS8pG
すいません。途中で書き込みました。
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 :,,・´∀`・,,)っ-○○○:2015/06/08(月) 22:54:29.21 ID:GQ7FFrMa
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 :,,・´∀`・,,)っ-○○○:2015/06/08(月) 22:55:00.93 ID:GQ7FFrMa
ミスった
__m256i x = _mm256_loadu_si256((__m256i*)&a[1]);

28 :デフォルトの名無しさん:2015/06/08(月) 23:02:02.79 ID:XUgdS8pG
>>__m256i x = _mm256_loadu_si256((__m256i*)a[1])
領域外(a[16])を参照してるような…
ゴミが入るだけだから気にしなくていいってことですか?

29 :デフォルトの名無しさん:2015/06/08(月) 23:58:10.30 ID:XUgdS8pG
うごいてるっぽいので気にしないことにします。
ありがとうございました。

30 :,,・´∀`・,,)っ-○○○:2015/06/09(火) 00:11:30.65 ID:2cA2PMHO
ページ境界跨がなきゃ平気

31 :25:2015/06/09(火) 00:47:54.26 ID:8QWNG3PG
>>ページ境界跨がなきゃ平気
跨ぐとどうなるんでしょうか。
突然プログラムがあぼーんすることも覚悟しなきゃいけないってことですか?

32 :デフォルトの名無しさん:2015/06/09(火) 02:10:05.37 ID:btE8Rt5a
アクセス違反例外で停止するわな

33 :デフォルトの名無しさん:2015/06/09(火) 02:26:12.65 ID:+xTmfGgc
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 :デフォルトの名無しさん:2015/06/09(火) 02:26:58.58 ID:+xTmfGgc
おっと間違えた

__attribute__((aligned(32)))

35 :デフォルトの名無しさん:2015/06/09(火) 08:01:24.58 ID:uvrBn2pL
別にアライメントの話じゃないし。
つうか領域外読み込んでも
落ちないからOKとか
それはないから

36 :,,・´∀`・,,)っ-○○○:2015/06/09(火) 10:18:10.60 ID:hpY+QnAE
上下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 :,,・´∀`・,,)っ-○○○:2015/06/09(火) 10:19:22.92 ID:hpY+QnAE
 __m128i u = _mm256_extractf128_si256(x, 1);

みすった

38 :25:2015/06/09(火) 21:40:12.66 ID:8QWNG3PG
16 x 16 だと結構オーバヘッド覚悟しなきゃいけないみたいですね。
11 x 11 なら128ビットに納まるから上下左右1ビットシフト高速にできますかね?

39 :,,・´∀`・,,)っ-○○○:2015/06/09(火) 21:47:54.51 ID:X9YqiuVE
ビットボードでも作ってるの?

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

40 :デフォルトの名無しさん:2015/06/09(火) 21:51:07.26 ID:8QWNG3PG
11 x 11 だと右端と左端がつながっちゃうか。

41 :デフォルトの名無しさん:2015/06/09(火) 21:55:17.24 ID:8QWNG3PG
>>39
はい、まさにビットボードです。
9 x 9 あれば囲碁9路盤が作れます。
やっぱ2のべき乗ですかね〜。

42 :デフォルトの名無しさん:2015/06/09(火) 22:00:22.26 ID:uvrBn2pL
SIMDとか並列プログラムは
各要素間の関連が薄けりゃ薄いほど良い
相関ゼロなら100%の性能が出せるが
逆なら劣化する。
要はお前のプランはSIMD向きじゃねえんだよ。
スカラで組めカス。

43 :デフォルトの名無しさん:2015/06/09(火) 22:11:17.04 ID:8QWNG3PG
なんでよ、ビットボードにSIMD使おうと考えるのは自然だろ。

44 :,,・´∀`・,,)っ-○○○:2015/06/09(火) 22:34:23.52 ID:ftbXeVKR
上下128ビットの入れ替えが面倒なら、1レジスタで1ボードじゃなくて2レジスタで2ボードみたいな割り当てもアリかな

45 :デフォルトの名無しさん:2015/06/11(木) 06:33:32.55 ID:PTMql3il
19x19は?

46 :デフォルトの名無しさん:2015/06/11(木) 17:55:12.67 ID:6lVnkCXZ
1レジスタに1ボードのらないで2レジスタに2ボードのる状況が想像できない。

47 :,,・´∀`・,,)っ-○○○:2015/06/11(木) 21:11:39.78 ID:ucI+50Qq
me too

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

48 :,,・´∀`・,,)っ-○○○:2015/06/11(木) 21:17:03.34 ID:ucI+50Qq
64ビットごとに19x3という割り当てもありか

49 :デフォルトの名無しさん:2015/06/13(土) 04:02:16.52 ID:0MXVYW8Q
さて、そろそろ団子が実験結果を公開してくれる頃だと思うんだが……
ソース書けた?

50 :,,・´∀`・,,)っ-○○○:2015/06/13(土) 06:50:53.32 ID:eCUflYbk
俺囲碁のルールすら知らんが?

51 :デフォルトの名無しさん:2015/06/22(月) 09:21:43.06 ID:0p5/VSpX
結局SSEとかの機械語でやる以外にC++には高速化の手段がないの?(´・ω・`)
後、変なclassを使わないとか?(´・ω・`)

52 :デフォルトの名無しさん:2015/06/22(月) 16:45:31.61 ID:BEzC3Nfs
クラスで遅くなるとか迷信でしょ

53 :デフォルトの名無しさん:2015/06/22(月) 16:51:45.79 ID:cpn0Yuio
今はSIMDがあるから
かろうじてC++使ってるけど
他で行けるようになったら
捨てると思う

54 :,,・´∀`・,,)っ-○○○:2015/06/22(月) 16:56:25.34 ID:h2li5DGU
クラスを使うから遅くなるんじゃなくて、動的なポリモーフィズムを実現するための仮想関数テーブルや
あるいは過剰にコンストラクタ呼び出しで遅くなる。

55 :デフォルトの名無しさん:2015/06/22(月) 19:26:36.11 ID:468RGWDu
>>53
C++と同程度の速度がでる言語って何よ?

56 :デフォルトの名無しさん:2015/06/22(月) 19:59:05.05 ID:cpn0Yuio
いやーそんなん無いけどさー
己が納得出来れば良い訳よ
vector4クラスとかあって
最適化コンパイルでSIMD使いますよ〜
で良い。所詮趣味だし俺はそれで乗り換え出来る。
今はfortranやC++以外にはそれすらも無いからな

57 :,,・´∀`・,,)っ-○○○:2015/06/22(月) 20:04:38.95 ID:L2Qxnu5O
過度なオブジェクト指向(笑)やめればC++でもアセンブラに迫る高効率のコード書けますよ

58 :デフォルトの名無しさん:2015/06/22(月) 21:19:49.22 ID:468RGWDu
最近はCとアセンブラを比較することも少なくなったろうな。
数学ライブラリなんかはまだアセンブラで書いてんのかねぇ。

59 :デフォルトの名無しさん:2015/06/22(月) 23:07:11.77 ID:R1+ZwB88
>>57
おっさんおっさん、それってCとして使うってのとほぼ同じ意味なんじゃ……?

60 :,,・´∀`・,,)っ-○○○:2015/06/22(月) 23:15:07.42 ID:OAaA5v1W
演算子オーバーロードやテンプレートがCにあるならそうだね
どの程度の抽象化までならオーバーヘッドが生じないかはdvec.hあたりのIntel謹製クラスライブラリ見ればわかるでしょ

61 :マ○コデラックス:2015/06/23(火) 23:58:04.32 ID:bwjeXC/X
スレ立てるまででもない質問じゃない質問ってどんなの?

62 :デフォルトの名無しさん:2015/06/26(金) 04:43:42.68 ID:1ST1aZRQ
え?そこらへん使ってもアセンブラに迫る高効率のコード吐き出してくれるの?

63 :デフォルトの名無しさん:2015/06/26(金) 09:20:27.34 ID:gBS6mhz7
コンパイラ舐めんなw

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

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

65 :デフォルトの名無しさん:2015/06/26(金) 18:56:22.95 ID:1eqFY8pT
>this->func() を func( this ) にするとか

まじで?

66 :,,・´∀`・,,)っ-○○○:2015/06/26(金) 23:08:38.05 ID:Tf/lkRBh
あとはMSVCだとthisポインタをECXで渡すけどSSE*ってECXを暗黙にdestinationとして扱う命令あるじゃん

67 :デフォルトの名無しさん:2015/07/04(土) 19:14:20.94 ID:g1Tiw5j6
みんgwでsse2つかってみたけど全然早くならないorz
何か間違ってんのかな?

68 :,,・´∀`・,,)っ-○○○:2015/07/04(土) 20:06:47.25 ID:4GC84Q0p
github晒しておくと構いたがりがどこがおかしいのか指摘してくれるよ

69 :デフォルトの名無しさん:2015/07/04(土) 20:23:55.16 ID:g1Tiw5j6
githubってよく知らないんだよなぁ。
イケてるギークはつかってるらしいが。
これを機にやってみるか…

70 : ◆kXDiHQuNQ2 :2015/07/04(土) 22:33:31.72 ID:g1Tiw5j6
http://www.age2.tv/rd05/src/up9736.zip.html

githubはとりあえず置いといて、ソースうpします。
物は囲連星というゲームの9路盤のAIです。

makefileが入ってるのでbenchmark.exeをmakeしてみてください。
うちのPC(core i7 4790)で40秒くらいで終わるベンチマークができます。
ベンチの内容はAIが3手プレイします。

SSE2で最適化したいクラスはPointSetというクラスで、
128bitつかって 10 x 10 のビットボードを実装しています。

SSE2化してみましたが速くなりませんでした。

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

71 :デフォルトの名無しさん:2015/07/04(土) 22:42:47.73 ID:YeWNQkLW
SSEって最適化できてもせいぜい20%アップ程度の気がするな。
アルゴリズムの見直しとか、CPU演算以外とかはやりきってるか?

72 :デフォルトの名無しさん:2015/07/04(土) 22:49:03.16 ID:g1Tiw5j6
ちなみにmakefileは依存関係全然考慮してないので毎回クリーンしてくださいw
コンパイラは64bit MinGWです。

73 :デフォルトの名無しさん:2015/07/04(土) 22:51:51.53 ID:g1Tiw5j6
オッとリロードしてなかった。
>>71
アルゴリズム見直しで速くなるのが一番いいんですけどね〜
なかなかアイディアが湧かないのでとりあえず手っ取り早いSSEを試してみたいです。

74 :デフォルトの名無しさん:2015/07/04(土) 23:13:48.96 ID:+CPi2s1F
>>73
i7 4790ならAVX2やiGPGPUで速くしたほうがいいんじゃないのか?
データ並列に適していないのにSIMDにしてもたいして速くならないと思うけど
いまの適している?

75 :デフォルトの名無しさん:2015/07/04(土) 23:23:18.20 ID:g1Tiw5j6
128bitで一つのビットボードになっていてもろandとかorとかandnotとかさせるので
SSE2で速くなるかなと思ったんですが。
AVX2は256bitですよね?どうやって適応させるか難しいです。
iGPGPUは使い方しらないorz

76 :デフォルトの名無しさん:2015/07/04(土) 23:28:34.72 ID:Ika70OGI
iGPGPUとか全然ダメ。
並列処理向きな処理でも激遅。
最低でもメモリ空間共有がサポートされなきゃゴミ。

77 :デフォルトの名無しさん:2015/07/05(日) 01:38:21.45 ID:U8xf2vl9
>>70はピンポイントでSSE化したい所、出来そうな所だけピックアップしてくれよ。
これでは解析が手間。

78 :,,・´∀`・,,)っ-○○○:2015/07/05(日) 06:57:39.74 ID:5Fixj9dP
ボトルネックがピンポイントで分かってないからこそ遅いのでは?

79 : ◆kXDiHQuNQ2 :2015/07/05(日) 08:14:07.41 ID:rj88vDKP
>>77
SSE化できそうなところはPointSetというクラスですが、
じつはもうSSE化してます。
でも速くなんなかった。

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

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

80 :,,・´∀`・,,)っ-○○○:2015/07/05(日) 08:44:17.99 ID:5Fixj9dP
関数ごとのプロファイルとってみて総実行時間を見てみるといいよ
並列化できない(と思ってる)ところが最大のボトルネックになってるなら他をいじってもどうしようもない

81 :デフォルトの名無しさん:2015/07/05(日) 09:42:48.10 ID:pEwkWnHA
最適化ってのはボトルネックになってるところ測定してからやるもんだぞ

82 :デフォルトの名無しさん:2015/07/05(日) 10:22:22.43 ID:rj88vDKP
なんか性能測りたい関数がインライン展開されちゃって測れないっぽいT△T

83 :デフォルトの名無しさん:2015/07/05(日) 10:47:06.39 ID:7niimHYF
だから計測しろって

84 :デフォルトの名無しさん:2015/07/05(日) 10:50:19.25 ID:rj88vDKP
ビットフィールドの立ってるビット数える関数をSSE4.2のpopcnt使ったらえらい速くなったんだが?

85 :デフォルトの名無しさん:2015/07/05(日) 10:59:07.88 ID:rj88vDKP
ちょっと出かけます。
夕方には帰ってくる。

86 :デフォルトの名無しさん:2015/07/05(日) 11:07:32.33 ID:7niimHYF
気を付けてな

87 :デフォルトの名無しさん:2015/07/05(日) 11:49:59.66 ID:pEwkWnHA
ちょっと伺いたいんですがavxまでで8bit(1byte)の中で上半分、下半分を取り出すのはありますか?
avx2までいくとpextというmaskをとった部分のビットだけ抽出するのはあるようなんですが・・・

88 :デフォルトの名無しさん:2015/07/05(日) 13:52:49.93 ID:TGTnUn4r
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 :デフォルトの名無しさん:2015/07/05(日) 13:55:24.70 ID:pEwkWnHA
>>88
なるほど!ありがとうございます

90 :デフォルトの名無しさん:2015/07/05(日) 14:06:01.88 ID:3mytObGh
どういう並びにしたいの?
こういう意味?
http://stackoverflow.com/questions/12795462/how-do-i-extract-32-x-4-bit-from-16-x-8-bit-m128i-value

91 :デフォルトの名無しさん:2015/07/05(日) 14:43:20.51 ID:pEwkWnHA
>>90
ちょうどこんな感じです!
このソースみたいにlowerとupperを取り出して返す関数つくろうと思ってました

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

92 :,,・´∀`・,,)っ-○○○:2015/07/05(日) 15:10:55.88 ID:5Fixj9dP
え?

movzx eax, al
shr eax, 4

じゃいかんのか?

93 :デフォルトの名無しさん:2015/07/05(日) 15:14:44.70 ID:IoTdVT02
どうしてもSIMD使いたいんだとさ
クロック数がかえって増えようとも

94 :デフォルトの名無しさん:2015/07/05(日) 16:55:23.92 ID:pEwkWnHA
いえアセンブリがわからないだけです!
>>92でいけるのならやってみます!ありがとうございます!

95 :デフォルトの名無しさん:2015/07/05(日) 17:09:15.78 ID:rj88vDKP
gprofの結果ビットボードを座標のベクタに変換する関数PointSet::toVector()が時間かかってることが分かった。
すまん、ちょっと飯食ってくる。

96 :デフォルトの名無しさん:2015/07/05(日) 17:14:58.64 ID:7niimHYF
大概は思わぬところでサイクルを食ってるもんだ。
食うのは飯だけにしたいものだな。

97 :デフォルトの名無しさん:2015/07/05(日) 19:12:24.15 ID:rj88vDKP
PointSet::toVector()は一回最適化試みた箇所なんだよなぁ
正直これ以上アイディアうかばん。

98 :デフォルトの名無しさん:2015/07/05(日) 19:48:59.00 ID:U8xf2vl9
なにをしてるか知らないがここが時間食ってる。
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 :デフォルトの名無しさん:2015/07/05(日) 19:54:28.58 ID:U8xf2vl9
あとここも。
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 :デフォルトの名無しさん:2015/07/05(日) 19:58:51.19 ID:13erbQHH
立ってるビット数が多いときはその数え方だと時間喰いそう

101 :デフォルトの名無しさん:2015/07/05(日) 20:02:29.73 ID:rj88vDKP
>>98
レスありがとうございます。
そこはビットボードのビットが立ってる数を数えています。
SSE4.2のpopcntに置き換えたら大分速くなりました。

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

102 :,,・´∀`・,,)っ-○○○:2015/07/05(日) 22:27:19.60 ID:HlvO5/Ro
ちなみに>>92
(unsigned char)n >> 4
でいける

103 :デフォルトの名無しさん:2015/07/05(日) 23:55:30.55 ID:pEwkWnHA
>>102
なるほど!
ちなみにシフト操作て5bitシフトならCPUのサイクル数5倍になるとかあるんですか?

104 :,,・´∀`・,,)っ-○○○:2015/07/06(月) 00:06:48.57 ID:MmNHQVlS
8ビット時代じゃねそれ
別にシフトの変量でサイクル数は変わらんよ

105 :デフォルトの名無しさん:2015/07/06(月) 00:08:37.50 ID:obJwiAn/
>>104
ありがとうございます
では積極的に使っていきます!

106 :デフォルトの名無しさん:2015/07/06(月) 00:15:26.05 ID:1z10P7tP
今のCPUはバレルシフタで1クロックじゃね

107 :デフォルトの名無しさん:2015/07/06(月) 09:26:17.06 ID:9h3CM3fP
386からは一発だな
その代わりマスクがかかる

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

はず

108 :デフォルトの名無しさん:2015/07/06(月) 17:03:51.46 ID:obJwiAn/
cpuの命令セットて全部アセンブラに還元されるんですか?
もしそうなら命令セットてアセンブラで作ったライブラリみたいなものですよね?

109 :デフォルトの名無しさん:2015/07/06(月) 17:18:20.33 ID:hLGIY9Ls
アセンブラとCPU命令と機械語は一対一対応で見かけだけの違いだろ。
より人間よりの記法がアセンブラ。

110 :デフォルトの名無しさん:2015/07/06(月) 17:19:36.84 ID:g1ABbiM2
ライブラリ?

111 :デフォルトの名無しさん:2015/07/06(月) 18:59:39.73 ID:K/ajJWQg
アセンブラに、1語で複数インストラクションに対応する組み込み済みマクロはよくあるね。
ユーザーにとっては見かけ上機械語のニモニックと変わらん

112 :デフォルトの名無しさん:2015/07/07(火) 12:45:53.44 ID:cmwJTquu
マイクロコードからビルドされた
ライブラリだな。

113 :デフォルトの名無しさん:2015/07/16(木) 18:53:32.86 ID:l6l+0TT5
シフト命令がサイクル数変わらずって事は
もしや乗算命令も……?

114 :デフォルトの名無しさん:2015/07/17(金) 00:15:18.58 ID:c113lVsF
乗算も1クロックだよ。かくして除算の遅さが際立つ。

115 :デフォルトの名無しさん:2015/07/17(金) 03:37:00.44 ID:Gq3JBEl3
3くらいじゃなかったか?

116 :デフォルトの名無しさん:2015/07/20(月) 17:52:21.46 ID:rBoKIpMh
乗算回路って素朴な筆算より効率的な回路存在するの?

117 :デフォルトの名無しさん:2015/07/21(火) 08:40:49.05 ID:JVfLP5Iv
効率て何?
回路規模?
速度とアルゴリズムのシンプルさなら表引きだけどな。

118 :デフォルトの名無しさん:2015/07/21(火) 12:54:25.50 ID:KUd+SBCt
表引きて何バイトの表用意するつもり?

119 :デフォルトの名無しさん:2015/07/21(火) 13:57:35.38 ID:tQ/auOKg
>>109
ニーモニックとオペコードは一対一とは限らないよ。

120 :デフォルトの名無しさん:2015/07/21(火) 23:36:30.91 ID:cKSGyEK/
>>76
http://blogs.msdn.com/b/nativeconcurrency/archive/2013/07/08/shared-memory-support-in-c-amp-introduction.aspx

121 :デフォルトの名無しさん:2015/07/22(水) 01:54:32.08 ID:Vve5AGCV
>>116
まあ筆算は筆算だけどね、boothのアルゴリズムとかwallace treeとか調べてみるといいと思うよ

122 :デフォルトの名無しさん:2015/07/29(水) 01:28:21.81 ID:OiAbEds4
>>76は今の時点だとあたってるように思えるなあ
CPUと頻繁にデータやり取りしたり、十分長い時間計算させるのでなければオーバーヘッド大きすぎるし

123 :デフォルトの名無しさん:2015/10/01(木) 15:36:21.06 ID:X8BXmh6N
pcooがいいかboostがいいかって話もここでいいの?

124 :デフォルトの名無しさん:2015/10/01(木) 16:47:08.19 ID:l3udI6g3
高速化手法の話でなければ、
C/C++のライブラリ総合スレ
http://peace.2ch.net/test/read.cgi/tech/1312906327/

125 :デフォルトの名無しさん:2015/10/01(木) 18:32:50.19 ID:X8BXmh6N
どもです

126 :デフォルトの名無しさん:2015/10/03(土) 22:48:54.48 ID:QjNm5BqA
>>109
嘘こけ。
アドレッシングモード一つとっても一意には対応していない。

127 :デフォルトの名無しさん:2015/10/23(金) 09:29:13.47 ID:I0uni5nx
☆ 日本の核武装は早急に必須ですわ。☆
総務省の『憲法改正国民投票法』、でググってみてください。
日本国民の皆様方、2016年7月の『第24回 参議院選挙』で、日本人の悲願である
改憲の成就が決まります。皆様方、必ず投票に自ら足を運んでください。お願い致します。

128 :デフォルトの名無しさん:2015/11/18(水) 22:46:47.01 ID:LC5LQUuD
>>116
いろいろとある
筆算方式だと桁数が倍になれば計算時間や回路規模が4倍になるけど、
3倍で済む方法もあるし、
2倍ちょっとで済む方法もある。

129 :デフォルトの名無しさん:2015/11/23(月) 15:07:59.69 ID:ZNmYnLez
>>127
「米国におしつけられた憲法」「日本人悲願の」といいつつ
米の意向による改憲だけどな
さすが米国の金で設立された米の利益代表団体自民党、国民を騙すのに躊躇ないぜ

130 :デフォルトの名無しさん:2015/11/23(月) 17:35:17.53 ID:OK+rBFmG
intelの乗算がスループットが1clock、レイテンシが3clock。
どうやったら3clockで計算が終わるん?

131 :デフォルトの名無しさん:2015/11/23(月) 17:50:28.72 ID:+Ddm9172
むしろどうやって乗算を3clockに分割しているのかが気になる

132 :デフォルトの名無しさん:2015/11/24(火) 13:23:40.31 ID:GksIIF6P
Load
Multiply
Store

133 :デフォルトの名無しさん:2015/11/24(火) 15:12:53.74 ID:iQw5GwIi
そこまでやるんかい

134 :デフォルトの名無しさん:2015/11/24(火) 19:32:05.64 ID:4kZfiltG
テーブル参照で済ませてんのかな?
教えて、だんごの人!

135 :デフォルトの名無しさん:2015/11/24(火) 21:52:15.52 ID:VivS0v9A
Load, Storeは別でしょ
乗算は
53bit x 53bit の整数乗算
106bitから53bitへの丸め
指数部分の計算
などが必要
この中で53bit x 53bitが一番時間がかかる

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

136 :デフォルトの名無しさん:2015/11/24(火) 21:53:14.32 ID:VivS0v9A
テーブルは割り算では使うけど、掛け算は使わないと思う

137 :,,・´∀`・,,)っ-○○○:2015/11/25(水) 02:03:47.62 ID:45GjjvYt
運転手が自動車のエンジンの内部構造を知る必要はない
車を動かすだけの最低限の知識さえあればいい

138 :デフォルトの名無しさん:2015/11/25(水) 04:32:17.38 ID:eJijZLoL
内部構造を知る事による運転技術の向上の可能性を否定出来ない。 (英訳せよ

139 :デフォルトの名無しさん:2015/11/25(水) 08:50:00.26 ID:s9hTLLjK
速いレーシングドライバーやライダーというものは、エンジンの内部構造だけではなく、
フレームの特性から、タイヤマネージメント、そしてメンタルをコントロールするための心理学まで詳しい。

140 :デフォルトの名無しさん:2015/11/25(水) 11:35:26.47 ID:Sra0FKsR
そりゃメカニックに指示を出さなきゃならないからな

141 :デフォルトの名無しさん:2015/11/25(水) 16:07:40.71 ID:9VrR2D9e
>>139
ペーパーテストでリアウイングを立てる効果を問われて
スポンサーロゴがよく見えるって答えたF1ドライバーが
ワールドチャンピオンになったぞ。

142 :デフォルトの名無しさん:2015/11/25(水) 16:08:46.62 ID:rHMnfdo0
これマジ?

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 :デフォルトの名無しさん:2015/11/25(水) 20:25:16.25 ID:pv6cEe5k
>>141
マジか!w

144 :デフォルトの名無しさん:2015/11/25(水) 23:05:14.13 ID:6PwtIsKT
頭のいい人はユーモアのセンスもあるってことか

145 :デフォルトの名無しさん:2015/11/26(木) 00:37:39.38 ID:4Zv1RZyd
ぶんぶ〜ん

146 :デフォルトの名無しさん:2015/11/26(木) 11:16:56.37 ID:anPORYOg
haswellはほんとエラッタが多くしかも不安定。

147 :デフォルトの名無しさん:2015/11/26(木) 21:49:54.17 ID:FNrtCodv
恥well

148 :デフォルトの名無しさん:2015/11/27(金) 00:11:49.01 ID:k1otT5p2
haswellってなーに

149 :デフォルトの名無しさん:2015/11/27(金) 00:58:51.08 ID:B/NYVAdM
電源回路の一部をCPUに乗っけてノイズ乗りまくり不安定になった馬鹿設計のCPU。

150 :デフォルトの名無しさん:2015/11/27(金) 01:32:59.31 ID:k1otT5p2
させん 理解出来ませんw これでも工学部卒orz
暫くROMります。

151 :デフォルトの名無しさん:2015/11/29(日) 17:12:51.03 ID:U49gaUJj
intel の主力 CPU製品の世代・バージョンを表すコード名だよ
セレロンとか Core7 とか商品名に隠れて見えにくくされてる
ちなみに現行最新は broadwell に替わってるらしい

152 :デフォルトの名無しさん:2015/11/30(月) 05:38:13.03 ID:McAnpNWD
最新は第6世代のSkylakeだよ
Broadwellは第5世代

153 :デフォルトの名無しさん:2015/11/30(月) 06:10:56.08 ID:VD56T+vD
みなさんHWもつおいんですね

154 :デフォルトの名無しさん:2015/11/30(月) 13:05:08.68 ID:KChypJW3
しかしインテルの話題ばかりですね
AMDがかわいそう

155 :デフォルトの名無しさん:2015/11/30(月) 14:57:41.28 ID:Ee9Jt/HC
単にAMD64が素晴らしすぎて、最適化の必要がないからです。

156 :デフォルトの名無しさん:2015/12/01(火) 09:29:42.23 ID:euK/mxZa
素晴らしいかどうかは兎も角、最適化の必要がないのは同意。
だってみかけねぇもんw

157 :デフォルトの名無しさん:2015/12/01(火) 09:39:53.24 ID:WgVnPdZx
haswell、amd64知らないっておまえらゆとりすぎだろ、おい。
and64っていわゆるx64命令セットのことだ。AMDのCPUのことじゃない。

158 :デフォルトの名無しさん:2015/12/01(火) 13:04:48.47 ID:1tGEKGVm
AMD64って3DNowのことだが(失笑)

159 :デフォルトの名無しさん:2015/12/01(火) 13:06:30.50 ID:xuYieJrT
そうかそうか、Intelは3DNowの後追いをしたのか
情けないな

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

161 :デフォルトの名無しさん:2015/12/01(火) 16:31:29.60 ID:xuYieJrT
互換切っちゃいけねえのは当然かもしんないけど
未だに4bitだか8bitのCPUに由来する制限や設計の歪みを引き継ぎ続けるのもなぁ……
カウンタレジスタとしてはRCXしか使えませんとかあまりにもウンコすぎる

162 :デフォルトの名無しさん:2015/12/01(火) 17:19:11.09 ID:yW8K+bhB
そんなん先読みやら最適化の都合じゃないの?

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

163 :デフォルトの名無しさん:2015/12/01(火) 20:49:07.03 ID:DqfiEd0O
64bit化の時が、唯一のx86系命令のエンコードを変えるチャンスだった
汎用レジスタは16個に増えたけど、それ以外はしょぼいまま継ぎ足し継ぎ足しのエンコード
命令が複雑すぎるし効率的じゃないし汎用整数命令が2オペランドのままだし

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

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

164 :デフォルトの名無しさん:2015/12/01(火) 21:11:09.22 ID:lfUAYGEe
一切のしがらみを解き放って、ゼロベースで命令セットを設計したら、
どれくらいの性能を叩きだせるんだろうか?

165 :,,・´∀`・,,)っ-○○○:2015/12/01(火) 21:16:38.38 ID:woh9g3Fk
>>163の発想で出来上がったのがItanium

166 :デフォルトの名無しさん:2015/12/01(火) 21:23:08.46 ID:DqfiEd0O
メニーコア系だな
GPUとCPUとDSPの良いところ取り
GPUとCPUは区別がなくなる
デコーダーやスケジューラーは極力小さく、
演算器と入出力に大きく回路を割く

167 :デフォルトの名無しさん:2015/12/01(火) 21:26:16.98 ID:DqfiEd0O
Itaniumの失敗は、
x86を軽視した
コンパイル時最適化がCPUの進化に合わなかった
こんな感じか?

168 :デフォルトの名無しさん:2015/12/01(火) 21:27:03.93 ID:DqfiEd0O
どっちかというとマーケティング的要因の方が大きかったかと

169 :,,・´∀`・,,)っ-○○○:2015/12/01(火) 21:28:26.40 ID:woh9g3Fk
並列化は並列化できないクリティカルパスで行き詰る
パンの製造ラインをいくら増やそうが1つのパンの一次発酵と二次発酵を同時にできないのと同じ。

170 :デフォルトの名無しさん:2015/12/01(火) 21:39:52.86 ID:DqfiEd0O
その為に非対称メニーコアとかいう考えもあるけど...
今ある重い処理の多くは並列化可能でしょ

171 :デフォルトの名無しさん:2015/12/01(火) 21:44:54.96 ID:DqfiEd0O
で団子の案は?

172 :デフォルトの名無しさん:2015/12/01(火) 21:47:11.88 ID:WgVnPdZx
skylakeでipc伸びたで

173 :,,・´∀`・,,)っ-○○○:2015/12/01(火) 21:47:21.62 ID:woh9g3Fk
決して順序が決まってる処理を同時並列化することはできない

174 :デフォルトの名無しさん:2015/12/01(火) 21:48:08.42 ID:lfUAYGEe
>>166
Cellやララビの方向性かな?
いずれにせよ、プログラマがどこまでしんどい重いするかも重要やね。

175 :デフォルトの名無しさん:2015/12/01(火) 21:49:36.60 ID:WgVnPdZx
条件分岐あるからクリティカルパスも変動するから、消費電力を対価に投棄実行できなくもないよ。

176 :デフォルトの名無しさん:2015/12/01(火) 22:00:04.59 ID:DqfiEd0O
>>172
超微妙にな
VADDPDはなぜかレイテンシーが増えたけど

177 :デフォルトの名無しさん:2015/12/01(火) 22:01:37.59 ID:DqfiEd0O
>>173
順序が決まっている処理は順序が決まっている
あたりまえじゃん

178 :,,・´∀`・,,)っ-○○○:2015/12/01(火) 22:21:53.65 ID:woh9g3Fk
ハードの設計の努力を知らない下衆が偉そうに語ることは何一つないのよ
与えられたものをうまく使う方法だけ考えればいい

179 :デフォルトの名無しさん:2015/12/01(火) 22:22:38.64 ID:M545w8lo
クリティカルパスってそんな問題になるかなぁ。
コア数が1万とかになったら大問題かもしれんが、
コア数4とかじゃあんまり問題に成らなくね。

180 :デフォルトの名無しさん:2015/12/01(火) 22:27:59.76 ID:BYRY3bxz
最近の事情は良く知らないんだけど
IntelのCPUでGPU内臓じゃないのってあるの?
サーバー用じゃなく

181 :,,・´∀`・,,)っ-○○○:2015/12/01(火) 22:30:35.15 ID:woh9g3Fk
>>180
http://ark.intel.com/ja/compare/82930,82931,82932

182 :デフォルトの名無しさん:2015/12/01(火) 22:57:39.27 ID:BYRY3bxz
ちょっと一般向けとは言いがたいね
しかもHaswellだし
個人的にGPUはグラボ刺すからCPUに内蔵してほしくないんだよなぁ
GPU無しで、その分値段を落としたモデルがほしい

183 :デフォルトの名無しさん:2015/12/01(火) 23:21:24.20 ID:BYRY3bxz
ちなみに今どきのGPU内臓CPUの、CPU対GPUのダイ比ってどれぐらいなんだろう
http://pc.watch.impress.co.jp/img/pcw/docs/726/778/html/05.jpg.html
を見る限り左のほうにあるの、全部GPU関係でしょ
必要ないんだけどなぁ

184 :デフォルトの名無しさん:2015/12/02(水) 00:01:13.31 ID:lLZXeX9n
>>178
一番偉そうな下衆がなんか書いてるwww

185 :デフォルトの名無しさん:2015/12/02(水) 00:34:39.84 ID:0XpBrEKR
GPUユニットは並列演算に利用できるのにそれが必要ない用途ねぇ。
Xeonでいいはずなのにキャッシュもメモリ帯域もコア数も必要ないってことですよねぇ。
結局、内臓GPU必要ないってことはゲーム用途でしょうねぇ。

186 :デフォルトの名無しさん:2015/12/02(水) 04:57:08.43 ID:rypJABRF
>>179
クリティカルパスってコア数が少ない方がループ回数が増えるから影響が大きくなると思うけどな
クリティカルセクションと勘違いしてない?

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

187 :,,・´∀`・,,)っ-○○○:2015/12/02(水) 06:15:06.45 ID:LTVoUgjb
ディスパッチ&リダクションのコストを軽視してるな

188 :,,・´∀`・,,)っ-○○○:2015/12/02(水) 06:21:53.98 ID:LTVoUgjb
同じコア性能なら多いほうが多い、それは当たり前だ
しかし低性能なコアを複数並べれば高機能なコアより常に速いというのは幻想

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

189 :デフォルトの名無しさん:2015/12/02(水) 12:21:50.26 ID:rypJABRF
また的外れなこと言ってる
団子って周りから人の話聞いてないって言われないか?

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

190 :デフォルトの名無しさん:2015/12/02(水) 12:27:00.90 ID:rypJABRF
リダクションは変だったな、リタイアメントだわ

191 :デフォルトの名無しさん:2015/12/02(水) 14:17:02.16 ID:aHX8DqFu
GPUユニットより柔軟性の高いSIMD演算器を高速なローカルストレージと一緒にCPUに内蔵させたい
GPGPU無駄多すぎ

192 :デフォルトの名無しさん:2015/12/02(水) 15:49:04.71 ID:tY3PsYOb
個人的にはSIMDが1024-wayとかになったら面白いんだが
サーバー用としてはメニーコアの方が相性が良いので
そういう流れにはならないだろうが

193 :デフォルトの名無しさん:2015/12/02(水) 19:05:39.75 ID:lLZXeX9n
ベクトルコンピューターがそんな感じだった
ベクトル化出来ない処理は急激に遅くなるから、
今はコア数とバランス良くって方向になってる

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

194 :デフォルトの名無しさん:2015/12/02(水) 19:13:57.66 ID:lSgAR6hy
>>191
SIMD、柔軟性高いかなぁ?
データの並びとか気を付けないといけないし、プレディケーションもプログラマが書かないとできない。
非アライメントのペナルティが軽減されたのは有難いけど、
せめてプレディケーションくらいはGPUのようにHWでサポートしてほしいなぁ。

195 :デフォルトの名無しさん:2015/12/02(水) 20:17:39.20 ID:rypJABRF
コストの掛かるOoOでもSIMDにすれば相対的にコストが下がるというのもあるし
マスク演算ができるようになればプリディケードとブランチをプログラマが選べるようになる
インテルが目指してる方向は手堅いものだと思うな

196 :デフォルトの名無しさん:2015/12/02(水) 20:53:25.97 ID:73uUfhWJ
早く1024bit SIMD実装してほしいぜ。
囲碁の処理が速くなりそう。
碁盤は19 x 19だから512bitだと微妙なんだよな。

197 :デフォルトの名無しさん:2015/12/02(水) 21:01:41.94 ID:OrMGyZIC
ハードウェアベクタをあまり長くしても大半のアプリケーションで無駄が出るだけだろ。
GPUのやりかたが落としどころとしてベストだと思うがな。

198 :デフォルトの名無しさん:2015/12/02(水) 21:24:30.33 ID:N4pdKraK
ここはC++の高速手法でよろしいのですよね・・・

199 :デフォルトの名無しさん:2015/12/02(水) 21:29:46.57 ID:lSgAR6hy
いや、C++に限らないんじゃない?
スレタイの【C++】や【SSE】ってのは主な手段であって、
GPUやFPGAだって立派な高速化手段だ。

200 :デフォルトの名無しさん:2015/12/02(水) 21:52:10.30 ID:lLZXeX9n
>>197
GPUで速くなる処理はベクタ長アップでも確実に速くなるよ

201 :デフォルトの名無しさん:2015/12/02(水) 22:03:19.40 ID:N4pdKraK
失礼しました かなり低レベルのスレだったのですね。

202 :,,・´∀`・,,)っ-○○○:2015/12/02(水) 22:14:48.90 ID:ky2179yM
(技術力が)

203 :,,・´∀`・,,)っ-○○○:2015/12/02(水) 22:20:01.73 ID:ky2179yM
>>189-190
みたいな頓珍漢なこというお前の言うことははなから聞く気はない

204 :デフォルトの名無しさん:2015/12/02(水) 22:32:44.25 ID:lSgAR6hy
>>201
上位の高速化も該当するから是非話題振ってね。
JITなんかもOK!

205 :デフォルトの名無しさん:2015/12/02(水) 23:16:28.02 ID:rypJABRF
>>203
命令レベルの並列化にしろマルチプロセッサでの並列化にしろ
クリティカルパスじゃない部分を見つけて並列化してるという点では一緒で
並列化のアプローチの仕方が違ってるだけなのは理解してるんでしょ?
命令レベルの並列化であるOoOの方が直接的にクリティカルパスの影響を受けて
並列化が並列化が制限されるようになったからハイパースレッディングが投入されたのに
メイニーコアでクリティカルパスが問題になるって言い方は引っかかるんだよ

206 :デフォルトの名無しさん:2015/12/03(木) 05:09:10.56 ID:Yx1WEMuy
【 オンラインTCGエディター 】 >>1

デュエル・マスターズ的な非電源TCGの 《 オンライン化ツクール系ソフト 》 制作の企画。

例えば、ガチンコ・ジャッジを直ぐにでも導入できる機能を持っておりながら、
当面それを扱わず単純化させておいて、事後的に導入拡張する際に当該システムを
ブロック構造の組み合わせで後付け挿入できるように予めシステム化してあるソフト(エディター)。
既存の非電源TCGを劣らずに再現できるならば大概のニーズに応えられる筈。
バトスピ、ヴァンガ、ウィクロス、ポケカ、デジモン、ゼクス、モンコレ、ガンダム・ウォー、ライブオン、ディメンション・ゼロ、カードヒーロー、シャーマン・キングなど
のシステムを完全再現できるように設計するけど、他に此のTCGの此のシステムは再現希望とか有ったら書いて。
マジック:ザ・ギャザリングの全システムを完全に再現するのは無理だから、此れだけは必用だ!って部分のみリクエストして。
WEB通信での対戦は、個vs個、多数乱戦、チームvsチーム、個vsチームを可能な仕様とする方針。

設計思想は 《 RPGツクール 》 が良いかな?  他に、優れたエディター有ったら挙げてみて。

個人や企業などのベンダーが提示する開発費(見積もり)で折り合えば、発注する。

エディター群から基本コンセプトを絞り込む(もちろんオリジナルで優れた新ネタが有れば導入する)。

遊戯王OCGに関しては、タッグフォース、ADS、デュエルオンラインを発注先ベンダーに研究させる。
なるべく前述3つで可能な再現は全て実装させる方向を目指す。 まぁ努力する・・・
バトスピ、ヴァンガ、バディ、デュエマなど発売済みゲームソフトが存在してるケースはベンダーに研究させる。

各社TCGを再現するテストプレイ ⇒ 更に改良や修正。

機能制限した下位版を5万円以上で発売 + デュエリ−グ用に改造した上位版でサーバー稼動=営業開始。

下位版の改造および商用利用には、別途で当社との契約が必要。

さ〜て、製作ベンダー見つけよっと!ww(クス
http://wc2014.2ch.net/test/read.cgi/entrance2/1449039272/-18

207 :,,・´∀`・,,)っ-○○○:2015/12/03(木) 19:46:04.23 ID:uwlB9z0+
メイニーってどこの田舎訛りだよ

208 :,,・´∀`・,,)っ-○○○:2015/12/03(木) 19:53:16.18 ID:uwlB9z0+
さすがに[?]をエイと発音するのは苦しいぞ
実はmainie coreという架空世界のCPUの話をしているという可能性もあるけどな

学の無い語るに値しない人間なんだろう

209 :デフォルトの名無しさん:2015/12/04(金) 00:10:19.06 ID:/PT96VDb
>>207
そうそう、気になって仕方なかったんだよ。

210 :デフォルトの名無しさん:2015/12/04(金) 00:26:47.97 ID:lgJQm9VI
世界で唯一の稀有な存在かもしれねえぜ…

211 :デフォルトの名無しさん:2015/12/04(金) 00:59:55.26 ID:vTE6A8P6
煽りじゃなくてぐうの音もでないような真実を突きつけてこそじゃねえかな

212 :デフォルトの名無しさん:2015/12/04(金) 09:21:04.02 ID:2jROh0Ef
メイニーコアってなんぞw

213 :デフォルトの名無しさん:2015/12/04(金) 09:31:38.80 ID:4C4dhHoE
逝ってるさん マンセー

214 :デフォルトの名無しさん:2015/12/04(金) 10:37:56.49 ID:yGPPr8Zs
母国語英語、第二母国語C++と日本語な俺からするとMulti-をマルチって言うのも違和感あるけどな

215 :デフォルトの名無しさん:2015/12/04(金) 18:14:24.01 ID:3WaVS3Ju
やっぱりこの板の住民は英語でレスする方が楽な感じですか?
苦手過ぎる…

216 :デフォルトの名無しさん:2015/12/04(金) 19:14:07.09 ID:yphLFvrP
どこに英語のレスがあるんだ

217 :デフォルトの名無しさん:2015/12/04(金) 22:00:51.54 ID:Wf0OQ3ZI
だからメイニーコアってなんだよw

218 :デフォルトの名無しさん:2015/12/04(金) 22:03:30.55 ID:YEfoDPnk
メニイコアならよかったのにな

219 :デフォルトの名無しさん:2016/05/01(日) 15:00:17.83 ID:tKi6j9CT
匿名通信(Tor、i2p等)ができるファイル共有ソフトBitComet(ビットコメット)みたいな、
BitTorrentがオープンソースで開発されています

言語は何でも大丈夫だそうなので、P2P書きたい!って人居ませんか?

Covenantの作者(Lyrise)がそういう人と話したいそうなので、よろしければツイートお願いします
https://twitter.com/Lyrise_al

ちなみにオイラはCovenantの完成が待ち遠しいプログラミングできないアスペルガーw


The Covenant Project
概要

Covenantは、純粋P2Pのファイル共有ソフトです

目的

インターネットにおける権力による抑圧を排除することが最終的な目標です。 そのためにCovenantでは、中央に依存しない、高効率で検索能力の高いファイル共有の機能をユーザーに提供します

特徴

Covenant = Bittorrent + Abstract Network + DHT + (Search = WoT + PoW)

接続は抽象化されているので、I2P, Tor, TCP, Proxy, その他を利用可能です
DHTにはKademlia + コネクションプールを使用します
UPnPによってポートを解放することができますが、Port0でも利用可能です(接続数は少なくなります)
検索リクエスト、アップロード、ダウンロードなどのすべての通信はDHT的に分散され、特定のサーバーに依存しません


220 :デフォルトの名無しさん:2016/09/28(水) 13:29:19.39 ID:8+L+QwLt
書いて

221 :デフォルトの名無しさん:2016/11/10(木) 01:32:20.10 ID:OAKAAmWh
書いて

222 :デフォルトの名無しさん:2017/01/21(土) 13:23:31.22 ID:dThE4/1u
なんかない?

223 :デフォルトの名無しさん:2017/05/07(日) 23:05:11.98 ID:8v4hzv7f
1次キャッシュに収まるスレッドを沢山作りたいとき、SSEやらAVX
のレジスタをメモリ代わりに使うのとメモリ直でアクセスするのとどっちが
キャッシュ乱さずに動くかな。
3次キャッシュは使いたくないし、2次キャッシュもスレッド切り替えだけに
消費させたいし。

224 :デフォルトの名無しさん:2017/05/08(月) 00:55:10.37 ID:BlZJ1Ed5
>>223
理論的にはレジスタを使うほうが乱さないだろうけど、
コンパイラやプロセッサがどうするかは動かしてみないと分からないだろうね。

53 KB
新着レスの表示

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50
名前: E-mail (省略可) :


read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)