rigayaの日記兼メモ帳

自動フィールドシフト 高速化版+10

Haswell向け高速化。

とはいえ、今までに比べればそんなに高速化しないのが残念。+6 → +8に比べるとたいしたことないと思う。拡張命令よりメモリアクセスパターンの改善のほうが効果があることを実感。

---

・AVX2により少し高速化。

・スレッド分割を見直し、わずかに高速化。より均等に分割されるように。

Haswell向け高速化。いつもどおり、AVX2が使用可能な環境なら自動的に使用される。(Haswell + Win7 SP1以降)

部分的には3割以上高速化しているところもあるけど、afs全体の高速化の度合いとしては多くても1割ぐらいかも。メモリアクセスが大半なところも多いので、そういった所では全く速度が伸びない…。

---

とりあえず、以下AVX2高速化に関するメモ書き。まあ、当たり前のことばっかりなんだろうけど。

・ちゃんと関数の終わりに_mm256_zerouppper(vzeroupper)を書く。
・ちゃんと/arch:AVXを指定してコンパイルする。

このへんを忘れると速度が出ず、ハマる。SSE-AVX遷移ペナルティーはそれなりに大きいみたい。気をつけていたつもりだったが、_mm256_zerouppperはやっぱり忘れやすい。

・メモリアクセスがメインのところをAVX2化してもほとんど効果出ない。

まあ当たり前といえば当たり前だけど…。

HaswellでメモリアクセスどころかL3キャッシュすらほとんど高速化されていないのもHaswellが性能上がらない原因のひとつじゃないかなあと思う。NehalemやSandyは前世代と比べてメモリアクセスが大幅に強化されたことが性能の飛躍的な向上を支えていたのかもしれない。

そこでeDRAMなんでしょうけど…。

・128bitの壁。vperm系が遅いらしい。

shuffle/pack/unpack、さらにshift/alignrが使いにくいです…。shuffle系はともかく、128bit×2でない256bitのshift/alignrは欲しかった…。

128bitの壁を越えるにはvperm～を使えばいいんだけど、これがまた遅いらしい。コメントにも頂いたように、意外とvextracti128とかvinserti128を使ったほうがいいようだ。

・Haswellちゃんはshuffle/pack/unpack/blendが苦手?

なるべく連投しないように…ってそんなこと言われても…。YC48を扱うとどうしてもshuffleまみれになるような気が。このへんはよくわからないし、あきらめ。

---

このあたりに注意すれば、あとはわりと簡単にAVX2コードを作成でき、そこそこ速度が出る。特にまとまった計算があるところだと、結構高速化できて面白い。

---

ダウンロード>>

---

スポンサーサイト

• 2013-06-12(23:17) :
• afs :
• コメント 12 :
• トラックバック 0

トラックバック

この記事にトラックバックする(FC2ブログユーザー)

コメントの投稿

No title

• 2013-06-13(23:47) :
• vextracti128の人 URL :
• 編集

No title

• 2013-06-15(00:28) :
• rigaya URL :
• 編集

管理人のみ閲覧できます

• 2013-07-26(21:06) :
• :
• 編集

Re: afs

• 2013-07-27(08:23) :
• rigaya URL :
• 編集

管理人のみ閲覧できます

• 2013-07-27(10:16) :
• :
• 編集

Re: No title

• 2013-07-29(23:49) :
• rigaya URL :
• 編集

管理人のみ閲覧できます

• 2013-07-30(00:16) :
• :
• 編集

Re: afs

• 2013-08-02(22:43) :
• rigaya URL :
• 編集

管理人のみ閲覧できます

• 2013-08-03(15:50) :
• :
• 編集

afs, 再現した…のですが…

• 2013-08-05(22:38) :
• rigaya URL :
• 編集

管理人のみ閲覧できます

• 2013-08-15(20:17) :
• :
• 編集

Re: No title

• 2013-08-16(23:27) :
• rigaya URL :
• 編集