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

結局C++とRustってど� ..

654:デフォルトの名無しさん
23/08/18 20:36:58.94 ISPaueS8.net
てかこれを理解できないのであればRustは習得できないんじゃないかね
Rustできるならわかるだろ

655:デフォルトの名無しさん
23/08/18 20:38:53.30 pJm/stU2.net
>>653
嫌なら配列使え、ということかね。

配列とスライスの表記に問題があるとは思うけど。[]と[1]で別物というのはやりすぎだわな。

656:デフォルトの名無しさん
23/08/18 20:40:40.07 VmqYer8d.net
余談
初期の開発中のC言語にはポインタは　int* じゃなくてint[]だった

657:デフォルトの名無しさん
23/08/18 20:51:02.38 NqAD2XrU.net
>>630
Goの何がおかしいのかわかった
C++やRustや他の普通の言語ならば
bがaのコピーならばその実験1～4すべてでaとbは異なる
bがaを参照しているならばその実験1～4すべてでaとbは同じになる
その二つのケースどちらかになる
Goは実験を進めるごとにaとbが異なったり再び同じになったり再び異なったりおかしい

658:デフォルトの名無しさん
23/08/18 20:54:15.45 VmqYer8d.net
わざと言ってるよねｗそれｗ

659:デフォルトの名無しさん
23/08/18 21:01:52.15 fjgGWx1p.net
なぜGoだけがそんな変な仕様にしちゃったの？
新旧の言語を見回してもそんな変な仕様の言語は存在しないよ

660:デフォルトの名無しさん
23/08/18 21:20:15.18 VmqYer8d.net
スライス自体は他も似たり寄ったりだよ
pythonは3で多分新しい配列を作る
多分appendの時に新しい配列をコピーしてそっちに代入するはず

元の実態を明確にコピーすると言わずにコピーするかどうかと言う設計理念の違いだろう
pythonは初心者向けだからそうしたgoはしなかった

661:デフォルトの名無しさん
23/08/18 21:24:30.15 VmqYer8d.net
配列の箱が並んだ絵でも書いてスライスは別のところに書いてポインタの矢印と長さでも書いてみれば理解しやすい

662:デフォルトの名無しさん
23/08/18 21:36:19.25 ISPaueS8.net
>>659
GoはC言語に近い言語だから
Cでmallocとかreallocとかを使って配列を扱ってたらよく理解できるはず

無駄なコピーを避けつつ、細かいメモリ操作も行えるようにして最適化の余地を残しているのがGoの特徴なので

663:デフォルトの名無しさん
23/08/18 21:36:31.10 pJm/stU2.net
>>659
スライスはrangeみたいなもので、スライスそのものはそんなに変なものではない。

問題はそこではなくて、
・スライスに「可変長なだけの配列」に見えるような表記を割り当てた
・真に「可変長なだけの配列」(vectorみたいなの)が存在しない
なので、スライスと配列を混同して使わざるを得ない言語設計が問題。

素直にCOWスライスを用意すればまだ良かったんだけどね。

664:デフォルトの名無しさん
23/08/18 21:41:06.14 VmqYer8d.net
Goのスライスは現実社会の物を表しているとも言える

1,2,3と書かれた箱が並べてあって、あるスライス（窓）が1,2を指しているとする
そのスライスに4の箱を追加されたとしたらどのようになるのが望ましいか

Goは現実世界のように1,2,4,3と箱が並ぶ
Pyothonはどこかから急に箱が表れて
1,2,4と言う並びの箱の列と1,2,3と言う並びの箱の列ができる

665:デフォルトの名無しさん
23/08/18 21:42:56.92 seEzfIxj.net
なるほど、スライスと言われてなんとなくわからんでもない挙動には見えてきた
でもやっぱりバグを呼び込むためだけの仕様にも思える
こんな仕様にして誰か幸せになるんかな

666:デフォルトの名無しさん
23/08/18 21:45:59.61 pJm/stU2.net
>>665
スピードマニア、つまりgo ユーザー。

667:デフォルトの名無しさん
23/08/18 22:01:59.17 UHKUI4sz.net
C++もRustもわかりやすい仕様だけどGoよりスピード出る

668:デフォルトの名無しさん
23/08/18 22:23:22.38 Jp8sOWVj.net
Goは言語設計をミスってるな

>>630
// 実験3: 要素の追加 (その1)
a = append(a, 777)

この部分は他の言語だとメソッド名こそ異なれど
a.add(777)
a.append(777)
a.push(777)
a.push_back(777)
となる
メソッド名は自由だがこの形式が正しい
Goの失敗の原点はここだ
a = append(a, 777)

669:デフォルトの名無しさん
23/08/18 22:31:11.69 7ABRPFiH.net
言語とライブラリを分離できないと潰しがきかない
C++の場合mallocやsjljを単なるライブラリではなく言語の一部にしたのが悪手

670:デフォルトの名無しさん
23/08/18 22:42:32.22 hfXr0Ior.net
>>668
go はオブジェクト指向じゃないからなぁ。

純関数にしやすいように、仮引数自体は変更しない設計にしたんじゃない？Rustも似たような思想だろ。

671:デフォルトの名無しさん
23/08/18 23:16:43.53 Xs4y23Ew.net
手軽というのは実際はただの手抜きなんだよ
その尻拭いをさせられてきた良識ある若者が次の世代のためにRustのようなものを産み出す
それを無自覚な老害が腐す

672:デフォルトの名無しさん
23/08/18 23:38:51.82 H/YqNwUg.net
>>629
標準ライブラリの範囲は言語ごとに異なる
Rustの方針は言語サポートが必要な機能を標準ライブラリとする傾向が強いため他より範囲が狭い
例えばRustの標準ライブラリに正規表現や乱数などは含まれていない
だからといってRustはそれらが扱えない、というのは正しくないように
標準ライブラリに入っているか否かはさほど重要なことではない
今回の例で言えばC++20のコルーチンもRustのasyncコルーチン(タスク)も意図的にそれ自体の機能のみを言語機能および標準ライブラリに入れている
コルーチンのスケジューリング機能など含めてほとんどの機能は標準ライブラリにない
それらは言語自体が直後サポートしなくても実装可能だからであろう
Rustの場合はデファクトスタンダードの地位を確立したtokioがあるため困ることはない

673:デフォルトの名無しさん
23/08/18 23:44:30.71 H/YqNwUg.net
>>647
気軽にの意味が多様だがRustでもGoルーチンのように気軽にタスクをspawnできる
もちろんチャネルも使えてGoスタイルのプログラミングをしたければそれも簡単にできる

674:デフォルトの名無しさん
23/08/18 23:52:18.58 H/YqNwUg.net
>>654
RustでVecだと最初のb = aの時点でムーブとなるためその問題は起きない
ムーブではなくb = &aとして参照にしても競合防止のため書き換えできず問題は起きない
Goでaとbが異なったり同じになったりを二転三転してるのはaとbが競合してると考えてもいいのかもしれない

675:デフォルトの名無しさん
23/08/18 23:57:19.87 H/YqNwUg.net
>>670
Rustはオブジェクト指向であってクラス継承の概念のみを排除している
だからそこではRustでもa.push(a)の形となりVec型の値(オブジェクト)が書き換わる
他の例でもイテレータはnext()する毎に値(オブジェクト)が書き換わる

676:デフォルトの名無しさん
23/08/19 00:22:06.39 yRRJwuXx.net
getterだけを公開すればオブジェクト指向だが
いつどこからsetされるか分からないコードはstatic変数に近い性質
それはオブジェクト指向ではない

677:デフォルトの名無しさん
23/08/19 00:59:21.18 78dnv4FG.net
>>676
「いつどこからsetされるか分からないコード」について
Rustは所有権もしくは可変参照を持たないと値を書き換えられないからコード上で明確にわかるよ
static変数については「いつどこからsetされるか分からないコード」によってデータ競合が起きうるのはその通り
しかしRustのstatic変数は(unsafeを除いて)可変(mutable)ではないため「いつどこからsetされるか分からないコード」によってデータ競合を起こすこともないよ
例えばRustのstatic変数をマルチスレッドで共有しつつ値を書き換えたいならばMutexなどによる内部可変性を与える必要がありデータ競合が必ず避けられる

678:デフォルトの名無しさん
23/08/19 01:55:38.87 3nD/Pt3g.net
こういう意味のない比較を少なくとも2年はずっと書き散らし続けて
何も生み出していないっていうね

679:デフォルトの名無しさん
23/08/19 06:12:11.05 ImsjC3MV.net
技術板のスレなのに無能が適当なこと書き散らすだけで他人が参考にならないスレ
板違いの雑談スレなんだからせめてageるな

680:デフォルトの名無しさん
23/08/19 08:18:21.33 7swIlm9f.net
Rust は安全(キリっ
ですね
わかります

681:デフォルトの名無しさん
23/08/19 08:30:53.11 EolsykgK.net
>>672
標準ライブラリのサポートは重要だろ
ちょっとしたことをやるだけでいちいちライブラリを選定する必要があり、コンパイルが遅くなる
CICDも遅くなるし、ライセンスもいちいちクリアしなくては行けない

同じく標準ライブラリが薄いNode.js使っててnode_modules肥大化問題に悩んでいる奴は多いだろう

例えばhttpリクエストするだけでもプロジェクトによってライブラリが異なる
ライブラリが異なるのでそれぞれの使い方をいちいち覚えないといけない
こういったことは企業で開発する上で不毛なんだよ

682:デフォルトの名無しさん
23/08/19 08:44:42.58 iXpPt34C.net
企業については、企業がライブラリを指定するんだし…感はある(非プロの感想です

683:デフォルトの名無しさん
23/08/19 10:43:11.58 7swIlm9f.net
>>681
わかります

684:デフォルトの名無しさん
23/08/19 10:53:02.71 LtLp+SED.net
選定ばかりで何も生み出さない消費者を許せないってそこに書いてある
だから選択肢を増やせば増やすほど評価が高い

685:デフォルトの名無しさん
23/08/19 14:23:54.36 whLCc1g8.net
オープンソース環境は、OSや環境に変化があるたびに、
別人が別の修正版を出してきて、少しずつ使い勝手が違う
ので、めんどくさい。
Rustもそうなる予感がするので使わない。

686:デフォルトの名無しさん
23/08/19 14:30:43.48 whLCc1g8.net
>>685
今、OSSのある開発環境を使い始めたとしよう。
・ドキュメントも不十分なので、上手く行く方法を
　試行錯誤して探すのが必須。
・やっと探し出した方法でmakefileやbatファイルなどを
　整備して開発できるようになる。
・数年後、試して見ると動作しなくなっている。
・それでまた、ググり調査 + 自分でテストを繰り返し、
　数種類の配布物を試してやっとの思いで昔と似た
　ことが出来る方法にたどり着く。その間、大部分の
　環境は、来たいはずれの「試し損」となる。
・そして、makefileやbatファイルが作り直しとなる。
・ライブラリパス、インクルードパス、#includeなどの
　修正も必要となる。xxx.h だったものが、sys/xxx に移って
　いたり、昔 typedef されていたものが、なぜか無くなったり
　別ファイルで定義し奈緒知れていたりする。
・ここまで、数日間かかり、プログラミングは全く出来ない。

経験法則から導かれたOSSの開発環境の日常の風景。

687:デフォルトの名無しさん
23/08/19 14:31:48.17 yRurJ253.net
>>685
C++の新しい規格を使わないのかな？

688:デフォルトの名無しさん
23/08/19 14:35:14.63 yRurJ253.net
>>686
>・数年後、試して見ると動作しなくなっている。
あなたのOSSとの付き合い方の問題点は上記に集約される
常に追っていかなくてはおいてきぼりにされる
あなたには向いていないので使わないこと

689:デフォルトの名無しさん
23/08/19 14:44:59.29 rWZzqTr8.net
2022年版年次Rust調査結果、1万超の回答　職場でRustを使う理由
URLﾘﾝｸ(atmarkit.itmedia.co.jp)

プロフェッショナルな環境でRustを使用する主な理由としては、「バグのないソフトウェアを作成できる」という認識(86％)、Rustのパフォーマンス特性(84％)、Rustのセキュリティと安全性の保証(69％)が挙げられる。また、回答者の76％が、「Rustが楽しいと感じたから」という理由だけでRustを使い続けている(ここでは回答者が複数の選択肢を選択できるので、数値の合計が100％になるわけではない)。

仕事でRustを使用した回答者のうち、72％が「チームの目標達成に役立った」と報告し(前年比4ポイント増加)、75％は今後もチームでRustを使用し続ける計画を持っている。

一方で、職場で適用されている他の言語と同様、Rustの学習曲線は重要な考慮事項だ。専門的な立場でRustを使用している回答者の39％は、そのプロセスが「挑戦的だ」と報告している。
回答者の9％は、職場でRustを採用することで「チームの速度が低下した」と回答した。

690:デフォルトの名無しさん
23/08/19 14:45:09.39 B82tdG00.net
>>681
Rustはデファクトスタンダードがあるからそのように困ったことないな
httpならhttpという名のクレートに基本事項が定められていて全てのhttp実装やその上の各フレームワーク等がこれを使う
httpクレート自体はhttp実装を持たずにhttpのリクエスト型やレスポンス型にURI型やヘッダ型やステータス型などだけを持つところが重要なポイント
もし新たな速いhttp実装が現れたとしてもインターフェイスはこのhttpクレートに(少なくとも今までは全て)従うため利用者が困ることはない

691:デフォルトの名無しさん
23/08/19 16:02:34.86 HZzlwK9f.net
>>688
うん。だから、OSSは大嫌いだし、出来る限り使わない。
Linuxを含めて色々試したが、ごく一部のものを除いては
結局駄目だった。

692:デフォルトの名無しさん
23/08/19 16:07:41.17 HZzlwK9f.net
>>691
ちなみに、俺は、自分で何から何まで作るのが好きなので、
人が作った環境に追いまくられるのが大嫌い。

693:デフォルトの名無しさん
23/08/19 16:16:02.61 yRurJ253.net
>>691
適応能力に長けてないと扱うのは難しい
変化の速さがOSSの競争力の源泉の一つと感じられなければ
苦痛だろうね

オープンソースでもboostとかはほとんど変わらんやろ? 使わないの?
規格にすらあなたは新しいものにクレームつけそうだがw

694:デフォルトの名無しさん
23/08/19 16:17:31.20 yRurJ253.net
>>692
仕事が遅いと言われるだろ?

695:デフォルトの名無しさん
23/08/19 16:19:22.12 LtLp+SED.net
debとかrpmとかバイナリパッケージを否定したら挫折するね
Windowsに依存しないだけならそこまで無理ゲーではないけど
WindowsもLinuxもどっちも認めないいわゆる「中立」が過激化するとうまくいかない

696:デフォルトの名無しさん
23/08/19 16:36:31.92 HZzlwK9f.net
>>692
むしろ逆で、今までみたことがないくらい仕事が
物凄く速いと言われていたぞ。
研修時の記録も塗り替えた伝説も持っている。

697:デフォルトの名無しさん
23/08/19 16:37:25.19 HZzlwK9f.net
>>696
アンカーミスした。
正しいアンカーは >>694。

698:デフォルトの名無しさん
23/08/19 17:00:00.61 nqM77Zy+.net
OSSかどうかとは関係なく現状のRustはライブラリ探しと精査に超時間がかかるのは確か
アプリケーションプログラマーから見るとこれがRustの最大の欠点

699:デフォルトの名無しさん
23/08/19 17:36:47.10 yRurJ253.net
>>696
仕事が速い人がOSSに適応できないわけないじゃんw
>>686に「・ここまで、数日間かかり、プログラミングは全く出来ない。」
と自分でも書いてるし

boostは使わないのかい?

700:デフォルトの名無しさん
23/08/19 17:53:56.37 2pOprLh9.net
>>698
そもそもRustは低レイヤ向けでライブラリを特に必要としない用途に向いてるってことだよ
Webやクラウドなどの通常のバックエンドアプリはライブラリを多用することになるがそれは向いていないってことの証

701:デフォルトの名無しさん
23/08/19 17:57:23.73 Y5l+MR//.net
ほんとに(webの上位層で)人気が出てくれば、ライブラリは勝手に揃ってくるだろうけどね

702:デフォルトの名無しさん
23/08/19 18:20:48.63 JEXSqoZz.net
webやるには十分よ

703:デフォルトの名無しさん
23/08/19 18:58:40.44 nqM77Zy+.net
>>700
ところが低レイヤもたくさんライブラリ使うんだよ

704:デフォルトの名無しさん
23/08/19 19:13:06.91 ZeP/2UQc.net
だんだんOSSがおかしいと思い始めてきた

705:デフォルトの名無しさん
23/08/19 19:18:41.11 bDuPlb9r.net
RHELやHashiCorpの動きはAmazonがターゲット？

706:デフォルトの名無しさん
23/08/19 19:32:52.64 bYZ/uEmX.net
actix-webとaxumどちらがいいのだろう

707:デフォルトの名無しさん
23/08/19 19:49:03.02 MPHyURRb.net
>>704-705
Mojo🔥がAmazonかGoogleに買収されてクラウドオンリーになる可能性

708:デフォルトの名無しさん
23/08/19 20:17:26.90 ScsfkQnZ.net
Firefoxはバクサイ開いたままにしてるとメモリー20GB、CPU100%になったりする
Chromeはそんなことにならない
そういう違いがある

709:デフォルトの名無しさん
23/08/19 20:41:53.76 JEXSqoZz.net
>>706
axum

710:デフォルトの名無しさん
23/08/19 20:47:27.03 ZeP/2UQc.net
>>707
妨害してるってこと？

711:デフォルトの名無しさん
23/08/19 21:06:21.33 LtLp+SED.net
インターネットはおかしいと最初から思ってた
でもソースコードを保存する場所はネットでもディスクでも紙でもなんでもいい

712:デフォルトの名無しさん
23/08/19 21:18:25.63 fB8B9G8R.net
>>690
Python3の場合(正常に動作しかも高速)
URLﾘﾝｸ(paiza.io)
Rustの場合(timeoutする)
URLﾘﾝｸ(paiza.io)

713:デフォルトの名無しさん
23/08/19 21:36:12.67 DB+Yglwb.net
write_allの後はflushした方いいんじゃね？
しらんけど
まあPythonの方がアマチュア向けというか面倒見がいいのは分かる

714:デフォルトの名無しさん
23/08/19 21:50:51.02 fB8B9G8R.net
>>697
自演がバレたなω

715:デフォルトの名無しさん
23/08/19 21:52:18.92 fB8B9G8R.net
>>698
crates.io 破綻してるよな

716:デフォルトの名無しさん
23/08/19 22:20:00.98 DB+Yglwb.net
crates.ioに限った話ではないけど
ライブラリ名と実装品質のミスマッチはいつも気になってる
HTTP/2用のライブラリでもhttp2よりh2の方が利用者数多いとか
オープンなレジストリの宿命として諦めるしかないのかな

717:デフォルトの名無しさん
23/08/19 22:20:55.24 uqHP0fTk.net
>>644
5chでデマ垂れ流して気持ち良くなるだけのゴミ人生でしたw

718:デフォルトの名無しさん
23/08/20 00:49:54.32 nxq7VYP6.net
損得の勝負をしてると、デマで得をする奴がいないか常に不安だよな
それなら単純に本当か嘘かで勝負すればデマと勝利は両立しないから安心安全なのでは

719:デフォルトの名無しさん
23/08/20 01:54:31.51 xEeb34b9.net
>>712
HTTPを知らないなら素直にライブラリを使えよ
そのRustコード汚すぎるがそこに正しくHTTPヘッダを一行加えたら動いたぞ
サイン曲線GIFが表示されている

720:デフォルトの名無しさん
23/08/20 02:56:13.90 shN/tp+V.net
>>719
修正版ウブおながいします

721:デフォルトの名無しさん
23/08/20 06:38:03.53 klcvUWNp.net
練習に書いてみた
fn base64_encode(input: impl AsRef<[u8]>) -> String {
　const TABLE: [u8; 64] = *b"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/";
　const MASK: usize = 64 - 1;
　let mut input = input.as_ref();
　let mut output = Vec::new();
　while let [i0, i1, i2, rest @ ..] = input {
　　let x = u32::from_be_bytes([0, *i0, *i1, *i2]) as usize;
　　(0..=3).rev().for_each(|shift| output.push(TABLE[x >> shift * 6 & MASK]));
　　input = rest;
　}
　match input {
　　[i0, i1] => {
　　　let x = u32::from_be_bytes([0, *i0, *i1, 0]) as usize;
　　　(1..=3).rev().for_each(|shift| output.push(TABLE[x >> shift * 6 & MASK]));
　　　output.push(b'=');
　　}
　　[i0] => {
　　　let x = u32::from_be_bytes([0, *i0, 0, 0]) as usize;
　　　(2..=3).rev().for_each(|shift| output.push(TABLE[x >> shift * 6 & MASK]));
　　　output.push(b'=');
　　　output.push(b'=');
　　}
　　_ => {}
　}
　String::from_utf8(output).unwrap()
}

722:デフォルトの名無しさん
23/08/20 07:18:09.55 3t1JnBWI.net
>>663
同意

723:デフォルトの名無しさん
23/08/20 08:16:48.41 6nnys+Pw.net
>>699
俺はOSSを使わない仕事をしているから。

724:デフォルトの名無しさん
23/08/20 08:21:25.95 6nnys+Pw.net
>>698
>OSSかどうかとは関係なく現状のRustはライブラリ探しと精査に超時間がかかるのは確か
いや、それはOSSだとほぼ必ず起きる現象。
OSS自体が持つ欠点の一つだから。

725:デフォルトの名無しさん
23/08/20 08:24:41.49 6nnys+Pw.net
クローズドなソフトだと、古いものも維持されるかどうかは、
それぞれの企業次第で各企業の特徴が出る。
ところがOSSの場合、人類全体の傾向となるから、
どのOSSなソフトでも似たような保守の傾向となり、
制御できない。なぜなら、人類全体の傾向はいつも
ほぼ同じだから。
電力送電における「無限大母線」という言葉を思い出した。

726:デフォルトの名無しさん
23/08/20 09:39:15.51 GjiTjTDJ.net
>>720
>>712 もう治ってる
 >>719 thx

727:デフォルトの名無しさん
23/08/20 09:56:36.27 GjiTjTDJ.net
>724
なんか全体集合と部分集合を理解出来ていない様な日本語ですね

728:デフォルトの名無しさん
23/08/20 10:26:38.95 nxq7VYP6.net
人類の傾向はいつも、n=1を笑い、前例が1つもない事件事故に泣く

729:デフォルトの名無しさん
23/08/20 10:50:22.50 1EohdLDs.net
>>723
boostは使わないのかな?

730:デフォルトの名無しさん
23/08/20 11:46:34.65 PLGKFrd6.net
>>727
実際rustに限らずOSSなら必ず当てはまることなので部分と言っても意味はない。

731:デフォルトの名無しさん
23/08/20 11:52:30.19 1EohdLDs.net
>>730
「ライブラリ探し」は検索すれば良いだけ
「精査」はOSSはソース手に入るが
プロプラなソフトでは諦めるしかない

732:デフォルトの名無しさん
23/08/20 12:53:04.65 nxq7VYP6.net
時間はお金で買える
ただ具体的にいくらで買えるのか誰も知らないだけ

733:デフォルトの名無しさん
23/08/20 13:19:08.66 sLWYcNsZ.net
>>731
ライブラリの選定ってソースコードの精査はそれほど比重高くないよ。
それよりもライセンス、開発体制やアクティブさ、直近のリリース状況、人気とかが重視されがち。

734:デフォルトの名無しさん
23/08/20 13:30:35.17 1EohdLDs.net
>>733
アンカー間違っとった

>>724
「ライブラリ探し」は検索すれば良いだけ
「精査」はOSSはソース手に入るが
プロプラなソフトでは諦めるしかない

735:デフォルトの名無しさん
23/08/20 15:55:58.84 KkFZufKp.net
>>712を見て思ったが
RustにもPythonのrequests/base64のようなライブラリあるんだろ

736:デフォルトの名無しさん
23/08/20 15:58:19.75 OKeiQGdq.net
標準ライブラリには入ってない

737:デフォルトの名無しさん
23/08/20 16:12:04.89 KkFZufKp.net
>>736
Pythonのrequestsも標準じゃないだろ
Rustは標準のみを使い,Pythonでは外部ライブラリも使ってだからな

738:デフォルトの名無しさん
23/08/20 16:22:18.11 mA4FcHyW.net
RustってSimd命令は非安定だよね？実際にSimd命令使うとどれくらい高速化できんの？
Simd命令ってCPUに応じて場合分けしてコードを書かないとならんの？

739:デフォルトの名無しさん
23/08/20 16:51:39.65 7DmX7Wr5.net
>>738
CPU以外にボトルネックがないならおおよそ並列度の分だけ性能上がる
32bit + 32bitのような計算を1命令で処理してたところを256bit幅がサポートされてるハードウエア&命令を使えば約8倍

740:デフォルトの名無しさん
23/08/20 16:54:56.78 7qQbvCdM.net
>>739
実際には、「お膳立て」のためのオーバーヘッドが有ることと、
SIMD命令が使える部分が少ないことで、8倍のSIMD命令を
使っても、20%位の向上にしかならないと言われている。
数値は大体。
だから、IntelはAVX512をメインストリームからは捨て
ようとした。

741:デフォルトの名無しさん
23/08/20 17:01:04.61 7qQbvCdM.net
スパコンが、ベクトル型が廃れてスカラー型の並列型が
流行していることからしても、SIMDは将来性の無い
ものだと個人的には思ってる。
むしろ、SIMDを捨て、コア数を増やす方が圧倒的に
高速化できる。

742:デフォルトの名無しさん
23/08/20 17:20:33.01 V1e9lq/f.net
スパコンのコーディングは知らんけど
雑にスレッドプールにぶん投げるだけで速くなる並列処理の方が
SIMDより使いやすいなって思う

743:デフォルトの名無しさん
23/08/20 18:05:27.72 a//hKKzV.net
>>720
整理するとこれでいいみたい

use std::error::Error;
use std::net::TcpStream;
use std::io::{BufReader, BufRead, Read, Write};
use std::fmt::Write as _;

fn http_get(host_port: &str, path: &str) -> Result<Vec<u8>, Box<dyn Error>> {
　let mut server = TcpStream::connect(host_port)?;
　let mut http = String::new();
　write!(http, "GET {path} HTTP/1.1\r\n")?;
　write!(http, "Host: {host_port}\r\n")?;
　write!(http, "Connection: close\r\n")?;
　write!(http, "\r\n")?;
　server.write_all(http.as_bytes())?;

　let mut server = BufReader::new(server);
　let mut line = String::new();
　server.read_line(&mut line)?;
　if line != "HTTP/1.1 200 OK\r\n" {
　　return Err("HTTP: not 200 OK".into());
　}
　while server.read_line(&mut line)? > 2 {}

　let mut data = Vec::<u8>::new();
　server.read_to_end(&mut data)?;
　Ok(data)
}

744:デフォルトの名無しさん
23/08/20 18:11:30.48 gUvM95Xg.net
よかったね

745:デフォルトの名無しさん
23/08/20 18:25:00.43 MyoNrmjT.net
>>743
え？Rustって標準ライブラリでhttpリクエストすらできないの？

746:デフォルトの名無しさん
23/08/20 18:38:37.77 iamuQ/3/.net
Rsutはwebやるための言語とか言ってたような

747:デフォルトの名無しさん
23/08/20 19:01:10.42 mA4FcHyW.net
とりあえず1000×1000の行列の行列積dotが0.015秒弱でできるようなところまで行列ライブラリーが実装できたので、何とか0.00秒台で計算が終わる様にしたい。
今の所手を出してない最適化
1) Simd命令
2) インラインアセンブリ
3)ループアンローリング(これはRustだと自動的にやってくれてる様で自分の実験した範囲ではあまり効果がなかった。)

この中で一番効果的な最適化は何？
ちなみに今の所は以下の最適下は既に実装済み
1) ループ交換
2) キャッシュブロッキング
3) rayonによる並列処理

748:デフォルトの名無しさん
23/08/20 19:10:25.82 IxOV384F.net
>>745
Rustの標準ライブラリは言語サポートを必要とするものを中心に極めて絞っている
既出のhttpやbase64だけでなく正規表現や乱数など多くの機能がデファクトスタンダードライブラリ

>>746
標準ライブラリにないだけで各種ライブラリは下位から上位フレームワークまで揃っている
CPUとメモリのリソースコスパ重視でWebやるならRust一択でまちがいない
Webインフラ各トップ企業たちも>>496のようにRustを採用している

749:デフォルトの名無しさん
23/08/20 19:16:55.65 55RG+hvj.net
デファクトスタンダードという選りすぐりに聞こえるが
単にそれしかないだけのような...
ユーザ数少ないので

750:デフォルトの名無しさん
23/08/20 19:20:14.76 yJmfO0+S.net
>>747
simdに手を出すとarmのsimdまでやる羽目になる
インラインアセンブリも同じ

つまり今のところおすすめはない
外部のライブラリなどに依存するなら別だけど

751:デフォルトの名無しさん
23/08/20 19:25:32.14 mA4FcHyW.net
>>750
じゃあ基本的にはdot演算に関してはこれ以上の最適化の余地はないって感じ？

752:デフォルトの名無しさん
23/08/20 19:26:47.41 MoWe6Sep.net
グーグルとアップルが流行らせようとしてるらしいが

753:デフォルトの名無しさん
23/08/20 19:44:59.22 sOv9anOF.net
paiza.io の Rust は crates 使えないから
ホント使いもんにならんわ

754:デフォルトの名無しさん
23/08/20 19:47:42.13 rPtHvv2S.net
じゃあGitHubのCodespacesでも使ってれば

755:デフォルトの名無しさん
23/08/20 19:54:55.65 yJmfO0+S.net
>>751
おすすめはしないけどやればやったになるはず
デバッグ環境があるかは知らないが

756:デフォルトの名無しさん
23/08/20 19:58:02.59 U3mkt6q/.net
>>753
それはpaizaが悪い
例えば>>712で意味のない比較をしているが
Python版はimport requestsと標準ライブラリではないものを使っている
つまりpaizaはPythonだと標準ライブラリ以外のライブラリも使える
同じようにRustでも標準ライブラリ以外を使えるようにpaizaが対応すれば解決

757:デフォルトの名無しさん
23/08/20 20:00:15.86 259yUXDO.net
>>747
これに即して測ってみては(1500x1500(f64)の生成、行列積、破棄の計測)
URLﾘﾝｸ(github.com)

とりあえずnumpyとの比較とか
URLﾘﾝｸ(github.com)

758:デフォルトの名無しさん
23/08/20 20:00:40.96 pu4udaaX.net
シミュレータなどは行列演算だけ高速化しても、全体の
高速化にはなら無い事が多い。

759:デフォルトの名無しさん
23/08/20 20:04:56.81 mA4FcHyW.net
>>757
手元のnumpyよりは少なくとも1000×1000の行列積は2倍から3倍速、10000×10000の行列積だと約5倍から10倍速い。手元よnumpyのバックエンドはIntelMKL。

760:デフォルトの名無しさん
23/08/20 20:07:47.30 mA4FcHyW.net
まだ、行列の対角化とか逆行列の計算は実装できてない。

761:デフォルトの名無しさん
23/08/20 20:20:10.35 259yUXDO.net
なんかnumpyが遅くない？

1000x1000でnumpy.dot(a, b)部分だけ測ったらこんな感じだったけど

0.006215572357177734
0.005822658538818359
0.005129098892211914
0.007399797439575195
0.011432886123657227
0.008414506912231445
0.009572029113769531
0.009091615676879883
0.008922100067138672
0.007265329360961914

762:デフォルトの名無しさん
23/08/20 20:23:55.44 259yUXDO.net
def calc(n):
n = n // 2 * 2
a = build_matrix_np(n, 1.0)
b = build_matrix_np(n, 2.0)

start = time.time()
d = matmul(a, b)
end = time.time()
time_diff = end - start
print(time_diff)

return d[n // 2][n // 2]

763:デフォルトの名無しさん
23/08/20 20:37:44.31 259yUXDO.net
pipで入れたのでopenblasだと思うけど、こんな感じ

OMP_NUM_THREADS=1 python mutmul-numpy.py 1000
0.030291080474853516
0.029540538787841797
0.029771089553833008
0.02943873405456543
0.02980208396911621
0.03012990951538086
0.0300595760345459
0.030525922775268555
0.03243899345397949
0.02984023094177246

OMP_NUM_THREADS=8 python mutmul-numpy.py 1000
0.0073316097259521484
0.007174968719482422
0.007193326950073242
0.006682157516479492
0.006906747817993164
0.006983757019042969
0.007711172103881836
0.008562803268432617
0.007740497589111328
0.00671076774597168

>>759のnumpy計測がsingle threadになってたりしてる？

764:デフォルトの名無しさん
23/08/20 22:44:27.85 mA4FcHyW.net
>>763
シングルスレッドでの計測になってたぽい。この計測って最初のメモリ確保は含めてる？

765:デフォルトの名無しさん
23/08/21 11:52:24.10 lrfEI2bB.net
SIMDでの行列演算の最適化方法そのものとかさすがに関係なさ過ぎ。
RustとC++の違いに着目するならまだしも。

766:デフォルトの名無しさん
23/08/21 14:56:42.48 jPnmmh+2.net
>>764
>>762の通り行列積部分

JuliaをREPLで試した

function matgen(n, seed)
tmp = seed / n / n
[tmp * (i - j) * (i + j - 2) for i = 1:n, j = 1:n]
end
n = 1000
n = round(Int, n / 2) * 2
a = matgen(n, 1.0)
b = matgen(n, 2.0)
using BenchmarkTools
c=@btime(a*b)

OPENBLAS_NUM_THREADS=1 julia --optimize=3 --check-bounds=no
29.581 ms (2 allocations: 7.63 MiB)
OPENBLAS_NUM_THREADS=8 julia --optimize=3 --check-bounds=no
6.875 ms (2 allocations: 7.63 MiB)

juliaが行列積でnumpyの10倍遅いのが意外

767:デフォルトの名無しさん
23/08/21 16:08:29.46 IYi1S2wl.net
>>765
まあ、この板は実質雑談板なんで。アンチOSS君も大暴れしてますし大目にみてください。

768:デフォルトの名無しさん
23/08/21 16:21:29.46 A+ik1f9X.net
OSS関係無いわな。スレチ。別のところで好きなだけやればいい。

769:デフォルトの名無しさん
23/08/21 16:41:35.26 W/JUog9y.net
OSSは関係大有りだと思う。

770:デフォルトの名無しさん
23/08/21 16:46:18.02 dQnAszLW.net
Juliaとかは関係あるの？

771:デフォルトの名無しさん
23/08/21 16:48:11.28 US7qznQL.net
議論に関係あるかどうかの議論が必要ですね

772:デフォルトの名無しさん
23/08/21 16:55:39.81 A+ik1f9X.net
>>769
rustのエコシステムの話とかなら関係あるけど、OSS自体のメリデメ、とかそういう論点はスレチ。

773:デフォルトの名無しさん
23/08/21 17:31:43.44 W/JUog9y.net
>>772
そんなことなくて、OSSであるということは、
非常に大きな影響を及ぼすので無視できない。

774:デフォルトの名無しさん
23/08/21 17:54:01.38 A+ik1f9X.net
>>773
それが通るなら少しでも擦れば何でもありになる。
影響の大小なんて本人が大きいと言い張れば大きいことになる。
スレタイ読んで関係あるかどうか常識で考えれば自明。もちろんあなたに言っても意味無いわけですけども。

775:デフォルトの名無しさん
23/08/21 18:18:38.42 W/JUog9y.net
>>774
そういうことじゃなくて、OSSは本質的に非常に大問題を
抱えてしまっているから、どうしようもない。

776:デフォルトの名無しさん
23/08/21 18:33:57.42 AlisErs6.net
>>775
そういうことじゃなくて、
じゃなくて、このスレそういうスレなんだよ。
マジで頭おかしいw

777:デフォルトの名無しさん
23/08/21 18:35:45.82 dQnAszLW.net
Rustが失敗した原因の根底にOSSの問題があるって言いたいんじゃね

778:デフォルトの名無しさん
23/08/21 19:07:31.63 8jq5nfQv.net
「（すべての）OSSは本質的に非常に大問題を抱えている」→「Rustは本質的に非常に大問題を抱えている」
ってことだな
一応前提が正しければ結論も正しいけど前提の論証が大変そうだ
「一部のOSSは本質的に非常に大問題を抱えている」→「すべてのOSSは本質的に非常に大問題を抱えている」
みたいな論証魔法を決めれば何とかなるけどプログラマはこの類には耐性あるからな
「一部の」と「すべての」を削って後ろの修飾語を盛る程度だとまだ術式が足りなくて通らない

779:デフォルトの名無しさん
23/08/21 19:20:23.58 NjHCZBFl.net
どっちでもいいから、面白いことを書いてくれ

780:デフォルトの名無しさん
23/08/21 19:32:31.36 jTK4AVkF.net
>>775
boostは使わないの?

781:デフォルトの名無しさん
23/08/21 19:53:38.34 2W/Jw/4i.net
矛盾を抱えているんだから論証とか無駄。
どんな結論でも導出できる。

782:デフォルトの名無しさん
23/08/21 20:44:27.67 oR9oJ1qa.net
背理法の仮定を利用しなくても矛盾するなら、任意の結論を背理法で証明できる
だから「矛盾しているのはお前だけ」みたいな結論はむしろ出てこないんだよ
属人的な仮定を必要としないのだから全人類が矛盾する

783:デフォルトの名無しさん
23/08/21 21:19:54.31 q/j5yT82.net
>>782
論理を語るのなら、まず共通の前提条件を全部出して合意取れよ。
前提条件より先に結論が出るとかありえないし、前提条件の合意が取れていないなら矛盾するから議論する意味がない。

784:デフォルトの名無しさん
23/08/21 21:26:14.98 6J/DqmTl.net
>>778
おもしろい

785:デフォルトの名無しさん
23/08/21 21:58:53.90 oR9oJ1qa.net
>>782
合意がなければ義務はないというのは正しい
議論には義務が必要不可欠というのは間違っている
強制力があるべきという合意がもしあれば論理ではなく物理的な戦争が始まる

786:デフォルトの名無しさん
23/08/21 22:02:41.22 oR9oJ1qa.net
ちょっと間違えたけど、どこを間違えたのかいちいち合意を取るのが面倒臭い

787:デフォルトの名無しさん
23/08/22 00:06:37.51 p77SLRC3.net
まあ、この板はプログラム関連なら基本的に何話しても良いってことで。この6traits目を、立てた本人が言ってることなんで。次のtraitからはそれについても書いとく？

788:デフォルトの名無しさん
23/08/22 00:42:55.89 CKREFo3h.net
>>787
君スレと板ごっちゃにしてない？

789:デフォルトの名無しさん
23/08/22 06:46:28.34 oV9q0mPv.net
このスレタイに釣られるって段階で、参加者がある程度絞られてる
別に何話そうが確かに構わんのだが、面白いことを書け
ライブラリ書いてるヤツが定着してるのは、Rustのライブラリ作りってこんな感じなのか、と思って眺めてる
そういや、hsutter氏がなんか動画出してたけど、まだ観てない
勉強しないといけないこと(non C++, non Rust)大杉

790:デフォルトの名無しさん
23/08/22 12:18:07.09 whNyN1Gw.net
>>773
スレタイを100万回読め

791:デフォルトの名無しさん
23/08/22 19:02:47.39 jvLbVv4g.net
>>766 訂正
測定自体はOKですが、最後の一文、桁を読み間違えてたorz
× >juliaが行列積でnumpyの10倍遅いのが意外
juliaとnumpyは同じスピードです(両方ともopenblasバックエンド、同一スレッド数の場合)
URLﾘﾝｸ(i.imgur.com)
>>747,759,764
そちらの環境でのマルチスレッドnumpyの測定数値が出ていたら自作ライブラリとの比較結果お願いします

792:デフォルトの名無しさん
23/08/22 19:57:32.16 p77SLRC3.net
>>791
なんかnumpyでマルチスレッド指定しても速度上がんないんですけど何か要因は考えられますか？

793:デフォルトの名無しさん
23/08/22 21:29:39.50 3Q3W0wKi.net
>>792
こちらでは素のvenvでやり直しても、defaultでマルチスレッドが効いています
$ python311 -m venv venv
$ . venv/Scripts/activate
$ pip install numpy
$ pip list
Package Version
---------- -------
numpy 1.25.2
pip 23.2.1
setuptools 65.5.0
$ du -h venv
96M venv
$ python matmul-numpy.py 1000
0.006245136260986328
0.006272077560424805
0.006720542907714844
0.007251739501953125
0.006670713424682617
0.0067596435546875
0.006724119186401367
0.005736351013183594
0.005699872970581055
0.007322788238525391
condaの場合は分かりませんので、とりあえずpipのopenblas版numpyで計測してみては?
URLﾘﾝｸ(numpy.org)

794:デフォルトの名無しさん
23/08/22 22:57:52.73 3Q3W0wKi.net
miniforgeのcondaでchannel指定してmkl版numpyを入れましたが、こちらもマルチスレッドが効いています(MKL_NUM_THREADS指定無しでも)
$ conda install -c intel numpy
$ du -h ****/tmpenv2
1.3G ****/tmpenv2 <-- orz
$ python -c 'import numpy; numpy.show_config()'
....
blas_mkl_info:
libraries = ['mkl_rt']
library_dirs = [****]
define_macros = [('SCIPY_MKL_H', None), ('HAVE_CBLAS', None)]
include_dirs = [****]
....
MKL_NUM_THREADS=8 python matmul-numpy.py 1000
0.007200717926025391
0.007269620895385742
0.0062868595123291016
0.00983738899230957
0.007195472717285156
0.006726503372192383
0.006485939025878906
0.0068206787109375
0.006815910339355469
0.006788492202758789

795:デフォルトの名無しさん
23/08/22 23:05:57.11 3Q3W0wKi.net
MKL版はthread数指定しないと=8よりも若干遅くなる
$ python matmul-numpy.py 1000
0.007860660552978516
0.009339094161987305
0.00830698013305664
0.006848335266113281
0.008496522903442383
0.007841348648071289
0.007840871810913086
0.00741887092590332
0.007982254028320312
0.006742000579833984
$ python -V
Python 3.8.11 :: Intel Corporation
芋づるインストールされた中でバージョンが気になるもの
mkl intel/win-64::mkl-2023.2.0-intel_49496
mkl-service intel/win-64::mkl-service-2.4.0-py38h9a4cf0c_35
mkl_fft intel/win-64::mkl_fft-1.3.6-py38h5020ddc_56
mkl_random intel/win-64::mkl_random-1.2.2-py38hf267b2b_76
mkl_umath intel/win-64::mkl_umath-0.1.1-py38h51af1d9_86
numpy intel/win-64::numpy-1.24.3-py38hcdfd0aa_0
numpy-base intel/win-64::numpy-base-1.24.3-py38h9b12b81_0

796:デフォルトの名無しさん
23/08/22 23:11:09.00 3Q3W0wKi.net
シングルスレッドがopenblasよりも若干遅いじゃないか!
この辺でやめておきますorz
MKL_NUM_THREADS=1 python matmul-numpy.py 1000
0.032694339752197266
0.03222513198852539
0.03307652473449707
0.03224611282348633
0.031710147857666016
0.03175640106201172
0.032773494720458984
0.032234907150268555
0.03272652626037598
0.0316920280456543

797:デフォルトの名無しさん
23/08/23 11:18:41.09 89z/H8g7.net
crate の docs の comment 率上げるために
struct に comment 付け捲る仕様はホントうざい

798:デフォルトの名無しさん
23/08/24 02:29:53.65 zGLBQFrp.net
python や bumpy の話題はスレ違い。
OSSの話題は許容範囲。
同一視してはいけない。

799:デフォルトの名無しさん
23/08/24 02:32:08.21 zGLBQFrp.net
RustとC++の比較において、前者が「パソコンにおいて」
OSSからスタートしてしまったことは、全ての問題の始まり。
かつてC言語はUnixではOSSであったろうが、パソコンでは
原則的にクローズドであったからこそ発展を遂げた。

800:デフォルトの名無しさん
23/08/24 02:42:41.30 hEI/Eij5.net
>>799
>かつてC言語はUnixではOSSであったろうが、パソコンでは
>原則的にクローズドであったからこそ発展を遂げた。
自分で書いていて論理がおかしいと思わないのかな?

801:デフォルトの名無しさん
23/08/24 02:45:44.43 hEI/Eij5.net
>>799
C言語がクローズドって何がクローズなのかな?
ANSIは誰もが使えるオープンな規格だろうが?
他人に伝えたい文章は正確に書き給え

802:デフォルトの名無しさん
23/08/24 02:47:37.96 zGLBQFrp.net
>>801
TurboC, msc, Watcom C/C++, LSI C, Lattice C,
Small C などがクローズであり、パソコンでOSSなものは
当時存在していなかったはずだ。

803:デフォルトの名無しさん
23/08/24 02:53:01.56 zGLBQFrp.net
C言語は、規格はオープンと言えばオープンであったが、
PC-9801用のコンパイラのソースコードは非公開であった。
X68000 は gcc だったらしいが。

804:デフォルトの名無しさん
23/08/24 02:53:58.47 hEI/Eij5.net
>>802

>>799
>パソコンでは原則的にクローズドであったからこそ発展を遂げた。
これは因果化関係を主張しているので
相関ではなくて因果の根拠を示すことが必要です
述べて下さい

805:デフォルトの名無しさん
23/08/24 02:56:38.98 hEI/Eij5.net
分かると思うけどタイポ
-因果化関係
+因果関係

806:デフォルトの名無しさん
23/08/24 03:19:55.67 zGLBQFrp.net
>>804
クローズドだから競争が生じ、開発環境が高度に発展した。

807:デフォルトの名無しさん
23/08/24 03:23:10.48 zGLBQFrp.net
Win95が開発環境にとって終わりの始まりだった。
OSが32BIT化したことで、Unix系の無料OSSツールが
「主流のビジネスパソコン(PC-9801など)」の世界に
大量流入。
競争条件が破綻し、競争が不可能となり、衰退。

次ページ