Rust part25

**デフォルトの名無しさん** · 2024/07/31(水) 00:46:26.17

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

公式ドキュメント
https://www.rust-lang.org/learn

Web上の実行環境
https://play.rust-lang.org

※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
https://doc.rust-lang.org/book/

※Rustを学ぶ際に犯しがちな12の過ち
https://dystroy.org/blog/how-not-to-learn-rust

※Rustのasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/

※次スレは原則>>980が立てること

前スレ
Rust part24
https://mevius.5ch.net/test/read.cgi/tech/1716759686/

ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.5ch.net/test/read.cgi/tech/1514107621/

**デフォルトの名無しさん** · 2024/09/01(日) 16:58:53.35

Zigは1.0になってから出直せ！
crateはpre-1.0でもそういうもんなのでヨシ！

はーくだらね

**デフォルトの名無しさん** · 2024/09/01(日) 17:07:22.02

言語とライブラリは流石に違わないか
ライブラリは開発止まっても同分野の別のライブラリがあればそれに差し替えられる (最悪、元のライブラリをフォークしても良い) けど、言語仕様はそうもいかないだろ

**デフォルトの名無しさん** · 2024/09/01(日) 17:08:31.34

比較の対象にすらならない
Zigはasync awaitを断念して削除
Rustはasync awaitによりCPUコアをフル活用できて実際にクラウドやCDNなどネットインフラで使われている

**デフォルトの名無しさん** · 2024/09/01(日) 17:48:17.89

>>584
詐欺の証明ができないのであればRustはNim2.0より劣る言語と
理解してもよろしいでしょうか？

>Rustと関係ないので
ORCでメモリ安全を担保できてCより２倍以上速くなるのであれば、
メモリ安全がありCより遅いRustは言語選択時の比較対象として関係あるだろ

**デフォルトの名無しさん** · 2024/09/01(日) 18:02:28.26

何でもできるC言語より速いと主張しだしたらそれは変な宗教だから相手にしてはダメ
しかもNimはC言語へトランスパイルされるんだろｗ

**デフォルトの名無しさん** · 2024/09/01(日) 18:08:55.61

雑に書いて十分に速いかってのと専門家が気合いを入れてチューニングをすれば最強に速いかってのは違う指標だろうし、仮に速さを比べるにしても想定を合わせないと意味がないよ。

**デフォルトの名無しさん** · 2024/09/01(日) 18:09:09.43

CへトランスパイルされるならCより速くなってても不思議じゃないな

**デフォルトの名無しさん** · 2024/09/01(日) 18:15:39.95

Rustは特殊なケースを持ち出さなくても
実際の実用ケースのほとんどで、Cと同じ速さ、もしくは、ほぼ同じ速さで、凝ったことをせずとも書けるから
IT業界が挙ってRustを支持した

**デフォルトの名無しさん** · 2024/09/01(日) 18:34:18.72

知らないから純粋な質問なんだけどnimって並行処理の安全性に強みはあるの？
個人的にRustで助かる部分だと思ってるので
メモリ周りは問題なさそう＆所有権はRustより楽そう (代わりに意図せぬコピーが起こりやすい？) に思う

**デフォルトの名無しさん** · 2024/09/01(日) 18:40:58.89

それとエラーの扱いやすさ

**デフォルトの名無しさん** · 2024/09/01(日) 19:43:48.04

>>590
じゃあ想定を合わせるためにCでもRustでもどっちでもいいから、下記のNim2.0のORCで明示的にオブジェクトプールを使ったプログラミングのベンチマークより速くできなかったら、今度こそ本当にRustはNim2.0より劣る言語と理解してもよろしいでしょうか？

Memory management strategy Time Peak Memory
object pooling　　　　　　　　　 2.4s　　 251.504MiB

オブジェクトプール（5）
proc main =
let maxDepth = parseInt(paramStr(1))
const minDepth = 4
let stretchDepth = maxDepth + 1
var longLived: Pool # 5行目
let stree = makeTree(longLived, maxDepth)
echo("stretch tree of depth ", stretchDepth, "\t check ",
checkTree(stree))
let longLivedTree = makeTree(longLived, maxDepth)
var iterators = 1 shl maxDepth
for depth in countup(minDepth, maxDepth, 2):
var check = 0
for i in 1..iterators:
var shortLived: Pool # 14行目
check += checkTree(makeTree(shortLived, depth))
echo iterators, "\t trees of depth ", depth
iterators = iterators div 4

main()

**デフォルトの名無しさん** · 2024/09/01(日) 20:00:37.37

はいはい
C/C++/Rustに勝ってから出直してきてね
スレ荒らしはダメよ

**デフォルトの名無しさん** · 2024/09/01(日) 20:08:43.57

わざわざ他言語のスレに来て噛み付かなきゃいけない時点で負けていると宣言しているようなもの
その言語のスレを盛況にすればいいのに

**デフォルトの名無しさん** · 2024/09/01(日) 20:08:50.47

>>596
はあ？日本語嫁内の？
>>59４より速いベンチマークで証明すればいいだけだろ

**デフォルトの名無しさん** · 2024/09/01(日) 20:12:17.24

Cより速い言語が本当に出現したのならば世界的なニュースになるのでここを荒らす必要なし

**デフォルトの名無しさん** · 2024/09/01(日) 20:18:33.83

>>599
証明できないから荒らし判定してるだけだろ

証明できないなら証明できないって正直にRustはNim2.0より劣る言語だと認めればいいだけだろ

**デフォルトの名無しさん** · 2024/09/01(日) 20:34:03.89

CスレやC++スレへ行ってくればいいんじゃね
相手にしてくれるかもよ

**デフォルトの名無しさん** · 2024/09/01(日) 20:36:25.69

RustスレでRust宣伝とかいう意味のないことやり続けた報い

**デフォルトの名無しさん** · 2024/09/01(日) 20:42:24.60

煽りたいだけなら他言語のコードも自分で書いてベンチマークを個人ブログまたはRedditかQiitaかZennに書けばよくない？
>>583はリンク先が無いし >>595 はCPU性能どころか入力の数すら書いてないから、誰かが他の言語で書いたとしても比較しようがない

**デフォルトの名無しさん** · 2024/09/01(日) 20:43:24.75

このスレはNim2.0のORCで明示的にオブジェクトプールを使ったプログラミングのベンチマークより速い事を証明できないカスばっかだな

**デフォルトの名無しさん** · 2024/09/01(日) 20:47:46.74

>>603
https://zenn.dev/dumblepy/articles/af2b2b9f8fd890

Website https://nim-lang.org/
Forum https://forum.nim-lang.org/
Github https://github.com/nim-lang/Nim
IRC https://webchat.freenode.net/?channels=nim

**デフォルトの名無しさん** · 2024/09/01(日) 20:49:35.02

検索してみたがNim 2.0がCより速いという記事が一つも見つからなかったのでガセっぽい
記事が出るまでこのお話はお預けってことで

**デフォルトの名無しさん** · 2024/09/01(日) 20:51:46.74

>>603
https://youtu.be/yA32Wxl59wo

https://github.com/Araq/fosdem2020

**デフォルトの名無しさん** · 2024/09/01(日) 20:53:27.80

>>605
純粋に疑問なんだけどそのページのどこをみてCの2倍速いって言ってるの？
単にNim同士でメモリ管理をいろいろ変えたら速くなったとしか書かれていないと思うんだけど

**デフォルトの名無しさん** · 2024/09/01(日) 21:03:34.87

Nimの過去のものより速くなったとしか読めないし
補足として貼ってるリンクもベンチマークじゃなくて言語自体の説明や公式ページだし
自分で手を動かさずにその記事だけ読んでCより速いと言うのは妄想レベルでは

**デフォルトの名無しさん** · 2024/09/01(日) 21:14:25.35

>>608
NimはCのソースコード吐けるからから、Nimの手動メモリ管理はCの手動メモリ管理と同じとして、Nim2.0のORCで明示的にオブジェクトプールを使ったプログラミングと比較した場合のベンチマークが2倍以上速くなってるからCより速いと言ってる

それが間違ってると主張したいのであれば、想定を合わせるためにCでもRustでもどっちでもいいから、さっきから何度も言ってるように速いベンチマークで証明すればいいだけだろ

**デフォルトの名無しさん** · 2024/09/01(日) 21:17:33.09

>>610
それはCでもオブジェクトプール使えば2倍速くなるのでは？
オブジェクトプール版のNimから生成したCはまさにそういうコードだと思うけど

**デフォルトの名無しさん** · 2024/09/01(日) 21:24:18.89

言語の差でなくメモリ管理方式の差では
ライブラリにはなるけど同様のものはRustにもあるし大して変わらなさそう

**デフォルトの名無しさん** · 2024/09/01(日) 21:27:22.64

コーディングもベンチもせずに
NimはCより2倍速いと主張していて
心の病をうたがってしまう

**デフォルトの名無しさん** · 2024/09/01(日) 21:38:54.81

そもそもNimがCより速いっていうのが原理的におかしいんだよ…
Nimの最速実装には必ずそこから生成されたCが存在するわけで
それとも生成されたCはCとは認めない、みたいな話なんだろうか

**デフォルトの名無しさん** · 2024/09/01(日) 21:48:04.56

方式の違いを言語の差と思ってるなら
例えば誰かがコストの大きい計算をスレッドプールで高速化した実装をC++やRustで示せばそれでNimより速いと納得するんだろうか

**デフォルトの名無しさん** · 2024/09/01(日) 21:52:21.87

>>611
>それはCでもオブジェクトプール使えば2倍速くなるのでは？
Cは手動メモリ管理しかできないオブジェクトプールの機能はないだろ

>オブジェクトプール版のNimから生成したCはまさにそういうコードだと思うけど
人間がCの手動メモリ管理したプログラムだと限界があるムーブセマンティクスの
アルゴリズムでメモリの最適化をしてるから、人間では到底太刀打ちできない事を
証明した論文があるオブジェクトプール版のNimから生成したCのコードは人間には書けない

Nim2.0のムーブセマンティクスの本当に優れた最適化とORCで明示的にオブジェクトプールでプログラミングすることによって、人間がCの手動メモリ管理したベンチマークより2倍以上速くできる

それが間違ってると主張したいのであれば、想定を合わせるためにCでもRustでもどっちでもいいから、速いベンチマークで証明すればいいだけだろ

**デフォルトの名無しさん** · 2024/09/01(日) 21:56:31.28

NimはCより2倍速いと主張している人がまずはその比較コードとベンチ結果を示す義務がありますよ

**デフォルトの名無しさん** · 2024/09/01(日) 22:00:47.66

主張するだけならどの言語でもできますがな
PythonはCよりも速い、違うというならお前らがコードを書いて証明しろ
みたいなのは面倒くさすぎて誰も相手にせんだろ

**デフォルトの名無しさん** · 2024/09/01(日) 22:04:17.16

>>617
https://github.com/Araq/fosdem2020

**デフォルトの名無しさん** · 2024/09/01(日) 22:06:25.77

>>616
別にCでも自分でオブジェクトプール実装するなり既存のarena allocator使えばいいじゃん
まぁ言語組み込みであることで「初心者が何の最適化もしないコードを書いたときにNimが最速」となる可能性はあると思うけど、それならそのように主張してくれ

**デフォルトの名無しさん** · 2024/09/01(日) 22:14:20.69

>>616
>Cは手動メモリ管理しかできないオブジェクトプールの機能はないだろ
はい、ここ笑うところですよ～

**デフォルトの名無しさん** · 2024/09/01(日) 22:18:07.82

>>619
2020年のNimのコードしか見当たりませんね
Cのコードとベンチ結果はどこですか

**デフォルトの名無しさん** · 2024/09/01(日) 22:19:40.68

CとC++の違いも判らない人が主張してもな

**デフォルトの名無しさん** · 2024/09/02(月) 02:02:31.42

最近のやり取りでなんとなくここの層がわかってきたなぁ

**デフォルトの名無しさん** · 2024/09/02(月) 10:14:38.25

MinifyされたJavaScriptのコードをChatGPTで読みやすい形式に戻すことに成功
https://gigazine.net...eering-with-chatgpt/

**デフォルトの名無しさん** · 2024/09/02(月) 11:00:21.39

まあ確かに純粋なCとの置き換えなら別にCでええやんってなるわな

**デフォルトの名無しさん** · 2024/09/02(月) 12:43:05.01

>>626
そんなあなたにZigがおすすめ
comptimeやdeferが便利です

**デフォルトの名無しさん** · 2024/09/02(月) 12:57:03.37

C++ に慣れてると後始末をデストラクタの中に隠蔽できてないのは抽象化の失敗だという感覚があるから defer には良い印象がない。

**デフォルトの名無しさん** · 2024/09/02(月) 16:42:30.80

RAIIがない欠陥言語たちはdeferとかwithとかusingとか毎回書かされて汚くなる

**デフォルトの名無しさん** · 2024/09/02(月) 16:51:36.63

別にRAIIが絶対的な正解というわけではないので
そこに自由度を持たせるにはその自由度を制御するための一言が必要になるのは当然のこと

**デフォルトの名無しさん** · 2024/09/02(月) 16:52:53.11

>>628
それならRust使えばいいっしょ
C++を置き換えるものがRust、
Cを置き換えるものがZigである

**デフォルトの名無しさん** · 2024/09/02(月) 17:01:06.29

clang ccは最適化フラグが沢山あるし、色々やればNimと同程度の速度くらい出せるんじゃないの？知らんけど

**デフォルトの名無しさん** · 2024/09/02(月) 17:19:45.07

>>631
defer は抽象化の失敗の表れだとは思うが抽象化をそれほど頑張らない方針を悪いと思ってるわけじゃないよ。
C++ が Better C としての用途でも超強力な選択肢として馴染みがあるからあらためて他の選択肢を使いたい気持ちがあまりないという程度の話。

**デフォルトの名無しさん** · 2024/09/02(月) 17:34:21.85

C++がBetter Cとして馴染みがあるから他の選択肢を使いたい気持ちがない人、弊社には来て欲しくねえな
馬鹿か、すごい賢くて賢い人としか働けないか、人と働いたことないかの三択だ

**デフォルトの名無しさん** · 2024/09/02(月) 17:37:11.39

Zigは結局のところ個人開発止まりで終わるよ

**デフォルトの名無しさん** · 2024/09/02(月) 18:24:18.22

>>632
Nimはclangに対応してる
Nim言語開発者がCの手動メモリ管理ソースをclangで最適化コンパイルしてたら5.23sで変わらないんじゃない

Memory management strategy　　　 Time　　　 Peak Memory
manual 　　　　　　　　　　　　　　　5.23s 　　　244.563MiB

**デフォルトの名無しさん** · 2024/09/02(月) 18:32:02.91

補足
NimはCのソースコード吐けるからから、Nimの手動メモリ管理はCの手動メモリ管理と同じとしてベンチマーク計測してる
https://github.com/Araq/fosdem2020
https://zenn.dev/dumblepy/articles/af2b2b9f8fd890

**デフォルトの名無しさん** · 2024/09/02(月) 18:41:55.01

補足2
人間がCの手動メモリ管理したプログラムだと限界がある
Nim2.0のムーブセマンティクスの本当に優れたアルゴリズムでメモリの最適化をしてるから、人間では到底太刀打ちできない事を証明した論文がある
オブジェクトプール版のNimから生成したCのコードは人間には書けない

Nim2.0のムーブセマンティクスの本当に優れた最適化とORCで明示的にオブジェクトプールでプログラミングすることによって、人間がCの手動メモリ管理したベンチマークより2倍以上速くできる

**デフォルトの名無しさん** · 2024/09/02(月) 18:51:06.06

>>632
NimがCより速いというガセネタに釣られるなよ
キチガイを招いただろ

**デフォルトの名無しさん** · 2024/09/02(月) 19:04:49.90

>>639
Nim言語開発者のORCで明示的にオブジェクトプールを使ったプログラミングのベンチマークがガセだと思うなら、それよりも速いベンチマークで証明すればいいだけだろ

**デフォルトの名無しさん** · 2024/09/02(月) 19:17:59.50

Nimの方が速いというコード比較ベンチが一つも存在しないから
現状ではNimが速いは嘘と判断するしかないね

**デフォルトの名無しさん** · 2024/09/02(月) 23:35:39.51

よく見たらNimのコードも別に言語の機能としてオブジェクトプールがあるわけではなさそうだな
コード例の中で定義してるし、記事はあくまでオブジェクトプールのNimでの実装例を示しているだけだと思う
GCアルゴリズムの改善 (ORC) もあるけど、それとオブジェクトプールは別の話

元の記事も言語間の比較なんてそもそもしてないし、メモリ戦略による効率化の例を示してるだけだから、
他の言語 (C/C++/Rustに限らずC#やJavaでも) で同じことをすれば同様に「プール戦略は効率が良い」という結果は得られそう
スレで暴れてる子はそれをNimだけができる特別な方法だと思ってるのかな

**デフォルトの名無しさん** · 2024/09/02(月) 23:47:47.09

周回遅れだなｗ
Nim言語開発者が論文で示されてたプール戦略をオブジェクトプールとして導入した

論文で示されてるから他の言語 (C/C++/Rustに限らずC#やJavaでも) で同じことをすれば同様に
「プール戦略は効率が良い」という結果は当然出るに決まってる

でも現時点で論文で示されてるプール戦略を導入してるのはNim2.0だけ

**デフォルトの名無しさん** · 2024/09/03(火) 00:13:59.39

人間がCの手動メモリ管理したベンチマークより、Nim2.0は循環参照が大量に使用されていればいればいるほどムーブセマンティクスとオブジェクトプールでベンチマークが速くなる

だからNim2.0は循環参照が大量に使用されていない通常の短いコードの言語間ベンチマーク比較だとÇと変わらなくなる

**デフォルトの名無しさん** · 2024/09/03(火) 00:22:16.43

>>643
嘘つきあかんよ
示された>>605の記事でオブジェクトプールはNimの機能ではなくNimで自作していてコードも示されている
しかも記事の中でオブジェクトプールとはC++でのArena Allocationのことだと解説している

このアリーナ方式(＝オブジェクトプール方式)を用いるとメモリ割り当て解放のオーバーヘッドが減るため速くなることは昔から知られている
もちろんRustでもアリーナの使用は盛んに行われておりこのスレで「Arena」で検索すれば8レスの書き込みがある

**デフォルトの名無しさん** · 2024/09/03(火) 01:11:48.95

ここ何のスレでしたっけ？

**デフォルトの名無しさん** · 2024/09/03(火) 01:53:59.18

次世代言語スレじゃない？

**デフォルトの名無しさん** · 2024/09/03(火) 06:26:51.96

最強言語を決めようスレ

**デフォルトの名無しさん** · 2024/09/03(火) 07:16:54.59

オブジェクトプールって要はキャッシュのことでいいの？

**デフォルトの名無しさん** · 2024/09/03(火) 07:43:29.24

>>645
訂正
アリーナ方式(＝オブジェクトプール方式)はC++とNim2.0だけに導入されてるわけではないと

じゃあNim言語開発者が、RustやC++、そしてSwiftがどのようにメモリ管理を行っているかを調べ、良い部分を再組み合わせたオブジェクトプールは他の言語にあるの？

無いなら、現時点でRustやC++、そしてSwiftがどのようにメモリ管理を行っているかを調べ、良い部分を再組み合わせたオブジェクトプールはを導入してるのはNim2.0だけって事で異論はない？

**デフォルトの名無しさん** · 2024/09/03(火) 07:47:47.67

訂正（オブジェクトプール　→　ムーブセマンティクス）
じゃあNim言語開発者が、RustやC++、そしてSwiftがどのようにメモリ管理を行っているかを調べ、良い部分を再組み合わせたムーブセマンティクスは他の言語にあるの？

無いなら、現時点でRustやC++、そしてSwiftがどのようにメモリ管理を行っているかを調べ、良い部分を再組み合わせたムーブセマンティクスはを導入してるのはNim2.0だけって事で異論はない？

**デフォルトの名無しさん** · 2024/09/03(火) 07:52:41.59

アロケータを細かく制御したいなら断然Zigだろ
Arena Allocatorももちろん用意されてるし、他にも選択肢がある

**デフォルトの名無しさん** · 2024/09/03(火) 07:59:06.62

>>649
普通オブジェクトプールをキャッシュとは言わないと思うけど
まぁ挙動としてはメモリ領域のキャッシュみたいなイメージでいいかもしれない
小領域の確保と解放が繰り返されるときにキャッシュすることで実際のmalloc/free（あるいはGC）呼び出し回数を減らすためのもの

**デフォルトの名無しさん** · 2024/09/03(火) 08:03:36.62

来年にはZigがメジャーバージョン1到達見込みみたいだし期待

**デフォルトの名無しさん** · 2024/09/03(火) 08:04:09.12

Zigはこのまま未完成に終わって極少数の趣味人にしか使われないでしょう

**デフォルトの名無しさん** · 2024/09/03(火) 10:06:28.79

なんかZigファン多いみたいだから、単独スレ立てて議論したら？
ここはRustスレだから、ただ単にZigはすごいんだあって宣伝するだけなのはつまらんぞ

**デフォルトの名無しさん** · 2024/09/03(火) 10:17:54.29

C++とかGoとかNimとかの他所様のスレにRustの宣伝を書き散らしてたカスもいたわけだし
今更そんなこと言っても誰も相手にせんだろう

**デフォルトの名無しさん** · 2024/09/03(火) 10:20:47.01

アロケータ周りの不自由さはRustの代表的なウィークポイントだから
Zigと比較するのは有意義だと思うよ

Rust for Linuxで不備を指摘されて、unstable featuresとして整備し始めてるのが現状でしょ？

**デフォルトの名無しさん** · 2024/09/03(火) 10:30:58.77

入院が安定化されればクリアする話だから年内か年明けにでも解決

**デフォルトの名無しさん** · 2024/09/03(火) 13:17:35.66

スレ違いなのに書き込んでるやつは頭悪そう

**デフォルトの名無しさん** · 2024/09/03(火) 16:24:34.66

>>631
>C++を置き換えるものがRust、

doubt

**デフォルトの名無しさん** · 2024/09/03(火) 16:46:40.15

>>657
いたね
ほんとめいわく
世界中のケンタという名のプログラマを敵に回しただろう

**デフォルトの名無しさん** · 2024/09/03(火) 20:18:41.62

>>589
Nim2.0は循環参照が大量に使用されていればいるほどオブジェクトプールとムーブセマンティクスのメモリ最適化アルゴリズムで、人間がCの手動メモリ管理したベンチマークより速くなる

だからNim2.0は循環参照が大量に使用されていない通常の短いコードの言語間ベンチマーク比較だとÇと変わらなくなる

>しかもNimはC言語へトランスパイルされるんだろｗ
人間がCの手動メモリ管理したプログラムだとメモリの最適化に限界がある
Nim2.0はオブジェクトプールとムーブセマンティクスのアルゴリズムでメモリの最適化をしてるから、オブジェクトプール版のNimから生成したCのコードは人間には書けない

Nim2.0のムーブセマンティクスの本当に優れたメモリ最適化アルゴリズムと明示的にオブジェクトプールでプログラミングすることによって、人間がCの手動メモリ管理したベンチマークより2倍以上速くできる

**デフォルトの名無しさん** · 2024/09/03(火) 20:29:12.43

補足
NimはCのソースコード吐けるからから、Nimの手動メモリ管理はCの手動メモリ管理と同じとしてベンチマーク計測してる
https://github.com/Araq/fosdem2020
https://zenn.dev/dum...icles/af2b2b9f8fd890

**デフォルトの名無しさん** · 2024/09/03(火) 20:30:56.39

比較コードとベンチ結果すら示せない嘘つきがまた来てるのか

**デフォルトの名無しさん** · 2024/09/03(火) 20:49:25.51

>>665
https://github.com/Araq/fosdem2020

ベンチマーク：処理能力
Memory management strategy Time Peak Memory
mark&sweep GC 　　　　　　　　17s 　　　588.047MiB
deferred refcounting GC 　　　　　16s 　　　304.074MiB
Boehm GC 　　　　　　　　　　12s 　　　　　N/A
ARC 　　　　　　　　　　　　　　　6.75s 　　472.098MiB(379.074MiB)
manual 　　　　　　　　　　　　5.23s　　　 244.563MiB
manual(with RC) 　　　　　　　6.244s 　　　379.074MiB
object pooling 　　　　　　　　　　2.4s 　　　　　251.504MiB
パフォーマンスはどうでしょうか？結果ははるかに速く、パフォーマンスが2倍以上向上し、メモリ消費もほぼ同じです。

**デフォルトの名無しさん** · 2024/09/03(火) 20:59:57.60

それはNim同士の別方式の比較
他の言語と比較しないと意味がないね
もちろん他の言語で書いてもobject pooling (= arena allocation)方式が一番速くなることが昔から知られている

**デフォルトの名無しさん** · 2024/09/03(火) 21:00:53.22

そもそもGCを使わない方法での比較はしてるの？

**デフォルトの名無しさん** · 2024/09/03(火) 21:03:35.60

V8とRustをベースとしたJavaScript/TypeScriptランタイム環境「Deno」v1.46.2
https://forest.watch.impress.co.jp/docs/digest/1620908.html

**デフォルトの名無しさん** · 2024/09/03(火) 21:22:39.41

Poolの概念
tps://boostjp.github.io/archive/boost_docs/libs/pool/concepts.html

他の実装
Pool 割り当て機構は多くのプログラミング言語に見ることができ、多くのバリエーションが存在する。
多くの実装の端緒は、ごく普通のプログラミングに関する文献に求めることができる。
いくつかを以下に示す。これらの何れも完全な実装ではない。
多くは実装のある局面を読者への練習問題としている。
しかしながら、これらの例はどれも、ある局面が欠落しているとはいえ、
このドキュメントで述べている単純分離記憶域と同じ基底概念を使用している。

"The C++ Programming Language", 3rd ed., by Bjarne Stroustrup, Section 19.4.2.
(略)
"MicroC/OS-II: The Real-Time Kernel", by Jean J. Labrosse, Chapter 7 and Appendix B.04.
(略)
"Efficient C++: Performance Programming Techniques", by Dov Bulka and David Mayhew, Chapters 6 and 7.
(略)
"Advanced C++: Programming Styles and Idioms", by James O. Coplien, Section 3.6.
(略)

**デフォルトの名無しさん** · 2024/09/04(水) 00:24:08.00

なんでstdで公開してるんだか知らんが、rustc開発陣には面白いこと考えて実装してしまう人がいるもんだね
https://doc.rust-lang.org/std/intrinsics/mir/index.html

**デフォルトの名無しさん** · 2024/09/04(水) 06:25:46.42

>>669
https://zenn.dev/ekusiadadus/articles/bench-go-node-rust-zig

denoって遅いんだな

**デフォルトの名無しさん** · 2024/09/04(水) 06:51:22.28

>>672
バカなベンチマーク記事の典型例
Goはマルチスレッドをフルに使っていて8倍速い結果

**デフォルトの名無しさん** · 2024/09/04(水) 08:21:33.86

こっちのが各種負荷が分かりやすい
youtu.be/2hWfLiRGaNM

**デフォルトの名無しさん** · 2024/09/04(水) 13:53:11.19

どっちのロゴもださい

**デフォルトの名無しさん** · 2024/09/04(水) 18:38:20.03

いくつか記事出てるけど、Rust for Linuxは失敗に終わったみたいだね

**デフォルトの名無しさん** · 2024/09/04(水) 18:53:43.06

>>676
既に次々とRustコードが入っていってる
一方でRustを理解できない人が抵抗勢力になっていてLinus氏が釘をさした形

**デフォルトの名無しさん** · 2024/09/04(水) 20:38:51.07

具体的にLinuxの何がRustで書かれてるんだっけか

**デフォルトの名無しさん** · 2024/09/04(水) 20:51:35.06

https://github.com/torvalds/linux

カーネルにはまだ何も入ってなさそう

**デフォルトの名無しさん** · 2024/09/04(水) 21:35:17.87

だよね
知ってた

**デフォルトの名無しさん** · 2024/09/04(水) 21:39:00.59

抵抗勢力のクズを一掃できないとLinuxの敗北の始まりになるかもな

**デフォルトの名無しさん** · 2024/09/04(水) 22:30:46.44

何に敗北するんだろうか
Rust製でもっと高信頼性かつ高機能なOSをどこかが作ってたりするの？

**デフォルトの名無しさん** · 2024/09/05(木) 00:00:09.27

linux はバイナリ互換性を大事にする。
(Windows ほどではないけど。)
ドキュメントに書いてない仕様外の挙動であってもそれを変更して動かなくなるアプリケーションがあってはならないというのが基本指針。
コンパイラの挙動とも協調して細部をコントロールしてる工芸品だ。
この状態を維持したまま Rust を導入するのは無理だよ。
比較的疎結合な一部のモジュールはなんとかなるかもしれんがあえてやるには時期尚早。

**デフォルトの名無しさん** · 2024/09/05(木) 00:04:52.28

それバイナリ互換と関係ない話