アカウント名:
パスワード:
2nより細かい単位、たとえば20.5nとかで区切ればいいのに。サイズとの対応が簡単に計算できればよくて、20.5nでもたかだか128エントリなんだから表にしちゃったっていいし、log2n求めてから選んでもいい。アロケータ内部の結構簡単な修正で他には修正いらないから局所性も高い。
...なのに...何考えてんだろ。
マイコミジャーナルの方にはちゃんと「基本的には2のべき乗」と書いてあるのを、私が「基本的には」をはしょったのですが、http://blog.mozilla.com/nnethercote/2011/08/05/clownshoes-available-in... [mozilla.com]を見ると、完全な2のべき乗ではないようです。(貼り付けようと思ったら、空白が多すぎるとかで投稿フィルタにひっかかる...)どっちにせよ、もっと細かい単位でとるようにすればいい話なのですが。
はしょった部分については、紛らわしいので、修正しておきます。
いやー、どっちにしても根本的な問題と解決法は同じで、ユーザ側でサイズを変えても統計に出ないだけで無駄なままだし、もっと細かくする以外の解はないし。ほぼO(1)で速くてフラグメント起きにくくてと、いいアルゴリズムなんだけどねー。
あと、ユーザプロセスであることを考えると実メモリの無駄はあんまり多くないはず。実メモリの無駄も多いんなら領域返却時に返せるページを返してない手抜きコードだわな。# これもアロケータの修正だけで直るけどな。
2のべき乗で確保するのはすでに行っていたけど、サイズを計算した後で文字列末尾のnullバイトの分を足したりヘッダサイズを足したりしてからjemallocに渡していたので、意図した割り当て量の2倍近く割り当てられてしまった上に半分近くはまったく何にも使えず完全な無駄になっていたという話。バグ以外の何者でもない。ご高説のとおりに2のべき乗で割り当てるのがそもそも妥当でないとしてもそれはまったくの別問題。> ユーザ側でサイズを変えても統計に出ないだけで無駄なままだし、アロケータの割り当て量そのものが半分になる。> 領域返却時に返せるページを返してない返却されないで無駄になってる。そもそもユーザ側は無駄な領域が存在することさえ認識していない。
ん？それって、確保サイズの半分扱いで返却する事があるって事か？
>nullを足したり
つまり「2^nプラスちょっと」になっていたため、jemallocで2^(n+1)確保されたということですか?
2nより細かい単位、たとえば20.5nとかで区切ればいいのに。
それはあまりよくありません。メモリ割り当ての処理で、欲しい大きさのブロックがなくて、その一つ上の大きさのブロックに解放済みのものがあったときは、一つ上のブロックを分割して使います。このとき、欲しい大きさのブロックを切り出した残りが中途半端な大きさだと、残りのブロックを登録するところがありません。20.5nだと、(20.5(n+1) - 20.5n) の大きさのブロックが残って、これを登録するところがなく、細切れにして登録するのは無駄ということです。2n
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
2^nで確保するとか本末転倒もいいとこだなw (スコア:1)
2nより細かい単位、たとえば20.5nとかで区切ればいいのに。サイズとの対応が簡単に計算できればよくて、20.5nでもたかだか128エントリなんだから表にしちゃったっていいし、log2n求めてから選んでもいい。アロケータ内部の結構簡単な修正で他には修正いらないから局所性も高い。
...なのに...何考えてんだろ。
Re:2^nで確保するとか本末転倒もいいとこだなw (スコア:1)
マイコミジャーナルの方にはちゃんと「基本的には2のべき乗」と書いてあるのを、私が「基本的には」をはしょったのですが、
http://blog.mozilla.com/nnethercote/2011/08/05/clownshoes-available-in... [mozilla.com]
を見ると、完全な2のべき乗ではないようです。(貼り付けようと思ったら、空白が多すぎるとかで投稿フィルタにひっかかる...)
どっちにせよ、もっと細かい単位でとるようにすればいい話なのですが。
はしょった部分については、紛らわしいので、修正しておきます。
1を聞いて0を知れ!
Re:2^nで確保するとか本末転倒もいいとこだなw (スコア:1)
いやー、どっちにしても根本的な問題と解決法は同じで、ユーザ側でサイズを変えても統計に出ないだけで無駄なままだし、もっと細かくする以外の解はないし。ほぼO(1)で速くてフラグメント起きにくくてと、いいアルゴリズムなんだけどねー。
あと、ユーザプロセスであることを考えると実メモリの無駄はあんまり多くないはず。
実メモリの無駄も多いんなら領域返却時に返せるページを返してない手抜きコードだわな。
# これもアロケータの修正だけで直るけどな。
Re:2^nで確保するとか本末転倒もいいとこだなw (スコア:4, 参考になる)
2のべき乗で確保するのはすでに行っていたけど、サイズを計算した後で文字列末尾のnullバイトの分を足したりヘッダサイズを足したりしてからjemallocに渡していたので、意図した割り当て量の2倍近く割り当てられてしまった上に半分近くはまったく何にも使えず完全な無駄になっていたという話。バグ以外の何者でもない。ご高説のとおりに2のべき乗で割り当てるのがそもそも妥当でないとしてもそれはまったくの別問題。
> ユーザ側でサイズを変えても統計に出ないだけで無駄なままだし、
アロケータの割り当て量そのものが半分になる。
> 領域返却時に返せるページを返してない
返却されないで無駄になってる。そもそもユーザ側は無駄な領域が存在することさえ認識していない。
Re:2^nで確保するとか本末転倒もいいとこだなw (スコア:1)
ん？それって、確保サイズの半分扱いで返却する事があるって事か？
Re:2^nで確保するとか本末転倒もいいとこだなw (スコア:2, 参考になる)
Re: (スコア:0)
#2001451 [srad.jp]には、
> > 領域返却時に返せるページを返してない
> 返却されないで無駄になってる。
と書いてあるけど、2^(n+1)で確保されてしまったメモリを返却しようとしたら
2^n+チョットしか開放できないなんておかしくないか？という指摘だよ。
malloc側では2^(n+1)で割り当てたのだから開放も2^(n+1)なんじゃないの？ということ。
Re: (スコア:0)
> 2^n+チョットしか開放できないなんておかしくないか？という指摘だよ。
jemallocでも2^(n+1)でmallocしたメモリをfreeしたら2^(n+1)返却されます。それはさすがに。
今回の問題は
・jemallocは内部でメモリ量をランドアップして確保している
・jemallocを使う側の中に、メモリ量をランドアップしてから＋チョットしてjemaloocにメモリ要求していたものがあった
というののあわせ技ということで。
ちなみにみんな２倍、２倍といってるけど、そういうわけで必要量の４倍近くとってたケースもあると思われ。
Angel's share (スコア:0)
問題解決するように読めますよね。
Re: (スコア:0)
>nullを足したり
つまり「2^nプラスちょっと」になっていたため、
jemallocで2^(n+1)確保されたということですか?
Re: (スコア:0)
それはあまりよくありません。メモリ割り当ての処理で、欲しい大きさのブロックがなくて、その一つ上の大きさのブロックに解放済みのものがあったときは、一つ上のブロックを分割して使います。このとき、欲しい大きさのブロックを切り出した残りが中途半端な大きさだと、残りのブロックを登録するところがありません。20.5nだと、(20.5(n+1) - 20.5n) の大きさのブロックが残って、これを登録するところがなく、細切れにして登録するのは無駄ということです。2n