【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/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で速くなる処理はベクタ長アップでも確実に速くなるよ

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

失礼しました　かなり低レベルのスレだったのですね。

**,,・´∀｀・,,）っ-○○○** · 2015/12/02(水) 22:14:48.90

（技術力が）

**,,・´∀｀・,,）っ-○○○** · 2015/12/02(水) 22:20:01.73

>>189-190
みたいな頓珍漢なこというお前の言うことははなから聞く気はない

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

>>201
上位の高速化も該当するから是非話題振ってね。
JITなんかもOK！

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

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