結局C++とRustってどっちが良いの？ 4traits

**デフォルトの名無しさん** · 2023/06/06(火) 19:13:06.15

「C++の色々配慮してめんどくさい感じは好きだけど、実務になったらメモリ安全性とか考えて今後Rustに変わっていくんかな」
「うだうだ言ってないで仕事で必要なのをやればいいんだよ、趣味なら好きなのやればいい」

っていう雑談スレ。

前スレ: 結局C++とRustってどっちが良いの？ 3traits
https://mevius.5ch.net/test/read.cgi/tech/1683154196/

関連スレ(マ板): Google&MS「バグの70%はC/C++。Rustにする」
https://medaka.5ch.net/test/read.cgi/prog/1619943288/

**デフォルトの名無しさん** · 2023/06/25(日) 17:45:44.71

>>696
ぴんきり。CPUの価格と比べて、そんなに高いわけではない。

**デフォルトの名無しさん** · 2023/06/25(日) 17:51:16.50

>>697
で、いくらなのよ？
定量的な話できないの？
ド文系？

**デフォルトの名無しさん** · 2023/06/25(日) 17:54:05.15

>>698
倍精度浮動小数点(double)が高速化されているGPUで、2万5000円
のものが有った。
今は分からない。

**デフォルトの名無しさん** · 2023/06/25(日) 18:10:51.69

>>692
使える人間自体が少ないのもそうだし、特定CPU向けのコード混ぜるとメンテナンスコストが高い
よほど有用だと判断されないかぎり普通はやらない

**デフォルトの名無しさん** · 2023/06/25(日) 18:12:45.82

記号処理と数値計算の対立
文系とか関係ないね

**デフォルトの名無しさん** · 2023/06/25(日) 18:17:34.92

IntelのSIMDは、レジスタの幅が小さすぎる。
1024個のdoubleを同時に掛け算できるような程度で無いと
余り高速化は望めない。

**デフォルトの名無しさん** · 2023/06/25(日) 18:17:44.43

>>699
もういいよ
定量って意味すらわからないとは

**デフォルトの名無しさん** · 2023/06/25(日) 18:19:26.67

ところが、10個の独立したCPUがあったならば、10倍近い速度
は出る。SIMDだと、1024個同時に計算しても、トータルの
数値計算は、やっと数十倍位にしかならないだろう。

**デフォルトの名無しさん** · 2023/06/25(日) 18:20:20.40

>>703
昔に調べたことだから数値は忘れている。
しかし、一般論として、SIMDよりマルチコア方式の方が
将来性が有ると言われているはず。

**デフォルトの名無しさん** · 2023/06/25(日) 18:20:53.67

>>705
マジで何もわかってなくて草

**デフォルトの名無しさん** · 2023/06/25(日) 18:24:48.59

SIMDは時代遅れ。
AMDとnVidiaは賢いから、どんどんマルチコア化を進め、
AIや数値計算で高い評価を得ている。
ところが、Intelはセンスの無いアホだからSIMD化を進めようと
したが、全然速度が上がらない上に命令が複雑で、しかも、
機種依存、世代依存が激しくて使い物にならない。
GPUだと数年後に買い換えれば、プログラムを修正しなくても、
何倍にも高速化される。コンパイラの修正も不要。
SIMDだと新命令が出るたびにコンパイラの修正が必要だから、
コンパイラ作者は、なんでこんなことに付き合わされる
か分からずないで泣いているだろう。
実際、富岳や地球シミュレータはコア数が多い。

**デフォルトの名無しさん** · 2023/06/25(日) 18:29:31.84

まぁでもやっぱりベクトル演算系は後回しにはなるんかな
そこまてニーズがあるとは思えない
しかし潜在需要は出てくるかもしれんけど
科学シミュレーション系、動画処理系、とか
YouTuberが動画合成するのに動画処理系は流行ってるけど
機械学習のためのベクトル演算も流行る兆しはあるけどな

**デフォルトの名無しさん** · 2023/06/25(日) 18:33:20.89

ベクトル演算は自由度が低すぎて使い勝手が悪い。
だから衰退して、いまのスパコンでベクトル型を採用しているものは
ほとんどない。
そして、それと似た設計思想なのがSIMD命令。
だから、SIMDが廃れるのは当然で、実際、Intelもやっと気付いて、
AVX512(zmmレジスタ)は廃止方向で、最近はコア数の増大へと
舵を切っている。その方向性は正しい。
AMDやnVidiaは頭が良くて、もっとずっと前からコア数増大へと
舵を切っている。
だから、科学技術計算でもGPGPUを使う流れは変わらない。
高いのは、半導体不足で高くなっているだけだろう。

**デフォルトの名無しさん** · 2023/06/25(日) 19:10:40.50

いやGPU使わないならSIMDしか高速の余地がないんだよ
せっかくrustで実装するならサイズによって実装を切り替えるべき

要素数が少ない→キャッシュメモリを活かすようにメモリレイアウトを工夫する
要素数が中→SIMD+キャッシュメモリ最適化
要総数が大→スレッド+AVX+キャッシュメモリ最適化

これこそ現代アーキテクチャを生かしまくった実装
そしてBlasはこういう実装になってる

ただの生VecでループするならCと変わらん

**デフォルトの名無しさん** · 2023/06/25(日) 19:34:48.57

メモリドリブンとか非ノイマン型になるとまたアーキテクチャが違ってくる

**デフォルトの名無しさん** · 2023/06/25(日) 20:19:06.24

モダンで高速なCPUベースの数値計算ライブラリのまとめ

1.CPUの活用
SIMDを使う

2.キャッシュメモリの活用
キャッシュメモリを常に意識する
常にキャッシュに乗る範囲で演算を行う

3.パイプライン処理
計算を直ちに実行するのではなくまず計算グラフを構築し
トポロジカルソートなどで依存関係を解析する
依存ごとにパイプラインを作成し非同期で計算を実行する
記法としてはメソッドチェーンを利用するとやりやすい

非同期実行にはpromise/futureに代表される
非同期ライブラリを使うと書きやすくなる
この点rustはtokioなど非同期実行には使いやすいライブラリが大量にある

この点pythonのライブラリは現状だと全くお話にならないレベルの実装だ
中身がCなのでそこまで細かいチューニングができない
rustを使えば相当速くできるはず

**デフォルトの名無しさん** · 2023/06/25(日) 20:43:38.33

>>594,635,663,670,676
ndarray本体にコントリビュートするつもりは無いの？

**デフォルトの名無しさん** · 2023/06/25(日) 20:46:48.87

SIMDの使い道がないなんて普通は思わないな
実際はSIMDは動画のデコードエンコードで使用されてる

**デフォルトの名無しさん** · 2023/06/25(日) 20:53:45.41

追加
>>683,712
ndarray本体にコントリビュートするつもりは無いの？

**デフォルトの名無しさん** · 2023/06/25(日) 21:06:17.68

本気でやるつもりがあるならこんな場所じゃなくてGitHubのissues/discussionsで議題出すでしょ

**デフォルトの名無しさん** · 2023/06/25(日) 21:15:14.90

まあまあ
>>594,635,663,670,676
>>683,712
の意見を訊いてみましょう

**デフォルトの名無しさん** · 2023/06/25(日) 21:49:47.41

>>715
ないかな
俺が上で言ってるアーキテクチャだとtokioを組み込む必要があって
ndarrayにそんなことができる余地はない
tokioを組み込んでおけば複数ノードへの展開まで視野に入る
GPUを凌駕するところまでいけるんだよ

**デフォルトの名無しさん** · 2023/06/25(日) 21:50:03.13

例えばUTF8 validationなどもbyte毎に処理するよりSIMDで速くなったりする

**デフォルトの名無しさん** · 2023/06/25(日) 22:04:27.70

この数値計算に「非同期ライブラリを組み込む」というのをやってるものは見たことがない
このアイデア使っていいよ

**デフォルトの名無しさん** · 2023/06/25(日) 22:09:54.64

了解
>>683,712,718は>>666の人なのね

>720
>tokioを組み込んでおけば複数ノードへの展開まで視野に入る
>この数値計算に「非同期ライブラリを組み込む」というのをやってるものは見たことがない
https://crates.io/crates/mpi ←生きてる
https://crates.io/crates/node_crunch ←過疎
これらはtokio要らない見たいだけど、他に良いのがあるの？

>>594,635,663,670,676
言いだしっぺ待ち

**デフォルトの名無しさん** · 2023/06/25(日) 22:15:33.85

>>721
MPIはHPC分野で伝統的に使われてるライブラリだけど
書き方に非常にクセがあるのよ
いわゆるデータ並列でCUDAっぽい書き方を強要される
これが使いにくい
今時のライブラリで使うものではないと思う

**デフォルトの名無しさん** · 2023/06/25(日) 22:25:12.80

>>722

気になっているのは
>>718 >tokioを組み込んでおけば複数ノードへの展開まで視野に入る
の部分なんだけど説明してもらえる？

**デフォルトの名無しさん** · 2023/06/25(日) 22:25:40.44

そういや、Intelからはdpcppとかいうのが出てるけど、あれってどうなん
ガチエアプで、そういうのもあるってのを把握してるにとどまってるんだが

**デフォルトの名無しさん** · 2023/06/25(日) 22:53:17.82

>>723
そこはまだ検討中ではあるがtokioのイベントループの中で
各ノードと通信を行うという意味
具体的な方法はまだ決めてはいないが既存のプロトコルでやれれようにしたい
gRPCをtokioの元で動くようにして
gRPCで各ノードと通信を行うようにするとかね
実際そういうライブラリはあるらしい

**デフォルトの名無しさん** · 2023/06/25(日) 22:59:23.24

>>725
了解
形になったら大宣伝しよう

という事で言いだしっぺ待ち

>>594,635,663,670,676
ndarray本体にコントリビュートするつもりは無いの？

**デフォルトの名無しさん** · 2023/06/25(日) 23:00:24.01

>>724
俺の知る限り実用的なマルチノードでの計算ライブラリはMPIぐらい
スパコンの世界ではMPIを使うこと前提に組まれた数値計算ソフトがめちゃくちゃ多い
しかしやはり古いと思う
新しいモダンな数値計算のライブラリをデザインする時に来ている

**デフォルトの名無しさん** · 2023/06/25(日) 23:01:01.04

>>680
結構、とりあえず異なる数値型同士の行列積は既に実装できてるけど。勿論、ユーザーは最初に型を指定しなくてすむように演算。組んでるけど。rustは型をある程度動的にしてもそとまでスピードも落ちないんだよね。少なく自分の計測の範囲内では。

**デフォルトの名無しさん** · 2023/06/25(日) 23:03:26.50

MPI自体は単なるマルチノードでの通信ライブラリに過ぎない
これを使っている前提のソフトが多いって意味ね

**デフォルトの名無しさん** · 2023/06/25(日) 23:07:06.21

>>727
>デザイン
coarray fortranってのがあるけど手書きMPIの方が性能は上らしい

**デフォルトの名無しさん** · 2023/06/25(日) 23:11:24.96

>>730
通信の方式とかかなりチューニングされてるからね
伊達に何十年も存在してない

**デフォルトの名無しさん** · 2023/06/25(日) 23:12:11.63

>>726
まあ、単純に自分が主体のクレートを開発したいというのと、ndarrayだと、型指定が多くてpythonライクな感じにならないから。ということで設計思想がndarrayの中の人たちとは少し違う。

**デフォルトの名無しさん** · 2023/06/25(日) 23:23:38.08

>>731
だね

>>732
なるほどね
>単純に自分が主体のクレートを開発したい
ver0.2.0で止まったりするとけっこう黄色信号で、せっかく技術力を誇示してもコミュ力評価が落ちるから
逆にコントリビューターが来るくらい頑張ってね

**デフォルトの名無しさん** · 2023/06/25(日) 23:34:38.25

>>683
ただ、ndarrayベースだとnumpyの様にas_typeとかreshapeを実装しにくい。self.reshape(shape)って感じにしにくい。APIは出来るだけnumpyに寄せたいのでそこら辺は少し困ってる。後、pythonでnumpyのfor文を回したときとの時間はまだ倍程度にしかなってない。自分で一から実装するべきかもしれない。

**デフォルトの名無しさん** · 2023/06/25(日) 23:36:37.70

>>734
倍速いってことねrustで開発中のクレートの方が。

**デフォルトの名無しさん** · 2023/06/25(日) 23:50:29.91

>>734
numbaでnjitした時との比較かどうかを明記した方が良い

**デフォルトの名無しさん** · 2023/06/25(日) 23:59:18.24

>>734,735
あとnumbaはparallel=Trueで簡単に並列処理が出来るから、速度優位を主張する時は
numba @njitは大前提で、parallel有り無し、自分のクレート(parallel有り無し)のデータを出さないと
見向きもされない

**Ndarray** · 2023/06/26(月) 00:46:15.23

タスクによるけどrayon使うと爆速になるものもあるな。1000倍以上早くなったタスクがあったのは驚いた。

**Ndarray** · 2023/06/26(月) 00:58:10.58

>>738
これ、勘違いだった。

**デフォルトの名無しさん** · 2023/06/26(月) 02:54:14.98

AVX512(zmm レジスタやEVEX)を使った高速化は、時代錯誤と言われる様になるぞ。
最新のCPUでは事実上使えなくなるらしいから。
命令表の表だけの行数(rowの個数)だけでも3500にも及ぶ複雑な体系を
沢山勉強しても、結局無駄になった。

**デフォルトの名無しさん** · 2023/06/26(月) 03:04:47.51

2020/04 にAMDがAVX512対応を表明して、実際に対応したと
思ったら、2022/03くらいで、IntelがAVX512を廃止する以降を
発表したとか。
そうやって競合企業を混乱させて弱体化させようとしている。
経営学における「陽動作戦」に近い。

**デフォルトの名無しさん** · 2023/06/26(月) 03:10:21.41

要素数を即値などで指定できずに、命令自体を買えてしまうので、
Intel準正のC/C++コンパイラ以外では、CPUが出てから対応に
時間が掛かる。ベクトル型スパコンでは、要素数を即値などで
指定できていたらしいのと対照的。
つまり、Intelが自分だけが優位に立てる作戦になっている。
命令のニモニックを分かりにくくすると同時に命令の個数や
オペランドの組み合わせをやたらと増やし、アセンブラ表記も
アセンブラの修正を必要とするようなものにしてしまうことで、
Intel純正開発環境以外では、対応に時間が掛かるようにしてある。
複雑すぎて人間の頭にはInputすることすら大変になり、全貌を把握する
のに膨大な時間が掛かる。複雑すぎて、サードパーティーのアセンブラや
コンパイラがバグ無く動作するのは難しい。コンパイラ作者の勘違い
があれば、バグになるから。

**デフォルトの名無しさん** · 2023/06/26(月) 03:13:27.69

Intel CPUの特徴は、アセンブラのニモニックが異常に分かりにくく、
Intel C/C++ コンパイラの intrinsic(組み込み関数)の表記は
少し分かり易い。
それで、純正コンパイラに誘導する作戦なんだろう。
アセンブラのニモニックも分かり易くしようと思えば出来たはず
なのに、高価なC/C++コンパイラを買わせるために、わざと
アセンブラを難しくした。
経営的には、参入障壁を上げ、模倣をしにくくし、自社だけに
有利なようにする戦略と考えられる。

**デフォルトの名無しさん** · 2023/06/26(月) 03:59:18.29

iclっていつのまにか無料だぞ(サポートが有償)

まあIntelほどの巨人でも、生き残りは大事だからな
我田引水は程度問題

**デフォルトの名無しさん** · 2023/06/26(月) 07:18:24.97

Linux のプロセス管理メモリ管理はピンピンコロリ作戦

**デフォルトの名無しさん** · 2023/06/26(月) 08:03:04.93

>要素数を即値などで指定できずに、命令自体を買えてしまうので、

>命令のニモニックを分かりにくくすると同時に命令の個数や
>オペランドの組み合わせをやたらと増やし

インテルはいってるは命令の一部に即値が入ってるアーキテクチャーが好きなだけ
つまりオペコード＝「オペコード＋オペランド」であって
「オペコード＋オペランド」であることには変わりない

**デフォルトの名無しさん** · 2023/06/26(月) 08:32:14.95

インテルどこ言ったんだよと思ったのはここだけの秘密です

**デフォルトの名無しさん** · 2023/06/26(月) 12:47:27.83

tokioとrayonの機能の違いを教えて！

**デフォルトの名無しさん** · 2023/06/26(月) 13:50:58.77

ここでは教えたがりの無能からしか回答が来ないので自分で調べることをおすすめします

**デフォルトの名無しさん** · 2023/06/26(月) 14:06:01.49

rayonは並列スケジューラ
tokioは並行並列スケジューラ
どちらもワークスティーリング方式でジョブ/タスクを効率よくスレッドに割り当てて並列処理してくれる点では同じ
しかしファイルやネットの読み書きなどで待ち時間が発生する場合に
スレッドからそのタスクを一旦外して他のタスクを割り当てる並行処理も行なうほうが効率がよい

**デフォルトの名無しさん** · 2023/06/26(月) 14:44:21.67

>>720
Rustのndarrayにはrayonベースで非同期ライブラリが組み込まれてるっぽいけど。

**デフォルトの名無しさん** · 2023/06/26(月) 15:40:30.64

常に同期して進めるわけでなければ非同期なので、非同期の並列は普通に起こり得て、非同期はそれ単体ではその観点で大した意味はないね
意味を持つのは非同期での並行、例えば一番わかりやすいのはシングルスレッドで非同期で並行して動作するJavaScriptかな
内部実装的には効率のためI/Oでマルチスレッドを使う実装もあるけど、シングルスレッドでも非同期に並行処理の実装が可能
各プログラミング言語のうちシングルスレッドでも並行に動作するpromiss/futureを持つ場合がこれに該当し、シングルスレッドでもasync/awaitで動作できるなら非同期な並行で動作してる
一方でJavaScriptはシングルスレッド内でしかasync/awaitの並行処理ができないけど、tokioなどはマルチスレッドで並行並列処理ができる
rayonはこの非同期な並行はできない

**デフォルトの名無しさん** · 2023/06/26(月) 16:07:13.82

>>751
マジ？
俺のアイデアパクられたかと思ったがあくまでプラグイン的な感じみたいね
俺のアイデアは非同期パイプラインベースの上で数値計算を行うこと
これができるのはtokioのみ

**デフォルトの名無しさん** · 2023/06/26(月) 16:18:30.02

何度も言うがなぜ非同期パイプラインを使うのかというと複数ノードで計算できることを想定に入れているから
その時点で俺のアイデアがずば抜けてることがわかると思う

**デフォルトの名無しさん** · 2023/06/26(月) 16:38:46.43

rayonっての知らなかったから調べてみたけど
やはり複数ノードは絶望的だな
しかしメソッドチェーンで数値計算を行うという俺のアイデアとかなり似たことはできるっぽくセンスの良さは感じる

**デフォルトの名無しさん** · 2023/06/26(月) 16:53:45.74

Vector SIB(VSIB)が良く分からない。
* vm32{x,y,z}
index レジスタが、xmm, ymm, zmm の中に 32BIT の個々の要素として入る。
* vm64{x,y,z}
index レジスタが、xmm, ymm, zmm の中に 64BIT の個々の要素として入る。
というところまでは分かったと思う。

[base + index * scale + disp]
で base は、GPR(RAX,RBXなど)、index が、xmm/ymm/zmm になっている。
float32 に対する vm32x の場合は、EA(Effective Address)が、
EA = base + xmm[i*4] * scale + disp
(i = 0,1,2,...,3/7)
の様になる感じ。
但し、xmm[i] で xmm の iバイト目から始まる DWORD みたいな意味になる。
でも、

Table 2-13. 32-Bit VSIB Addressing Forms of the SIB Byte
の
Note
1. If ModR/M.mod = 00b, the base address is zero, then effective address is computed as [scaled vector index] + disp32. Otherwise the
base address is computed as [EBP/R13]+ disp, the displacement is either 8 bit or 32 bit depending on the value of ModR/M.mod:
MOD Effective Address
00b [Scaled Vector Register] + Disp32
01b [Scaled Vector Register] + Disp8 + [EBP/R13]
10b [Scaled Vector Register] + Disp32 + [EBP/R13]

の部分の意味が分からない。

**デフォルトの名無しさん** · 2023/06/26(月) 17:06:57.57

>>756
分かって来た。
これは、base が 2進数で 101 の場合の話で、注意が
必要な場合に言及していたんだ。
特に難しいことは無いようだ。
もともと 32BIT の x86 で、SIB が無い ModRB で [d32]
だった箇所が、AMD64で、[RIP+d32]に変更になったので、
混乱を招き易いので注意書きを書いているだけらしい。
但し、SIB が有る場合の、mod=00、base=101 の場合の該当箇所は、
x86でもx64でも、[d32 + sclae * index] の意味になっていて、
特に混乱が無い。
SIBが有る場合は、mod != 00 の場合でも、x86、x64 で特に違いが
見られない。
だから、この注意書きは、もともとそんなに注意を必要とする部分
ではないと思う。逆に注意書きを書くことで混乱を招きそうな
気もする。

**デフォルトの名無しさん** · 2023/06/26(月) 18:11:27.20

いったい何のスレで何を見せられているのだろうか？

**デフォルトの名無しさん** · 2023/06/26(月) 19:15:53.61

いったい隔離スレに何を求めているのだろうか？

**デフォルトの名無しさん** · 2023/06/26(月) 21:51:11.03

スレに合った話をするか。
CやC++よりもRustの方が優れてる。
1)RustはCやC++と比べてセキュリティ的に圧倒的に勝ってる。
2)rust anslyzerはかなり優秀。
3)非同期処理や並列処理周りのライブラリが優れている。
4)CやC++みたいにコンパイラが乱立してない。

**デフォルトの名無しさん** · 2023/06/26(月) 22:02:08.35

4は「乱立」って言葉使って誤魔化してるが欠点だろーが?w

**デフォルトの名無しさん** · 2023/06/26(月) 22:14:55.18

予めネガティブな言葉を使うことによりさもそれが悪いことかのように見せかける詭弁のテクニックだな
「C/C++はコンパイラが複数ある。Rustは一つしかない」だとネガキャンには弱い
だからここぞとばかりに貶めるネガティブな言葉を使ったワケだ。
これが宗教戦争の端緒だよ
これに「○○言語を使ってる人間は劣っている」とかの人格批判まで加われば立派な宗教だ

**デフォルトの名無しさん** · 2023/06/26(月) 22:15:59.04

ところでC++にはtokioやrayonにそれぞれ相当するものがないのですか？

**デフォルトの名無しさん** · 2023/06/26(月) 22:20:21.85

あるのかないのかは知らない
ないのかもしれないけど大規模なプロジェクトでC++は使われているだろう

**デフォルトの名無しさん** · 2023/06/26(月) 22:37:03.61

>>763
C++ならtbbかな
あと非同期イベントループ使いたいならlibuv
しかしそれらを組み合わせることは不可能
tokioの素晴らしさは自分たちで非同期の仕組み自体を作れるところ

**デフォルトの名無しさん** · 2023/06/26(月) 23:19:03.58

>>765
それらはレベルが低すぎて対応するものではない
libuvはLinuxでいうところのepollシステムコールのイベントループにタイマとウォッチャの毛が生えた程度のライブラリ
使い勝手はコールバックを駆使する昔の不便な時代なもの
そしてスレッドセーフでないためシングルスレッド用
Rust tokioやGoのような高機能で使い勝手の良いものはC++に存在しない

**デフォルトの名無しさん** · 2023/06/27(火) 01:24:43.67

Rustって型を抽象的にしてもあまり実行時間に変化がない？ゼロコスト抽象化と言ってるけど。

**デフォルトの名無しさん** · 2023/06/27(火) 01:51:51.98

なにいってんだおめ

**デフォルトの名無しさん** · 2023/06/27(火) 03:21:29.26

>>762
こういうものには、カルト構造が有り、
本当に「信者」という言葉がふさわしいと言われている。

**デフォルトの名無しさん** · 2023/06/27(火) 03:37:30.86

AVX512 は、非推奨(deprecated)で、第12世代 Core i
シリーズの Alder Lake からは、デフォルトで disableになる
とのこと。重い処理用に用意されている P コアではまだ使えるが、
低消費電力の E コアでは、AVX512 が使えない。
どちらが使われるかは OS が切り替えて、どちらになるかは
アプリが決められない(?)ので、AVX512 が使えない、みたいな
話らしい。知らんけど。
こうなった根本原因は、AVX512にはそもそも熱狂的人気が無かったから
なんだそうだ。SIMD命令だけが速くなるだけで、数値計算プログラム
においてすら、全体的には数%しか速くならないのに、電力消費は
25%位も多くなる、という困った事になっていたそうだ。
SIMD命令はプログラムの自由度が低過ぎるし、お膳だてのための
オーバーヘッドがかなり掛かってしまう。
そもそも、今や、乗算、除算ですらかなり速く計算で来てしまうので
SIMDにするメリットより、デメリットの方が多くなってきつつある。
なでなら、SIMDにするためには、離れた要素をmergeしたり、
maskパターンを用意したりする必要があるが、それに時間が
掛かってしまう。いまや乗算なんて、10クロックくらいしか掛からない
のに、maskパターンを用意するのにそれよりも多く掛かってしまう可能性
があるので、SIMD命令を使ってもトータルではほとんど速くならない
ことが多くなってきている。
さらに、加算(add)や減算(sub)なんて、もともと1クロックで
実行できてしまうし、本質的に並列化できる場合には、
1クロックで4命令程度は同時実行されることがある。
だから、SIMD命令を使わなくてもループ命令を
展開するだけで、勝手に同時実行される場合がある。
だから、SIMD命令の高価がほとんど無い事が多くなってきている。

それに対して、マルチコアによる同時並列実行は、とても上手くいく。

**デフォルトの名無しさん** · 2023/06/27(火) 03:45:53.40

わかったから
使うほうが早いのだから使うんだよ
わからんやつだな

**デフォルトの名無しさん** · 2023/06/27(火) 03:58:12.99

>>771
特殊ケース以外は、微妙に速いだけだろう。

**デフォルトの名無しさん** · 2023/06/27(火) 03:59:31.74

どうせ、研究目的とかで、非常に非現実的な
例で実験して速くなった、とか言っているに一票。

**デフォルトの名無しさん** · 2023/06/27(火) 04:00:43.55

そんなに速くなるんなら、廃止する理由が無い。
便利でも無いし、単純なマルチコア実行に比べれば、
遅いし。

**デフォルトの名無しさん** · 2023/06/27(火) 04:04:45.59

マルチコア実装が理想的な動作をしないから仕方がない
手元のコードを通してしか動作を見れないのだから仕方がない

**デフォルトの名無しさん** · 2023/06/27(火) 04:05:34.80

もちろんマルチコア「も」使うんだよ
さらにプラスアルファで搾り取る
そのためのSIMD

**デフォルトの名無しさん** · 2023/06/27(火) 04:09:08.60

そもそもデータって、色んな場所に散らばっている。
しかし、SIMD命令で演算するためには、それらを
1つの場所に集めてくるか、VSIBを使わなければならない。
しかし、それが効率よく出来ない。
マルチコアでやれば、そのような手間が無いため、単純に
速度がコア数分だけ倍増するが、SIMDだとそうはいかない。
SIMDで高速化できるのは、数値計算に限定しても、
気象シミュレータの様に場合分けが少なめで単純な
メッシュで計算自体は場合分けが無くて同じ事の単純な
繰り返しになっている場合に限られる。
レイトレーシング、剛体力学計算、パーティクル計算、
量子シミュレータなどは、同じ事の繰り返しにはしにくい
ので SIMD で高速化するのは難しい。
一方、マルチコアで高速化するのはSIMDに比べれば
簡単である場合が多い。

**デフォルトの名無しさん** · 2023/06/27(火) 04:10:31.41

あとAVXは廃止されてないぞ
Xeonでは普通に使えるし
コンシューマー用の製品でもAVXを復活させるらしい
なぜならAMDが対応したから
AVX大戦国時代に突入が確定
普通のコア側の性能が完全に頭打ちなのだから
これまであまり活用されてなかったAVXなどのSIMDが今まで以上に大事だ

**デフォルトの名無しさん** · 2023/06/27(火) 04:10:37.14

>>776
SIMDでは微妙に高速化されるだけだろう。
マルチコアするための「スペース」が減ってしまう。

**デフォルトの名無しさん** · 2023/06/27(火) 04:15:00.63

やはりこれから数値計算にはAVXは当たり前のようになりそうだな
mojoというプログラミング言語もSIMD構造体を使えるし
juliaでもSIMDモジュールがある
ライブラリ作者が勝手に最適化するのはもはや義務となりそう

**デフォルトの名無しさん** · 2023/06/27(火) 04:16:41.02

そういう意味ではrustのstd::simdなどが標準モジュールに入ってきたのもこの流れを受けてのことだろう
rustのコア開発者は流行りに敏感だ

**デフォルトの名無しさん** · 2023/06/27(火) 04:24:09.85

これを読め

Intelが将来登場するCPUで再びAVX-512に対応する模様。AMDに対抗するため。
https://gazlog.com/entry/intel-avx512-rebirth/

**デフォルトの名無しさん** · 2023/06/27(火) 04:26:37.65

とはいえ並列数が少なすぎるというのは同意
GPUの数万スレッドと比べるとあまりにも差がある

**デフォルトの名無しさん** · 2023/06/27(火) 05:30:53.79

なんかの避難スレみたいになってるようだけど、自由にしゃべっててくれ
C++派だが、Rustの奴がガチな話してるの見るのは刺激になっていい
適当に流し読みしとくから

**デフォルトの名無しさん** · 2023/06/27(火) 10:58:25.30

IntelとAMDで使えるAVX命令がオワコンと思ってた人がいるみたいですね
さらにサーバー用CPUの存在も知らなかったのか？
無知って怖い

**デフォルトの名無しさん** · 2023/06/27(火) 11:51:09.37

多分win12か13でAVXの対応有り無しで足切りがあると思うわ
AVX使わない理由がない

**デフォルトの名無しさん** · 2023/06/27(火) 11:57:06.05

今までセレロンでAVXは無効化されてた
急にセレロンが無くなってそれ相当の後継CPUでAVX有効になってる

MSから通達があったんじゃないかな
次のOSでAVX必須にしますって

MSだってコードはAVXありで統一したほうがテストが楽になる

**デフォルトの名無しさん** · 2023/06/27(火) 12:01:56.73

中途半端に新しいCPUも名前はセレロンのままにして
AVXで足切りすると一般ユーザーは自分のPCが足切り対象かどうかわかりづらい

それで名前を変えた
セレロンではwin12は使えませんと言えれば楽だから

**デフォルトの名無しさん** · 2023/06/27(火) 12:06:05.20

tokioとasync-stdはどちらが使いやすいの？

**デフォルトの名無しさん** · 2023/06/27(火) 12:29:11.86

>>789
個人的にはasync-stdが好きだったが
tokioの充実度とtokio前提クレートの増大によりasync-stdを捨てた

**デフォルトの名無しさん** · 2023/06/27(火) 14:29:16.42

インテルの新しい仕様でAMXというのが搭載される模様

これはまさにディープラーニング用の命令セットで見る限りGPUの設計思想を持ってきた感じ

https://www.intel.com/content/dam/www/central-libraries/us/en/documents/2022-12/accelerate-ai-with-amx-sb.pdf

浮動小数点数の演算でAVX-512より16倍高速らしい

わかりやすいAVX/AMXの解説
https://zenn.dev/herumi/articles/granite-rapids-sierra-forest

今、CPUが熱い

**デフォルトの名無しさん** · 2023/06/27(火) 14:47:05.10

やめろPen4のおもいでが (その熱いじゃない

**デフォルトの名無しさん** · 2023/06/27(火) 19:28:14.66

ただ、12世代 Core i では、一時的であるにせよ、
AVX512が使えないような状態になるって事
だよね。

**デフォルトの名無しさん** · 2023/06/27(火) 19:39:04.70

どうやらCPUが復権するみたいだな
AMXのレジスタ数を見るとまたまだGPUには及ばないが
GPUメモリへの転送がクソ遅いことを考えるとワンチャンあるのか？
https://fuse.wikichip.org/news/3600/the-x86-advanced-matrix-extension-amx-brings-matrix-operations-to-debut-with-sapphire-rapids/
とりあえず早く使ってみたい

**デフォルトの名無しさん** · 2023/06/27(火) 20:47:43.85

GPUはCPUでは速度低下するような大量の計算に向いてる
少ないとCPUに完全に負けるパターンが多い

**デフォルトの名無しさん** · 2023/06/27(火) 21:22:42.14

Rustで数値型みたいのってないの？一々132,i64, f32, f64とか宣言しないとダメなの？