【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/

**デフォルトの名無しさん** · 2017/05/08(月) 00:55:10.37

>>223
理論的にはレジスタを使うほうが乱さないだろうけど、
コンパイラやプロセッサがどうするかは動かしてみないと分からないだろうね。

**デフォルトの名無しさん** · 2017/08/09(水) 20:46:58.02

レジスタに収まるならレジスタの方が良いに決まってる

**デフォルトの名無しさん** · 2017/08/09(水) 20:56:25.64

1次キャッシュに収まるなら他のキャッシュなんて気にする必要は無いと思うんだが
普通のOSで普通のコードを動かすなら、スレッド切り替えによるオーバーヘッドなんて無視できるレベルだし

そんなことを心配するよりも、肝心なコードを気にしようよ
いろんなテクニックを知ってるからコードをアップしてくれれば、小さいループならお役にたてるかも知れない

**デフォルトの名無しさん** · 2017/08/09(水) 20:57:28.26

ロングパスだったorz

**デフォルトの名無しさん** · 2017/08/16(水) 16:38:15.04

最近ニコニコ動画に上がってる経済シミュ、生態シミュ動画の人の高速化手法がすごい

**デフォルトの名無しさん** · 2017/08/17(木) 03:34:48.76

どんな高速化手法なんだい？

**デフォルトの名無しさん** · 2017/09/13(水) 01:32:53.89

std::copyってsimd化などの最適化って既にされてるのかな？
sse_copy()とか自作したとして
効果は期待出来る？

**デフォルトの名無しさん** · 2017/09/13(水) 02:02:50.51

sse_copyとやらはmemcpy、memmoveと何が違うの？

**デフォルトの名無しさん** · 2017/09/13(水) 02:20:34.07

名前的に、SSEの128bitレジスタを使ってのコピーだろう

memcpyとmemmoveの違いはぐぐればすぐわかる

**デフォルトの名無しさん** · 2017/09/13(水) 02:25:23.48

じゃなくて、自作しようとしているSSEでコピーするであろう「sse_copy」と
標準で用意されている「memcpy、memmove」←両方合わせて、とで
何が違うの？という話
当たり前だがmemcpyはCPUがSIMDに対応していれば使うし
カリカリにチューニングしてあるわけだが
sse_copyなど要るの？

**デフォルトの名無しさん** · 2017/09/13(水) 02:48:41.88

memcpyはC言語の関数だったか
存在を忘れてた
こいつは最適化入ってるのね
これ使えば良さそうだ
そうする、どうもです

**デフォルトの名無しさん** · 2017/09/13(水) 05:53:18.22

条件にもよるがmemcpyあたりはコンパイラ自身がインライン展開したりする

**デフォルトの名無しさん** · 2017/09/13(水) 11:25:41.68

std::copy使っておけばPODならmemcpyかmemmove使うんじゃないの
VS2017のやつはmemmove使ってるな

**デフォルトの名無しさん** · 2017/09/13(水) 15:04:16.35

copyrect

**デフォルトの名無しさん** · 2017/09/13(水) 18:53:59.90

謎の速度低下で悩んでいたが、キャッシュレイアウトって重要だな。
AVX512で一部分だけ値更新したい時、16バイト読み込んでその位置に64バイト書き戻すようなケース。
そのまま16バイト読み込みで実装すると、読み込み時に16バイト分しかキャッシュがないので、書き込む時に64バイトに拡張というか再配置されて遅くなる。
最初から64バイトで読み出すと、サイズが変化しないので遅くならない。
ついつい、読み出し量が少ない方が速いに違いないと思い込んでしまう罠。

**デフォルトの名無しさん** · 2017/09/13(水) 20:49:54.25

パーシャルライトって奴だな
キャッシュにも有効なのか

昔のPenProの頃の8/16bitレジスタへの書き込み後の32bit読み出しとか
HDDが2T超える頃の4Kセクタのパーティションでの位置ずれとか
信じられないほど遅くなる要因になるもんな

**デフォルトの名無しさん** · 2017/09/13(水) 21:31:13.89

え、memcpy()とかstd::copy()ってSIMD使うん？？
vectorのコピー遅いから困ってて、カリカリとSIMDで書こうかと思ってたんやけど、手間省けるわ。

**デフォルトの名無しさん** · 2017/09/13(水) 21:45:57.88

コピーが遅いから困っててと言うけれど
どうやって遅いと結論づけたのですか？
本来なら16ms完了するはずなのに29msもかかってしまっている！
とかわかるんですか？

**デフォルトの名無しさん** · 2017/09/13(水) 21:55:49.49

ああ、いえいえ、言い方が悪かったですが、
処理時間に占めるコピーの割合が増えてきたので、高速化したいなぁ、と思っただけです。

**デフォルトの名無しさん** · 2017/09/14(木) 20:07:50.27

rep movsbが糞速い
https://srad.jp/~miyuri/journal/569822/
＞＞REP MOVSはマイクロコードで実装されていて、最初にコピーサイズを見て適するコピーアルゴリズムを決めるセットアップ処理を行なってから
＞＞実際のコピー処理を始めるようになっている。そのため小さいサイズのコピーではセットアップ時間のオーバーヘッドが無視できないが
＞＞コピーサイズ(適度に大きいサイズ)とアラインメントの要件とプロセッサの世代の条件を満たすとそこそこの性能が出る。
＞
＞＞プロセッサの世代によって展開されるマイクロプログラムが変わり最適化の度合いも変わってくると。
＞＞第1世代Core i以降のプロセッサのREP MOVSのマイクロコードは比較的速い。
デコード済みの命令をキャッシュ出来るようになったから、マイクロコード展開命令でも最適化が行われるようになってるみたいだよ。

**デフォルトの名無しさん** · 2017/09/14(木) 21:12:13.74

メモリのレイテンシ、スループットやキャッシュサイズに依存するんだから
ブロック転送命令の最適化は無駄な努力だとインテルは思ってんだろう。

**デフォルトの名無しさん** · 2017/09/14(木) 21:41:42.21

Visual Studio 2017 で
memcpyを調べてみた

x86は rep movs
x64は vmovups 128bit 2パラ16アンロール

オプションでAVX2命令を使うようにしてもかわらず

vmovaps 256bit/512bitの方が速いから
頻繁に使うなら自作した方が良い

**デフォルトの名無しさん** · 2017/09/14(木) 23:27:05.22

>>238
キャッシュ可な領域はキャッシュライン単位でDRAMの読み書きが行われるはずだから
キャッシュは関係ないでしょ。

**デフォルトの名無しさん** · 2017/09/15(金) 00:42:48.43

>>246
アライメントのほうだったかも。
境界跨いで更新する時、あらかじめ更新サイズで読み出しておけば、全領域使用可能状態になるが、読み出し半分だと残り分キャッシュ要求発生して遅くなると。

**デフォルトの名無しさん** · 2017/09/16(土) 02:31:32.38

>>247
一定のストライドで読み込んでいれば自動プリフェッチで早めにキャッシュに取り込まれる可能性もあるけど、
DRAMの帯域を圧迫しないようにページ境界をまたいでは機能しないようになってるはずだったので、
AVX512のベクタ長だと、何サイクルか先のループで使うデータをプリフェッチで要求した方がいいかも。

**デフォルトの名無しさん** · 2017/09/16(土) 11:37:46.61

>>248
ありがとう。すでに別件でPrefetchもやってみてるけど、AVX512だとかなり効果があった。

**デフォルトの名無しさん** · 2017/09/16(土) 17:07:26.32

>>249
一時は自動プリフェッチの性能が向上してあまりprefetchの意味がない状態が続いていたけど、
AVX512ともなると1ページ分のデータをループ64回で消費しちゃうんだよな…
DRAMのCASレイテンシをCPUクロックで換算すると結構長いからね。

**デフォルトの名無しさん** · 2017/09/17(日) 15:21:48.39

え？AVX512は手書きprefetchのほうが性能出る？
これまではハードウェアプリフェッチが超優秀で、手書きprefetchはむしろオーバーヘッドになって遅くなる感じだったんだけど。

**デフォルトの名無しさん** · 2017/12/10(日) 20:33:52.61

prefetchはハードウェアにまかせて手書きでclflush入れるのが一番いい感じなんだけど。こんなケースは少数派なのかな。

**デフォルトの名無しさん** · 2018/02/01(木) 08:35:26.88

xeonでavx命令使うと過熱防止のため1ms間、動作クロック下げるなんて聞いてないよ～(＞∀＜)

**デフォルトの名無しさん** · 2018/02/02(金) 00:44:37.85

>>253
本末転倒やなw

**デフォルトの名無しさん** · 2018/02/16(金) 06:35:40.61

☆ 日本の、改憲を行いましょう。現在、衆議員と参議院の
両院で、改憲議員が３分の２を超えております。
『憲法改正国民投票法』、でググってみてください。国会の発議は
すでに可能です。平和は勝ち取るものです。お願い致します。☆☆

**デフォルトの名無しさん** · 2018/05/23(水) 20:32:42.01

僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法　モニアレフヌノ』

YF4RO

**デフォルトの名無しさん** · 2018/06/04(月) 11:52:09.21

過熱してなくても1ms間、強制的にクロック下げるん？

**デフォルトの名無しさん** · 2018/06/09(土) 11:11:22.69

>>257、そうみたいなんですよ

https://pc.watch.impress.co.jp/img/pcw/docs/665/641/html/14.png.html
> AVX命令が実行されるときに、CPUはAVXベースで定義されている
> クロック周波数に一時的に下がって実行し、実行終了後元のベースクロックに戻る

> AVX命令の実行完了後1ms程度で通常(非AVX)動作モードに復帰

**デフォルトの名無しさん** · 2018/06/09(土) 11:42:37.36

1msってペナルティ、デカすぎやろ

**デフォルトの名無しさん** · 2018/06/09(土) 12:18:26.60

AVXが有効な処理なら微妙にクロックが落ちようがどうでもいい

**デフォルトの名無しさん** · 2018/06/09(土) 12:21:09.00

クロックが高いのが目的じゃなくて
処理が速いのが目的

その辺がよくわかってないアホがいるみたい

**デフォルトの名無しさん** · 2018/06/10(日) 12:04:49.97

なんか知らんがPCUの動作速度だろ。

**デフォルトの名無しさん** · 2018/06/10(日) 12:47:49.30

CPU?

**デフォルトの名無しさん** · 2018/06/10(日) 13:00:30.59

Programmable Calculation Unit (嘘)

**デフォルトの名無しさん** · 2018/06/10(日) 13:18:51.18

どうせならUも工夫しろよ

**デフォルトの名無しさん** · 2018/06/13(水) 06:44:44.44

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)

**デフォルトの名無しさん** · 2018/06/13(水) 07:54:13.98

さすがに下がり過ぎｗ

**デフォルトの名無しさん** · 2018/07/04(水) 22:24:56.45

HHG

**デフォルトの名無しさん** · 2018/07/05(木) 16:49:03.96

HHG

**デフォルトの名無しさん** · 2018/07/12(木) 17:41:30.02

そもそも4倍の量が同時に計算できるわけだから
クロックが半分になっても元は取れる

**デフォルトの名無しさん** · 2018/07/12(木) 18:11:27.11

だね

**デフォルトの名無しさん** · 2018/07/12(木) 22:27:22.56

同じクロックで2倍の効率との違いは消費電力？

**デフォルトの名無しさん** · 2018/07/13(金) 00:03:25.32

クロックが実際は半分にならないから
メリットは高速化

**デフォルトの名無しさん** · 2018/10/24(水) 21:06:49.85

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

**デフォルトの名無しさん** · 2018/10/24(水) 22:27:31.88

そりゃ、やってることが違うんだから
同じにしたけりゃ sum2 で for (auto& p: v) にしてみ

**デフォルトの名無しさん** · 2018/10/24(水) 22:49:24.04

うお、autoってこんな書き方も出来るのかよｗ
勉強になりました。

**デフォルトの名無しさん** · 2018/10/25(木) 11:47:46.18

結果も違うんじゃね
ちゃんと中身観たか

**デフォルトの名無しさん** · 2018/10/25(木) 17:06:36.77

結果は同じだろ? 鬼のように発生するコピーのためにメモリ不足で死なない限りは。

**デフォルトの名無しさん** · 2018/10/25(木) 17:51:37.93

C++は高速化に向かいないといういい見本だ。

**デフォルトの名無しさん** · 2018/10/25(木) 19:41:56.48

C++は、書いた通りに実行されるだけ。
高速な処理が必要なら、そう実行されるように実装しないと。

**デフォルトの名無しさん** · 2018/10/25(木) 21:01:08.67

まるでC++コンパイラは最適化しないとかデタラメな言い分けだな。

**デフォルトの名無しさん** · 2018/10/26(金) 16:39:17.96

vectorとか激しくコピーしすぎ

**デフォルトの名無しさん** · 2018/10/26(金) 16:49:29.10

何のためにコピーしてるん？　使い方間違ってんじゃね？

**デフォルトの名無しさん** · 2018/10/27(土) 19:00:07.11

reserveせずのpush_backしまくるバカのことじゃね？

**デフォルトの名無しさん** · 2019/11/09(土) 12:43:46.37

push_backしまくってもそれほどパフォーマンスは悪化しないように出来てるはずだが
コピーしまくりっていうんだから関数で値渡ししてるとかじゃないか？

いずれにしろC++自体の問題ではない

**デフォルトの名無しさん** · 2019/11/09(土) 12:46:29.28

データの並び順やアルゴリズム、...
この辺がパフォーマンスに大きな影響を与える

コンパイラの最適化なんぞ知れてる
その辺を最適化したければガシガシアセンブラだが
その前にいくらでもやることがあるのが普通

**デフォルトの名無しさん** · 2019/11/09(土) 12:48:19.04

メインメモリが相対的に遅くなってきてるので
データの並びは非常に重要
大きなデータはディスクアクセスのような感覚で扱わないとダメ

**デフォルトの名無しさん** · 2019/11/09(土) 12:49:37.15

ちゃんとキャッシュサイズや階層を意識する

**デフォルトの名無しさん** · 2019/11/09(土) 21:44:34.74

突っ込みどころもあるが1年前のレスに真面目に返答してるおまえを評価する。

**デフォルトの名無しさん** · 2019/11/10(日) 12:14:45.63

x おまえ
o おまえら

って書こうとしたが
同じ人だった orz

**デフォルトの名無しさん** · 2019/11/10(日) 18:59:30.87

御評価、有難う御座います

**デフォルトの名無しさん** · 2019/11/11(月) 20:31:51.81

プログラムを高速化する話
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ではインラインアセンブラも使えないコンパイラがあるし、関数呼び出しや例外処理の
書き方も変わってしまっているので移植性が低いよ

**デフォルトの名無しさん** · 2019/11/11(月) 20:40:17.77

組み込み関数でSIMD命令駆使すれば、しっかり高速化されてキモティー！

**デフォルトの名無しさん** · 2019/11/12(火) 13:18:01.61

>>292
アセンブラを使わなくても速度チューニングネタはたくさんあるが
当然最後の手段としてはアセンブラは有効

小さいループに処理が集中してるような処理は
特に効果的

下手くそがアセンブラに手を出すと逆に遅くなったりもするけど

**デフォルトの名無しさん** · 2019/11/12(火) 23:06:40.80

>>292
急にどうしたｗ
レジスタ割り当て面倒くさいから、Intrinsics使うの普通だぞ

**デフォルトの名無しさん** · 2019/11/13(水) 00:56:22.92

>>295
>>286が
＞コンパイラの最適化なんぞ知れてる
＞その辺を最適化したければガシガシアセンブラだが
とか書いてたから
この人10年くらい時間が止まってるよね
64bitと32bitじゃレジスタの数も違うし、SIMDの新命令に対応させるたびに
レジスタ割り付けが全く変わってしまうこともあるのにアセンブラって…
AVXなら3オペランドも使えるから、コンパイラに任せてもコードの質は低下しにくくなってるはず

**デフォルトの名無しさん** · 2019/11/13(水) 10:22:08.98

費用対効果を考えればIntrinsicsでも良いけど

究極の最適化はアセンブラしか無い
IACAを使ったり実測したりしながらパズルする

処理が非常に単純で速度の求められる小規模DSPなんかでも
いまだにそういう開発をする

**デフォルトの名無しさん** · 2019/11/13(水) 11:21:40.17

FPGAで専用回路組んだ方が手っ取り早い

**デフォルトの名無しさん** · 2019/11/13(水) 12:35:34.29

>>297
IACA=Intel Architecture Code Analyzer
ですよね。

**デフォルトの名無しさん** · 2019/11/13(水) 13:05:36.17

SIMDを覚えたての初心者はこんなコードを書きやすい
典型的な糞コード

ループ {
sum = _mm_add_ps(sum, data[i]);
}

>>299
そうです

**デフォルトの名無しさん** · 2019/11/13(水) 13:15:07.61

>>298
CPU, GPU, FPGA
それぞれ得意分野が違うから

**デフォルトの名無しさん** · 2019/11/13(水) 13:21:58.53

GPUユニットはCPUに乗っけたのだから後はFPGAも乗っけるだけ。
アルテラは既に買収済みだしな。

**デフォルトの名無しさん** · 2019/11/13(水) 15:28:17.20

FPGAに夢見すぎじゃね？

**デフォルトの名無しさん** · 2019/11/13(水) 16:48:11.25

スパコン分野じゃ固定の計算式はFPGAが一番効率的。そういう意味で地球シミュレータや京はゴミ。
スパコンが必要な分野でCPUのような汎用性などいらない。

**デフォルトの名無しさん** · 2019/11/13(水) 17:02:40.99

今度はスパコンが出て来たか
関わったこともないだろうに

スーパーコンピューターこそ汎用性が必要
ベクトルコンピューターが消えたのも
より汎用性を重視するから

スーパーコンピューターの世界でFPGAが求められてるなら
当然スーパーFPGAが流行ってないと辻褄が合わないわけだけど
流行ってないね

**デフォルトの名無しさん** · 2019/11/13(水) 17:18:55.90

何を言ってるからよく分からないなぁ。
特定の式を大量に速く計算したいという要望に対してなんで汎用性が出てくるの？
汎用性スパコンが1億なら同じ性能で1000万で達成できるんだよ。
しかも汎用性のために可用性が落ちるとか話にならないよ。京見れば分かるでしょ。

**デフォルトの名無しさん** · 2019/11/13(水) 17:37:57.46

自分専用ならTSSにする必要もないしな

**デフォルトの名無しさん** · 2019/11/13(水) 18:11:35.42

FPGAとかスーパーコンピューターとか自分専用とか
具体的な処理を何も語ってないのによくもまあ勝手に前提を作るよなあ

ここはソフトの最適化のスレなんだけど

**デフォルトの名無しさん** · 2019/11/13(水) 18:13:46.44

FPGAなんかで妥協しないでASICでも作れば良いよ

**デフォルトの名無しさん** · 2019/11/13(水) 18:26:47.86

FPGAだってプログラムでコーディングするんだが・・・。勝手な前提作ってるのはおまえじゃん。
というかSSEでの高速化がOKなら、GPGPU、FPGAもOKだろう。

**デフォルトの名無しさん** · 2019/11/13(水) 19:03:44.22

スレタイ
他のスレへどうぞ

**デフォルトの名無しさん** · 2019/11/13(水) 19:23:44.45

1年もレスが無かった過疎スレになんでこんな必死な自治厨がいるのだろうw
前スレも10年かけて1スレ消費したんだぞw

おまえは何者だw

**デフォルトの名無しさん** · 2019/11/13(水) 19:25:42.10

突然カテ違いのFPGAなんか布教し始めるから

**デフォルトの名無しさん** · 2019/11/13(水) 19:49:30.87

ID:EqcpRCSG　= >>311 = >>313 か？

こんな過疎スレで布教ってw マジおまえここの住人じゃないんだな。

**デフォルトの名無しさん** · 2019/11/13(水) 19:51:20.51

>>312
前に64bitで絶対アドレス使えって書いて突っ込み受けたらファビョってたのいたでしょ
あれと同一人物っぽいんだよなあ
＞究極の最適化はアセンブラしか無い
とか書くところとか

午後のこ～だの開発者たちが動画コーデックの開発しなかったのだって、
MMXは除外しても、SSE2、SSE3、SSSE3、SSE4、SSE4.1、AVX、AVX2、AVX512に加えて、
64bitでは一気に種類が2倍と、次々と登場する新命令ごとに最速のルーチン用意していく手間と、
コードが異なるために特定のCPUでしか発現しないバグがでるリスクが増すこと考えたら、
最速に拘るのが現実的ではなくなったんだよ
彼らとしては妥協したコード書く気はなかっただろうし、興味が失せるのも仕方ないのかもね

AVISynthもインラインアセンブラ使ったプラグインだらけで64bit化に対応できずに放置されてたのが
相当あったけど、自分も64bit化やった経験からも、今更初心者にアセンブラ使えなんて教えんなと言いたい

**デフォルトの名無しさん** · 2019/11/13(水) 20:53:55.20

初心者ならIntrinsicsなんか使わないで素直に汎用性のあるC++で書くかライブラリを使えばいいよ

ここは高速化手法スレだから高速なコードであることは重要
Intrinsicsよりアセンブラの方が高速に書けるのは自明なのでアセンブラの話題は当然出てくる

**デフォルトの名無しさん** · 2019/11/13(水) 21:08:18.46

アセンブラ狂信者はお前だけだよ

**デフォルトの名無しさん** · 2019/11/13(水) 21:12:18.74

Intrinsicsで32bit/64bitの共通化は出来ても
新命令がでたらどうせ作り直しだよ

新命令に最適化しないならそのままでいいよ
｢新命令対応｣て謳うのが目的じゃなければ

SSEからAVXの移植もレーン縛りで苦労しただろ？
単純に置き換えなんて出来ない
128bitのまま単に3オペとレジスタ数だけなら簡単だけど

AVX512も同じ
マスクレジスタや新命令を使うなら書き直し

**デフォルトの名無しさん** · 2019/11/13(水) 21:13:39.13

アセンブラ狂信者じゃない
Intrinsicsも使う

極限な最適化にはアセンブラが必要ってだけ
まあ当然だ

**デフォルトの名無しさん** · 2019/11/13(水) 21:19:04.07

どうせ今後は32bit向けの最適化なんかやらんだろ
だとすると手間の差はレジスタ管理くらい

**デフォルトの名無しさん** · 2019/11/13(水) 21:42:54.67

>>320
＞だとすると手間の差はレジスタ管理くらい
こんなこと書くようだと大したコードは書けないな
レジスタ割り付けの妙味と面倒さを知らないのなら、別に組み込み関数で書いても構わないだろ

**デフォルトの名無しさん** · 2019/11/13(水) 22:04:42.12

>>321
レジスタ割り付けの妙味www
さほど時間をかけなくてもコンパイラよりマシなのは作れるよ
そもそもIntrinsicsの時点でもレジスタ数削減は考えるべきであって
何も考えなきゃIntrinsicsだろうがアセンブラだろうが遅い

**デフォルトの名無しさん** · 2019/11/13(水) 22:06:07.35

詳しい自信があるなら
とりあえず問題ありまくりな>>300の問題点でも語ってみようか