[過去ﾛｸﾞ] Rust part30 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
359(1): デフォルトの名無しさん [sage] 2025/06/02(月) 00:18:26.39 ID:Z4CT4v88(1) AAS
Windowsを使う人は滅多にいないだろうしな
普通はLinuxかMac
360: デフォルトの名無しさん [] 2025/06/02(月) 00:33:24.53 ID:FhxrXIqd(1) AAS
人間の頭から放電した場合は下記の経路になる
人間は電磁界【脳波８Hz〜４０Hz】【電線【６０Hz】の電圧と同じ】なので周囲に影響を与えれる範囲が狭い
人体への雷撃パターン ｜身を守る｜ 雷の知識
https://www.franklinjapan.jp/raiburari/knowledge/safety/61/
超低周波電磁界にばく露した人体に起きる電磁的現象
https://www.jeic-emf.jp/public/web_mag/explanation/1016/
1 人間の頭部から放電しないことはここで説明されている
2 お風呂場で湯船につかっているのでお湯の方に電流が流れる
3 頭からお湯をかぶっているやシャワーを浴びている場合はお湯にそって電流が流れる
4 雨降りの時は雨によって地面の方に電流が流れる
5 何か物に接している【手で手すりを触っているなど】場合はその者にそって電流が流れる
などこれらの条件がそろっているのに外部の人が対象者の思考や動作がわかるはおかしなことを話している
361: デフォルトの名無しさん [sage] 2025/06/02(月) 01:35:42.19 ID:d/cxZYnc(1) AAS
>>321
何を言ってるんだか。
362: デフォルトの名無しさん [sage] 2025/06/02(月) 02:03:54.92 ID:wOJOfP6S(1) AAS
Windowsのtauriは余計なことしないでwebview2に丸投げすればIMEは普通に動きそうな気がするんだけど
クロスプラットフォームの抽象化があるから単純ではないのかな
363: デフォルトの名無しさん [] 2025/06/02(月) 07:27:24.42 ID:GgLxuemZ(1/2) AAS
>>359
GUIアプリってプログラマでなく一般ユーザーに使ってもらうために作るものじゃないの？
シェア率が70%もあるWindowsを「滅多に使わない」？
364: デフォルトの名無しさん [sage] 2025/06/02(月) 08:02:49.76 ID:zmXNsHtd(1) AAS
どちらかというとIME切り替えながらウィンドウ動かす、というのがないかな…
数年間毎日使って気付かなかったし正直どうでもいい
直してくれるならそれに越したことはないけども
365: デフォルトの名無しさん [sage] 2025/06/02(月) 08:51:42.98 ID:h4tRZExf(1) AAS
いや、ウィンドウズはほぼ毎日使うよ
会社でも同じだわ
366: デフォルトの名無しさん [sage] 2025/06/02(月) 10:49:02.15 ID:XWrf3Dm6(1/4) AAS
IDEなら編集しながらコンパイルしてるから不愉快な挙動をするのは火を見るより明らか
367: デフォルトの名無しさん [] 2025/06/02(月) 11:11:49.92 ID:NteO/GBi(1) AAS
>>293
Rustに限らずZigとかC#とか、extern cできる言語ならなんでもAndroidで使えるよ
Androidのjniやndkに全部C互換があるから
368: デフォルトの名無しさん [sage] 2025/06/02(月) 11:15:54.47 ID:aX5lnsqr(1/2) AAS
出来るけど公式にサポートしているもののほうが楽ではある。
369(2): デフォルトの名無しさん [sage] 2025/06/02(月) 12:21:45.02 ID:yqv+vYMm(1) AAS
Amazon Aurora DSQLは当初はJavaVM上のKotlinで開発されたものの、バグの混入を避けるためなどの理由でメモリ安全なRust言語での開発に切り替えたところ、それだけで性能が約10倍向上したとも説明されています。
https://www.publickey1.jp/blog/25/awspostgresqldbamazon_aurora_dsql.html
370: デフォルトの名無しさん [sage] 2025/06/02(月) 12:27:33.61 ID:XWrf3Dm6(2/4) AAS
オールド公式とニュー公式どっちを選ぶかは結局自分で判断するしかない
371: デフォルトの名無しさん [sage] 2025/06/02(月) 13:03:04.42 ID:cfmG04/d(1) AAS
再現方法を見てウィンドウ動かさなければ問題ないだろうと考える人は経験が浅すぎるわな
そういう感覚で物作ってると行き着くところは「複オジ品質基準」だぞ
372: デフォルトの名無しさん [sage] 2025/06/02(月) 13:17:30.01 ID:aX5lnsqr(2/2) AAS
わかった上で重大ではない (から放置で良い) と判断することはあるだろうけど……
そういう小さなことが積み重なってよくわからん挙動を引き起こすこともそれなりにある話。
373(1): デフォルトの名無しさん [sage] 2025/06/02(月) 14:20:48.94 ID:w8zlJvU9(1) AAS
>>369
困るとそれを貼り付けるね
374: デフォルトの名無しさん [] 2025/06/02(月) 14:21:05.82 ID:czhP5p30(1/3) AAS
>>369
やはりサーバー分野はRustが最強だな
375: デフォルトの名無しさん [] 2025/06/02(月) 14:21:43.53 ID:czhP5p30(2/3) AAS
>>373
どゆこと？
376: デフォルトの名無しさん [] 2025/06/02(月) 14:31:27.48 ID:czhP5p30(3/3) AAS
373がなにを否定したいのかよく分からないがRustの並列処理は非常に効率がよい
Rustで再開発することによりこの恩恵を受けて大幅に性能が向上した
今回AWSが正式リリースしたAurora DSQLは並列処理に重きをおいたものだから特に高い効果を得られたのだろう
377: デフォルトの名無しさん [sage] 2025/06/02(月) 14:41:07.84 ID:XWrf3Dm6(3/4) AAS
カオスは初期値だけで引き起こせるんだよね
途中の小さな積み重ねは原因ではなく結果
378(2): デフォルトの名無しさん [] 2025/06/02(月) 14:49:11.87 ID:z+CFOxG+(1/4) AAS
KotlinというかJavaの並行処理はむっちゃ安全だけどその代わりにパフォーマンスが犠牲になってる。
C++のはパフォーマンスが良いけどみんなご存知のように安全性がゴミ。
Goのはパフォーマンスも安全性もいいからRustかGoのどちらを使うかでRustが選ばれたんでしょ知らんけど。
379(1): デフォルトの名無しさん [] 2025/06/02(月) 15:15:13.25 ID:z+CFOxG+(2/4) AAS
俺が考察せずともAWSの当事者の後日談的な記事あるじゃん。
KotlinのJVMのガベージコレクションのオーバーヘッドが敵だったみたいね。
もともとKotlinのスペシャリストであってRustは初心者だった開発チームが苦労の果てにコンパイル可能なコードを実行してみたらなんとKotlinで書いていたコードの10倍性能がよかった。
気分を良くした開発チームがどんどんKotlinのコードをRustに書き換えていったんだって。
Just make it scale: An Aurora DSQL story
https://www.allthingsdistributed.com/2025/05/just-make-it-scale-an-aurora-dsql-story.html
380: デフォルトの名無しさん [sage] 2025/06/02(月) 15:31:24.30 ID:AD6qUyw7(1) AAS
そんでこれはオープンソースなのか?
381: デフォルトの名無しさん [] 2025/06/02(月) 15:53:39.10 ID:z+CFOxG+(3/4) AAS
CLI部分はオープンソースだよ
382: デフォルトの名無しさん [sage] 2025/06/02(月) 15:55:37.90 ID:3XGAbOaK(1) AAS
本体をオープンソースにしろよw
383: デフォルトの名無しさん [sage] 2025/06/02(月) 15:58:30.64 ID:bKFtipAC(1/3) AAS
>>378
単に会社の方針としてJavaかKotlinかC/C++かRustで、Goは選択肢にないんだろう
379の元記事読んだけど技術選定の際に社内実績をかなり重視してそうだし、そもそも制約がなきゃKotlinなんか選ばないでしょ
384(1): デフォルトの名無しさん [sage] 2025/06/02(月) 15:59:31.58 ID:WAnrQ9FR(1) AAS
>>378
Goは同じくガベージコレクションのある言語だから厳しい
385: デフォルトの名無しさん [] 2025/06/02(月) 16:03:48.59 ID:z+CFOxG+(4/4) AAS
やはり敵はガベコレにあり。
386: デフォルトの名無しさん [sage] 2025/06/02(月) 16:06:35.67 ID:qTYmSia5(1) AAS
敵はオープンソース資産を食い逃げする企業だろ
387(1): デフォルトの名無しさん [sage] 2025/06/02(月) 16:28:08.28 ID:owUgTJXK(1/3) AAS
>>384
GoのGCはJVMと比較すると低遅延だから、記事の通りGCによる停止が問題になっている状況なら選択肢になりうる
388: デフォルトの名無しさん [sage] 2025/06/02(月) 16:40:40.26 ID:k0FlxjxP(1) AAS
>>387
GCによる害悪2つのうちレイテンシ悪化はGoで軽減できるが全体パフォーマンスはGoも悪化する
389(1): デフォルトの名無しさん [sage] 2025/06/02(月) 16:43:17.43 ID:/ossn2s1(1/2) AAS
悲報！Rust版AV1デコーダーがCより5%遅い問題が解決できず、カネで解決しようとする
https://www.memorysafety.org/blog/rav1d-perf-bounty/
Macではもっと遅かったしRustじゃなくてGoで良い領域だな
390(1): デフォルトの名無しさん [sage] 2025/06/02(月) 16:49:07.25 ID:/ossn2s1(2/2) AAS
>>236 >>243
Arc削除できないと返答してるな
391: デフォルトの名無しさん [] 2025/06/02(月) 16:52:44.19 ID:Ca4PuVUf(1) AAS
シャープ、PythonによるAIデバイス向け高位合成ツールをオープンソースで公開
https://news.mynavi.jp/techplus/article/20250602-3343055/
博報堂メディカル、生成AIを用いた審査業務効率化ソリューションを開発 [
https://news.mynavi.jp/techplus/article/20250602-3342950/
「AIをより魅力的にする戦略」がAIチャットボットに「薬物使用を促す」といった有害な考えを強化させる可能性があると研究で判明
https://gigazine.net/news/20250602-ai-chatbots-user-influence-attention/
392: デフォルトの名無しさん [sage] 2025/06/02(月) 16:54:15.56 ID:64YfA+90(1/4) AAS
Arcは所有者を増やすときのみカウンタ+1のオーバーヘッドがある
参照はderefによりコストゼロ
393: デフォルトの名無しさん [sage] 2025/06/02(月) 17:21:42.21 ID:fJbPstNP(1) AAS
>>390
なるほど
幸先良くスタートしたけど分かっていても直せない箇所が出て来る訳ね
394: デフォルトの名無しさん [sage] 2025/06/02(月) 17:27:52.34 ID:64YfA+90(2/4) AAS
所有者を増やしまくる愚を犯さない限りArcにデメリットはない
395(2): デフォルトの名無しさん [sage] 2025/06/02(月) 17:49:16.64 ID:iSmTN9kp(1/10) AAS
>>379
Aurora DSQLは、データベース管理ソフト(DBMS)であり、データを収めているのは原則としてHDDやSSD。
だから、メインメモリーは、キャッシュのために少し使う、というのが基本のはず。
だから、データ集約に関係する高度なアルゴリズムはHDD/SSDに対して必要となるが、
メインメモリに対しては余り必要ない。だから、Rustが適す。
396(2): デフォルトの名無しさん [sage] 2025/06/02(月) 17:52:38.64 ID:F42JmYRi(1) AAS
>>395
もうちょっと調べた方が良いよ、DB全般
397(1): デフォルトの名無しさん [sage] 2025/06/02(月) 17:59:35.62 ID:iSmTN9kp(2/10) AAS
>>396
ちゃんとした言葉で反論してください。
398(1): デフォルトの名無しさん [sage] 2025/06/02(月) 18:02:50.08 ID:owUgTJXK(2/3) AAS
>>397
Geminiに聞いてやったぞ
ご指摘のコメントは、データベースの仕組みとRustに関する理解に多くの誤解があるようです。
* DBのメインメモリ利用の認識違い: データベースはキャッシュだけでなく、データ処理やソート、インデックスなど、パフォーマンスのためにメインメモリを広範に活用します。「少し使う」というのは誤りです。
* Rust適用の理由が不適切: Rustはメモリを安全かつ効率的に制御できるため、DBのようなパフォーマンスが求められるシステム開発には適しますが、「メインメモリをあまり必要としないから」という理由は論理が破綻しています。
したがって、このコメントは技術的に見て多くの点で適切ではありません。
399(2): デフォルトの名無しさん [sage] 2025/06/02(月) 18:04:48.37 ID:iSmTN9kp(3/10) AAS
>>398
DBMSの場合、メインメモリーに置いておく集約構造は、データの量が小さい。
だから、ある程度の速度性能が出れば、全体の速度には影響が及びにくい。
400: デフォルトの名無しさん [sage] 2025/06/02(月) 18:05:34.76 ID:iSmTN9kp(4/10) AAS
そのGeminiの回答は、理解が浅い。
401(1): デフォルトの名無しさん [sage] 2025/06/02(月) 18:06:28.04 ID:owUgTJXK(3/3) AAS
>>399
お相手の方の返信も、やはりデータベースのメモリ利用とパフォーマンスに関する誤解が続いていますね。
主な問題点
* 集約構造のデータ量は「小さい」は誤り: データベースは、高速化のために可能な限り多くの集約データや中間結果をメモリに置こうとします。データ量が多いほど、メモリを効率的に使う必要があります。
* 「ある程度の速度」で全体の速度に影響が出にくいは誤り: メモリ上の処理が非効率だと、それが全体のパフォーマンスのボトルネックになり、特に大規模データや高負荷環境では深刻な影響が出ます。少しの遅延でも、積み重なると大きな差になります。
データベースの性能は、メモリの効率的な活用に大きく依存します。
書き込む前にAIにチェックしてもらうことをお勧めする
402: デフォルトの名無しさん [sage] 2025/06/02(月) 18:08:30.83 ID:iSmTN9kp(5/10) AAS
>>401
ただ、ネットで使うことが多い DBMSは、単位時間当たりの書き込み回数が小さい傾向がある。
そういう事まで含めて考えれば、あなたやGeminiの回答は理解が浅い。
403: デフォルトの名無しさん [sage] 2025/06/02(月) 18:11:00.40 ID:iSmTN9kp(6/10) AAS
論理ではなく、トータルの必要時間を数式で考えないといけない。
404(2): デフォルトの名無しさん [sage] 2025/06/02(月) 18:13:55.93 ID:64YfA+90(3/4) AAS
>>399
一番効果が大きいのはメモリ上のキャッシュ効果
そのキャッシュ構造管理もRustがベスト選択
405: デフォルトの名無しさん [sage] 2025/06/02(月) 18:16:26.41 ID:iSmTN9kp(7/10) AAS
>>404
DBMSに必要な処理の特徴が、Rustとは相性がいいとは言えるかもしれないが、
DBMS以外のアプリではもっと別の特徴が必要となることが有る。
406(2): デフォルトの名無しさん [sage] 2025/06/02(月) 18:25:01.24 ID:iSmTN9kp(8/10) AAS
>>404
「405」で「キャッシュ」という言葉を使ったが、CPUの中のキャッシュの事ではなく、
メインメモリー自体が HDD/SSDに対するキャッシュとみなせるという意味で使った。
混乱してはいけない。
407: デフォルトの名無しさん [sage] 2025/06/02(月) 18:32:11.04 ID:iSmTN9kp(9/10) AAS
>>406
誤: 405
正: 395
408(1): デフォルトの名無しさん [] 2025/06/02(月) 18:40:12.36 ID:KbudeIgC(1) AAS
次からスレタイ「複おじ Part31」に変えようぜ
409(1): デフォルトの名無しさん [sage] 2025/06/02(月) 18:42:37.74 ID:64YfA+90(4/4) AAS
>>406
DBはそのHDD/SDDに対するキャッシュ効果が最も効く
そのキャッシュ管理にもRustが最適
410: デフォルトの名無しさん [sage] 2025/06/02(月) 18:44:18.26 ID:iSmTN9kp(10/10) AAS
>>409
もちろん、KotlinやJavaよりは効くだろう。
411: デフォルトの名無しさん [sage] 2025/06/02(月) 18:50:00.32 ID:uLOpbVD1(1) AAS
>>408
別にそれでもいいよｗ
普通にRustスレ立ててもおかしな人間がやって来て自説を繰り返すだけだから
412: デフォルトの名無しさん [sage] 2025/06/02(月) 19:31:43.37 ID:a238vP89(1) AAS
それやっても自分でRustスレ立てて何事もなかったかのように振る舞うだけだと思う
413(1): デフォルトの名無しさん [sage] 2025/06/02(月) 20:32:38.85 ID:ddfioDeu(1) AAS
>>389
GCがあり不便なGoは適用範囲がほとんどないのよ
Goが使われている領域の狭さを見つめてね
414: デフォルトの名無しさん [sage] 2025/06/02(月) 20:44:46.47 ID:+aIkiiO4(1/4) AAS
将来的にオリジナルのdav1dと乖離させない様に出来るだけ1to1で移行するには良いのでは
TypeScriptコンパイラと同じ状況かと
415: デフォルトの名無しさん [sage] 2025/06/02(月) 20:51:40.32 ID:+aIkiiO4(2/4) AAS
書いてあるね
https://github.com/memorysafety/rav1d/issues/1419#issuecomment-2925693567
> And we'd like to keep the Rust code similar to the C code if there's no significant advantage to changing it, as this helps backporting changes from dav1d
416: デフォルトの名無しさん [sage] 2025/06/02(月) 20:54:08.00 ID:+aIkiiO4(3/4) AAS
Macの現状は7%差か
もう「significant」じゃない気がする
> Apple M3で8.8%遅かったのが7%になったとな
> 「5%遅い」はAMD Ryzenでの数字
417(1): デフォルトの名無しさん [sage] 2025/06/02(月) 20:56:39.33 ID:OnNK0eHp(1/4) AAS
小さいメモリを確保したり解放したりを頻繁にやるわけではないユースケースでは GC はそんなに速度に影響しない。
するとしても回避策はある。
そんなことより Go の問題点はメモリ管理を自動化しておきながらメモリアクセス違反をあまり防げないことだな。
C/C++ から移行する分にはそんなもんだろと思えるが、メモリ安全性を期待したら失望すると思う。
418: デフォルトの名無しさん [sage] 2025/06/02(月) 21:00:04.05 ID:+aIkiiO4(4/4) AAS
どの道テストはみっちり必要ですよ
コンパイル時のあの標語は罠かと
419: デフォルトの名無しさん [sage] 2025/06/02(月) 21:06:48.63 ID:3VeAkVql(1) AAS
Goは各種安全性対策が中途半端でプログラマの自己責任だからな
Goに未来はない
420(1): デフォルトの名無しさん [sage] 2025/06/02(月) 21:18:44.47 ID:3Ri7GR+v(1) AAS
>>396
禿同だな
>>395というか複おじはド素人なのになんで無理に変なコメントしようとするんだ？
421(1): デフォルトの名無しさん [sage] 2025/06/02(月) 21:28:48.01 ID:uzsj2Y7F(1) AAS
>>417
>小さいメモリを確保したり解放したりを頻繁にやるわけではないユースケースでは GC はそんなに速度に影響しない。
真逆だろ
422: デフォルトの名無しさん [sage] 2025/06/02(月) 21:28:51.61 ID:XWrf3Dm6(4/4) AAS
キリトリ記事禁止の呪いか
思いつたことはすべて公表しなければならないという
423(2): デフォルトの名無しさん [sage] 2025/06/02(月) 21:40:20.45 ID:OnNK0eHp(2/4) AAS
>>421
確保しようとするメモリが大きくても小さくても一回あたりの確保・解放に必要な実行コストはあまり差がない。
大きさではなく回数が効いてくるので頻繁な確保・解放がないなら GC のコストは小さいよ。
画像処理関係は大きなデータは扱うがメモリを確保・解放する回数が大きいわけではない。
424: デフォルトの名無しさん [sage] 2025/06/02(月) 21:43:30.36 ID:nIRomA7P(1) AAS
>>423
C/C++/Rustが絶対に勝つ利用法だ
425(1): デフォルトの名無しさん [] 2025/06/02(月) 21:48:51.08 ID:GgLxuemZ(2/2) AAS
>>413
Dockerとか使ったことないの？
426(1): デフォルトの名無しさん [sage] 2025/06/02(月) 21:56:07.57 ID:OnNK0eHp(3/4) AAS
Go の GC もヒープメモリの確保と解放のコスト自体は C と同程度じゃないかな。
生存しているか (参照が残っているか) どうかの判定にコストがかかっているので依存関係の複雑なデータ構造だと速度的には不利になる。
どうせそのあたりを意識しながら設計するなら Go より Rust のほうがいいかなぁとは思う。
427: デフォルトの名無しさん [sage] 2025/06/02(月) 22:01:25.40 ID:OnNK0eHp(4/4) AAS
逆にもう手に負えないほど複雑なデータ構造になってしまったときは GC の実行コストを受け入れてでも任せてしまいたいということはあるかもね。
428(1): デフォルトの名無しさん [sage] 2025/06/02(月) 22:01:47.11 ID:bKFtipAC(2/3) AAS
>>426
GC自体は軽い処理で、それ自体のコストが問題になることは少ない
問題は、現在主流のGCの実装では、予測困難なタイミングでGCによる比較的長時間のアプリケーションの停止が生じること
そもそも明示的なdeleteやRAIIや参照カウントのような方法も決してゼロコストではないわけで、そのコストを払うタイミングが違うんだよ
429(1): デフォルトの名無しさん [sage] 2025/06/02(月) 22:03:46.27 ID:J5nAKj7S(1) AAS
>>425
Docker創始者が明言「WASM+WASIがあればDockerは不要」
https://twitter.com/solomonstre/status/1111004913222324225
https://twitter.com/thejimwatkins
430: デフォルトの名無しさん [sage] 2025/06/02(月) 22:26:19.81 ID:GjabKUPP(1) AAS
なお>>429 tweetから丸6年後の今
431(1): デフォルトの名無しさん [sage] 2025/06/02(月) 22:28:58.46 ID:UNbfduAo(1) AAS
>>428
1行目から2行目で世界線が違うのか？
432(2): デフォルトの名無しさん [sage] 2025/06/02(月) 22:33:31.23 ID:bKFtipAC(3/3) AAS
>>431
あなた以外には理解いただけているものと思うが、念のため補足すると、
GCの問題は処理コストの大きさではなく、そのコストを払うタイミングにある
433: デフォルトの名無しさん [sage] 2025/06/02(月) 22:44:13.11 ID:ur17A/w2(1/3) AAS
>>432
要するにこれが良いと言う事か
> もうすぐGCが進化するからフリーランチ出来るね
> https://qiita.com/hez2010/items/e0a3573ecb3b14325336
> https://github.com/dotnet/runtime/discussions/115627
新計測データが来てる
434(1): デフォルトの名無しさん [sage] 2025/06/02(月) 22:45:31.08 ID:MPKk5iPb(1/3) AAS
>>432
GCはどの方式でも処理コストが高い
これがGC依存言語が遅い原因
435: デフォルトの名無しさん [sage] 2025/06/02(月) 22:48:22.30 ID:MPKk5iPb(2/3) AAS
GCするなら一斉停止が最も低コスト
並行しながらGCは時間の分散ができる代わりにコストの増大を招く
436: デフォルトの名無しさん [sage] 2025/06/02(月) 22:59:32.23 ID:ur17A/w2(2/3) AAS
Satori GC (No Gen0)は良さそうだから、さっさとGodotで試したデータを上げたら良いのに
437: デフォルトの名無しさん [sage] 2025/06/02(月) 23:06:29.24 ID:ur17A/w2(3/3) AAS
godot使いが言っている最大レイテンシーが~5ms程度が実際に達成されるのか見て見たい
438: デフォルトの名無しさん [sage] 2025/06/02(月) 23:16:57.64 ID:9HexqnhX(1) AAS
現実を無視して自己満足
439(2): デフォルトの名無しさん [sage] 2025/06/02(月) 23:35:07.57 ID:e80Lnwqt(1/3) AAS
5msが本当ならゲームチェンジャー
>>434
GC言語が楽なのは分かるから
逆にGC憎くしだな
440(1): デフォルトの名無しさん [sage] 2025/06/02(月) 23:41:42.00 ID:MPKk5iPb(3/3) AAS
>>439
GCを用いる以上はGCのコストを無くす方法はない
必ずペナルティが生じる
441: デフォルトの名無しさん [sage] 2025/06/02(月) 23:43:45.20 ID:e80Lnwqt(2/3) AAS
>>440
そこはクライアント側CPUはあまっているから大丈夫
ゲームだとGPU律速
DB/IOがあればそれで律速
442: デフォルトの名無しさん [sage] 2025/06/02(月) 23:50:27.08 ID:e80Lnwqt(3/3) AAS
というかJVMが取り入れたら世界線レベル
DSQLで1秒想定だったのが200分の1
443: デフォルトの名無しさん [sage] 2025/06/02(月) 23:52:03.77 ID:w80jJ2EG(1) AAS
GCはメモリ消費量の問題もあるため論外
何をするにも不利
444(1): デフォルトの名無しさん [sage] 2025/06/02(月) 23:57:57.40 ID:ab+RrVue(1) AAS
>>439
無学だな
GCコストを下げる魔法は存在しない
445: デフォルトの名無しさん [sage] 2025/06/03(火) 00:01:16.56 ID:7WxgzsHE(1/2) AAS
>>420
Geminiの方が優秀だね
446: デフォルトの名無しさん [sage] 2025/06/03(火) 00:06:53.82 ID:7WxgzsHE(2/2) AAS
見せて欲しい>>444氏の学とやらを
447(1): デフォルトの名無しさん [] 2025/06/03(火) 01:21:41.32 ID:WkxEnd7y(1/2) AAS
node.jsでサーバー構築してるけどRustにしたほうがええんかなあ
448: デフォルトの名無しさん [sage] 2025/06/03(火) 09:39:37.51 ID:xhVN3bhy(1/2) AAS
Rustの利点が活きるAPIサーバなら普通にいいんじゃないか
フロントもある普通のWebアプリケーションだったら辞めたほうがいいと思うが
449(1): デフォルトの名無しさん [sage] 2025/06/03(火) 10:20:07.21 ID:cgHky4oh(1) AAS
もし移行コストに見合った効果が出るのであれば相当にトラフィックの多いサーバーだろうから、
なんとなくの雰囲気や好みじゃなくて論理的に判断すべきだろう
たぶんそうではないんだろうけど、その場合モチベーションは無益な徒労を続ける上で無視できない重要な要素だから、Rustを採用することでモチベーションが上がるならやればいいんじゃないか
450(1): デフォルトの名無しさん [sage] 2025/06/03(火) 10:46:12.79 ID:97yIcMrS(1) AAS
>>423
arena使わないとRustがGC言語に速度で負けるのはどういう場合かな？
大昔ならいざ知らず現代のGCが問題になるのはそんな単純なケースじゃないよ
451: デフォルトの名無しさん [sage] 2025/06/03(火) 11:29:40.94 ID:g1P4UzEL(1) AAS
>>450
arenaを使っていないRustプログラムがほとんど
もちろんGC言語より速い
452: デフォルトの名無しさん [sage] 2025/06/03(火) 12:38:00.30 ID:SsEYb5J+(1) AAS
GC言語は速さと省メモリで勝ち目は一切ないため他の理由がある時のみ用いる
453(1): デフォルトの名無しさん [sage] 2025/06/03(火) 12:47:09.85 ID:rqu5SnLS(1/2) AAS
>>449
構築コストはRustもNode.jsも覚えた人には同じ
省メモリと捌けるクライアント数はRustが圧倒的
454(1): デフォルトの名無しさん [sage] 2025/06/03(火) 13:01:58.34 ID:Kt5mEPBd(1) AAS
>>453
クライアント数が増えたらサーバーの数を増やせばいいだけだ
一般に、Node.jsのエンジニアよりもRustのエンジニアの単価の方が平均的には高いから、
Rust採用による人件費の増加とサーバーのコスト低減効果のどちらが優位か？という金の問題に帰着する
先のAurora DSQLの例では明らかに後者が優位だが、>>447含め大多数のプロダクトでは状況は異なる
いやそうではない、Rustエンジニアの単価は安い、例えば俺のように、と主張するのなら話は別だかな
455(1): デフォルトの名無しさん [sage] 2025/06/03(火) 13:04:22.23 ID:rqu5SnLS(2/2) AAS
>>454
Rustが使える人にとってそんなこと関係ない
Rustで書けばサーバ数も激減できる
456(1): デフォルトの名無しさん [sage] 2025/06/03(火) 13:09:50.21 ID:/7yVoUF5(1/3) AAS
>>455
Rustはコーダーに好き勝手させないためのマネジメント向け言語だよ。
unsafeの扱いは問題あるけど、そのうちコーティング規約でライブラリアン以外はunsafe使えなくするケースが増えるんじゃないんかね。
457(1): デフォルトの名無しさん [sage] 2025/06/03(火) 13:19:44.29 ID:VYRLmXgA(1/3) AAS
>>456
無知がデタラメ書くのは止めなさい
Webサーバー構築でunsafeなんて出て来ない
458(1): デフォルトの名無しさん [sage] 2025/06/03(火) 13:42:18.60 ID:/7yVoUF5(2/3) AAS
>>457
「コーダーがunsafeを使わない」と「コーダーはunsafeを使えない」は別物。
マネジメントサイドはコーダーを信用しないから、禁止できるなら禁止するだろ。
上下前次1-新書関写板覧索設栞歴
あと 544 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.030s