公式
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/
Rust part25
■ このスレッドは過去ログ倉庫に格納されています
2024/07/31(水) 00:46:26.17ID:DBMWY2QT
566デフォルトの名無しさん
2024/09/01(日) 11:50:19.16ID:wKqEGZJE >chronoのようなほとんどのプログラムで使われない機能を
こんなこと書くやつは何書いても信用度ゼロ
”偽情報注意！”ってやつだな
こんなこと書くやつは何書いても信用度ゼロ
”偽情報注意！”ってやつだな
567デフォルトの名無しさん
2024/09/01(日) 12:08:43.54ID:cwes3csq chronoなんて日時を扱わない限り使うことないだろ
特定の分野だと必須だろうが
Rustが使われる分野は広いからね
特定の分野だと必須だろうが
Rustが使われる分野は広いからね
568デフォルトの名無しさん
2024/09/01(日) 12:21:28.53ID:Coh3zEx3 >>565
いや、ならんでしょ
結局破壊的変更があれば2.0になるわけで、実際5.0とか10.0みたいなのもあるし
まぁこの作者が1.0を宣言するんならもう十分安定してるんだろう、みたいなのはあるけどな
そういう背景情報なしなら1.0と0.1の違いは特にないと思うよ
いや、ならんでしょ
結局破壊的変更があれば2.0になるわけで、実際5.0とか10.0みたいなのもあるし
まぁこの作者が1.0を宣言するんならもう十分安定してるんだろう、みたいなのはあるけどな
そういう背景情報なしなら1.0と0.1の違いは特にないと思うよ
569デフォルトの名無しさん
2024/09/01(日) 12:26:37.18ID:ySw/MmvM バージョン0.x.yは cargo tree | grep v0 で確認できて
大量の基盤ライブラリが見つかるけどそれで困ったことはないな
>>565
そういう守るべきマナーとしては
0.x指定しておけば破壊的変更はないとされているので大丈夫
クレイトを作ってる側は破壊的変更があればx←x+1と上げるため
大量の基盤ライブラリが見つかるけどそれで困ったことはないな
>>565
そういう守るべきマナーとしては
0.x指定しておけば破壊的変更はないとされているので大丈夫
クレイトを作ってる側は破壊的変更があればx←x+1と上げるため
570デフォルトの名無しさん
2024/09/01(日) 12:51:19.19ID:wKqEGZJE >>567
chronoとtimeを合わせたダウンロード数見てみ
トップ10レベルだから
regexやserdeやrandやclapよりもずっと多い
君が書いた内容は
「regexなんて正規表現を扱わない限り使うことないだろ
特定の分野だと必須だろうが
Rustが使われる分野は広いからね」
とか
「serdeなんてシリアライズ/デシリアライズしない限り使うことないだろ
特定の分野だと必須だろうが
Rustが使われる分野は広いからね」
とかと同じレベル
どのくらい馬鹿なこと書いたかわかったかな？
chronoとtimeを合わせたダウンロード数見てみ
トップ10レベルだから
regexやserdeやrandやclapよりもずっと多い
君が書いた内容は
「regexなんて正規表現を扱わない限り使うことないだろ
特定の分野だと必須だろうが
Rustが使われる分野は広いからね」
とか
「serdeなんてシリアライズ/デシリアライズしない限り使うことないだろ
特定の分野だと必須だろうが
Rustが使われる分野は広いからね」
とかと同じレベル
どのくらい馬鹿なこと書いたかわかったかな？
571デフォルトの名無しさん
2024/09/01(日) 12:57:25.84ID:y1BosOiy Linusのリンク貼ってた人いたけどそこにも描いてある
バージョン番号に意味は無い
と
バージョン番号に意味は無い
と
572デフォルトの名無しさん
2024/09/01(日) 13:02:17.26ID:y1BosOiy573デフォルトの名無しさん
2024/09/01(日) 13:06:30.98ID:y1BosOiy574デフォルトの名無しさん
2024/09/01(日) 13:13:51.37ID:ydrH9psJ >>571
それは自分のプロジェクト (Linux) におけるバージョン番号の意味を述べてるもので、ソフトウェアライブラリ一般を指して言ったものではなくない？
それは自分のプロジェクト (Linux) におけるバージョン番号の意味を述べてるもので、ソフトウェアライブラリ一般を指して言ったものではなくない？
575デフォルトの名無しさん
2024/09/01(日) 13:26:50.54ID:t3ZzK7/4 v2.0が出た後も末永くv1.xブランチでメンテされ続けるなら意味あるけど
そんなの全く期待できないよね
そんなの全く期待できないよね
576デフォルトの名無しさん
2024/09/01(日) 13:29:19.13ID:ydrH9psJ 乱数生成ですら外部クレートが必要になるんだから、そういう言語なんだと割り切ってはいるけど
577デフォルトの名無しさん
2024/09/01(日) 13:34:18.52ID:NN/ZIFle >>573
インターフェイスの互換性はある程度は機械的検証が出来るかもしれないけど挙動の互換性まで検証するのは非現実的だろ。
バグで制約が緩かったのを修正した (ドキュメント通りに使っていれば問題ない) みたいなケースだと機械的には非互換に見えることもあるだろうし。
そこらへんは使う側でバージョンの固定をするしか仕方ない。
いや、もちろん仕組みを構築できるならそのほうがいいよ。 でも、出来ないだろ？ って話でさ。
インターフェイスの互換性はある程度は機械的検証が出来るかもしれないけど挙動の互換性まで検証するのは非現実的だろ。
バグで制約が緩かったのを修正した (ドキュメント通りに使っていれば問題ない) みたいなケースだと機械的には非互換に見えることもあるだろうし。
そこらへんは使う側でバージョンの固定をするしか仕方ない。
いや、もちろん仕組みを構築できるならそのほうがいいよ。 でも、出来ないだろ？ って話でさ。
578デフォルトの名無しさん
2024/09/01(日) 13:57:51.22ID:N2jhi4ch >>576
Rustの標準ライブラリにランダムあるよ
HashMapなどのデフォルトハッシュで使われてるのご存知でしょ
use std::hash::{BuildHasher, RandomState};
let random_seed = RandomState::new().hash_one(0_u64);
Rustの標準ライブラリにランダムあるよ
HashMapなどのデフォルトハッシュで使われてるのご存知でしょ
use std::hash::{BuildHasher, RandomState};
let random_seed = RandomState::new().hash_one(0_u64);
579デフォルトの名無しさん
2024/09/01(日) 14:22:12.72ID:MnUgJTxK >>576
playgorund とか paiza とかで use crate 出来ないのがあると面倒やね
playgorund とか paiza とかで use crate 出来ないのがあると面倒やね
580デフォルトの名無しさん
2024/09/01(日) 14:23:04.37ID:ydrH9psJ >>578
盲点だった
ハッシュマップが乱数を使うのは言われてみればその通りだ
けどこれってHashMapのための機能だし、「この方法でも乱数を得られる」であって、乱数をつくるために提供されてるものではなくない？
英語でも調べたけど、Rustで乱数を生成する方法を調べたらrandクレートの方が最初にヒットする
盲点だった
ハッシュマップが乱数を使うのは言われてみればその通りだ
けどこれってHashMapのための機能だし、「この方法でも乱数を得られる」であって、乱数をつくるために提供されてるものではなくない？
英語でも調べたけど、Rustで乱数を生成する方法を調べたらrandクレートの方が最初にヒットする
581デフォルトの名無しさん
2024/09/01(日) 14:49:06.86ID:N2jhi4ch >>580
いずれも環境に応じて最終的にはgetrandomシステムコールを呼んだり/dev/urandomを読んだりするだけだから機能としては同じだね
何度も使うならそれをシード値としてxorshiftなどするだけなのでstdだけで使えるメリットは大きいよ
いずれも環境に応じて最終的にはgetrandomシステムコールを呼んだり/dev/urandomを読んだりするだけだから機能としては同じだね
何度も使うならそれをシード値としてxorshiftなどするだけなのでstdだけで使えるメリットは大きいよ
582デフォルトの名無しさん
2024/09/01(日) 14:58:42.54ID:NN/ZIFle 必要な乱数の性質は状況によってかなり違うから安易に (ユーザの検討が不十分になりそうな形で) 特定の実装を使わせてしまうのはよくないと思う。
基本的な枠組みを定めたトレイトが標準にあると便利だろうとは思うし
そのトレイトの利用例としてひとつくらいの簡易実装は有っても良いかなとは思うけど
皆でひとつの標準を利用しようという性質のもんじゃないでしょ。
乱数は標準に入れるモチベーションはやや低いんじゃないかなぁ。
標準に入れるべきだと思うものだとなんかもっと他にあるでしょ。
基本的な枠組みを定めたトレイトが標準にあると便利だろうとは思うし
そのトレイトの利用例としてひとつくらいの簡易実装は有っても良いかなとは思うけど
皆でひとつの標準を利用しようという性質のもんじゃないでしょ。
乱数は標準に入れるモチベーションはやや低いんじゃないかなぁ。
標準に入れるべきだと思うものだとなんかもっと他にあるでしょ。
583デフォルトの名無しさん
2024/09/01(日) 16:10:10.29ID:f0nFMo6o >>５4
RustがCより速くなるベンチマークは見たことがない
Nim2.0のORCは明示的にオブジェクトプールを使ったプログラミングが必要ですが
ベンチマークがCより２倍以上速くなって、特にハードなリアルタイムシステム向け
のチューニングもできるようになってるみたい
https://zenn.dev/dum...icles/af2b2b9f8fd890
Nim2.0がCより２倍以上速くなって、しかもORCでメモリ安全も担保されているなら
Rustを使う意味がなくなると思うのですが、このベンチマークは本当なのでしょうか？
RustがCより速くなるベンチマークは見たことがない
Nim2.0のORCは明示的にオブジェクトプールを使ったプログラミングが必要ですが
ベンチマークがCより２倍以上速くなって、特にハードなリアルタイムシステム向け
のチューニングもできるようになってるみたい
https://zenn.dev/dum...icles/af2b2b9f8fd890
Nim2.0がCより２倍以上速くなって、しかもORCでメモリ安全も担保されているなら
Rustを使う意味がなくなると思うのですが、このベンチマークは本当なのでしょうか？
584デフォルトの名無しさん
2024/09/01(日) 16:37:38.74ID:ViuTOdnl Cより何倍も速い詐欺の話は他のスレでやろう
Rustと関係ないので
Rustと関係ないので
585デフォルトの名無しさん
2024/09/01(日) 16:58:53.35ID:FX04qzI+ Zigは1.0になってから出直せ！
crateはpre-1.0でもそういうもんなのでヨシ！
はーくだらね
crateはpre-1.0でもそういうもんなのでヨシ！
はーくだらね
586デフォルトの名無しさん
2024/09/01(日) 17:07:22.02ID:ydrH9psJ 言語とライブラリは流石に違わないか
ライブラリは開発止まっても同分野の別のライブラリがあればそれに差し替えられる (最悪、元のライブラリをフォークしても良い) けど、言語仕様はそうもいかないだろ
ライブラリは開発止まっても同分野の別のライブラリがあればそれに差し替えられる (最悪、元のライブラリをフォークしても良い) けど、言語仕様はそうもいかないだろ
587デフォルトの名無しさん
2024/09/01(日) 17:08:31.34ID:ROff46JY 比較の対象にすらならない
Zigはasync awaitを断念して削除
Rustはasync awaitによりCPUコアをフル活用できて実際にクラウドやCDNなどネットインフラで使われている
Zigはasync awaitを断念して削除
Rustはasync awaitによりCPUコアをフル活用できて実際にクラウドやCDNなどネットインフラで使われている
588デフォルトの名無しさん
2024/09/01(日) 17:48:17.89ID:f0nFMo6o >>584
詐欺の証明ができないのであればRustはNim2.0より劣る言語と
理解してもよろしいでしょうか？
>Rustと関係ないので
ORCでメモリ安全を担保できてCより２倍以上速くなるのであれば、
メモリ安全がありCより遅いRustは言語選択時の比較対象として関係あるだろ
詐欺の証明ができないのであればRustはNim2.0より劣る言語と
理解してもよろしいでしょうか？
>Rustと関係ないので
ORCでメモリ安全を担保できてCより２倍以上速くなるのであれば、
メモリ安全がありCより遅いRustは言語選択時の比較対象として関係あるだろ
589デフォルトの名無しさん
2024/09/01(日) 18:02:28.26ID:YFaA0adv 何でもできるC言語より速いと主張しだしたらそれは変な宗教だから相手にしてはダメ
しかもNimはC言語へトランスパイルされるんだろｗ
しかもNimはC言語へトランスパイルされるんだろｗ
590デフォルトの名無しさん
2024/09/01(日) 18:08:55.61ID:NN/ZIFle 雑に書いて十分に速いかってのと専門家が気合いを入れてチューニングをすれば最強に速いかってのは違う指標だろうし、仮に速さを比べるにしても想定を合わせないと意味がないよ。
591デフォルトの名無しさん
2024/09/01(日) 18:09:09.43ID:B8TxC8Ku CへトランスパイルされるならCより速くなってても不思議じゃないな
592デフォルトの名無しさん
2024/09/01(日) 18:15:39.95ID:tFzE2nE4 Rustは特殊なケースを持ち出さなくても
実際の実用ケースのほとんどで、Cと同じ速さ、もしくは、ほぼ同じ速さで、凝ったことをせずとも書けるから
IT業界が挙ってRustを支持した
実際の実用ケースのほとんどで、Cと同じ速さ、もしくは、ほぼ同じ速さで、凝ったことをせずとも書けるから
IT業界が挙ってRustを支持した
593デフォルトの名無しさん
2024/09/01(日) 18:34:18.72ID:ydrH9psJ 知らないから純粋な質問なんだけどnimって並行処理の安全性に強みはあるの？
個人的にRustで助かる部分だと思ってるので
メモリ周りは問題なさそう＆所有権はRustより楽そう (代わりに意図せぬコピーが起こりやすい？) に思う
個人的にRustで助かる部分だと思ってるので
メモリ周りは問題なさそう＆所有権はRustより楽そう (代わりに意図せぬコピーが起こりやすい？) に思う
594デフォルトの名無しさん
2024/09/01(日) 18:40:58.89ID:ydrH9psJ それとエラーの扱いやすさ
595デフォルトの名無しさん
2024/09/01(日) 19:43:48.04ID:f0nFMo6o >>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()
じゃあ想定を合わせるために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()
596デフォルトの名無しさん
2024/09/01(日) 20:00:37.37ID:9GOpEruV はいはい
C/C++/Rustに勝ってから出直してきてね
スレ荒らしはダメよ
C/C++/Rustに勝ってから出直してきてね
スレ荒らしはダメよ
597デフォルトの名無しさん
2024/09/01(日) 20:08:43.57ID:ZXrp9Cnz わざわざ他言語のスレに来て噛み付かなきゃいけない時点で負けていると宣言しているようなもの
その言語のスレを盛況にすればいいのに
その言語のスレを盛況にすればいいのに
599デフォルトの名無しさん
2024/09/01(日) 20:12:17.24ID:pPmOnqPH Cより速い言語が本当に出現したのならば世界的なニュースになるのでここを荒らす必要なし
600デフォルトの名無しさん
2024/09/01(日) 20:18:33.83ID:f0nFMo6o601デフォルトの名無しさん
2024/09/01(日) 20:34:03.89ID:J5FWiNml CスレやC++スレへ行ってくればいいんじゃね
相手にしてくれるかもよ
相手にしてくれるかもよ
602デフォルトの名無しさん
2024/09/01(日) 20:36:25.69ID:FX04qzI+ RustスレでRust宣伝とかいう意味のないことやり続けた報い
603デフォルトの名無しさん
2024/09/01(日) 20:42:24.60ID:ydrH9psJ604デフォルトの名無しさん
2024/09/01(日) 20:43:24.75ID:f0nFMo6o このスレはNim2.0のORCで明示的にオブジェクトプールを使ったプログラミングのベンチマークより速い事を証明できないカスばっかだな
605デフォルトの名無しさん
2024/09/01(日) 20:47:46.74ID:f0nFMo6o606デフォルトの名無しさん
2024/09/01(日) 20:49:35.02ID:/rP62rMk 検索してみたがNim 2.0がCより速いという記事が一つも見つからなかったのでガセっぽい
記事が出るまでこのお話はお預けってことで
記事が出るまでこのお話はお預けってことで
607デフォルトの名無しさん
2024/09/01(日) 20:51:46.74ID:f0nFMo6o608デフォルトの名無しさん
2024/09/01(日) 20:53:27.80ID:Coh3zEx3609デフォルトの名無しさん
2024/09/01(日) 21:03:34.87ID:ydrH9psJ Nimの過去のものより速くなったとしか読めないし
補足として貼ってるリンクもベンチマークじゃなくて言語自体の説明や公式ページだし
自分で手を動かさずにその記事だけ読んでCより速いと言うのは妄想レベルでは
補足として貼ってるリンクもベンチマークじゃなくて言語自体の説明や公式ページだし
自分で手を動かさずにその記事だけ読んでCより速いと言うのは妄想レベルでは
610デフォルトの名無しさん
2024/09/01(日) 21:14:25.35ID:f0nFMo6o >>608
NimはCのソースコード吐けるからから、Nimの手動メモリ管理はCの手動メモリ管理と同じとして、Nim2.0のORCで明示的にオブジェクトプールを使ったプログラミングと比較した場合のベンチマークが2倍以上速くなってるからCより速いと言ってる
それが間違ってると主張したいのであれば、想定を合わせるためにCでもRustでもどっちでもいいから、さっきから何度も言ってるように速いベンチマークで証明すればいいだけだろ
NimはCのソースコード吐けるからから、Nimの手動メモリ管理はCの手動メモリ管理と同じとして、Nim2.0のORCで明示的にオブジェクトプールを使ったプログラミングと比較した場合のベンチマークが2倍以上速くなってるからCより速いと言ってる
それが間違ってると主張したいのであれば、想定を合わせるためにCでもRustでもどっちでもいいから、さっきから何度も言ってるように速いベンチマークで証明すればいいだけだろ
611デフォルトの名無しさん
2024/09/01(日) 21:17:33.09ID:Coh3zEx3612デフォルトの名無しさん
2024/09/01(日) 21:24:18.89ID:MVARTL7s 言語の差でなくメモリ管理方式の差では
ライブラリにはなるけど同様のものはRustにもあるし大して変わらなさそう
ライブラリにはなるけど同様のものはRustにもあるし大して変わらなさそう
613デフォルトの名無しさん
2024/09/01(日) 21:27:22.64ID:0f8jKoK3 コーディングもベンチもせずに
NimはCより2倍速いと主張していて
心の病をうたがってしまう
NimはCより2倍速いと主張していて
心の病をうたがってしまう
614デフォルトの名無しさん
2024/09/01(日) 21:38:54.81ID:pUggxEL4 そもそもNimがCより速いっていうのが原理的におかしいんだよ…
Nimの最速実装には必ずそこから生成されたCが存在するわけで
それとも生成されたCはCとは認めない、みたいな話なんだろうか
Nimの最速実装には必ずそこから生成されたCが存在するわけで
それとも生成されたCはCとは認めない、みたいな話なんだろうか
615デフォルトの名無しさん
2024/09/01(日) 21:48:04.56ID:MVARTL7s 方式の違いを言語の差と思ってるなら
例えば誰かがコストの大きい計算をスレッドプールで高速化した実装をC++やRustで示せばそれでNimより速いと納得するんだろうか
例えば誰かがコストの大きい計算をスレッドプールで高速化した実装をC++やRustで示せばそれでNimより速いと納得するんだろうか
616デフォルトの名無しさん
2024/09/01(日) 21:52:21.87ID:f0nFMo6o >>611
>それはCでもオブジェクトプール使えば2倍速くなるのでは？
Cは手動メモリ管理しかできないオブジェクトプールの機能はないだろ
>オブジェクトプール版のNimから生成したCはまさにそういうコードだと思うけど
人間がCの手動メモリ管理したプログラムだと限界があるムーブセマンティクスの
アルゴリズムでメモリの最適化をしてるから、人間では到底太刀打ちできない事を
証明した論文があるオブジェクトプール版のNimから生成したCのコードは人間には書けない
Nim2.0のムーブセマンティクスの本当に優れた最適化とORCで明示的にオブジェクトプールでプログラミングすることによって、人間がCの手動メモリ管理したベンチマークより2倍以上速くできる
それが間違ってると主張したいのであれば、想定を合わせるためにCでもRustでもどっちでもいいから、速いベンチマークで証明すればいいだけだろ
>それはCでもオブジェクトプール使えば2倍速くなるのでは？
Cは手動メモリ管理しかできないオブジェクトプールの機能はないだろ
>オブジェクトプール版のNimから生成したCはまさにそういうコードだと思うけど
人間がCの手動メモリ管理したプログラムだと限界があるムーブセマンティクスの
アルゴリズムでメモリの最適化をしてるから、人間では到底太刀打ちできない事を
証明した論文があるオブジェクトプール版のNimから生成したCのコードは人間には書けない
Nim2.0のムーブセマンティクスの本当に優れた最適化とORCで明示的にオブジェクトプールでプログラミングすることによって、人間がCの手動メモリ管理したベンチマークより2倍以上速くできる
それが間違ってると主張したいのであれば、想定を合わせるためにCでもRustでもどっちでもいいから、速いベンチマークで証明すればいいだけだろ
617デフォルトの名無しさん
2024/09/01(日) 21:56:31.28ID:0f8jKoK3 NimはCより2倍速いと主張している人がまずはその比較コードとベンチ結果を示す義務がありますよ
618デフォルトの名無しさん
2024/09/01(日) 22:00:47.66ID:ydrH9psJ 主張するだけならどの言語でもできますがな
PythonはCよりも速い、違うというならお前らがコードを書いて証明しろ
みたいなのは面倒くさすぎて誰も相手にせんだろ
PythonはCよりも速い、違うというならお前らがコードを書いて証明しろ
みたいなのは面倒くさすぎて誰も相手にせんだろ
619デフォルトの名無しさん
2024/09/01(日) 22:04:17.16ID:f0nFMo6o620デフォルトの名無しさん
2024/09/01(日) 22:06:25.77ID:pUggxEL4 >>616
別にCでも自分でオブジェクトプール実装するなり既存のarena allocator使えばいいじゃん
まぁ言語組み込みであることで「初心者が何の最適化もしないコードを書いたときにNimが最速」となる可能性はあると思うけど、それならそのように主張してくれ
別にCでも自分でオブジェクトプール実装するなり既存のarena allocator使えばいいじゃん
まぁ言語組み込みであることで「初心者が何の最適化もしないコードを書いたときにNimが最速」となる可能性はあると思うけど、それならそのように主張してくれ
621デフォルトの名無しさん
2024/09/01(日) 22:14:20.69ID:2CzFvl+J622デフォルトの名無しさん
2024/09/01(日) 22:18:07.82ID:0f8jKoK3623デフォルトの名無しさん
2024/09/01(日) 22:19:40.68ID:B8TxC8Ku CとC++の違いも判らない人が主張してもな
624デフォルトの名無しさん
2024/09/02(月) 02:02:31.42ID:PjDKSqdJ 最近のやり取りでなんとなくここの層がわかってきたなぁ
625デフォルトの名無しさん
2024/09/02(月) 10:14:38.25ID:UFeMRrS3 MinifyされたJavaScriptのコードをChatGPTで読みやすい形式に戻すことに成功
https://gigazine.net...eering-with-chatgpt/
https://gigazine.net...eering-with-chatgpt/
626デフォルトの名無しさん
2024/09/02(月) 11:00:21.39ID:bCUpdzqg まあ確かに純粋なCとの置き換えなら別にCでええやんってなるわな
627デフォルトの名無しさん
2024/09/02(月) 12:43:05.01ID:wq6C4ZI5628デフォルトの名無しさん
2024/09/02(月) 12:57:03.37ID:o+5p2SR6 C++ に慣れてると後始末をデストラクタの中に隠蔽できてないのは抽象化の失敗だという感覚があるから defer には良い印象がない。
629デフォルトの名無しさん
2024/09/02(月) 16:42:30.80ID:ctZgLyfU RAIIがない欠陥言語たちはdeferとかwithとかusingとか毎回書かされて汚くなる
630デフォルトの名無しさん
2024/09/02(月) 16:51:36.63ID:FQfjCQIj 別にRAIIが絶対的な正解というわけではないので
そこに自由度を持たせるにはその自由度を制御するための一言が必要になるのは当然のこと
そこに自由度を持たせるにはその自由度を制御するための一言が必要になるのは当然のこと
631デフォルトの名無しさん
2024/09/02(月) 16:52:53.11ID:13HDFjot632デフォルトの名無しさん
2024/09/02(月) 17:01:06.29ID:C3j8rcv1 clang ccは最適化フラグが沢山あるし、色々やればNimと同程度の速度くらい出せるんじゃないの？知らんけど
633デフォルトの名無しさん
2024/09/02(月) 17:19:45.07ID:o+5p2SR6 >>631
defer は抽象化の失敗の表れだとは思うが抽象化をそれほど頑張らない方針を悪いと思ってるわけじゃないよ。
C++ が Better C としての用途でも超強力な選択肢として馴染みがあるからあらためて他の選択肢を使いたい気持ちがあまりないという程度の話。
defer は抽象化の失敗の表れだとは思うが抽象化をそれほど頑張らない方針を悪いと思ってるわけじゃないよ。
C++ が Better C としての用途でも超強力な選択肢として馴染みがあるからあらためて他の選択肢を使いたい気持ちがあまりないという程度の話。
634デフォルトの名無しさん
2024/09/02(月) 17:34:21.85ID:4iRl8tQB C++がBetter Cとして馴染みがあるから他の選択肢を使いたい気持ちがない人、弊社には来て欲しくねえな
馬鹿か、すごい賢くて賢い人としか働けないか、人と働いたことないかの三択だ
馬鹿か、すごい賢くて賢い人としか働けないか、人と働いたことないかの三択だ
635デフォルトの名無しさん
2024/09/02(月) 17:37:11.39ID:lNYL9rdL Zigは結局のところ個人開発止まりで終わるよ
636デフォルトの名無しさん
2024/09/02(月) 18:24:18.22ID:VEiLzJpt >>632
Nimはclangに対応してる
Nim言語開発者がCの手動メモリ管理ソースをclangで最適化コンパイルしてたら5.23sで変わらないんじゃない
Memory management strategy Time Peak Memory
manual 5.23s 244.563MiB
Nimはclangに対応してる
Nim言語開発者がCの手動メモリ管理ソースをclangで最適化コンパイルしてたら5.23sで変わらないんじゃない
Memory management strategy Time Peak Memory
manual 5.23s 244.563MiB
637デフォルトの名無しさん
2024/09/02(月) 18:32:02.91ID:VEiLzJpt 補足
NimはCのソースコード吐けるからから、Nimの手動メモリ管理はCの手動メモリ管理と同じとしてベンチマーク計測してる
https://github.com/Araq/fosdem2020
https://zenn.dev/dumblepy/articles/af2b2b9f8fd890
NimはCのソースコード吐けるからから、Nimの手動メモリ管理はCの手動メモリ管理と同じとしてベンチマーク計測してる
https://github.com/Araq/fosdem2020
https://zenn.dev/dumblepy/articles/af2b2b9f8fd890
638デフォルトの名無しさん
2024/09/02(月) 18:41:55.01ID:VEiLzJpt 補足2
人間がCの手動メモリ管理したプログラムだと限界がある
Nim2.0のムーブセマンティクスの本当に優れたアルゴリズムでメモリの最適化をしてるから、人間では到底太刀打ちできない事を証明した論文がある
オブジェクトプール版のNimから生成したCのコードは人間には書けない
Nim2.0のムーブセマンティクスの本当に優れた最適化とORCで明示的にオブジェクトプールでプログラミングすることによって、人間がCの手動メモリ管理したベンチマークより2倍以上速くできる
人間がCの手動メモリ管理したプログラムだと限界がある
Nim2.0のムーブセマンティクスの本当に優れたアルゴリズムでメモリの最適化をしてるから、人間では到底太刀打ちできない事を証明した論文がある
オブジェクトプール版のNimから生成したCのコードは人間には書けない
Nim2.0のムーブセマンティクスの本当に優れた最適化とORCで明示的にオブジェクトプールでプログラミングすることによって、人間がCの手動メモリ管理したベンチマークより2倍以上速くできる
639デフォルトの名無しさん
2024/09/02(月) 18:51:06.06ID:x+sFU8Hh640デフォルトの名無しさん
2024/09/02(月) 19:04:49.90ID:VEiLzJpt >>639
Nim言語開発者のORCで明示的にオブジェクトプールを使ったプログラミングのベンチマークがガセだと思うなら、それよりも速いベンチマークで証明すればいいだけだろ
Nim言語開発者のORCで明示的にオブジェクトプールを使ったプログラミングのベンチマークがガセだと思うなら、それよりも速いベンチマークで証明すればいいだけだろ
641デフォルトの名無しさん
2024/09/02(月) 19:17:59.50ID:CQW1lAEf Nimの方が速いというコード比較ベンチが一つも存在しないから
現状ではNimが速いは嘘と判断するしかないね
現状ではNimが速いは嘘と判断するしかないね
642デフォルトの名無しさん
2024/09/02(月) 23:35:39.51ID:Azu0Ww0Z よく見たらNimのコードも別に言語の機能としてオブジェクトプールがあるわけではなさそうだな
コード例の中で定義してるし、記事はあくまでオブジェクトプールのNimでの実装例を示しているだけだと思う
GCアルゴリズムの改善 (ORC) もあるけど、それとオブジェクトプールは別の話
元の記事も言語間の比較なんてそもそもしてないし、メモリ戦略による効率化の例を示してるだけだから、
他の言語 (C/C++/Rustに限らずC#やJavaでも) で同じことをすれば同様に「プール戦略は効率が良い」という結果は得られそう
スレで暴れてる子はそれをNimだけができる特別な方法だと思ってるのかな
コード例の中で定義してるし、記事はあくまでオブジェクトプールのNimでの実装例を示しているだけだと思う
GCアルゴリズムの改善 (ORC) もあるけど、それとオブジェクトプールは別の話
元の記事も言語間の比較なんてそもそもしてないし、メモリ戦略による効率化の例を示してるだけだから、
他の言語 (C/C++/Rustに限らずC#やJavaでも) で同じことをすれば同様に「プール戦略は効率が良い」という結果は得られそう
スレで暴れてる子はそれをNimだけができる特別な方法だと思ってるのかな
643デフォルトの名無しさん
2024/09/02(月) 23:47:47.09ID:LcFbNhg2 周回遅れだなｗ
Nim言語開発者が論文で示されてたプール戦略をオブジェクトプールとして導入した
論文で示されてるから他の言語 (C/C++/Rustに限らずC#やJavaでも) で同じことをすれば同様に
「プール戦略は効率が良い」という結果は当然出るに決まってる
でも現時点で論文で示されてるプール戦略を導入してるのはNim2.0だけ
Nim言語開発者が論文で示されてたプール戦略をオブジェクトプールとして導入した
論文で示されてるから他の言語 (C/C++/Rustに限らずC#やJavaでも) で同じことをすれば同様に
「プール戦略は効率が良い」という結果は当然出るに決まってる
でも現時点で論文で示されてるプール戦略を導入してるのはNim2.0だけ
644デフォルトの名無しさん
2024/09/03(火) 00:13:59.39ID:kXSWNX4e 人間がCの手動メモリ管理したベンチマークより、Nim2.0は循環参照が大量に使用されていればいればいるほどムーブセマンティクスとオブジェクトプールでベンチマークが速くなる
だからNim2.0は循環参照が大量に使用されていない通常の短いコードの言語間ベンチマーク比較だとÇと変わらなくなる
だからNim2.0は循環参照が大量に使用されていない通常の短いコードの言語間ベンチマーク比較だとÇと変わらなくなる
645デフォルトの名無しさん
2024/09/03(火) 00:22:16.43ID:SddP/phw646デフォルトの名無しさん
2024/09/03(火) 01:11:48.95ID:1HHGF7Zl ここ何のスレでしたっけ？
647デフォルトの名無しさん
2024/09/03(火) 01:53:59.18ID:Dbzwi48i 次世代言語スレじゃない？
648デフォルトの名無しさん
2024/09/03(火) 06:26:51.96ID:q/sgL6ap 最強言語を決めようスレ
649デフォルトの名無しさん
2024/09/03(火) 07:16:54.59ID:1bP400Ev オブジェクトプールって要はキャッシュのことでいいの？
650デフォルトの名無しさん
2024/09/03(火) 07:43:29.24ID:kXSWNX4e >>645
訂正
アリーナ方式(＝オブジェクトプール方式)はC++とNim2.0だけに導入されてるわけではないと
じゃあNim言語開発者が、RustやC++、そしてSwiftがどのようにメモリ管理を行っているかを調べ、良い部分を再組み合わせたオブジェクトプールは他の言語にあるの？
無いなら、現時点でRustやC++、そしてSwiftがどのようにメモリ管理を行っているかを調べ、良い部分を再組み合わせたオブジェクトプールはを導入してるのはNim2.0だけって事で異論はない？
訂正
アリーナ方式(＝オブジェクトプール方式)はC++とNim2.0だけに導入されてるわけではないと
じゃあNim言語開発者が、RustやC++、そしてSwiftがどのようにメモリ管理を行っているかを調べ、良い部分を再組み合わせたオブジェクトプールは他の言語にあるの？
無いなら、現時点でRustやC++、そしてSwiftがどのようにメモリ管理を行っているかを調べ、良い部分を再組み合わせたオブジェクトプールはを導入してるのはNim2.0だけって事で異論はない？
651デフォルトの名無しさん
2024/09/03(火) 07:47:47.67ID:kXSWNX4e 訂正（オブジェクトプール → ムーブセマンティクス）
じゃあNim言語開発者が、RustやC++、そしてSwiftがどのようにメモリ管理を行っているかを調べ、良い部分を再組み合わせたムーブセマンティクスは他の言語にあるの？
無いなら、現時点でRustやC++、そしてSwiftがどのようにメモリ管理を行っているかを調べ、良い部分を再組み合わせたムーブセマンティクスはを導入してるのはNim2.0だけって事で異論はない？
じゃあNim言語開発者が、RustやC++、そしてSwiftがどのようにメモリ管理を行っているかを調べ、良い部分を再組み合わせたムーブセマンティクスは他の言語にあるの？
無いなら、現時点でRustやC++、そしてSwiftがどのようにメモリ管理を行っているかを調べ、良い部分を再組み合わせたムーブセマンティクスはを導入してるのはNim2.0だけって事で異論はない？
652デフォルトの名無しさん
2024/09/03(火) 07:52:41.59ID:e/LVUItZ アロケータを細かく制御したいなら断然Zigだろ
Arena Allocatorももちろん用意されてるし、他にも選択肢がある
Arena Allocatorももちろん用意されてるし、他にも選択肢がある
653デフォルトの名無しさん
2024/09/03(火) 07:59:06.62ID:32lfd5Tu >>649
普通オブジェクトプールをキャッシュとは言わないと思うけど
まぁ挙動としてはメモリ領域のキャッシュみたいなイメージでいいかもしれない
小領域の確保と解放が繰り返されるときにキャッシュすることで実際のmalloc/free（あるいはGC）呼び出し回数を減らすためのもの
普通オブジェクトプールをキャッシュとは言わないと思うけど
まぁ挙動としてはメモリ領域のキャッシュみたいなイメージでいいかもしれない
小領域の確保と解放が繰り返されるときにキャッシュすることで実際のmalloc/free（あるいはGC）呼び出し回数を減らすためのもの
654デフォルトの名無しさん
2024/09/03(火) 08:03:36.62ID:LULqlZCj 来年にはZigがメジャーバージョン1到達見込みみたいだし期待
655デフォルトの名無しさん
2024/09/03(火) 08:04:09.12ID:UM5ITwja Zigはこのまま未完成に終わって極少数の趣味人にしか使われないでしょう
656デフォルトの名無しさん
2024/09/03(火) 10:06:28.79ID:+fPFl5kU なんかZigファン多いみたいだから、単独スレ立てて議論したら？
ここはRustスレだから、ただ単にZigはすごいんだあって宣伝するだけなのはつまらんぞ
ここはRustスレだから、ただ単にZigはすごいんだあって宣伝するだけなのはつまらんぞ
657デフォルトの名無しさん
2024/09/03(火) 10:17:54.29ID:Dbzwi48i C++とかGoとかNimとかの他所様のスレにRustの宣伝を書き散らしてたカスもいたわけだし
今更そんなこと言っても誰も相手にせんだろう
今更そんなこと言っても誰も相手にせんだろう
658デフォルトの名無しさん
2024/09/03(火) 10:20:47.01ID:e/LVUItZ アロケータ周りの不自由さはRustの代表的なウィークポイントだから
Zigと比較するのは有意義だと思うよ
Rust for Linuxで不備を指摘されて、unstable featuresとして整備し始めてるのが現状でしょ？
Zigと比較するのは有意義だと思うよ
Rust for Linuxで不備を指摘されて、unstable featuresとして整備し始めてるのが現状でしょ？
659デフォルトの名無しさん
2024/09/03(火) 10:30:58.77ID:oCyo/VGZ 入院が安定化されればクリアする話だから年内か年明けにでも解決
660デフォルトの名無しさん
2024/09/03(火) 13:17:35.66ID:q/sgL6ap スレ違いなのに書き込んでるやつは頭悪そう
661デフォルトの名無しさん
2024/09/03(火) 16:24:34.66ID:/Ve5otW6662デフォルトの名無しさん
2024/09/03(火) 16:46:40.15ID:/Ve5otW6663デフォルトの名無しさん
2024/09/03(火) 20:18:41.62ID:70res71t >>589
Nim2.0は循環参照が大量に使用されていればいるほどオブジェクトプールとムーブセマンティクスのメモリ最適化アルゴリズムで、人間がCの手動メモリ管理したベンチマークより速くなる
だからNim2.0は循環参照が大量に使用されていない通常の短いコードの言語間ベンチマーク比較だとÇと変わらなくなる
>しかもNimはC言語へトランスパイルされるんだろｗ
人間がCの手動メモリ管理したプログラムだとメモリの最適化に限界がある
Nim2.0はオブジェクトプールとムーブセマンティクスのアルゴリズムでメモリの最適化をしてるから、オブジェクトプール版のNimから生成したCのコードは人間には書けない
Nim2.0のムーブセマンティクスの本当に優れたメモリ最適化アルゴリズムと明示的にオブジェクトプールでプログラミングすることによって、人間がCの手動メモリ管理したベンチマークより2倍以上速くできる
Nim2.0は循環参照が大量に使用されていればいるほどオブジェクトプールとムーブセマンティクスのメモリ最適化アルゴリズムで、人間がCの手動メモリ管理したベンチマークより速くなる
だからNim2.0は循環参照が大量に使用されていない通常の短いコードの言語間ベンチマーク比較だとÇと変わらなくなる
>しかもNimはC言語へトランスパイルされるんだろｗ
人間がCの手動メモリ管理したプログラムだとメモリの最適化に限界がある
Nim2.0はオブジェクトプールとムーブセマンティクスのアルゴリズムでメモリの最適化をしてるから、オブジェクトプール版のNimから生成したCのコードは人間には書けない
Nim2.0のムーブセマンティクスの本当に優れたメモリ最適化アルゴリズムと明示的にオブジェクトプールでプログラミングすることによって、人間がCの手動メモリ管理したベンチマークより2倍以上速くできる
664デフォルトの名無しさん
2024/09/03(火) 20:29:12.43ID:70res71t 補足
NimはCのソースコード吐けるからから、Nimの手動メモリ管理はCの手動メモリ管理と同じとしてベンチマーク計測してる
https://github.com/Araq/fosdem2020
https://zenn.dev/dum...icles/af2b2b9f8fd890
NimはCのソースコード吐けるからから、Nimの手動メモリ管理はCの手動メモリ管理と同じとしてベンチマーク計測してる
https://github.com/Araq/fosdem2020
https://zenn.dev/dum...icles/af2b2b9f8fd890
665デフォルトの名無しさん
2024/09/03(火) 20:30:56.39ID:65xXv9p+ 比較コードとベンチ結果すら示せない嘘つきがまた来てるのか
■ このスレッドは過去ログ倉庫に格納されています
