アカウント名:
パスワード:
メモリーも大量に使えるようになってきたので・・・最小確保単位が128byteととかでなく1024byteとかでも問題なくなり始めている、そこでガベコレもmallocも、専用CPUを1つ搭載して、各種処理を裏側でやってしまうと良いのではと思っている。大半のオブジェクトやスタックフレームを格納できる程度のサイズ(1024byte程度)を、バックグラウンドで100個くらい確保してあらかじめ溜め込んでおく。そして、malloc要求が来たら、1024byte以下のサイズを要求された場合、あらかじめ確保しておいたメモリーの先頭番地を返すだけ、それ以上のサイズの要求が来たらソフトウェ
ハードウェアでメモリ確保というと68000系のLINK/UNLINK命令のこと、、、じゃなかったのか。# SP移動するだけだが。
> スタックフレームの確保もSPレジスタを使うのではなく malloc によって確保して統一的にしてしまえばと思い始めています。
コルーチンあるやつは、だいたいこうなってない?
スタックフレームをスタック上に確保すると、再帰をするコードで簡単にスタックがあふれます。メモリー容量も増えたので・・・と、スタックサイズを大きくしようと考えると、こんどはスレッド毎にスタックが必要なので、昨今のマルチCPUを生かしたコードだと余りうれしくない事態になります。そこで、スタックフレームをヒープ上に確保できれば、再帰型のコードを書きやすくなりますが、スタック上に確保するのは現行非常に高速ですから、その利点を捨ててまでヒープ上にスタックフレームを確保したいとは思えません。しかし1Clockでヒープが確保できるとすれば・・・これは有りかなと。
何を言ってるのかわからん。プロセス単位で保護が効くから他のプロセスとメモリ空間を共有したりしないし。プロテクトモードが無い時代の話か?
マルチスレッドプログラミングをすると、当然スレッドを複数確保します。スタックは、各スレッドにそれぞれ指定の最大容量が必要です。スタックは非常に深いネストを作らない限り殆ど消費されません、再帰コードの為だけに確保するとすればそれは膨大な無駄となります。ですから、現行のプログラムでは、LISPのような再帰前提の言語でもなければ極度に深い再帰はできません。自前でスタックを実装する必要が生じます。しかし、ヒープに確保できればCのような言語でもLISPのような深い再帰コードを書く事が可能になります。
別にスレッド毎にスタックサイズ1GiB割り当ててもかまわんでしょ。物理メモリが固定で割り当てられるわけじゃないし。
> 物理メモリが固定で割り当てられるわけじゃないし。
同感です
多分この方は,カーネル側のメモリ管理(仮想メモリと実メモリの対応づけ)とユーザ側のメモリ管理(今回のタレコミはこっち側の話)が区別できていません
基礎知識が足りてないので,これ以上まともな話をするのは無理でしょう
64bitでVirtual Addressに問題ないとしても、スタックをdedaultで広げるのと、間違って無限たらい回し関数とか作ったときに、すぐに気づけないしstack overflowする前にスラッシングしたりして被害が広がるよ。
バグってる事想定するなら何でもありだ。そんなのいい出したら話にならんバカバカしい。
メモリ空間を共有しないのはプロセス単位、マルチスレッドは同一プロセス内でメモリ空間を共有してるものを指すことが多い。プロセスとスレッドを混同するなんていつの時代の人?
専用プロセッサがあらかじめ確保したメモリを割り当てると言ってるんだぞ?プロセス別に保護されたメモリ空間になってるか?プロテクトモードが無い時代の話かと言ったのはそういう意味だ。
> そこで、スタックフレームをヒープ上に確保できれば、再帰型のコードを書きやすくなりますが、スタック上に確保するのは現行非常に高速ですから、その利点を捨ててまでヒープ上にスタックフレームを確保したいとは思えません。
だから、コルーチンとか扱うときは、今もそうなってるよねって話でしょ。名称は「スタックフレーム」のままでも、関数から戻ったとか、呼び元が終了したって、その関数が終了したわけじゃないので「スタック」ではないんだから。
> スタック上に確保するのは現行非常に高速ですから、
まずCPUと実メモリの接続を考えるとヒープ領域もスタック領域は単にCPUから実メモリにアクセスしているだけだからアクセス速度に差はない
次に1Clockでヒープが獲得できると言ってるがそれも間違い
別CPU,仮にCPU1でメモリ管理をするとしてCPU0がそのメモリを使う場合はCPU1とCPU0間で通信,何らかの情報交換を行う必要がある.またCPU0とCPU1で実メモリを共有している場合はメモリの一貫性を保つ処理が必須になる.排他制御,バリア同期,キャッシュの操作が必要
これらを実現するのに数クロックでは無理.かりに専用命令をCPU側に実装しても原理は一緒,つまりキャッシュを破棄するためにパイプラインをストールさせるのが不可避だからスループットは大幅に落ちる.
>CPU1とCPU0間で通信,何らかの情報交換を行う必要がある.コプロセッサとして接続するなら、通常はメモリーを経由せずCPU内のレジスター間で行うことになるでしょう。前もって確保したメモリーの先頭アドレスをCPU0の特殊レジスタに転送して、CPU0に実装されたmalloc命令の処理は、「AX = 特殊レジスタ」のようなイメージで行なう事を想定しているのでしょう。PS2のDSPの例が上がっていますが、PS2の場合、DSPのレジスタをCPU側からアクセス可能な命令が備わっています。レジスター経由なら排他制御,バリア同期,キャッシュの操作といった物は必要なくなりますね
スタックと同じくらい高速にヒープからメモリ確保したい、という点はそんな難しく考えなくても実現できる。
スタックからの確保が高速な理由は、スタックポインタを減算するだけだから。ならば、ヒープでも同じようにやればいい。
(スタックとは逆向きに伸びていることに注意)
メモリの解放はGCで対処する。
CLR (.NET Frame
どうでもいいけど、スタックに向きの決まりなんてないだろ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生の大半の問題はスルー力で解決する -- スルー力研究専門家
mallocは、ハードウェアで実装すれば良いのにと思っている (スコア:0)
メモリーも大量に使えるようになってきたので・・・
最小確保単位が128byteととかでなく1024byteとかでも問題なくなり始めている、そこで
ガベコレもmallocも、専用CPUを1つ搭載して、各種処理を裏側でやってしまうと良いのではと思っている。
大半のオブジェクトやスタックフレームを格納できる程度のサイズ(1024byte程度)を、バックグラウンドで100個くらい確保してあらかじめ溜め込んでおく。
そして、malloc要求が来たら、1024byte以下のサイズを要求された場合、あらかじめ確保しておいたメモリーの先頭番地を返すだけ、それ以上のサイズの要求が来たらソフトウェ
Re: (スコア:0)
ハードウェアでメモリ確保というと68000系のLINK/UNLINK命令のこと、、、じゃなかったのか。
# SP移動するだけだが。
> スタックフレームの確保もSPレジスタを使うのではなく malloc によって確保して統一的にしてしまえばと思い始めています。
コルーチンあるやつは、だいたいこうなってない?
Re:mallocは、ハードウェアで実装すれば良いのにと思っている (スコア:0)
スタックフレームをスタック上に確保すると、再帰をするコードで簡単にスタックがあふれます。
メモリー容量も増えたので・・・と、スタックサイズを大きくしようと考えると、こんどはスレッド毎にスタックが必要なので、昨今のマルチCPUを生かしたコードだと余りうれしくない事態になります。
そこで、スタックフレームをヒープ上に確保できれば、再帰型のコードを書きやすくなりますが、スタック上に確保するのは現行非常に高速ですから、その利点を捨ててまでヒープ上にスタックフレームを確保したいとは思えません。
しかし1Clockでヒープが確保できるとすれば・・・これは有りかなと。
Re: (スコア:0)
何を言ってるのかわからん。
プロセス単位で保護が効くから他のプロセスとメモリ空間を共有したりしないし。
プロテクトモードが無い時代の話か?
Re: (スコア:0)
マルチスレッドプログラミングをすると、当然スレッドを複数確保します。
スタックは、各スレッドにそれぞれ指定の最大容量が必要です。
スタックは非常に深いネストを作らない限り殆ど消費されません、再帰コードの為だけに確保するとすればそれは膨大な無駄となります。
ですから、現行のプログラムでは、LISPのような再帰前提の言語でもなければ極度に深い再帰はできません。自前でスタックを実装する必要が生じます。
しかし、ヒープに確保できればCのような言語でもLISPのような深い再帰コードを書く事が可能になります。
Re: (スコア:0)
別にスレッド毎にスタックサイズ1GiB割り当ててもかまわんでしょ。
物理メモリが固定で割り当てられるわけじゃないし。
Re: (スコア:0)
> 物理メモリが固定で割り当てられるわけじゃないし。
同感です
多分この方は,カーネル側のメモリ管理(仮想メモリと実メモリの対応づけ)と
ユーザ側のメモリ管理(今回のタレコミはこっち側の話)が区別できていません
基礎知識が足りてないので,これ以上まともな話をするのは無理でしょう
Re: (スコア:0)
64bitでVirtual Addressに問題ないとしても、スタックをdedaultで広げるのと、
間違って無限たらい回し関数とか作ったときに、すぐに気づけないし
stack overflowする前にスラッシングしたりして被害が広がるよ。
Re: (スコア:0)
バグってる事想定するなら何でもありだ。
そんなのいい出したら話にならんバカバカしい。
Re: (スコア:0)
メモリ空間を共有しないのはプロセス単位、マルチスレッドは同一プロセス内でメモリ空間を共有してるものを指すことが多い。
プロセスとスレッドを混同するなんていつの時代の人?
Re: (スコア:0)
専用プロセッサがあらかじめ確保したメモリを割り当てると言ってるんだぞ?
プロセス別に保護されたメモリ空間になってるか?
プロテクトモードが無い時代の話かと言ったのはそういう意味だ。
Re: (スコア:0)
> そこで、スタックフレームをヒープ上に確保できれば、再帰型のコードを書きやすくなりますが、スタック上に確保するのは現行非常に高速ですから、その利点を捨ててまでヒープ上にスタックフレームを確保したいとは思えません。
だから、コルーチンとか扱うときは、今もそうなってるよねって話でしょ。
名称は「スタックフレーム」のままでも、関数から戻ったとか、呼び元が終了したって、その関数が終了したわけじゃないので「スタック」ではないんだから。
Re: (スコア:0)
> スタック上に確保するのは現行非常に高速ですから、
まずCPUと実メモリの接続を考えると
ヒープ領域もスタック領域は単にCPUから実メモリにアクセスしているだけだから
アクセス速度に差はない
次に1Clockでヒープが獲得できると言ってるがそれも間違い
別CPU,仮にCPU1でメモリ管理をするとして
CPU0がそのメモリを使う場合は
CPU1とCPU0間で通信,何らかの情報交換を行う必要がある.
またCPU0とCPU1で実メモリを共有している場合はメモリの一貫性を保つ処理が必須になる.排他制御,バリア同期,キャッシュの操作が必要
これらを実現するのに数クロックでは無理.かりに専用命令をCPU側に実装しても
原理は一緒,つまりキャッシュを破棄するためにパイプラインをストールさせるのが不可避だからスループットは大幅に落ちる.
Re: (スコア:0)
>CPU1とCPU0間で通信,何らかの情報交換を行う必要がある.
コプロセッサとして接続するなら、通常はメモリーを経由せずCPU内のレジスター間で行うことになるでしょう。
前もって確保したメモリーの先頭アドレスをCPU0の特殊レジスタに転送して、CPU0に実装されたmalloc命令の処理は、「AX = 特殊レジスタ」のようなイメージで行なう事を想定しているのでしょう。
PS2のDSPの例が上がっていますが、PS2の場合、DSPのレジスタをCPU側からアクセス可能な命令が備わっています。
レジスター経由なら排他制御,バリア同期,キャッシュの操作といった物は必要なくなりますね
Re: (スコア:0)
スタックと同じくらい高速にヒープからメモリ確保したい、という点はそんな難しく考えなくても実現できる。
スタックからの確保が高速な理由は、スタックポインタを減算するだけだから。ならば、ヒープでも同じようにやればいい。
(スタックとは逆向きに伸びていることに注意)
メモリの解放はGCで対処する。
CLR (.NET Frame
Re: (スコア:0)
どうでもいいけど、スタックに向きの決まりなんてないだろ。