Rust part31 (615ﾚｽ)
上下前次1-新
1: 07/03(木)21:30 ID:ORBrZxS2(1) AAS
公式
外部ﾘﾝｸ:www.rust-lang.org
外部ﾘﾝｸ:blog.rust-lang.org
外部ﾘﾝｸ:github.com
公式ドキュメント
外部ﾘﾝｸ:www.rust-lang.org
Web上の実行環境
外部ﾘﾝｸ:play.rust-lang.org
※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
外部ﾘﾝｸ:doc.rust-lang.org
省11
489: 07/25(金)12:12 ID:SwDtBX88(3/3) AAS
>>488
原因がわかりました
どうやらbindgenをする際、ヘッダー側で専用ライブラリを読み込むことはできないらしいです。
Qt系の処理をcppファイルに移して、hppにはラッピングされたものだけ書いてみたら、無事にコンパイルできました
(´・ω・)
490(1): 07/25(金)12:26 ID:cBulrbkl(2/2) AAS
あー「include ~が見つからない」の~はチルダじゃなくて書くのを省略したってことね
491: 07/25(金)21:08 ID:I5tDQGVV(1) AAS
>>490
そういうことです(´・ω・)
それで、またいくつかコードをいじってみたんですが、
gtk was not actually initializedってエラーが出るようになったんです。
助けてください(´・ω・)
外部ﾘﾝｸ[rs]:raw.githubusercontent.com
492: 07/26(土)18:00 ID:e8Yyj5Zq(1) AAS
lualatexをrustで作り直して欲しい
493: 07/26(土)20:56 ID:Urx/nuHD(1) AAS
そうか。
494: 07/26(土)22:27 ID:gFhGkZ1/(1) AAS
動的言語では名前空間もオブジェクトである
という思想により名前空間の仕様が安定していった
静的なrustやhaskellには関係ないが、lispには致命的な影響があったかも
495: 07/27(日)06:22 ID:VOHQ0aL2(1) AAS
それはまあ「1人前に速くなったLISPでさあ何を書こうか」ということでは？
たぶんC++やRustのコンパイラをLISPで書く時代の波が来てる
496: 07/27(日)07:27 ID:XSMxDaZG(1/12) AAS
Common Lisp やその系統の Lisp ではグローバル変数の定義はパッケージへの登録 (intern) であるという立場を取っているけど、 Lisp が全部そうってわけじゃないよ。
たとえば Scheme は Rust と近い構成になってる。
Lisp の伝統である対話的な開発環境・開発スタイルとどう折り合いをつけるかでまだ完全には決着がついてないんだけど。
497: 07/27(日)11:16 ID:nZXsiMQ0(1) AAS
グローバル変数という考え方が昔のものだからね
今はどの名前空間にあってどのように隠蔽されているかが重要
どこからも見えて自由にアクセスできるグローバル変数はバグや可読性悪化の温床でしかない
498(2): 07/27(日)12:01 ID:fVl0GDML(1) AAS
今lispてemacsの設定くらいでしか使われてないやろ
499: 07/27(日)12:06 ID:XSMxDaZG(2/12) AAS
昔の Lisp は対話的に開発 (コンパイル) してメモリ全体のダンプイメージを保存する形でセーブする運用が普通だったので隠蔽を徹底すると二度と修正できない (または全体をやり直し) ということになって効率が悪かったんだよ。
あまり分割しないかわりに妙に長い名前を使う習慣があって、これは Emacs Lisp になごりがある。
開発体制やツール全体との整合性の問題もあるので単純には言えない。
500: 07/27(日)12:12 ID:XSMxDaZG(3/12) AAS
>>498
ロボット制御、数理最適化などの分野ではそれなりに使われてるよ。
保険屋の商品開発システムの開発の求人がこないだ出てたよ。
1990年頃までは主流の一角だったのでその時代に比べれば大幅に衰退したのは間違いないけど。
501: 07/27(日)12:16 ID:LBT37M4+(1/13) AAS
バカなおいらに結局、拡張言語はダイナミックスコープの方が使いやすいのかどうか教えておくれ
502: 07/27(日)12:26 ID:NqsNrN1W(1) AAS
Rustのように可能な限り静的に確定させる言語ではグローバル変数は不要なため
変数は関数実行中のみ存在して毎回新しく用意される変数と
プログラム実行中ずっと存在するstatic変数の二種類のみとなりました
503: 07/27(日)12:31 ID:XSMxDaZG(4/12) AAS
ダイナミックスコープは論外。
すでにほとんど駆逐されている実態からもあきらかだろ。
最後の生き残りである Emacs Lisp ですらレキシカルスコープに切り替えるオプションが用意されて十年以上になる。
504: 07/27(日)12:37 ID:XSMxDaZG(5/12) AAS
そういえば AutoLISP もダイナミックスコープだな。
互換性の都合で昔のままになってるだけで、拡張言語としてそれが特に有用というわけではない。
505(2): 07/27(日)12:51 ID:LBT37M4+(2/13) AAS
Emacs Lispは使いやすい
Script-Fuは使いにくい
理由は山ほどあって、例えばEmacsはテキストエディタだからグラフィックソフトのGIMPよりスクリプトを書きやすいのは当たり前だ
他にもEmacsはrmsが丁寧に創り上げた統合開発環境であるのに対しGIMPはletやlambdaのヘルプすら出ないといった理由はいくらでも挙げられる
しかし Emacs Lispの本当の使いやすさはそれがダイナミックスコープの言語であることに起因するんじゃないだろうか
506(1): 07/27(日)13:01 ID:XSMxDaZG(6/12) AAS
>>505
script-fu をコンソールから直接入力してるの……？
Emacs に接続するのが普通の開発スタイルだよ。
Lisp 系言語は大抵の場合に Emacs と連携する仕組みがある。
507(1): 07/27(日)13:14 ID:LBT37M4+(3/13) AAS
>>506
あー、そんなことできるのか
俺は動画用の連番gifを生成したくてMakefile書いてたよ
とここまで書いて気づいたけどEmacsに接続ってなんだ？
Emacsのバッファ内でコンソールが動くことをそういうの？
508: 07/27(日)13:50 ID:LBT37M4+(4/13) AAS
技術者の横で目を凝らす開発営業さんにはそう見えるのね
509: 07/27(日)14:06 ID:V2C/94hf(1) AAS
>>498
mathematicaとかあれ実質lispっぽくねえか
510(1): 07/27(日)14:20 ID:XSMxDaZG(7/12) AAS
>>507
実行中の GIMP のメニューから
フィルター → Development → Script-Fu → サーバースタート
とすると他のプロセスが GIMP と通信して対話的に Scheme のコードをやり取りできるようになるだろ。
そうやって実行中の GIMP と Emacs が通信でやりとりするってことを言ってる。
こうなっているのは GIMP の側で Script-Fu の開発環境を抱え込む気はないという思想の表れだと思うんで、
開発環境の不足を挙げるのは筋違いかなということを言いたかった。
511(1): 07/27(日)14:44 ID:LBT37M4+(5/13) AAS
>>510
じゃあそうでない（GIMPのようでない）シェルとかコンパイルプロセスはどうやってEmacsと通信してるの？
512: 07/27(日)14:58 ID:LBT37M4+(6/13) AAS
割と重要だよね
Emacsは皆が機嫌を伺わなければならないオツボネなのか
それともEmacs自身が甲斐甲斐しく皆の面倒を見るメイドなのか
513: 07/27(日)14:58 ID:XSMxDaZG(8/12) AAS
>>511
プロセス間通信の内で最も簡単なのはパイプ。
特別扱いがある部分もあるので単純ではないんだけど標準入出力もパイプの一種で、
コマンドラインツールは標準入出力の接続先をターミナルから Emacs にするだけで Emacs との接続は成立するよ。
514: 07/27(日)15:45 ID:LBT37M4+(7/13) AAS
厳しくツッコんでやろうと思ってたんだけど、そんなもんかなとも思う
・プロセス間通信とはリアルタイムリダイレクトである
・シェルが、あるプログラムの入出力をリダイレクトできるのだから、
俺のプログラムもあるプログラムの入出力をリダイレクトできる
515: 07/27(日)17:12 ID:Inu3UTcX(1) AAS
505 デフォルトの名無しさん sage 2025/05/16(金) 08:42:23.59 ID:QL8B1Lzv
今日公開のRust 1.87.0でio::pipeが追加された
今までなかったことが不思議
507 デフォルトの名無しさん sage 2025/05/16(金) 09:12:43.25 ID:r8NIoUWT
>>505
Stdio::piped()が10年前からある
無名パイプはOS依存かつプロセス間だから汎用化は安定化に時間がかかったのかな
516: 07/27(日)18:58 ID:LBT37M4+(8/13) AAS
Rustの3倍くらいわかりやすい（冗長に書いてくれてる）
外部ﾘﾝｸ[pdf]:www.gnu.org
517: 07/27(日)20:07 ID:LBT37M4+(9/13) AAS
前々から1度やってみたかった、こういう
読みこなす実力は十分あるのにたまたま読んでいないだけのレベルの人の大勢集まるスレで
Emacs Lispのマニュアルを貼る実験
518: 07/27(日)21:53 ID:XSMxDaZG(9/12) AAS
Emacs Lisp が Script-Fu より使いやすいという感覚は全然わからない。
常にブチ切れながら書いてる。
あえていうならライブラリが充実しているということくらいで、それすらも互換性を壊す変更を入れられない理由として足を引っ張っているとも言える。
特にダイナミックスコープは滅びるべき害悪という意識しかなくてそれが使いやすさに寄与しているという意見は初めて聞いた。
519: 07/27(日)22:00 ID:LBT37M4+(10/13) AAS
日本のLISP事情はなにかおかしい
世代的にEmacsそれ自体はある程度触ったことはあるんだろうにという層はなぜかelispのマニュアルに見向きもせず、
それよりもっと若い、言語なんて選べると思ってなさそうな子たちはなぜかEmacsを触ろうとしない
520: 07/27(日)22:17 ID:LBT37M4+(11/13) AAS
そうだなあ、例えばEmacsにはauto-wrapという関数がある。
これはカーソルが行末に近づいた時に自動的に改行して行末整形を行うためのものだ
この関数が「あれっ、さっきディセーブルしたろ？」ってくらい、断っても断っても呼ばれるもんだから
俺の設定ファイルではこの関数自体が空の関数で上書きされてある
この芸当はダイナミックスコープでないとできない
521: 07/27(日)22:43 ID:XSMxDaZG(10/12) AAS
上書きしたけりゃ代入で出来るのでダイナミックスコープである必然性はない。
ダイナミックスコープを誤解してない？
522: 07/27(日)22:45 ID:XSMxDaZG(11/12) AAS
アプリケーションの拡張という点で考えるとモダンなアプリケーションでは WASM でプラグインに出来る仕組みを用意しているものもある。
近頃はセキュリティを意識しなきゃならないので制約をコントロールしやすい WASM というのは良いアイデアだよね。
523: 07/27(日)22:57 ID:LBT37M4+(12/13) AAS
代入するためにはオブジェクトへのリンクをそのままでなく変数として持っとかないと「他の人は」変更できないでしょ
実際Script-Fuではオブジェクトにアクセスするのに「ああ、さらにそのcarをもう1度辿るのか」ってのばっかじゃん
524: 07/27(日)23:34 ID:XSMxDaZG(12/12) AAS
言いたいことが何も伝わらない。
ただ Rust スレの話題でないことははっきりしているのでとりあえず私はこのスレでこの話題を続けるのはやめる。
525: 07/27(日)23:41 ID:LBT37M4+(13/13) AAS
Rustだってレキシカルスコープの言語じゃないか
526: 07/28(月)00:22 ID:Tf0o2LzD(1/2) AAS
ここからが世界の舞台なのに馬鹿だよなー
Script-FuとRustはどちらもレキシカルスコープの言語だ
つまり似たようなメモリ配置のプロセス空間を持ち、
なんらかのスタックコンベンションで動く点では同じだ
Script-Fuが用意した小細工は(car(buf
Rustが用意した小細工はBox<T>
くらいのことは言ってみろ
527: 07/28(月)00:39 ID:54WCUCT3(1) AAS
すっこんでろ
528(1): 07/28(月)01:28 ID:8xcLMnqm(1) AAS
最近書き始めたけど日時取得するのにもややこしいコード書かなきゃいけなくてなんでこんなもんが持て囃されてるんだろうと思った
この言語作った人重度のアスペなんじゃないの
529: 07/28(月)02:21 ID:1axX/Ndk(1) AAS
日時取得とプログラミング言語仕様は一切関係がない
530: 07/28(月)02:28 ID:LtpwkZt9(1) AAS
できた
println!("現在の日時(ローカルタイム): {}", chrono::Local::now());
531: 07/28(月)02:31 ID:u3ejyRV1(1) AAS
chronoは使いづらいからおすすめしない
532: 07/28(月)06:13 ID:zOCRCDwg(1/2) AAS
tinyschemeが持て囃されemacsが敬遠される現象と同じ
533: 07/28(月)06:41 ID:Tf0o2LzD(2/2) AAS
>>528
逆に聞きたいんだけど
PCやスマホの中で指令を受けて日時を取得しに行くのは
「小人さん」ではなく「シリコンのチップとかそれなりのセンサ」なのに
なぜITだけこんなことを言われるんだろう
534: 07/28(月)07:35 ID:Qh5MRIIH(1/8) AAS
さてはemacsにビビってやがるな、開発営業
フツーに号令かけることもできるんだぜ
「この世のありとあらゆる文字コードを扱える言語がある。
Emacs Lispだ。
LISPついでに習熟しておいて損はない」
535: 07/28(月)08:27 ID:Qh5MRIIH(2/8) AAS
そのうえテキストエディタがついてくるんだから損はないよな
開発営業のおっさんは同じ条件（~/.emacsというテキストファイル）なのに
それを「非技術者」なもんだから「設定ファイル」としてしか活用できない「悲哀」に気づいてるんだよなw
プログラマ様方はまったく同じ道具立てなのにそれだけで「あの」プログラミングができておしまいになるんだもん
これはみんなに知られちゃまずいんだもんなw
536: 07/28(月)08:44 ID:Qh5MRIIH(3/8) AAS
みんなー、最初の課題はな
Emacsには
M-x what-line
と
M-x what-cursor-position
とがあるからその2つの情報をいっぺんに表示する
M-x what-line-and-cursor-position
というコマンドを書いてC-x =とかにバインドするんだ
537: 07/28(月)08:52 ID:zOCRCDwg(2/2) AAS
よほどのことがない限り二刀流を想定しない
これはITだけではない
特に、万物は一長一短であると信じている者にとっては
弱点を消すもう一つの武器を用意するなんて考えたくもないだろ
538: 07/28(月)09:40 ID:E3NP8lW2(1) AAS
躁うつ病（双極性障害）の周期は、躁状態とうつ状態が交互に現れるのが特徴です。
この周期は数カ月から数年と個人差があり、常に躁状態とうつ状態が表れているわけではなく、
間に症状がない「寛解期」を挟むこともあります
539: 07/28(月)14:08 ID:O7aojHnp(1/3) AAS
Rustで自分用にライブラリを作ろうとしていて、
そこでC++のライブラリを利用しようとしているんですけど、
上手い感じに統合するためには、どうやったらいいんですかね…?
特にメモリ管理とかです。unsafeを使わなくていいようにしたいです
540: 07/28(月)14:16 ID:Qh5MRIIH(4/8) AAS
俺様アロケータがあるなら型Tの変数をアロケートするときに
Oresama<T>
と書くだけで、使い勝手はBox<T>とかと同じにしてしまう
541: 07/28(月)14:34 ID:O7aojHnp(2/3) AAS
なんかsafetyでnewerなbindgenはないのか
542: 07/28(月)17:15 ID:kpR5qn81(1) AAS
Rust の外で定義されたものが safe かどうかは自動では判断しようがない。
プログラムを書かずに済ますにしてもなんらかのメタデータは与える必要があるだろうし、
バッチリと何から何まで自動化ってのは無理なんじゃねーのかな。
543: 07/28(月)17:29 ID:daSk2bcg(1) AAS
そんなもんAIで余裕でしょ
最もAIが得意とする類の課題
544: 07/28(月)18:03 ID:Qh5MRIIH(5/8) AAS
そして最大の罠
545: 07/28(月)18:11 ID:oTNRYreL(1) AAS
そこはAIが最も不得意とする分野
unsafeを用いて提供されるsafeな関数やモジュール関数群が安全か否かを100%判定できること
これができる時代になった時に全てのプログラマーを全廃できる
546: 07/28(月)18:16 ID:V7NHZwCK(1) AAS
AI使ってたらそんなこと言うはずもないんだよな
再現性ないんだぜ？
547: 07/28(月)18:41 ID:Qh5MRIIH(6/8) AAS
例えばRustはVecがあるからダブルリンクリストがいらなかったりするでしょ
「えっ、Rustでダブルリンクリスト？しかも自作？なにこの老害」
とかなって
「Rust歴何年よ？」「えっへん〇〇年」「馬鹿だったんだ、この人」
548: 07/28(月)18:51 ID:vSY6h8X4(1) AAS
その理解もどうなのw
549: 07/28(月)21:04 ID:O7aojHnp(3/3) AAS
抽象化レイヤーをRustで書く方法
550: 07/28(月)22:26 ID:Qh5MRIIH(7/8) AAS
Rust歴というよりもダブルリンクリスト歴なんだよな
Cで実際にダブルリンクリストを使って問題に対処した実務経験なしで彼らがRust製のダブルリンクリストを手放すわけがないし、
第一それだって彼らにとっては眺めて楽しむものなのだ
551: 07/28(月)22:28 ID:SLPj4B6Y(1) AAS
まずRustの基本常識を身に着け終えた後でFFIやunsafeに進みなさい
552: 07/28(月)23:23 ID:Qh5MRIIH(8/8) AAS
人類は数十年かかって
・シングルリンクリストはそもそもライブラリ化しません
・ダブルリンクリストは「単純継承」のみライブラリ化します
・さもなきゃコンスセル
という知恵を石から絞り出した
RustはそれをVecとVecDeqeueに発展させたが
問題はそれが進化の正しい舳先かどうか
553: 07/29(火)01:00 ID:A5j4bQYz(1/2) AAS
双方向のリンクリストにこだわるのは
強参照の循環が必ず生じると思ってるか、その一部を弱参照に変えるしかないと思ってるんだよね
生ポインタなら一部ではなく全部生ポインタで作るのに
554: 07/29(火)01:00 ID:+DAbbYTz(1) AAS
CPUキャッシュメモリ考慮が速さを支配する時代になって以降
リンクリストが有利な場面が大きく減ってベクタやベクタベースのデックなどが有利に変わったのは事実
それでも残るリンクリスト利用もCPUキャッシュメモリを配慮したアンロールリンクリストなど様々な応用変種が各用途ごとに使われることとなった
555(1): 07/29(火)15:51 ID:pHNfVPjg(1/2) AAS
データの特性にあわせて最適なもの選ぶだけだろ
有利不利とかなんでそういう思考になるか謎
556: 07/29(火)19:05 ID:EalfDF/V(1/5) AAS
AA省
557(1): 07/29(火)19:07 ID:yr1Z5meU(1) AAS
>>555
データ特性によるアルゴリズムの選択で参考にされるO(n)などはメモリアクセスでかかるコストをゼロもしくは均一とみなして来たが
CPUの高速化によりメモリキャッシュに載るかどうかで何百倍も速さが変わるようになってアルゴリズム選択の観点も大きく変わって来た話だろ
有利と思われていたものが不利へと変わった
558: 07/29(火)19:12 ID:q5zHFRxw(1) AAS
必ずまとまった連続領域にあることが保証されるベクタはキャッシュに乗ることが保証されて速いからね
559: 07/29(火)19:36 ID:zbBRX4z5(1) AAS
スタックvsヒープも
常にキャッシュに載るスタックを活用しまくるRustが登場
560(1): 07/29(火)20:11 ID:EalfDF/V(2/5) AAS
Rustは変数の寿命をソースコードの静的解析から解き明かすのみならず、実際のメモリ確保もスタックから行うのであると思ってる人まだいるの？
561(1): 07/29(火)20:15 ID:1nklfDHD(1/5) AAS
>>560
それで合ってる
RustではBoxかVecを指定しない限り
構造体などオブジェクトもスタック上に確保
562(1): 07/29(火)20:19 ID:RU6DXavP(1) AAS
駄目じゃん
563: 07/29(火)20:20 ID:1nklfDHD(2/5) AAS
>>562
何がダメなの？
スタック上に確保するから速くて有利
564(1): 07/29(火)20:20 ID:EalfDF/V(3/5) AAS
>>561
え？返り値として返される時はコピーされるんでしょ？
565: 07/29(火)20:24 ID:1nklfDHD(3/5) AAS
>>564
コピーされない
返り値最適化により初めから呼び出し元のスタックフレーム上に生成される
566: 07/29(火)20:29 ID:EalfDF/V(4/5) AAS
あのさ、
スタック上に確保すると
「解析がなくても」「解放は容易」でしょ？
それが
「解析はあるのだから」「どこでも同じ」にならない？
567: 07/29(火)20:36 ID:1nklfDHD(4/5) AAS
何を問題にしてる？
スタック上のため確保もアクセスも高速
その上でRustではアクセスと解放の安全も両立している
568(1): 07/29(火)20:47 ID:EalfDF/V(5/5) AAS
「スタック上に確保しなくても同じことはできる」
って言ってる
そのうえで
「スタック上にしか確保してないのか」
って言ってる
569: 07/29(火)20:52 ID:1nklfDHD(5/5) AAS
>>568
スタック上に確保するときのみ確保が高速
スタック上で確保した時はキャッシュにほぼ載るためアクセスも高速
ヒープ上ではどちらも遅くて不利
570: 07/29(火)21:02 ID:yJ/ZZe3K(1) AAS
ついに糖質と言い争えるレベルまで落ちたか
571(1): 07/29(火)22:39 ID:pHNfVPjg(2/2) AAS
>>557
操作ごとに計算量違うだろ？
CSの教養のないど素人じゃん
572: 07/29(火)22:48 ID:ysadVfOf(1) AAS
>>571
どの操作も計算量の算出時にメモリアクセスによる時間コストを考慮していなかったことが昔の敗因
573: 07/29(火)23:17 ID:VkX72Ez2(1) AAS
「計算量」を理解してないだけだな
574: 07/29(火)23:23 ID:A5j4bQYz(2/2) AAS
多少遅くてもいいからCPUと関係ない言語で書きたい
mallocが使えない状況でその言語を使えるならそのほうがCPUと無関係でいられる
575(1): 07/29(火)23:25 ID:gZolU48c(1/2) AAS
計算量は係数を考慮せず次数だけだからね
キャッシュヒットとミスのような係数が桁違いに変わってくる現実だと逆転が起きるのは当たり前
576: 07/29(火)23:29 ID:gZolU48c(2/2) AAS
机上の計算量だけ見ていてもダメで必要な箇所は比較計測になる
そこでのRustは選択肢を広げてくれた存在
577: 07/29(火)23:41 ID:4+dSqHol(1) AAS
大きな2次元配列で2次元のどちらを基準に全走査するかで桁違いに速度が変わるのもCPUメモリキャッシュのせいだよな
そのへん考慮できない人はプログラマに向いていない
578: 07/30(水)00:05 ID:2CCQm4VI(1) AAS
マイクロマネジメントをな、マイクロマネジメントをいつでもサボれるくらいになりなよ
579(1): 07/30(水)00:46 ID:zYz0+G1r(1/4) AAS
>>575
それは小さいデータのときだけ
計測してみろよ
特殊な前提なのに話を一般化すんなよ
580(1): 07/30(水)00:51 ID:6h+f7gEs(1) AAS
ほらやっぱり
複オジは「計算量」を理解していないだろ？
581(1): 07/30(水)01:15 ID:ZVYNNQCS(1) AAS
ベクタは確保メモリサイズを超えると別メモリへの移動ペナルティが発生するにも関わらず、
ベクタへのデータの追加操作はベクタのサイズに関わらずO(1)とされる。
これはデータを2^n個追加した時の累計メモリ移動は最悪時でも、
1+2+4+8+...+2^(n-1)＝2^n-1個のメモリ移動しか発生しないためである
582: 07/30(水)06:58 ID:dn+Bg3eY(1) AAS
・超指向性スピーカーを使用して統合失調症の周囲で殺人をしたと話していたのですがご存じの方知りませんか？
【兵庫県知事問題】「斎藤知事動画はバズる」と直感、編集して1500万再生 中傷動画も発信した男性（31）の後悔 [ぐれ★]
2025/07/29(火) 21:04:36.36
2chｽﾚ:newsplus
こちらの方は後悔しているけれど
統合失調症周囲の人間は逆の精神状態の下記の人物
「仕事はデキるのに…」異常で執拗なパワハラをする“ダーク・トライアド“と呼ばれる、職場のヤバい人たち [パンナ・コッタ★]
2025/07/30(水) 02:17:10.53
2chｽﾚ:newsplus
583: 07/30(水)10:38 ID:kDw0lUC7(1) AAS
Rustが糞遅いのはこういうのも関係してるんだろうな
584: 07/30(水)10:55 ID:HGz1hbaM(1) AAS
>>580
complexityを計算量と訳したバカのせいで新しいバカが量産されてる
585(1): 07/30(水)15:55 ID:gxsH3v1Z(1) AAS
>>579
データが大きくても係数の差が次数の差より影響することは普通にありえる
キャッシュミスしまくるがO(n)で済むアルゴリズムと
ほぼキャッシュヒットしまくるがO(n·log(n))かかるアルゴリズムがあるとしよう
両者のアルゴリズム自体の係数差は単純にnとn·log2(n)とする
例えばn＝2^30≒10億の場合はアルゴリズムの差でlog2(2^30)＝30倍の差が生じる
ところがキャッシュミスするとメモリアクセスの差で300倍遅いことが現代のCPUでありえる
そのためキャッシュミスしまくるO(n)よりもO(n·log(n))が速く実行されることが起きる
586: 07/30(水)16:10 ID:aMDk5tN6(1) AAS
だからさー計算量ってそういう比較をするためにあるんじゃないんだって
CS101の超基礎だからちゃんと勉強しなよ
587: 07/30(水)16:28 ID:zYz0+G1r(2/4) AAS
>>585
はいはい
計測してからほざけ
588: 07/30(水)17:11 ID:cfT0F8KB(1) AAS
実効速度の比較の場合
計算量はNが無限近くに大きい時のみ有効なんだよ
Nが無限近いと係数がいくら大きくても無視できる
ところが現実にはコンピューターで扱えるNは小さな有限値だから係数を考慮しないと実効速度は逆転しちゃう
589: 07/30(水)18:05 ID:Kp0t8wWh(1) AAS
O(1)とO(n)の話だったのにO(n)とO(n log(n))にすり替えて自己正当化しようとするところがいかにも複おじ仕草
590: 07/30(水)19:07 ID:hgMZBDIB(1) AAS
>>581
そのメモリ移動もまとめてキャッシュに乗るから速いね
591: 07/30(水)19:41 ID:ZSzdQGzh(1/5) AAS
DDRn-SDRAMからキャッシュへのfetch時間は、12(ns)位だから、メモリコントローラが賢ければ、
3GHzのCPUの場合、36クロック位で済むので、めちゃくちゃ遅いわけではない。
592: 07/30(水)19:44 ID:jptgQq59(1) AAS
で、結局Rustでは実際どういうときにリンクトリスト使うの？
593: 07/30(水)20:03 ID:ZSzdQGzh(2/5) AAS
Grokによれば、以下のように、DDR5 SDRAMからキャッシュに乗せるまでの時間は、8〜20(ns)程度らしい。
これは、3GHz の CPU だと 24〜60 (クロック) 程度に相当する時間。ものすごく遅いわけではない。
「
実測値として、Intelのx86 CPU（例：12th/13th/14th Gen Core）＋DDR5構成でのプリフェッチ完了時間は、以下のように報告されています（）：標準的なDDR5-4800構成：約15〜25 ns（L1/L2へのプリフェッチ）。
高性能DDR5-7200構成：約10〜20 ns。
最適化された環境（低CL、オーバークロック）：8〜15 ns。
」
594: 07/30(水)20:11 ID:ZSzdQGzh(3/5) AAS
大体で言えば、32バイト位の領域がキャッシュに乗っていない場合に、24〜75 (クロック) 程度の追加時間が必要になる。
しかし、そこから連続するメモリーにアクセスしている場合には、追加時間は 0 クロック。
通常、1つの構造体やクラスに対してまとまって処理するが、処理に本質的に必要な時間が 100 クロックだとすると、
そこに、24〜70 クロック程度が上乗せされることになる。だから、トータルだと、24%〜75% 程度、処理時間が
長くかかる、ということになる。
もしも、本質的な処理に必要な時間が 10 クロックのように非常に粒度が小さい処理の場合だと、
キャッシュに乗っていれば、10 クロックだけで済むところが、34〜85 クロックかかることになる。
その場合は、3.4倍から8.5倍の時間がかかる、ということになる。
だから、リンクリストの場合、1つのノードのバイト数が少なかったり、ループの中で1ノードあたりに処理
する内容が少ないならば、キャッシュに乗っている事が重要になる事が有る。
省2
595: 07/30(水)20:19 ID:ZSzdQGzh(4/5) AAS
具体例で言うと、大量の3Dの座標データなどに対して、CPUで単純に平行移動を書けるような場合は、SIMD命令を使わない場合、
1点当たりの処理は、ループ自体に必要な時間が5クロック、足し算に必要な時間が3次元の場合、3クロックで、
全体で、1点当たり8クロック、と見積もれる。ループを展開して、例えば、8点ずつ処理したりすれば、一点当たりに
必要なクロック数はもっと下げられる。SIMD命令を使えば、もっと下げられる。
このような場合は、LinkedList(list) よりも、ArrayList(vector)の方が適す。
しかし、1行に80文字くらい入っているようなテキストの1行を処理する場合、1行を処理するには数百クロックが必要になり、
行全体を収める構造としては、LinkedListでも、キャッシュミスによる速度低下の影響は軽微。
596: 07/30(水)20:27 ID:zYz0+G1r(3/4) AAS
すげーわw
初手から間違った方向の議論してるのに早く気付け
597(1): 07/30(水)20:46 ID:ZSzdQGzh(5/5) AAS
高速なプログラムを作った人が「キャッシュの事も考慮することで高速化しています」と言っていたとしても、
それは、キャッシュ以外の部分が既に早く作りこまれた後だからの話。大部分の遅さの原因はキャッシュの事を気にする
以前の問題で、大半はLinkedListを使うべき場所でArrayListを使っている事だったりする。
なぜなら、キャッシュミスは、24〜75クロック程度の時間増加にしかならないからだ。
598: 07/30(水)21:02 ID:S65PQfLi(1/2) AAS
机上の空論プログラマ
いるよね
599: 07/30(水)21:07 ID:W/B9cxh8(1/7) AAS
俺はプログラミングばかりしている人間だし、高速化技術には定評があるから、机上の空論家ではない。
実際に作ったものの速度を見ると、どうやってこんなに高速化したのか分からず目を白黒させた人がいる。
600(1): 07/30(水)21:08 ID:W/B9cxh8(2/7) AAS
ID:ZSzdQGzh
が俺だ。俺は、高速化技術の第一人者であり、先生と呼ばれる人間だ。
601(1): 07/30(水)21:12 ID:9ZmySMAs(1) AAS
草
リンクリストは要素毎にポインタを持つ必要があるから、仮にstrのリストとすると要素あたりのサイズはダブルリンクリストの場合は倍となり、
キャッシュミスを考慮しないとしても単純にスキャン量が倍になる
602(1): 07/30(水)21:14 ID:W/B9cxh8(3/7) AAS
はっきり言って、高速化に関しては、教科書を書いている人は間違っている事が多い。
こんなところに買いても嘘だと思われて終わりだろうが、１つの証拠は、俺の作ったアプリは異常に速度が速い。
これは嘘ではない。速度を得たければ、ArrayList(std::vector)だけでは駄目で、LinkedList(std::list)を効果的に使う必要がある。
603: 07/30(水)21:15 ID:W/B9cxh8(4/7) AAS
>>601
それでも速い。
604(1): 07/30(水)21:17 ID:R2zwxvxE(1) AAS
>>602
では試しにサンプルコードを提示してくれないか？
それを動かしてみて実際に速いと体験してみたい
605(1): 07/30(水)21:22 ID:S65PQfLi(2/2) AAS
GrokにDDRのレイテンシ聞いてる時点でど素人じゃん
値おかしいし
606(1): 07/30(水)21:36 ID:W/B9cxh8(5/7) AAS
>>605
俺はプログラミングばかりやっていたので、メモリーのクロック数の実際の値には詳しくない。
ハードに詳しいようなタイプのパソコン博士ではない。
607: 07/30(水)21:36 ID:W/B9cxh8(6/7) AAS
>>604
嫌だ。
608: 07/30(水)21:37 ID:W/B9cxh8(7/7) AAS
なぜいやかと言うと、俺の知見や技術を、
当たり前であったかのように論文や本などに記載
する人がいるからだ。
609: 07/30(水)22:01 ID:IkZxqK3l(1) AAS
>>600
数学100点先生は高速化技術の第一人者でもいらっしゃられたのですね
>>597
>大部分の遅さの原因はキャッシュの事を気にする以前の問題で、大半はLinkedListを使うべき場所でArrayListを使っている事だったりする。
本当にそんな事例があるのならば
ぜひ具体的なコードを挙げていただけませんか
610: 07/30(水)22:01 ID:GCxxEIm4(1) AAS
「いる」ではなく「いた」なら使ってもいい
611: 07/30(水)22:20 ID:zYz0+G1r(4/4) AAS
>>606
それでよく高速化の専門家自称できんのな
お前メモリーアクセスオーダーとかも理解できてないだろ
中の下を自覚したほうがいいぞ
612(1): 07/30(水)22:28 ID:bASHA+tv(1) AAS
100点先生は複雑な並列は専門外だったはず
メモリ同期の抽象化やそれを用いたロックフリーアルゴリズムなど知らないと思う
613: 07/30(水)22:52 ID:+nnd8qy9(1) AAS
>>612
> メモリ同期の抽象化
横だけど、抽象化だけじゃなくてテストは必須な
ユーザー環境でメモリオーバークロックやタイミングチューンでTSOが保たれてない場合をいくつも見たから
614: 07/30(水)23:25 ID:g7G1hz5M(1) AAS
プログラミングではTotal Store Orderが保たれないハードを相手にする必要はないけど
そのような破綻したハードが存在することを知っておかないと
正しく動かない環境があった時に原因が分からず悩みそうだ
615: 07/31(木)00:30 ID:QRajgvO2(1) AAS
知りたいと欲する者が実在すればいいけど
登場人物全員無欲だったりしたら欲しくもない物を押し売りするのは偽善だよ
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.030s