AtCoderでHaskell解がスタックオーバーフローを起こす問題の回避策 - www.kotha.netの裏
これを書いている時点でAtCoderのHaskell処理系はGHC 7.4であり、これはプログラムに対してデフォルトで8MBのスタック制限を課す。したがって、深さ数十万の再帰を普通に書くと容易にスタック溢れによるREを起こす。 このスタック制限値はコンパイル時または実行時にRTSの-Kオプションで変更できるが、AtCoderではGHCにも自分のプログラムにも好きなオプションを渡すことが基本的にはできない*1ので、他の方法を考える。 回避策 以下のコードをコピペした上で、mainの先頭でunlimitStackSizeを呼べば良い。 import Control.Monad import Data.Word import Foreign.Ptr import Foreign.Storable -- | Remove the stack size limit in the RTS (+RTS
GHC STM Notes
Note: this document now lives here Introduction This document give an overview of the runtime system (RTS) support for GHC's STM implementation. We will focus on the case where fine grain locking is used (STM_FG_LOCKS). Some details about the implementation can be found in the papers "Composable Memory Transactions" and "Transactional memory with data invariants". Additional details can be found i
Segmented Stackについて
Masanori Ogino @omasanori Rustがsegmented stackをやめた件 https://t.co/fSibG8zoqA を見逃していたので、別の議論でsegmented stackをやめてないと成り立たない話が展開されて混乱した 2013-11-15 19:28:47
scheduler · Wiki · Glasgow Haskell Compiler / GHC · GitLab
The Glorious Glasgow Haskell Compiler.
rts · Wiki · Glasgow Haskell Compiler / GHC · GitLab
The Glorious Glasgow Haskell Compiler.
Haskell(GHC)での軽量ユーザスレッドの実装方法 - あどけない話
命令型言語の Java や Ruby がユーザスレッドからカーネルスレッドに移行したのとは対照的に、関数型言語の Erlang や Haskell では軽量なユーザスレッドを提供することに成功しています。僕は、この違いが何から生じているのか理解したいと思っています。この記事では、これまで調べたことをまとめます。 軽量なユーザスレッドは Erlang が有名ですが、Haskell (GHC)でも利用できることを重ねて強調しておきます。Haskell の方が Erlang よりも速いようです。追記：フェアな比較ではないようなので、話半分で参照して下さい。 Rubyの場合 Ruby 1.8 まで提供されていたユーザスレッドは、軽量とは言えませんでした。その理由は、ユーザスレッドをコンテキストスイッチさせる際にスタックをコピーしていたからです。Rubyソースコード完全解説の第19章 スレッドによれ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://blog.ezyang.com/2014/01/so-you-want-to-add-a-new-concurrency-primitive-to-ghc/
