[過去ﾛｸﾞ] Rust part30 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
785: 06/13(金)23:27 ID:UVwTiSSY(1) AAS
>>784
終わってない、とかほざいてた人はどうなん？
786(1): 06/13(金)23:44 ID:/3nWCuFC(1) AAS
>>784
2017年にFacebookを去った時点で手を引いて現Meta管轄なんだな
787: 06/14(土)00:01 ID:YcnPIob9(1/3) AAS
>>786
その記事の内容を読んでそういう感想なら死んでるのと変わらない
788: 06/14(土)13:57 ID:k1IJmlZ/(1) AAS
形式的には Meta が管理下に置いていたプロジェクトであるというのは間違いではないでしょ。
その上で Meta は全然やる気がなくなってるというだけで。 (少なくとも Jason の視点ではそう見えている。)
789(1): 06/14(土)14:50 ID:dtGV1Vl4(1) AAS
凄腕のエンジニア達が長い時間をかけて育ててきたjemallocといえども、
アリーナアロケーションのようなアプリケーション依存の原始的な手法には敵わないってのは虚しい話だな
特にRust信者はともすると小手先の技巧にかまけて視野が狭くなりがちだから気をつけなければならない
790: 06/14(土)15:08 ID:YcnPIob9(2/3) AAS
jemallocがMETAの管理下に入ってMETA寄りの機能を実装する開発方針に切り替わった
そして一般よりの機能を削減して一般からそっぽを向かれた
作者自身も一般からの需要にが付いていなかった
結局jemallocはMETA向けに局所最適化されてそこから一般向けに戻すにはかなりの人員と労力が必要だけど
それに見合うだけのメンテナーも資金もどこからも出てこない
実質死んでますよと
こういう内容
791: 06/14(土)15:13 ID:YcnPIob9(3/3) AAS
資金力があるところに吸収されて開発されてもそれが必ずしも良いことではないと言うことだ
吸収する側には目的があって吸収して機能を実装し終わったらそれでもう満足なんだ
792: 06/14(土)15:48 ID:RARc7ln1(1/2) AAS
万能なメモリアロケータは実現不可能
どういう用途に効率を特化するかで無数に分かれる
793: 06/14(土)15:53 ID:RARc7ln1(2/2) AAS
>>789
最適なタイミングでまとめて確保と解放するアリーナ方式が最も性能出るのは自明
794: 06/14(土)19:21 ID:TLqczxub(1) AAS
mRNAワクチンの“新たな懸念”接種済み妊婦の子どもに「異常タンパク質構造」血中で確認★2 [Gecko★]
2025/06/14(土) 15:48:24.59
2chｽﾚ:newsplus
・ワクチン問題になっている
795: 06/14(土)20:11 ID:dS5ekNAa(1) AAS
jemallocがRustから外されて各OSの標準アロケーターに戻った理由も重要だよね
796: 06/14(土)22:46 ID:3wtf6RT3(1) AAS
性能は用途により一長一短
特定のアロケータが標準だとバイナリサイズで不利なため
797: 06/15(日)00:30 ID:bKWQLrbi(1) AAS
#[global_allocator]標準化が1.28でjemalloc非標準化が1.32だな
外した理由はブログで書いてる
外部ﾘﾝｸ:blog.rust-lang.org
外部ﾘﾝｸ:blog.rust-lang.org
798: 06/15(日)00:56 ID:sxaow1g9(1/2) AAS
システム開発言語であるのにシステムのメモリアロケーターを使っていない
799: 06/15(日)00:59 ID:ujM9EzWd(1) AAS
Rustにおけるシステムプログラミングというのは「ケチ臭いプログラミング」と読み替えるとよい
必ずしも低レベルであることを意味しない
800: 06/15(日)09:10 ID:sxaow1g9(2/2) AAS
jemalloc使用するとメモリが300kb消費されると
rustプログラム一個につき300kb
801: 06/15(日)21:04 ID:nFrUb4vG(1/2) AAS
組み込み開発はRust一択
802: 06/15(日)21:27 ID:xQVjBVZp(1) AAS
WEB開発もERust一択
803: 06/15(日)21:37 ID:nFrUb4vG(2/2) AAS
今日もRustで組み込み開発しちゃった
804: 06/15(日)22:40 ID:B7Y6UoIx(1) AAS
俺はC++で開発し続けているが。
805: 06/15(日)23:08 ID:vsQD4t+X(1) AAS
組込みデバイスのRustのサポート状況ってどうなん？
少し前にNVIDIAのJetsonを触ったことがあるんだけと、SDKやサンプルはC++が基本だったと思う
(例えばJetson multimedia APIというのがあって、デバイス付属のGPUで動画をエンコードする等ができるんだけど、これはC++のクラスを使うAPIだから他の言語からFFIしづらい)
こういうのがRustに対応するようになるまでは、この分野はまだしばらくC++中心になるんじゃないかと思う
ラズパイなんかはRustの話も聞くし、できることは増えてると思うけど
806: 06/16(月)02:15 ID:0s59hzvI(1) AAS
メジャーなCPUならそれなりに対応してると思う
外部ﾘﾝｸ[html]:doc.rust-lang.org
SDKは需要とベンダーのやる気次第
807: 06/16(月)05:39 ID:YU6mcAo1(1) AAS
ヌルポ😳😳
Google Cloud、世界中のリージョンが影響を受けた大規模障害、原因は管理システムがヌルポインタ参照でクラッシュしたこと
2025年6月16日
外部ﾘﾝｸ[html]:www.publickey1.jp
808(1): 06/16(月)06:07 ID:Y7h+7ucI(1/2) AAS
記事あんま理解できてないけどヌルポインタってそんなにまずいもんなの？
コンパイラーが検出してくれるし、スコープから外れた変数はドロップされるからそもそも参照されないかと思ってた
809(1): 06/16(月)06:43 ID:pyVTMG/F(1) AAS
ヌルポインタ参照って
プログラムをCとかunsafeとか使わずにRustで全て作ってるとしたら起き得ないことであってる？
810: 06/16(月)08:20 ID:GmbZlZxT(1/2) AAS
>>808-809
ヌルポインタの問題は型の非互換性、本質的には機能の非互換性の問題。
古いJavaで顕著だけど、ヌルポインタは何の機能もサポートしないのにコンパイル時はほとんどすべての型に化けることができるから、コンパイル時に問題を発見できずに実行時に問題になることがある。
本来なら互換性を保つためにヌルオブジェクトとかを使うべきだけど、言語で禁止しているわけではないので、低能力コーダーとか無能ライブラリアンとかはヌルポインタを返す関数とかを作って問題になる。
safe rust は基本的にヌルポインタを使えないので、このようなトラブルになることは少ないかと。
811: 06/16(月)11:48 ID:d1GW0AGS(1) AAS
問題の本質はヌルポじゃないだろ
publickeyの人はそれがわかってない
てかGoogleの品質管理体制も杜撰すぎるな
812: 06/16(月)12:21 ID:LhShA12G(1) AAS
ガッ！
813: 06/16(月)12:30 ID:Y7h+7ucI(2/2) AAS
空白のフィールド含んだだけでクラッシュとかよく分かんないよ
俺がテストせずにこのプログラムをリリースさせた責任者だったら会社に残れないな。明らかにテスト捏造してるから
——
新しいポリシーデータには意図せず空白のフィールドが含まれており、これをサービスコントロールが読み込んで実行したところ、ヌルポインタ参照となりクラッシュが発生します
——
814(1): 06/16(月)13:38 ID:Zx2RP+Vb(1) AAS
要は不具合を引き起こす特定のパターンがあり、テストで発見されなかったってことだろ
たまたま結果としてヌルポでクラッシュしただけで、仮にヌルポの可能性に気づけていたとしてもそれ自体がバグの原因でない以上、
問題のパターンが別の形で障害を起こしていた可能性を否定できないな
上下前次1-新書関写板覧索設栞歴
あと 188 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.018s