結局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/24(土) 01:32:20.34

アメリかは911事件によって、初めて恐怖を味わった。
それにより初めて自由を制限することこそ重要である事を悟った。
彼らは極端なので、超監視社会に移行した。
彼らはやっと、自由を制限しないと、自分の自由も守られない
ことを知った。
世界の国の何週も後を行っている国家。
嘘つき大国で、あらゆることが嘘。
Rust人気も嘘。github人気も嘘。オープンソース人気も嘘。
RedHatが大儲けしていると言うのも嘘。カルト信者の
集団協力により、数値が捏造されているだけ。

**デフォルトの名無しさん** · 2023/06/24(土) 01:43:01.82

>>621
決算捏造したら犯罪だよ
そんなことも知らんのか?

**デフォルトの名無しさん** · 2023/06/24(土) 01:48:07.36

>>630
・カルト信者による集団行動。
・ネットサポートなんて実際にやったかどうかの証拠が残らず
　事実かどうか確認できない。

**デフォルトの名無しさん** · 2023/06/24(土) 01:51:03.98

>>631
>>621
>RedHatなんて、多分に嘘だろうけど1万9,000人も社員がいて
>年間4000億円もの収益があるとされている。
この数字はどこから出した? 決算として公表されたものじゃないのか?

**デフォルトの名無しさん** · 2023/06/24(土) 02:19:05.92

アメリカのハッカー文化は中国の工作だった！？

**デフォルトの名無しさん** · 2023/06/24(土) 03:10:24.26

Linuxって寄付がおおきいんじゃなかっけ?
大企業でもその上でアプリを作って儲けようようという算段があるから
インターフェースだけしっかり作ってくれれば自社製品で使うのはそんなに
大変じゃない

日本との文化の違いだな

**デフォルトの名無しさん** · 2023/06/24(土) 05:49:32.16

Rustのndarrayはonesとzerosを高次元のの形状に関して実行速度を計測するとなぜかonesの時がzerosよりも6桁くらい実効時間が遅かった。これ、絶対バグあるな。

**デフォルトの名無しさん** · 2023/06/24(土) 06:02:34.14

かすだよ

**デフォルトの名無しさん** · 2023/06/24(土) 06:06:16.85

>>613
HTML/CSS がプログラミング言語部門の二位ってなんの冗談ランキングだ？

**デフォルトの名無しさん** · 2023/06/24(土) 09:17:43.46

数学100点マンが100点をとったのは何十年も前でマイクロソフトの一部の環境しか知らずオープンソースが大嫌いなのか

**デフォルトの名無しさん** · 2023/06/24(土) 10:03:50.07

非標準ライブラリを弄らないと何も作れないC
unsafeを使わないとライブラリを作れないRust

STLやboostだけでも成立する競プロ
出題範囲内だけで成立する何十年前の数学

**デフォルトの名無しさん** · 2023/06/24(土) 11:04:11.18

>>639
そろそろunsafeの意味を覚えろよ
unsafe ＝人間がコードの安全性を保証しなければいけない部分
C/C++はプログラム全体がunsafeであることが様々な問題を引き起こしてきた
そこでunsafeな部分をできる限り小さく限定することで問題を根本的解決することになった

**デフォルトの名無しさん** · 2023/06/24(土) 11:11:37.55

C/C++は、普通、やっちゃだめなところは避けて使う
当たり前のことを守れないコーダーが現場に大量導入されて今に至る

Rustは、普通、unsafeを最小化して使う
…おなじことになるだろ?

**デフォルトの名無しさん** · 2023/06/24(土) 11:32:51.54

>>641
Rustはほとんどのケースで一般プログラマーがunsafeを使う必要がない
もしunsafeを使っていたら厳重にチェックされ必要ないのにunsafeを使うプログラマーは排除される
どうしてもunsafeを避けられない構造が発見されると一般化されるとともにモジュール内に閉じ込められ多数の監視の元に管理される
Rustの標準ライブラリもそうしてできあがった

**デフォルトの名無しさん** · 2023/06/24(土) 11:33:07.59

デフォルト全危険　人間が責任を持たねばならないのが全域

デフォルト全安全　明示したところだけは人間が責任を持てば良い

同じと見るか違うと見るかは自分次第
ただしチームメンバーのことを信用できるか？　チームメンバーが自分を信用していると確信できるか？
ここを考えるとハゲ具合は一目瞭然やろ

他言語バインディング関連は…知らんので全部Rustで置き換えろ

**デフォルトの名無しさん** · 2023/06/24(土) 12:30:06.63

struct Hoge {
Foo* foo;
};

この構造体が所有するfooはこの構造体が所有しているのか？
所有している場合、他に外部で参照しているオブジェクトはないのか？
それは弱参照としての扱いかそれとも所有者として振る舞っているのか？
fooは共有されるのか？
fooの生存期間は？
fooの初期化方法は？
デストラクタなどで勝手に破棄して良いのか？
(他に参照がある場合、ダングリングポインタ発生)
このオブジェクトは変更されるのか？されないのか？
このオブジェクトがコピーされる時の動作は？
クローンすべきなのかムーブすべきなのか
ポインタのコピーで良いのか？

C/C++の問題点はこれに尽きる
何もわからないのだ
C++だともう少し明確になるが問題は変わらない
上記を全てクリアにするために文法や仕組みを考えたらrustになったと言う話

**デフォルトの名無しさん** · 2023/06/24(土) 12:53:31.49

>>639
>unsafeを使わないとライブラリを作れないRust

ほんそれ
はいはい御安全に

**デフォルトの名無しさん** · 2023/06/24(土) 12:55:13.50

>>640
>そこでunsafeな部分をできる限り小さく限定することで問題を根本的解決することになった

違うね
unsafeが散在して同じ事

**デフォルトの名無しさん** · 2023/06/24(土) 12:59:38.18

>>643
>デフォルト全危険　人間が責任を持たねばならないのが全域
>デフォルト全安全　明示したところだけは人間が責任を持てば良い

ネガティブリストの方が扱いやすいが漏れが発生しやすい
大規模になるとポジティブリストより面倒臭いぞ？

**デフォルトの名無しさん** · 2023/06/24(土) 13:03:08.56

>>644
おまいはドキュメントも参照せずにAPI利用する糞プログラマ

**デフォルトの名無しさん** · 2023/06/24(土) 13:41:17.82

C++ってまともなドキュメントなんてあったっけ

**デフォルトの名無しさん** · 2023/06/24(土) 13:41:50.49

> 必要ないのにunsafeを使うプログラマーは排除される

これができるかどうかだな

ま、unsafe使ったコード全部排除したらいいだけなんだが

**デフォルトの名無しさん** · 2023/06/24(土) 13:55:59.31

>>648
その観点でドキュメントAPIに全面依存の遅れた考えの人がまだいることに驚いた
ドキュメントは書き忘れたり書き間違えたり更新でコードと乖離したりするうえに
ドキュメントを読まない人や読み間違える人や更新された時に追随を忘れるなどミスは多岐に渡る
人間に大きく依存していることが敗因なので可能な限り自動チェック化が進められてきた

**デフォルトの名無しさん** · 2023/06/24(土) 14:13:04.49

>>650
> 必要ないのにunsafeを使うプログラマーは排除される
生ポインタやnewを直接使うプログラマーを排除すれば良い

**デフォルトの名無しさん** · 2023/06/24(土) 14:15:01.22

>>649
その「まともなドキュメント」の用途にもよるが
C++には規格書がある（Rustにはまだない）

**デフォルトの名無しさん** · 2023/06/24(土) 15:23:36.60

各企業がコンパイラを乱立し始めると統一のために規格書が必要となる
Rustは大手ITが手を組んでRust Foundationが支える単一コンパイラだから規格書は不要だろう

**デフォルトの名無しさん** · 2023/06/24(土) 15:32:23.38

既にrustcとrust-analyzerが異なるコードベースを独自に抱えてしまっていることすら知らずに、彼はそうつぶやくのだった

**デフォルトの名無しさん** · 2023/06/24(土) 15:59:34.51

言語を広めるために規格が必要だった時代があったんだよ
特に異なるプラットフォーム用に異なるコンパイラを各プラットフォームベンダが先んじて作らないといけなかった時代にはね

**デフォルトの名無しさん** · 2023/06/24(土) 16:16:21.63

>>644
c++なら「smart pointer使え」「const使え」「ポインタと自動変数を使い分けろ」だろ。
生ポインタは主に過去互換性のためのもので、新しいコードで使うものじゃ無いわな。

**デフォルトの名無しさん** · 2023/06/24(土) 16:22:08.74

>>653
規格書はあくまで規格書
言語を使うための必要な情報となるドキュメントにはならない

**デフォルトの名無しさん** · 2023/06/24(土) 16:33:30.41

生ポを使わないとスマポを定義できない点はブーメラン刺さってる

あとは、安全と自称するより何も自称しない方が謙虚だと思うかもしれないが
unsafeな箇所をunsafeと自称するのはもっと謙虚である

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

>>657
それならそのルールをコンパイラで強制したらいいじゃん
できるもんならね

**デフォルトの名無しさん** · 2023/06/24(土) 17:35:28.23

ナマポが危険ってのは
どこで必要になるか
どこがスコープでがスコープに入るか、もしくはstaticで参照して解放まで用意するか
どこで使わなくなるか
等の設計ができてないから危険と思うんだよね
こういうのが出来てないとポインタだけ危険とか言っても他の場所でバグらせそうな気しかしない
セマホみたいな排他制御で解放せぬまま進めたり終わらせて起動できなくなったり
さらに設計が出来て無い人からぐちゃぐちゃのソースになりそう

初めからどこで使ってプールするから解放は最後とか決めて書けば解放はほぼできると思うけどな

**デフォルトの名無しさん** · 2023/06/24(土) 17:50:09.49

>>660
自前のホルダーとファクトリーを定義すればだいたい強制できる。
生ポインタを晒す必要があるときが厳しいけど、global deleter以外はなんとか禁止できる。

c++標準にget()を無くしたsmart ptr欲しい。

**デフォルトの名無しさん** · 2023/06/24(土) 17:52:53.86

Rustのndarrayの改善点を自分なりに調査してまとめてみた。
1) 配列の型変換のサポートが微妙。
2) ブロードキャスト機能のサポートが微妙。
3) numpyと比べてユーザーが配列の中の型を一々意識する必要がある。
4) pytorchのtensor型が持っているような機能がない。(requires_gradとか)

**デフォルトの名無しさん** · 2023/06/24(土) 20:49:47.56

>>663
あとin-place modeを作ってくれ
特定の領域を一度アロケートしたらそれを使い回すような演算ができると良い
とにかく途中でメモリを消費しないように

**デフォルトの名無しさん** · 2023/06/24(土) 20:54:27.16

>>663
あとベクトル演算を自動で使ってくれ
AVX命令ね
https://zenn.dev/termoshtt/books/b4bce1b9ea5e6853cb07/viewer/simd

さらにスレッドを使うオプションも欲しい

**デフォルトの名無しさん** · 2023/06/24(土) 20:55:59.01

さらにいうと演算を一度グラフ構造に落とし込んで依存関係を解析し
依存ごとに並列実行してもらえるとありがたい
ここまでやるとガチで速いと思う

**デフォルトの名無しさん** · 2023/06/24(土) 21:01:14.04

どちらにしろrequires_grad入れるならこれをやらないと勾配計算できないから必須

**デフォルトの名無しさん** · 2023/06/24(土) 23:42:18.72

>>665
そこら辺はrayonでサポートされてる？

**デフォルトの名無しさん** · 2023/06/24(土) 23:51:57.35

numpyは自動でAVXとか使うようになってる

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

>>666
requires_gradは実装できそう。ただ、AVX命令は今のところRustの安定版ではサポートしてない感じかな。流石に情報学科の人間ではないからAVX命令とかのハードに近い部分の実装はムズいかな。ただ、型指定に関してはだいぶpythonの様に融通が効く感じにできてるとは思う。

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

rustではAVXの取り扱いがむずいの？
相性が悪いとか？

AVX自体は皆が思ってるより難しくない
やってることは大したことないんだけど
配列をポインタでグルグル回すだけ

利用も下請けの関数作ってそこに投げるだけなんだけどね

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

基本的にこんな流れ

配列AとBがあって
それぞれをポインタなどで指して
AVX命令でロードして計算して結果をどこかに吐き出す
ポインタを進める
これを終わりまで繰り返すだけで汎用性が高い
すでに誰かが書いたコードを丸パクリすることも簡単

誰にでも使える
でもみんな毛嫌いする

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

問題は都合の良い配列じゃない場合ｗ

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

>>671
RustでもnightlyでAVX使える
https://doc.rust-lang.org/core/arch/x86_64/index.html

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

>>672
AVX判ってないだろ

**デフォルトの名無しさん** · 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自体は単なるマルチノードでの通信ライブラリに過ぎない
これを使っている前提のソフトが多いって意味ね