Rust part21

**デフォルトの名無しさん** · 2023/08/15(火) 22:24:39.45

公式
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 part20
https://mevius.2ch.net/test/read.cgi/tech/1677771928/

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

**デフォルトの名無しさん** · 2023/09/19(火) 07:20:03.69

>>294
目的のために敢えてUB引き起こすってこと？

**デフォルトの名無しさん** · 2023/09/19(火) 11:44:23.57

>>294
＞そういうときにでもどうにかする知見が C/C++ では積み上がってる。

所謂、バッドノウハウね。
そりゃさんざん今までやりまくって、なんなら現在進行形だったりするんだからノウハウも積み上がるさ。

**デフォルトの名無しさん** · 2023/09/19(火) 13:23:13.06

データベースのデータファイルの中の構造は、
C言語の「全部生メモリ」状態で、ポインタの
変わりにファイルポジションになっていて
普通に相互リンクトリンクやファイルポジション
をデータの位置を表現するのに使われていたりする。
だから、実行中のプログラムの RAM のメモリー安全
は確保されたとしても、ファイルの中は安全には
ならない。

**デフォルトの名無しさん** · 2023/09/19(火) 13:27:32.55

>>298
[補足]
・ポインターの代わりにファイルポジションが使用され、
　古来の plain C と同様のプロググラミングが行なわれている。
・LockFile や fnctl で「部分ロック」が当たり前
　のように使用されており、非常に複雑な
　配慮が必要なプログラミングになっている。

もっといえば、DBMS を使うアプリケーションも、非常に
配慮が必要な場合も多く、どのようなテーブルやカラム構造
にするかは難しい。ID番号をリンクしたり、どうやって
データを参照しあうかなどが生ポインタと同様の難しさ
を持っていて、わずかでも間違えば、全データが論理破損
してしまう可能性を持っている。

**デフォルトの名無しさん** · 2023/09/19(火) 14:54:41.30

だれか巻き込まれてないか？
https://www.youtube.com/watch?v=SzpaDEhm-8Q

**デフォルトの名無しさん** · 2023/09/19(火) 15:58:16.52

形式検証をrustに組み込むのってどれくらい現実的なんだろ
言語本体ではなくてproc macroで実現できるのかね

**デフォルトの名無しさん** · 2023/09/19(火) 16:39:15.02

>>299
一般的なDBMSは中央集権でページアクセスを一元管理してるから生ポインタとは全く質が異なる

**デフォルトの名無しさん** · 2023/09/19(火) 17:37:47.80

>>302
ただ、購入履歴などは「誰が購入したか」のIDを
購入項目テーブルとユーザーテーブルを結びつける
必要があるので、IDがポインタの役割になる。
わずかでも狂うと、別人が買った項目が結び付け
られてしまう。
値が1つ、または、行が一行でもずれるとほぼ全体が破綻する。

**デフォルトの名無しさん** · 2023/09/19(火) 18:14:50.54

DBでも何でもそうだけどshared xor mutableも必要

**デフォルトの名無しさん** · 2023/09/19(火) 18:23:26.80

販売サイトなどのバグって怖くて、500円のものが
バグれば5000円になったりする可能性ある。
そういうものは、プログラミングを気をつける
しかなくて、Rustの安全対策でも防げない。

**デフォルトの名無しさん** · 2023/09/19(火) 18:32:19.28

「気を付ける」の内訳にはテストを書く習慣とかが含まれてる。
気を付けないとしょうがないけど
気を付けるのに使える道具はそれなりに揃ってる。

**デフォルトの名無しさん** · 2023/09/19(火) 18:34:24.73

すべてのバグをなくせる言語がないのは当たり前
データ競合により起こるそういう値のバグも現実にあるのだからRustでその手のバグをなくせるのも事実

**デフォルトの名無しさん** · 2023/09/19(火) 18:55:07.79

>>303
そのレイヤーの話でもDBMSはトランザクション管理されてるから生ポインタとは状況が全く異なる
トランザクショナルメモリで管理された共有メモリと生ポインタの違い(実際はそれよりもまだ差がある)

**デフォルトの名無しさん** · 2023/09/19(火) 19:02:27.03

>>304
同時実行制御には大きく楽観的制御と悲観的制御があるがshared xor mutableは後者
高い同時実行性能が求められる場合には楽観的同時実行制御を使うことが増えている
DBの話だけでなくロックフリーアルゴリズムも基本は楽観的制御

**デフォルトの名無しさん** · 2023/09/19(火) 19:54:07.45

>>309
楽観的排他制御を用いることができる現実的ケースが狭い
衝突した時の処理やり直しコストも考慮する必要がある

その一般的な話とは別にポインタ(参照)の話の方は必ず衝突するためsingle writer xor multiple readersが必須

**デフォルトの名無しさん** · 2023/09/19(火) 21:00:27.72

排他制御も凄く奥深い話ではあるが、そういう
ものだけでなく、単なるプログラムミスで、
ID番号が1つずれたり、行がなんらかの事が
原因で1ぎょうずれたりしても、大変な問題
を巻き起こす。だからテストは必須。

**デフォルトの名無しさん** · 2023/09/19(火) 21:30:53.89

RDBMSで物理的な一行とか関係ない
テキストファイルに永続化してる素人だな

**デフォルトの名無しさん** · 2023/09/19(火) 21:34:30.39

>>312
DBMS自体をプログラムする場合には関係ある。

**デフォルトの名無しさん** · 2023/09/19(火) 21:41:37.42

それと、DBMSを使うに徹する場合でも、行に
付ける ID 番号の管理がまた問題になる。
それも慎重に良く考える必要がある。

**デフォルトの名無しさん** · 2023/09/19(火) 21:50:10.01

それサロゲートキー義務で設計したらの話でしょ

**デフォルトの名無しさん** · 2023/09/19(火) 21:55:08.52

>>315
色々な機能を実装する上で、色々有り得る。

**デフォルトの名無しさん** · 2023/09/19(火) 22:32:18.55

>それと、DBMSを使うに徹する場合でも、行に
>付ける ID 番号の管理がまた問題になる。

DB板にもそういうのいるけどRDBにID必要と考えてるやつはもっかい勉強してこい

**デフォルトの名無しさん** · 2023/09/19(火) 22:44:03.77

>>310
>楽観的排他制御を用いることができる現実的ケースが狭い
MVCCやCASが楽観的制御
分散非同期が前提の世界では楽観的制御がデフォルト
じゃないとスケールしないから

Rustがコンパイル時悲観的制御にしてるのは実行時の管理を無くしたいからであってポインタだとshared xor mutableが必須だからではない
トランザクショナルメモリがその一例

**デフォルトの名無しさん** · 2023/09/19(火) 22:57:59.75

DBMSをプログラムする場合には当然関係ある
でも1行ずれたら大変とかいう下手くそは任されないので関係ない

**デフォルトの名無しさん** · 2023/09/19(火) 23:03:17.25

>>319
下手クソとか上手いとかっていうより、
そうならないようなアルゴリズムやデータ構造を
ちゃんと考える能力があるかどうかなん
だろうけどな。

**デフォルトの名無しさん** · 2023/09/19(火) 23:06:22.84

可変参照と不変参照に対してMVCCなんて使えないよ
それはデータをコピーすることと同じになってしまう
ソフトウェアトランザクショナルメモリはどの環境でも使用可能なのに不利だからほぼ使われていない
さらにRustのshared xor mutableはそれらと独立した話であり共存できる話なのでshared xor mutable必須は問題ない

**デフォルトの名無しさん** · 2023/09/20(水) 01:44:31.66

会話のドッジボール

**デフォルトの名無しさん** · 2023/09/20(水) 09:31:56.94

>>303
マイニャンバーですね判ります

**デフォルトの名無しさん** · 2023/09/20(水) 09:33:37.66

>>305
500円の商品が5000円になるバグよりも
500円の商品が5円になるバグの方がはるかに怖い

**デフォルトの名無しさん** · 2023/09/20(水) 09:37:31.04

>>313
いやいやωωω

**デフォルトの名無しさん** · 2023/09/20(水) 09:39:49.95

>>324
一番の問題は、レジ打ちの人間だったら絶対間違わない
ミスがコンピュータでは起こりえるということだよ。

**デフォルトの名無しさん** · 2023/09/20(水) 09:41:04.74

>>325
DBMSのアルゴリズムやSQLiteのソースなどを見ていたが、
大いに関係あるぞ。

**デフォルトの名無しさん** · 2023/09/20(水) 10:30:52.85

SQLiteはファイルロックに頼らざるを得ない仕組みなのでDBとしては特殊

**デフォルトの名無しさん** · 2023/09/20(水) 11:17:52.24

俺が高校生だった25年前頃、志木駅で500円分ぐらいのパンを買ったら4000円ぐらい請求されたぞ

**デフォルトの名無しさん** · 2023/09/20(水) 11:46:41.00

まあ他のバグが減ればその分本質的な問題に注力出来るわな
そういうのはテストケースも綿密に行う必要がある

**デフォルトの名無しさん** · 2023/09/20(水) 12:17:55.14

>>317
むしろナチュラルキーにして詰んだりバグってる

**デフォルトの名無しさん** · 2023/09/20(水) 13:53:51.14

ナチュラルキーがプロジェクトの最後までユニーク保障されたことなんかマジで無いズラ
サロゲートキーは必須ズラ

**デフォルトの名無しさん** · 2023/09/20(水) 14:13:13.56

今日入門した。ツアーやったらサンプルプログラムが80個ぐらいできた
fn a(i: i32){ println!("{}",i) }
fn main(){ let x = 10; a(x); a(x) }
これは10が2回出力される
構造体引数だと2回よべずにエラーが出たけど
プリミティブ型？なら所有権がどうのとかなくてスタックにコピーされるだけであってる？

**333** · 2023/09/20(水) 14:30:53.92

別のチュートリアル始めて理解した
コピートレイトが実装されてるからなのか

**デフォルトの名無しさん** · 2023/09/20(水) 15:53:12.11

#[derive(Copy)] 禁止

**デフォルトの名無しさん** · 2023/09/20(水) 18:16:56.45

>>328
他のDBMSでもプロセス間の排他制御は
出来る方法が限られているのでファイルロックを
使っている可能性が高い。
他の方法だと、mkdir 法や、名前付きパイプが
あることがあるが、ファイルロックの方が便利。
一つのプロセスの中のスレッド間の排他制御は
色々な方法が有るが、プロセスを越えた排他制御
は意外と他に出来る方法が無いから。

**デフォルトの名無しさん** · 2023/09/20(水) 18:33:23.45

>>335
#[derive(Copy,Clone)]はもう試しました
Rustのいいところが失われますね

**デフォルトの名無しさん** · 2023/09/20(水) 18:51:23.96

rustの名前の由来は？

**デフォルトの名無しさん** · 2023/09/20(水) 19:07:11.98

https://en.wikipedia.org/wiki/Rust_(fungus)

robustな菌らしい

**デフォルトの名無しさん** · 2023/09/20(水) 19:38:07.98

OpenGLをやりたくてcrates.ioで最新版を調べてCargo.tomlに
[dependencies]
bytemuck = "1.14.0"
ogl33 = "0.3.0"

[dev-dependencies]
beryllium = "0.13.0"
imagine = "0.5.1"

このプログラムをビルドするとberylliumがunresolvedと出ます
use beryllium::*;
fn main() { let sdl = Sdl::init(init::InitFlags::EVERYTHING); }
berylliumのパッケージ名が変わったりしたのでしょうか
わかる人いますか

**デフォルトの名無しさん** · 2023/09/20(水) 20:29:54.63

>>336
さすがにmutex_lock使ってるよ
乏しい経験からの妄想なんかじゃなく、ちゃんとソース見れ

**デフォルトの名無しさん** · 2023/09/20(水) 21:48:28.31

>>331
ナチュラルキーをまともに扱えない奴はそもそも設計者失格だろう

**デフォルトの名無しさん** · 2023/09/20(水) 22:20:31.31

>>340
単純に動かすだけならdev-dependenciesからdependenciesに移せばいいと思う

テスト用の依存としてdev-dependenciesにこだわるなら
use beryllium::*;
の前に
extern crate beryllium;
を入れれば通るかな
あまりdev-dependencies使わないから分からん

**デフォルトの名無しさん** · 2023/09/20(水) 22:37:25.93

>>343 ありがとうございます、動かせました！楽しい

**デフォルトの名無しさん** · 2023/09/20(水) 23:23:26.93

dev-dependenciesについてはこの辺参照
testやbenchやexampleだけで使う依存を定義するやつ
https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#development-dependencies

main関数の中で必要なら普通のdependencyにしないといけない
extern crateは関係ない

**デフォルトの名無しさん** · 2023/09/20(水) 23:35:58.10

>>331
未来永劫ユニークとノンヌルを単独ナチュラルキーで満たせればいいけど
そうでないときもあるもんね

>>336
プロセス間mutexやセマフォもあるよ

>>337
小さいデータならCopy実装は有利

**デフォルトの名無しさん** · 2023/09/21(木) 00:37:39.43

>>336
単一ファイルでまかなうSqliteと一緒にすんな

**デフォルトの名無しさん** · 2023/09/21(木) 02:18:25.33

>>341
CreateMutex()の第三引数に名前を指定しなければ
ならないが、ユニークな名前をどうやって作るか
が大問題になるよね。
その点、LockFile() なら名前衝突の問題は
最初から簡単に確実に回避できる。

**デフォルトの名無しさん** · 2023/09/21(木) 03:10:10.71

普通のDBってインターフェースを一つのサーバーで提供してると思うんだけど
名前解決が出来ない管理なんてあるの？

**デフォルトの名無しさん** · 2023/09/21(木) 03:14:44.34

>>349
なるほど。そういうことか。
SQLiteは、中央サーバー的なプロセスが無いから
事情が違うってことなんだな。

**デフォルトの名無しさん** · 2023/09/21(木) 04:39:08.18

まずプロセスを分けるメリットがない
CPUコアスレッド数のスレッドを立ち上げれば一つのプロセスでそのマシンのリソースを使い切れる
ただし通信待ちでスレッドが止まったらその分のCPUリソースを無駄にしてしまうため各スレッドで複数のタスクを動かす
ただし各スレッドが抱えるタスク数は偏りがちなことが知られているため暇なスレッドは他からタスクを盗んで実行できるようにする
以上のスケジューリングをするのがRustのtokio

**デフォルトの名無しさん** · 2023/09/21(木) 08:25:19.60

https://www.sqlite.org/whyc.html

**デフォルトの名無しさん** · 2023/09/21(木) 10:46:48.71

>>352
Rust以外の言語は完全に否定されているけど
今後Rustだけは条件を満たせば採用するとあるね

**デフォルトの名無しさん** · 2023/09/21(木) 10:59:44.45

mutable xor sharedはトランザクション分離レベルで言うとSERIALIZABLEだと思うけど、書き込み性能にけっこう致命的なパフォーマンス劣化が出たりしない？

あらかじめ主要な書き込み先オブジェクトの参照を保持しておくとかのオブジェクト指向の定石が利用出来ないし。

**デフォルトの名無しさん** · 2023/09/21(木) 11:03:41.54

SQLiteは今、日本の人が一人でRustに移植してるみたいだけど？
完成度は知らない

**デフォルトの名無しさん** · 2023/09/21(木) 13:31:34.10

>>351
MySQLやPostgreSQLみたいな普通のDBMSでは
単一プロセスがデーモンとして常駐してファイル更新
を一元管理するのが前提となっているが、
SQLiteでは、そのような常駐プロセスが
存在しなくて、各アプリがSQLiteのライブラリ
プログラムを呼び出して、ライブラリの関数が
排他制御を行なって単一ファイルを壊さないように
ロックしながら互いに強調しつつ、部分書き換えや
部分読み込みを行っている。
つまり、SQLiteは管理を担う単一の常駐プログラム
がなくて、個々のアプリ(の中のライブラリ)が
協調動作するようになっている。
だから、プロセス間で同期を取る仕組みが必要となる。
しかし、CreateMutexでは、ユニークな名前が必要
となってしまい、その名前を決めるのがメンドクサイ。
一方、LockFile だとファイルのパス名で自動的に
ユニークの名前に出来てしまうから、非常に簡単に
安全に正しくロックできる。

**デフォルトの名無しさん** · 2023/09/21(木) 16:18:11.92

3文字で言うと

**デフォルトの名無しさん** · 2023/09/21(木) 16:54:51.87

SQLite便利だよ

**デフォルトの名無しさん** · 2023/09/21(木) 17:25:46.98

sqliteは便利だけどテーブルロックなところがうんこなんだよな
begin conccurentとか予定あるらしいが

**デフォルトの名無しさん** · 2023/09/21(木) 20:32:07.68

複数のプロセスからアクセスしないのを前提条件に出来る場合もそれなりにあるもんな。
ちょっとしたツールでデータベースのプロセスをいちいち起動するのはわずらわしいし、 sqlite くらいの気軽さはありがたいのは確か。
sqlite みたいな方針のデータベースが他に台頭してないのが不思議なくらいだ。

**デフォルトの名無しさん** · 2023/09/21(木) 20:41:30.87

>>359
テーブルロックじゃなくデータベースロック
multiple reader xor single writerはデータベース単位

**デフォルトの名無しさん** · 2023/09/21(木) 20:59:40.19

もっとひどいデータベース単位か
https://www.sqlite.org/cgi/src/doc/begin-concurrent/doc/begin_concurrent.md
これでページ単位が導入されても、select for updateみたいに明示的にロック
がほしいな
リトライとかだるい

**デフォルトの名無しさん** · 2023/09/21(木) 20:59:47.82

もっとひどいデータベース単位か
https://www.sqlite.org/cgi/src/doc/begin-concurrent/doc/begin_concurrent.md
これでページ単位が導入されても、select for updateみたいに明示的にロック
がほしいな
リトライとかだるい

**デフォルトの名無しさん** · 2023/09/21(木) 23:58:45.91

以下のような関数(実際のものとは少し違いますが)を実装してみたのですがイテレータのメソッドチェーンの箇所で型が合っていないとコンパイルエラーが発生します
アルゴリズム自体を変更することで目的としていた処理はできましたが結局このエラーの直し方がわかりません
ライフタイム周りが原因だとは考えていますがどのように修正すればよいしょうか

fn hoge(
func: &impl Fn((&i64, i64)) -> i64,
arr: &[i64],
ret: &mut Vec<impl Iterator<Item = i64>>
) {
ret.push(arr.iter().zip(std::iter::repeat(arr[0])).map(func));
for i in 1..arr.len() {
hoge(func, &arr[i..], ret);
}
}

**デフォルトの名無しさん** · 2023/09/22(金) 09:19:17.11

fn hoge(
func: &impl Fn((&i64, i64)) -> i64,
arr: &[i64],
ret: &mut Vec<impl Iterator<Item = i64>>
) {
ret.push(arr.iter().zip(std::iter::repeat(arr[0])).map(func).collect()[0]);
for i in 1..arr.len() {
hoge(func, &arr[i..], ret);
}
}

**デフォルトの名無しさん** · 2023/09/22(金) 12:36:56.71

lifetimeの問題もあるかもしれないがimpl Iteratorの型をとるところに関数内で生成したイテレータを渡しているのがそもそもおかしい

**デフォルトの名無しさん** · 2023/09/22(金) 13:53:26.70

>>360
mdb

**デフォルトの名無しさん** · 2023/09/22(金) 16:15:11.47

>>366
mapにはhogeの外から引数として関数を渡しているので再帰呼出しごとにイテレータの型は変わらないですし
```
let mut v = Vec::new();
hoge(|(&a, b)| a + b, &[1, 3, 5], &mut v);
```
という形でhogeを呼び出せばイテレータの型は自動的に推論されると思うんですが...

**デフォルトの名無しさん** · 2023/09/22(金) 18:07:36.44

impl TraitはTraitを実装した型のいずれか一つを受け入れるだけで、Traitを実装した型全てを受け入れるわけではない

**デフォルトの名無しさん** · 2023/09/22(金) 18:31:55.39

>>369
mapの中に直接クロージャを渡せば確かにその制限に引っかかりますが、今回は再帰の中で一つの関数を使いまわしているのでimpl Iteratorの型は一つに固定されませんか?

**デフォルトの名無しさん** · 2023/09/22(金) 18:41:57.56

>>365
イテレータのまま保持して遅延評価させたいんです

**デフォルトの名無しさん** · 2023/09/22(金) 18:43:25.81

関数定義から一意な具体型に推論されるのは戻り値型に書いた impl の話ですね
引数型に書いた impl は単にジェネリック引数を匿名化したものという扱いなので
hoge は I: Iterator<Item=i64> なる任意の I で単一化できるような定義が求められます

https://doc.rust-lang.org/reference/types/impl-trait.html

なので引数で&mut引き回してdynも使いたくないということであれば↓になりますかね

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=32403112ac74f1a10cadf1236590744c

**デフォルトの名無しさん** · 2023/09/22(金) 19:29:43.87

>>372
コンパイル通りました!ありがとうございます!
ただもう少しわがままを言うと、実際の実装ではメソッドチェーンの箇所がこれの2倍ぐらいの長さなので具体的なイテレータの型を書かずにコンパイラ任せにしたかったんですが、話を見る限りどうも無理そうですね...

**デフォルトの名無しさん** · 2023/09/23(土) 08:15:26.34

>>373
>>372も書いてるけどimpl IteratorをBox<dyn Iterator>にする手もあるよ

**デフォルトの名無しさん** · 2023/09/23(土) 09:19:17.35

可能なら dyn は避けるに越したことは無い。
dyn はトレイトオブジェクトを扱うための仕組みであって
推論を補助する仕組みではないから。

**デフォルトの名無しさん** · 2023/09/23(土) 09:55:40.35

>>375
実装の隠蔽目的でdyn使うのはそんなに変な使い方ではないと思うが

**デフォルトの名無しさん** · 2023/09/23(土) 09:59:36.45

Box<dyn Trait>で解決しました本当にありがとうございました

**デフォルトの名無しさん** · 2023/09/23(土) 16:36:06.31

>>364です
補足すると今回自分がわかっていなかったのは以下のような関数がコンパイルを通らないということですね
```
fn hoge<T>(a: i64, b: &mut T) {
*b = a;
}
```
impl Traitが単にジェネリクスの糖衣構文であるということと、
トレイト境界を満たす型をジェネリクス引数に渡した場合は合法に"ならなければならない"、トレイト境界は十分条件も満たさなくてはならないという点を解っていなかったのがポイントでした...

**デフォルトの名無しさん** · 2023/09/23(土) 21:17:07.32

戻り値のimpl Traitと引数のimpl Traitで振る舞い違うのは当たり前ではあるんだけど混乱しやすいポイントではあるかもね

**デフォルトの名無しさん** · 2023/09/24(日) 12:22:42.57

0788デフォルトの名無しさん
2022/06/21(火) 08:59:28.38ID:vO+TReRM
俺はフロントエンドやらないからこのスレでTauriの話をしないでくれ

**デフォルトの名無しさん** · 2023/09/24(日) 12:36:49.28

こいつはどうかな
https://zenn.dev/ksilverwall/articles/2869b4c73e6327

**デフォルトの名無しさん** · 2023/09/25(月) 23:08:53.71

rustでdx12ってまともに使えますか？
そろそろc++は卒業したい

**デフォルトの名無しさん** · 2023/09/26(火) 10:01:41.63

>>382
使えないということだな。

**デフォルトの名無しさん** · 2023/09/26(火) 17:46:11.75

一応d3d12があるけど、これを直接使うよりwgpu経由のほうがいいんじゃないか？

**デフォルトの名無しさん** · 2023/09/26(火) 18:52:01.41

rustとgoとc#でjsonのシリアライズ、デシリアライズ実験したんだけど
rust 1ms cargo run --release
go 10ms
c# 40ms dotnet build -c Release
こんなに違うもんなの?
リリースモードでビルドしたつもりだけど
WebAPIのバックエンドどれにするか悩んでたけどもうrust1択でいいやん

**デフォルトの名無しさん** · 2023/09/26(火) 21:18:52.63

最適化で計測対象の処理が丸ごと消えてないかな
どこかでデータのサイズとか集計とか出力してればいいけど

**デフォルトの名無しさん** · 2023/09/26(火) 21:22:16.85

さすがそこまで速くないよね
C#ももっと速いような気がする

**デフォルトの名無しさん** · 2023/09/26(火) 21:40:15.73

コードの問題かベンチマークの問題だね

**デフォルトの名無しさん** · 2023/09/26(火) 21:41:15.28

>>385
goこのライブラリ使うとどうなる？
https://github.com/goccy/go-json

**デフォルトの名無しさん** · 2023/09/26(火) 21:41:38.03

>>378
>fn hoge<T>(a: i64, b: &mut T)
fn hoge<T>(a: T, b: &mut T)にすればいいと思うけど
同じような解決策が>>364にあるということなの？

**デフォルトの名無しさん** · 2023/09/26(火) 21:56:19.26

>>385
それやってる
まず、デシリアライズ1000回して
シリアライズ1000回でシリアライズでバイト配列になるからそのサイズのトータル
を求めてる
さっきのは1回あたりの平均

>>389
それやったら7.5ms
experimentalなJSON v2は13ms

**デフォルトの名無しさん** · 2023/09/26(火) 21:59:59.97

つか、goってリリースビルドないやろ?
コンパイルも一瞬でへ?ってなるわ

それぞれ30行未満のコードだけど..

**デフォルトの名無しさん** · 2023/09/26(火) 22:29:35.41

https://controlc.com/77570dbc
goだとこんな感じ

**デフォルトの名無しさん** · 2023/09/26(火) 22:43:29.67

ああ、ごめんC#は嘘でしたすみません
3msになりました

**デフォルトの名無しさん** · 2023/09/26(火) 22:55:30.68

Rustは最強で
C#はメモリ使用量多いがMSが最適化ガンバッテル
Goはメモリ使用量少なくて言語仕様がシンプルだがC#に負けたり...

**デフォルトの名無しさん** · 2023/09/26(火) 23:05:14.16

意味のないベンチマークだね
ちなみにこういうのはNimが速いと思うよ

結局こういうのってコンパイラの最適化の勝負をしているだけだから

Rustが速いというよりはLLVMが速いだけ
Zigとかでも同じスピードが出るはず

その代わりにコンパイル速度が遅いというデメリットがあるからこれは単なるトレードオフで、用途に応じて適した言語を選択するのが重要ってだけだね

WebAPI作るならIOが結局ボトルネックになるからパフォーマンス気にするにしても別にスクリプト言語じゃないならなんでもいいのよね
好きな言語にすればいいと思う