結局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/23(金) 18:29:00.54

>>594
BLAS
Complex Linear Algebra

**デフォルトの名無しさん** · 2023/06/23(金) 18:35:21.00

Rubyは、パッケージシステムやインストーラーを強要しなかったから
普及したが、node.jsは強要したので普及が遅いかも。
Rustもcargoを強要するのでダメ。

**デフォルトの名無しさん** · 2023/06/23(金) 18:46:22.56

>>601
水深4000フィートまで耐えられるよう建造して
水深4000メートル潜ろうとして途中で水圧に耐えられなかった
長さの単位が統一されていないUSAだから起きた
メートル法に統一しているべきだった
この件はプログラミング言語は関係なさそうだ

しかし似たような事例で文字エンコーディングの不統一のためのバグが昔あった
Rustなら言語レベルでstrとStringがUTF8に統一され正当性チェックもあるため
入力の間違いやプログラムの間違いで取り違えたまま実行されることはなさそうだが

**デフォルトの名無しさん** · 2023/06/23(金) 18:46:27.54

Rustは全体的に、実際の使い方を無視した作り。

**デフォルトの名無しさん** · 2023/06/23(金) 18:52:53.90

>>603
cargoを使いたくないなら使わなくても使える
$ rustc foo.rs
これで実行可能バイナリfooが作られる
$ ./foo
あとはrustc --helpなどを見てくれ

**デフォルトの名無しさん** · 2023/06/23(金) 18:56:09.97

>>606
恐らくそれだとcrateが使えないので、cargoを強要される。
C/C++ではありえない設計思想。

**デフォルトの名無しさん** · 2023/06/23(金) 18:57:27.27

そして、crateを使うことで、オープンソース思想に染まった一員
のようになってしまい。オープンソースが指示されているかのような
嘘の証拠を作ってしまう。

**デフォルトの名無しさん** · 2023/06/23(金) 19:30:18.50

オープンソース思想っていうか、オープンソース世代だね

プロプラもオープンソースも貪欲に利用できる大胆さがほしいね

**デフォルトの名無しさん** · 2023/06/23(金) 19:31:29.42

また、cargoを使うことで、exeサイズの増大が起きるだろう。

**デフォルトの名無しさん** · 2023/06/23(金) 19:53:35.15

>>607
できるよ
まずクレートbarをコンパイル
$ rustc --crate-type=rlib bar.rs
ライブラリファイルができた
$ ls -l libbar.rlib
ライブラリのある場所を指定してコンパイル
$ rustc -L . foo.rs
できあがったので実行
$ ./foo

**デフォルトの名無しさん** · 2023/06/23(金) 19:55:15.02

しかし、現実的に出来ないんだろうて。
そんなに簡単なら、cargoなんて不要なんだから。

**デフォルトの名無しさん** · 2023/06/23(金) 21:20:51.32

SOのサーベイの所得プロットなんだけどZigの所を見る限り、普通に受け止める「言語別所得」と違う
https://survey.stackoverflow.co/2023/#section-salary-salary-and-experience-by-language
https://www.itmedia.co.jp/news/articles/2306/23/news109.html
https://image.itmedia.co.jp/news/articles/2306/23/l_dy_fig_04.png

まずZigの平均経験が10年以上が有り得ない(Zigは2016～)
あと、ホバーすると出てくる数字だと
$103,000 * 259 = $ 26.7m = 38億円となって、
現段階では純Zig案件でこんな額は注がれてるイメージが出来ない
(せいぜいZig Software Foundationトータルで$1m寄付が有るか無いか程度)

言語別というより、言語扱う人別(複数延べ)データとして見ないと可笑しなことになる

Zigの場合は、250人位が仕事は他言語、完全趣味+OSSでZig、の方が近いのでは

**デフォルトの名無しさん** · 2023/06/23(金) 21:27:03.23

cmakeやcargoが必要なのは、gccとllvmの仕様が統一される保証がないから？

**デフォルトの名無しさん** · 2023/06/23(金) 22:27:58.10

それと愛され言語の呼び名が変わったけど
https://survey.stackoverflow.co/2023/#technology-admired-and-desired
Go
desired-admired
20.59%-62.45%
所得プロットでの"人数" 6650

これも下と比較すると全く整合性がない
https://go.dev/blog/survey2023-q1-results
satisfied = 92%
n=5280

調査による差が激し過ぎでは

**デフォルトの名無しさん** · 2023/06/23(金) 23:53:15.64

>>602
何かBlasはndarrayクレートのオプションをfeatures = ["blas"]で、Cargo.tomlに設定すると使えるらしいですよ。

**584** · 2023/06/23(金) 23:59:58.87

>>587
いや、俺が見かけた話は CH32V003 でなく CH32V203。

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

間違えた。俺は584でなく586だった。

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

かつて日本人が1000人いたら、300人くらいはNECのマシンを
買ったことがあった。
RedHatはかつてのNEC以上に大儲けしていることになっているが、
fact checkが必要で、1000人いても、一人も世話になってない
気がするぞ。
つまり、オープンソースはfakeだらけなんじゃないの。
だれが、Linuxのサポートなんて必要としているものか。

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

そもそも、そんなに大人数の会社のサポートが本当に儲かっている
なら、誰でも真似できるはず。RedHatに優秀な人材なんて
入社するわけ無いんだから、その辺のマクドナルドのアルバイト
みたいなのにコールセンターで「サポート」させればいいだけ。
でもRedHatに続く企業が現れないと言うことは、RedHat
は、左翼によって捏造された企業である疑いが濃厚。
いつも左翼はそうやって嘘を付いて人々を操る。

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

RedHatなんて、多分に嘘だろうけど1万9,000人も社員がいて
年間4000億円もの収益があるとされている。
サポートで収益がそんなにあるわけない。
誰がそんな有象無象の社員の電話サポートなんて必要とするものか。
じゃあ聞くが、Windowsのサポートなんて何回電話したこと有る？
無料でさえ電話しない。
金取るのにそんな電話するわけ無い。
つまり、捏造。
オープンソースは、カルト宗教で信者達が捏造しているに決まってる。

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

1万9,000人もコンサルタント(?)がいて、そんな人のアドバイスで
ことが改善するわけ無いことは、誰の目にも明らか。
カルト宗教の力が無ければ、とっくに衰退しているはず。
そもそも技術力が無いから、サポートが必要なOSにしか育て
られないわけで、サポートを必要とするのは技術力が無い
ことの証明になっている。
そんなことは、誰でもわかることで、パッパラパーでなければ、
そんなテレホンサポートになんて金払って電話するわけ無い。
カルト信者の集団捏造に決まってる。
githubは、中国の国営企業がスポンサーの大多数を占めていて、
共産主義のプロパバンダ組織になっている。
そして、5chのLinux板とプログラマ板は、中国の五毛党による
工作活動が盛んで、オープンソースと社会主義を礼賛ばかりしている。

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

あのーCppとRustのどっちが良いのかと関係ない話すんのやめてもらえますか？

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

SDGsで考えれば、そんなカルト宗教集団の作ったものを使うことは、
カルト宗教に利することになってしまうからダメだ。

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

>>619-622
まーた始まった
書き込みを見ていると長いこと生きている筈なのに
なーんでそんなに世間知らずなの?

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

また五毛党のオープンソース支持が始まったぞ。

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

若いと、世界が制御下におかれていることが分かって無い。
学校では世界がまるで実力社会であるかのように教えるからな。
現実は嘘つきや捏造であふれかえっている。

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

そもそも、平均寿命が日本より8.15歳も短い国がまともなわけが無い。
人権だ自由だなんて言っても、実際には助ける振りしてるだけで
人を助けないし。
最近じゃ彼らの思う「自由」の限界が来て超監視社会になっている。
アメリカではネットすら監視装置として使うことが当たり前になっているし。
当然日本の個人も監視されている。
これは妄想ではない。スノーデン氏などのハッカーにも指摘されているし。
アメリカのGDPが高いのも、はっきり言って寿命が短いからだろう。

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

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