- repeatedly
- 7132
- 3
- 18
- 0
Rustがsegmented stackをやめた件 https://t.co/fSibG8zoqA を見逃していたので、別の議論でsegmented stackをやめてないと成り立たない話が展開されて混乱した
2013-11-15 19:28:47@repeatedly SS自体は説明しなくてもいいですよね? ・RustのランタイムがSSを廃止した ・理由はスタックのスイッチコスト、及びそれを最適化することにかかる労力が割に合わないと判断したから ・スタックの割り当てとスイッチは予測不可能な性能低下を起こす
2013-11-15 19:36:13@omasanori SSってgoroutineとかでも使われてるあの仮想的なスタックなことだよね?そうだとすると,Rustの並行処理はこれに依存していたのでは?
2013-11-15 19:37:08@repeatedly ・SSしてるとFFIの難易度が増す ・LLVMの一部の命令はlibcにリンクするか組み込み命令になるかをLLVMが判断するので上述の理由によりFFIと同様の考慮が必要になる ・上2つの問題を回避するためにスタックの初期サイズを大きくしたらSSの意味がない
2013-11-15 19:39:46@repeatedly そうです。OSやMMUがうまくやってくれることに頼ることにしたようです。x86_64だとSSやってた頃と大差ないだろう、32ビットのアドレス空間だときついかもしれないけどそれは"calculated risk"だ、とのこと。
2013-11-15 19:43:51@omasanori OSやMMUがうまくやるってのがどこまで現実的かよくわかってないんですが,Rustで並行処理のユニットを一つspawnすると,それはネイティブスレッドが起動する?それとも今まで通りなんか間に一つ挟む?
2013-11-15 19:46:21予測不能な性能低下はGoではhot split problemと呼ばれているらしい。 https://t.co/HESNe52lun
2013-11-15 19:46:42Rustでポンポン並行処理の単位を生成出来るのはSegmented Stackのおかげだったはずだけど,それをやめるとなると,いわゆるネイティブスレッドでほげほげ,という感じになるんだろうか?Goでもパフォーマンス低下が知られてるようだけど,今は無視出来るほどなのかな…?
2013-11-15 19:47:38GHCの軽量スレッドは同じような問題抱えてないのかな?実装の問題だろうか? > "[rust-dev] Abandoning segmented stacks in Rust" https://t.co/T65emmLgri
2013-11-15 19:50:12@repeatedly タスクとスレッドの間にはスケジューラがあった(=分離されている)ような。前にあなたが紹介していたあのスレッドでそれもどうしようかという話が挙がっていますが。(M:Nスレッドモデルと1:1スレッドモデルの両方の需要に応えられるようにしたいとか何とか)
2013-11-15 19:52:09"Having memory is cheap, accessing it isn't." https://t.co/KLTPAJaqLP
2013-11-15 19:54:22@omasanori なるほどー.タスクの割り当て先としてのSegmented Stackが消えて,そこは適当に環境に任せる,という感じかー.複数のスレッドモデル対応はなんか面倒そうだ
2013-11-15 19:56:43HaskellのIOスケジューラを改善する"Mio: A High-Performance Multicore IO Manager for GHC"という論文がrust-devで話題になっていたので、多分GHCも何かやってはいるはず
2013-11-15 19:59:15#[fixed_stack_segment] というのが大量にRustのコードから消えてるけど,これがsegmented stackを示すattributeなのか?Task周りのコード読むか…
2013-11-15 20:06:20アレな会社で一般人なイケメンやってます. Software Alchemist. D(Phobos committer), Ruby(1.9), Python(Tornado), Opera, Android, Mac, Emacs, No! SQL, Sports, Red Bull, No つけ麺 No Life!