結局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(日) 15:15:05.11

rustでそこまで型を気にしなくてよくてnumpyと殆どAPIが一緒で実行速度も十分なライブラリができれば、rustはもっと流行ると思う。ということでまずはrustのndarraryクレートベースで作っておいおいndarrayクレートの中身もAVXやrayonで最適化を目指す感じかな。

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

>>670
この本がめちゃくちゃわかりやすかったよ
https://www.cutt.co.jp/book/978-4-87783-387-9.html

この本は数値計算で必要な概念が全部説明されてるしおすすめ
というかこんなニッチな分野独学以外無理

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

unsafe はガン細胞のようなもの
unsafe を散らすのが Rust
unsafe のままそっとじするのが C++

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

同じ著者のこれもおすすめ
https://www.cutt.co.jp/book/978-4-87783-369-5.html

よく使うAVX命令がほぼ全て説明されてるが機械的なので上の本を読んでからの方が良い
内容はかなり被ってる

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

>>676
物事はそう単純じゃない
pythonみたいに何も考えなくても使えることに意味がある
rust勉強しなければ使えないライブラリはあまり普及には意味がない

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

AVX512(zmm)は、使えないCPUもあると思う。
Intelでも少し古い場合や、AMDだと最近のものでも
使えない場合があるはず。
GPUだと、コア数が少なくなってもそれなりに動くが、AVXだと
ハングアップするだろう。

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

SIMDに対応するかどうか判定することもできるので分岐でもなんでもしたらいい
さらにベクタ長を出すこともできる
ループのところでベクタ長で割ってループさせる
ベストプラクティスは知らんけど動く

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

まあndarrayは使いにくいと思う

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

それにIntelのSIMDは、並列化の度合いが少な過ぎる。
AVX512ですら、float32で、やっと16倍個同時では、そんなに高速化
はできない。なぜなら、計算の前と後の処理に時間が掛かるので。
それに科学技術計算では、float64 が基本だから、AVX512ですら、
中核部分ですら8倍にしかならない。
それに8倍といっても、基本的に掛け算や足し算の計算部分だけが
8倍になるだけだし。
実際には、ソースや結果(デスト)のコピーやループしたりするのに時間が掛かる。
GPUだと、計算以外のコピーの部分まで高速化できる可能性がある。

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

Intelも設計の悪さにやっと気付いたらしく「、AVX512は廃止される
らしい。
数%しか速度向上しないのに、電力が23%位上がってしまうのだとか。
だったら、GPUみたいにした方がいい。
GPUだと、コア数に比例して速くなるはずだから、集積度を上げるだけで
速度はいくらでも上がる。問題は電力使用量。
だから、電力を如何に抑えるかが重要になる。
それだのに、電力が異常に上がってしまうAVXは設計が悪すぎる。
そもそも、Intelは命令セットの全体的な設計力には昔から問題が有る。

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

その結論はCPUによる高速化は効率が悪いからしないほうがいいと言うことか？
だったら愚かな人間の考えはやはり愚かと言うことだよ

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

Intel、超高速AVX-512ソートライブラリを公開、Numpyが10〜17倍高速ソートに対応
masapoco　投稿日：2023年2月16日 16:35
https://texal.jp/2023/02/16/intel-publishes-blazing-fast-avx-512-sorting-library-numpy-switching-to-it-for-1017x-faster-sorts/

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

AVXの場合、乗算と除算、加算、減算のような中核部分だけが
速くなるだけ。転送はデータバスのビット数のまま。
だから、限界がある。
データバスが64BIT程度では、どうにもならない。
一方、GPUは、完全に並列化できるので、コア数に比例するような
速度向上が見込めるはずだ。知らんけど。
それに、レイトレーシングの様なものを並列化するのは、SIMDでは
無理が有る。

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

CPUとGPUは別売りできるからもしGPUは要らないと思ったらクビにできる
抱き合わせ販売は解雇規制みたいなもの

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

>>686
CPUによる高速化もやるべきだけど、SIMDはとても扱いにくい。
効果が小さいのに、知るべき命令数が多すぎるし、分かりにくいし。
しかも、たかだか中核部分ですら16倍にしかならない。
しかし、それをするための準備にオーバーヘッドが大きすぎて、
典型的には1.3倍とかにしかならないらしい。

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

そもそもnumpyはBLASのラッパだということを理解してるか？

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

SIMDでもなんでもかんでも早くなるわけでもない
ただ自分のところではメソッドレベルで処理速度が80倍近くまで上がったものもあった
全体に占める処理量は多くないが驚異的

AVX利用できるのにしないのは何故なのかと言えば
単純に知識がないので使えないからと言うだけだろう

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

>>692
>ただ自分のところではメソッドレベルで処理速度が80倍近くまで上がったものもあった

x87 FPUはスタックマシンで、SSE の xmm/ymm/zmm 系は
レジスタマシンだからではないのかな。
AVX512ですら、速くなるのは最大でも16倍程度のはずだ

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

GPUはもう科学計算の分野では遠い存在になりつつある
あまりにもコストが高すぎる
今後どんどん上がっていくだろう
もう普通の大学や企業で研究開発の一部で使えるものではなくなった
今こそCPU復権の時だと思っている
シングルノードでカリカリにチューニングした数値計算ライブラリが欲しいよ

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

>>694
そんなはずない。

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

>>695
いくらかかるかご存知？
まあ知らないのだろうけどw

**デフォルトの名無しさん** · 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

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