アカウント名:
パスワード:
メモリーも大量に使えるようになってきたので・・・最小確保単位が128byteととかでなく1024byteとかでも問題なくなり始めている、そこでガベコレもmallocも、専用CPUを1つ搭載して、各種処理を裏側でやってしまうと良いのではと思っている。大半のオブジェクトやスタックフレームを格納できる程度のサイズ(1024byte程度)を、バックグラウンドで100個くらい確保してあらかじめ溜め込んでおく。そして、malloc要求が来たら、1024byte以下のサイズを要求された場合、あらかじめ確保しておいたメモリーの先頭番地を返すだけ、それ以上のサイズの要求が来たらソフトウェ
ハードウェアでメモリ確保というと68000系のLINK/UNLINK命令のこと、、、じゃなかったのか。# SP移動するだけだが。
> スタックフレームの確保もSPレジスタを使うのではなく malloc によって確保して統一的にしてしまえばと思い始めています。
コルーチンあるやつは、だいたいこうなってない?
スタックフレームをスタック上に確保すると、再帰をするコードで簡単にスタックがあふれます。メモリー容量も増えたので・・・と、スタックサイズを大きくしようと考えると、こんどはスレッド毎にスタックが必要なので、昨今のマルチCPUを生かしたコードだと余りうれしくない事態になります。そこで、スタックフレームをヒープ上に確保できれば、再帰型のコードを書きやすくなりますが、スタック上に確保するのは現行非常に高速ですから、その利点を捨ててまでヒープ上にスタックフレームを確保したいとは思えません。しかし1Clockでヒープが確保できるとすれば・・・これは有りかなと。
何を言ってるのかわからん。プロセス単位で保護が効くから他のプロセスとメモリ空間を共有したりしないし。プロテクトモードが無い時代の話か?
マルチスレッドプログラミングをすると、当然スレッドを複数確保します。スタックは、各スレッドにそれぞれ指定の最大容量が必要です。スタックは非常に深いネストを作らない限り殆ど消費されません、再帰コードの為だけに確保するとすればそれは膨大な無駄となります。ですから、現行のプログラムでは、LISPのような再帰前提の言語でもなければ極度に深い再帰はできません。自前でスタックを実装する必要が生じます。しかし、ヒープに確保できればCのような言語でもLISPのような深い再帰コードを書く事が可能になります。
別にスレッド毎にスタックサイズ1GiB割り当ててもかまわんでしょ。物理メモリが固定で割り当てられるわけじゃないし。
> 物理メモリが固定で割り当てられるわけじゃないし。
同感です
多分この方は,カーネル側のメモリ管理(仮想メモリと実メモリの対応づけ)とユーザ側のメモリ管理(今回のタレコミはこっち側の話)が区別できていません
基礎知識が足りてないので,これ以上まともな話をするのは無理でしょう
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy
mallocは、ハードウェアで実装すれば良いのにと思っている (スコア:0)
メモリーも大量に使えるようになってきたので・・・
最小確保単位が128byteととかでなく1024byteとかでも問題なくなり始めている、そこで
ガベコレもmallocも、専用CPUを1つ搭載して、各種処理を裏側でやってしまうと良いのではと思っている。
大半のオブジェクトやスタックフレームを格納できる程度のサイズ(1024byte程度)を、バックグラウンドで100個くらい確保してあらかじめ溜め込んでおく。
そして、malloc要求が来たら、1024byte以下のサイズを要求された場合、あらかじめ確保しておいたメモリーの先頭番地を返すだけ、それ以上のサイズの要求が来たらソフトウェ
Re: (スコア:0)
ハードウェアでメモリ確保というと68000系のLINK/UNLINK命令のこと、、、じゃなかったのか。
# SP移動するだけだが。
> スタックフレームの確保もSPレジスタを使うのではなく malloc によって確保して統一的にしてしまえばと思い始めています。
コルーチンあるやつは、だいたいこうなってない?
Re: (スコア:0)
スタックフレームをスタック上に確保すると、再帰をするコードで簡単にスタックがあふれます。
メモリー容量も増えたので・・・と、スタックサイズを大きくしようと考えると、こんどはスレッド毎にスタックが必要なので、昨今のマルチCPUを生かしたコードだと余りうれしくない事態になります。
そこで、スタックフレームをヒープ上に確保できれば、再帰型のコードを書きやすくなりますが、スタック上に確保するのは現行非常に高速ですから、その利点を捨ててまでヒープ上にスタックフレームを確保したいとは思えません。
しかし1Clockでヒープが確保できるとすれば・・・これは有りかなと。
Re: (スコア:0)
何を言ってるのかわからん。
プロセス単位で保護が効くから他のプロセスとメモリ空間を共有したりしないし。
プロテクトモードが無い時代の話か?
Re: (スコア:0)
マルチスレッドプログラミングをすると、当然スレッドを複数確保します。
スタックは、各スレッドにそれぞれ指定の最大容量が必要です。
スタックは非常に深いネストを作らない限り殆ど消費されません、再帰コードの為だけに確保するとすればそれは膨大な無駄となります。
ですから、現行のプログラムでは、LISPのような再帰前提の言語でもなければ極度に深い再帰はできません。自前でスタックを実装する必要が生じます。
しかし、ヒープに確保できればCのような言語でもLISPのような深い再帰コードを書く事が可能になります。
Re: (スコア:0)
別にスレッド毎にスタックサイズ1GiB割り当ててもかまわんでしょ。
物理メモリが固定で割り当てられるわけじゃないし。
Re:mallocは、ハードウェアで実装すれば良いのにと思っている (スコア:0)
> 物理メモリが固定で割り当てられるわけじゃないし。
同感です
多分この方は,カーネル側のメモリ管理(仮想メモリと実メモリの対応づけ)と
ユーザ側のメモリ管理(今回のタレコミはこっち側の話)が区別できていません
基礎知識が足りてないので,これ以上まともな話をするのは無理でしょう