アカウント名:
パスワード:
メモリーも大量に使えるようになってきたので・・・最小確保単位が128byteととかでなく1024byteとかでも問題なくなり始めている、そこでガベコレもmallocも、専用CPUを1つ搭載して、各種処理を裏側でやってしまうと良いのではと思っている。大半のオブジェクトやスタックフレームを格納できる程度のサイズ(1024byte程度)を、バックグラウンドで100個くらい確保してあらかじめ溜め込んでおく。そして、malloc要求が来たら、1024byte以下のサイズを要求された場合、あらかじめ確保しておいたメモリーの先頭番地を返すだけ、それ以上のサイズの要求が来たらソフトウェ
ハードウェアでメモリ確保というと68000系のLINK/UNLINK命令のこと、、、じゃなかったのか。# SP移動するだけだが。
> スタックフレームの確保もSPレジスタを使うのではなく malloc によって確保して統一的にしてしまえばと思い始めています。
コルーチンあるやつは、だいたいこうなってない?
スタックフレームをスタック上に確保すると、再帰をするコードで簡単にスタックがあふれます。メモリー容量も増えたので・・・と、スタックサイズを大きくしようと考えると、こんどはスレッド毎にスタックが必要なので、昨今のマルチCPUを生かしたコードだと余りうれしくない事態になります。そこで、スタックフレームをヒープ上に確保できれば、再帰型のコードを書きやすくなりますが、スタック上に確保するのは現行非常に高速ですから、その利点を捨ててまでヒープ上にスタックフレームを確保したいとは思えません。しかし1Clockでヒープが確保できるとすれば・・・これは有りかなと。
> スタック上に確保するのは現行非常に高速ですから、
まずCPUと実メモリの接続を考えるとヒープ領域もスタック領域は単にCPUから実メモリにアクセスしているだけだからアクセス速度に差はない
次に1Clockでヒープが獲得できると言ってるがそれも間違い
別CPU,仮にCPU1でメモリ管理をするとしてCPU0がそのメモリを使う場合はCPU1とCPU0間で通信,何らかの情報交換を行う必要がある.またCPU0とCPU1で実メモリを共有している場合はメモリの一貫性を保つ処理が必須になる.排他制御,バリア同期,キャッシュの操作が必要
これらを実現するのに数クロックでは無理.かりに専用命令をCPU側に実装しても原理は一緒,つまりキャッシュを破棄するためにパイプラインをストールさせるのが不可避だからスループットは大幅に落ちる.
>CPU1とCPU0間で通信,何らかの情報交換を行う必要がある.コプロセッサとして接続するなら、通常はメモリーを経由せずCPU内のレジスター間で行うことになるでしょう。前もって確保したメモリーの先頭アドレスをCPU0の特殊レジスタに転送して、CPU0に実装されたmalloc命令の処理は、「AX = 特殊レジスタ」のようなイメージで行なう事を想定しているのでしょう。PS2のDSPの例が上がっていますが、PS2の場合、DSPのレジスタをCPU側からアクセス可能な命令が備わっています。レジスター経由なら排他制御,バリア同期,キャッシュの操作といった物は必要なくなりますね
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
mallocは、ハードウェアで実装すれば良いのにと思っている (スコア:0)
メモリーも大量に使えるようになってきたので・・・
最小確保単位が128byteととかでなく1024byteとかでも問題なくなり始めている、そこで
ガベコレもmallocも、専用CPUを1つ搭載して、各種処理を裏側でやってしまうと良いのではと思っている。
大半のオブジェクトやスタックフレームを格納できる程度のサイズ(1024byte程度)を、バックグラウンドで100個くらい確保してあらかじめ溜め込んでおく。
そして、malloc要求が来たら、1024byte以下のサイズを要求された場合、あらかじめ確保しておいたメモリーの先頭番地を返すだけ、それ以上のサイズの要求が来たらソフトウェ
Re: (スコア:0)
ハードウェアでメモリ確保というと68000系のLINK/UNLINK命令のこと、、、じゃなかったのか。
# SP移動するだけだが。
> スタックフレームの確保もSPレジスタを使うのではなく malloc によって確保して統一的にしてしまえばと思い始めています。
コルーチンあるやつは、だいたいこうなってない?
Re: (スコア:0)
スタックフレームをスタック上に確保すると、再帰をするコードで簡単にスタックがあふれます。
メモリー容量も増えたので・・・と、スタックサイズを大きくしようと考えると、こんどはスレッド毎にスタックが必要なので、昨今のマルチCPUを生かしたコードだと余りうれしくない事態になります。
そこで、スタックフレームをヒープ上に確保できれば、再帰型のコードを書きやすくなりますが、スタック上に確保するのは現行非常に高速ですから、その利点を捨ててまでヒープ上にスタックフレームを確保したいとは思えません。
しかし1Clockでヒープが確保できるとすれば・・・これは有りかなと。
Re:mallocは、ハードウェアで実装すれば良いのにと思っている (スコア: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側からアクセス可能な命令が備わっています。
レジスター経由なら排他制御,バリア同期,キャッシュの操作といった物は必要なくなりますね