アカウント名:
パスワード:
メモリーも大量に使えるようになってきたので・・・最小確保単位が128byteととかでなく1024byteとかでも問題なくなり始めている、そこでガベコレもmallocも、専用CPUを1つ搭載して、各種処理を裏側でやってしまうと良いのではと思っている。大半のオブジェクトやスタックフレームを格納できる程度のサイズ(1024byte程度)を、バックグラウンドで100個くらい確保してあらかじめ溜め込んでおく。そして、malloc要求が来たら、1024byte以下のサイズを要求された場合、あらかじめ確保しておいたメモリーの先頭番地を返すだけ、それ以上のサイズの要求が来たらソフトウェア処理、これで見かけ上1clockで実行する形にする。free要求が来たら、とりあえず解放キューに追加する、これもバックグラウンドで解放していく。専用CPUは1つで十分、どうせマルチCPUで処理するとしても lock 処理をして同時に1CPUしか実行できないのだから、メモリー管理用の1CPUにリクエストを投げ込んでも一緒だから。スタックフレームの確保もSPレジスタを使うのではなく malloc によって確保して統一的にしてしまえばと思い始めています。
仮想記憶について勉強してから出直した方がいいですよ
ページングサイズを小さくするという考えですか？オーバーヘッドが大きくて実用性がないんじゃないですかねもしくは大量のCAMを搭載するという事になるんでしょうが、こんどは消費電力がヤバイ事になりそうな予感。
あなたが言っていることが理解できません
判ることは以下の3点だけです- あなたの文章は原理を説明できてない- あなたはOSの仕組み，例えば仮想記憶の仕組み（ページテーブルのハードウェアとか）や，ユーザ空間とカーネル空間の違いを理解してない- スタックが1024byte単位でOKとか，基本的に考え方が30年ぐらい古い
私にはあなたの言っている事の方がよくわからないです今回の話は本質的には仮想記憶があってもなくても関係ないですし、「仮想記憶について勉強してから」と書かれたので仮想記憶を利用したmallocを提案しているのかな？と思ってこう返答しました、私は普通に仮想記憶もページングの仕組みも知っています。そもそもmallocに仮想記憶とか意味不明でしたから、そんなものそもそもmallocには必要ないですよね？
1024byteとかいったのは、多くのオブジェクトがそのくらいのサイズがあれば良くて、スタックフレーム(要するにサブルーチン内で使われた自動変数の全体、実態は構造体みたいな仕組みになっている)、ここにある変数のサイズも極端に大きいという事はなく多くのオブジェクトと同一サイズ程度だなぁと書いていて思うわけ。そして、あらかじめ確保して待機させておくなら、速度的にもメモリスラッシング対策的にもサイズは統一しておいた方が良いなという事で、1024byteとか書いてみた。実際には多くのコードで統計を取って、8割型の class や スタックフレーム(サブルーチンの自動変数)が収まるようなサイズに決定すればと思う。足りなければ普通のアルゴリズムでmallocするのであって、スタックが1024byte以外許さないとかいう話ではないです。
ややこしいのでIDでやってくれ
いつから自作自演じゃないと勘違いしてた?
メモリ共有されてる前提で話してるっぽいので、その文脈だと番兵処理くらいしかHW化するメリット無いのでは…
ハードウェアでメモリ確保というと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
どうでもいいけど、スタックに向きの決まりなんてないだろ。
むかし、OSの機能をマイクロプロセッサに取り込もうとして大失敗した石がありましてね
インテルの大失敗がありますね、でも昔と今では集積度が全然違います。PS2でも、DSPをCPU上に搭載しましたが失敗などありません。あのDSPでも無理すれば書けます、しかしFPUなんか必要ありませんし、整数部は16ビットではなく64bitにして足し算引き算シフトくらいあれば十分です。
iAPX 432 とか今の集積度とコンパイラ技術で作れば十分な性能が出せそうだよね。
次世代8080として出発したアーキテクチャですからね、あれはZ80世代です無理に決まっています。(笑)それに、あれをそのまま真似する必要もないと思うんです。IBMの汎用機 Z/Architecture のような、VMを挟んでの互換性を保つようにして、CPUメーカーはVMとセットで供給するようにして、ここでエラッタ対応とかもしてしまう。ハードウェアで容易に実装可能なパーツ的命令だけを実装して、VMで活用するようにし、パーツ的命令には直接触らないというルールでやっても良いと思います。
ちなみに malloc の場合は、重いけれどもプログラム内で連発する命令ではなく、前後に依存性が無いので、小さい回路規模でもうまく処理時間を裏側に隠せるのでは？と思いました。
そんなのもどっかでやってたよね。トランスメタとか言ったっけ?
排他制御ですごく遅くなるよそれ
普通のmallocでも排他制御は必要不可欠ですよちなみに、このあらかじめ確保しておいたメモリを返すだけなら、メモリ管理処理CPUをコプロセッサ的に汎用CPUと繋いでしまえばなんと排他制御不要できます。
マルチスレッドの排他制御が遅いってんで、排他制御の少ないjemallocが出てきたコプロでやるならメモリバリアが必要だトーシロは黙っとけ
>コプロでやるならメモリバリアが必要だ要りませんよ、専用1CPUでメモり管理を全部やるんだから、他のCPUから管理情報をアクセスする必要などハナから無いので。
専用1CPUでやるからシングルスレッドでしか動かなくて、排他制御なんてわざわざ用意するまでもなくハードウェアが他のプロセスを待たせてくれるんですね、わかります。それロックかかってるのと同じで全く速くない
そもそもmallocを使うのは、ハードウェアに制限がある場合でしょ専用CPUなんて搭載する予算なんかないよ
ロック処理をして 1CPU しか同時に実行できない、というのは間違っていて、いまどきは標準の malloc でも複数 CPU からメモリーを確保できます。
それでも数千命令程度のコードを通過するでしょう。スタックフレームの変数を確保するのにそのmallocは使いたくない。目標は一命令で即時確保です。スタックにスタックフレーム確保する速度と同等なレベルのパフォーマンスが欲しい。そこまで行けば、世界が広がるから。
あんたが考えている数千命令ってどんな具合だ擬似コードでいいからmallocとfreeのコードを書いてみろ
目標は一命令で即時確保です。それでも数千命令程度のストールが発生するでしょう。
あらかじめ用意済みのメモリーを返すだけなのでストールしません即実行可能ですmallocのデバッガで追跡してみるとロック処理が大半、しかしロックすら必要ありません。従って数千命令も大幅に減ります。
そういうのは拡張機能やフレームワークあたりでやるべきで、mallocみたいなもんは単純コンパクトであるべきかと。
「あらかじめ確保しておいたメモリーの先頭番地を返すだけ」、「free要求が来たら、とりあえず解放キューに追加する」、どちらも、汎用命令セット上にロックフリーなデータ構造で実装できることです。1クロックとまではいきませんが、僅かな命令数で書けます。あとのバックグラウンド処理はCPUの暇なコアにスレッドを割り当てて実行すればよく、わざわざ専用CPUを作る必要性が見いだせません。
そもそもだけど、MMUってないやってるんだっけ。仮想アドレスで管理された物理アドレスを渡すわけでしょ。これはmalloc()でないのかえ。
MMUがやるのは仮想アドレスと物理アドレスの相互変換。メモリブロックを受け渡しするわけじゃないから、メモリブロックを割り当てるmallocとは無関係。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
mallocは、ハードウェアで実装すれば良いのにと思っている (スコア:0)
メモリーも大量に使えるようになってきたので・・・
最小確保単位が128byteととかでなく1024byteとかでも問題なくなり始めている、そこで
ガベコレもmallocも、専用CPUを1つ搭載して、各種処理を裏側でやってしまうと良いのではと思っている。
大半のオブジェクトやスタックフレームを格納できる程度のサイズ(1024byte程度)を、バックグラウンドで100個くらい確保してあらかじめ溜め込んでおく。
そして、malloc要求が来たら、1024byte以下のサイズを要求された場合、あらかじめ確保しておいたメモリーの先頭番地を返すだけ、それ以上のサイズの要求が来たらソフトウェア処理、これで見かけ上1clockで実行する形にする。
free要求が来たら、とりあえず解放キューに追加する、これもバックグラウンドで解放していく。
専用CPUは1つで十分、どうせマルチCPUで処理するとしても lock 処理をして同時に1CPUしか実行できないのだから、メモリー管理用の1CPUにリクエストを投げ込んでも一緒だから。
スタックフレームの確保もSPレジスタを使うのではなく malloc によって確保して統一的にしてしまえばと思い始めています。
Re: (スコア:0)
仮想記憶について勉強してから
出直した方がいいですよ
Re: (スコア:0)
ページングサイズを小さくするという考えですか？
オーバーヘッドが大きくて実用性がないんじゃないですかね
もしくは大量のCAMを搭載するという事になるんでしょうが、こんどは消費電力がヤバイ事になりそうな予感。
Re: (スコア:0)
あなたが言っていることが理解できません
判ることは以下の3点だけです
- あなたの文章は原理を説明できてない
- あなたはOSの仕組み，例えば仮想記憶の仕組み（ページテーブルのハードウェアとか）や，ユーザ空間とカーネル空間の違いを理解してない
- スタックが1024byte単位でOKとか，基本的に考え方が30年ぐらい古い
Re:mallocは、ハードウェアで実装すれば良いのにと思っている (スコア:1)
私にはあなたの言っている事の方がよくわからないです
今回の話は本質的には仮想記憶があってもなくても関係ないですし、「仮想記憶について勉強してから」と書かれたので仮想記憶を利用したmallocを提案しているのかな？と思ってこう返答しました、私は普通に仮想記憶もページングの仕組みも知っています。
そもそもmallocに仮想記憶とか意味不明でしたから、そんなものそもそもmallocには必要ないですよね？
1024byteとかいったのは、多くのオブジェクトがそのくらいのサイズがあれば良くて、スタックフレーム(要するにサブルーチン内で使われた自動変数の全体、実態は構造体みたいな仕組みになっている)、ここにある変数のサイズも極端に大きいという事はなく多くのオブジェクトと同一サイズ程度だなぁと書いていて思うわけ。
そして、あらかじめ確保して待機させておくなら、速度的にもメモリスラッシング対策的にもサイズは統一しておいた方が良いなという事で、1024byteとか書いてみた。
実際には多くのコードで統計を取って、8割型の class や スタックフレーム(サブルーチンの自動変数)が収まるようなサイズに決定すればと思う。
足りなければ普通のアルゴリズムでmallocするのであって、スタックが1024byte以外許さないとかいう話ではないです。
Re:mallocは、ハードウェアで実装すれば良いのにと思っている (スコア:1)
ややこしいのでIDでやってくれ
Re: (スコア:0)
いつから自作自演じゃないと勘違いしてた?
Re: (スコア:0)
メモリ共有されてる前提で話してるっぽいので、
その文脈だと番兵処理くらいしかHW化するメリット無いのでは…
Re: (スコア:0)
ハードウェアでメモリ確保というと68000系のLINK/UNLINK命令のこと、、、じゃなかったのか。
# SP移動するだけだが。
> スタックフレームの確保もSPレジスタを使うのではなく malloc によって確保して統一的にしてしまえばと思い始めています。
コルーチンあるやつは、だいたいこうなってない？
Re: (スコア: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)
どうでもいいけど、スタックに向きの決まりなんてないだろ。
Re: (スコア:0)
むかし、OSの機能をマイクロプロセッサに取り込もうとして大失敗した石がありましてね
Re: (スコア:0)
インテルの大失敗がありますね、でも昔と今では集積度が全然違います。
PS2でも、DSPをCPU上に搭載しましたが失敗などありません。
あのDSPでも無理すれば書けます、しかしFPUなんか必要ありませんし、整数部は16ビットではなく64bitにして足し算引き算シフトくらいあれば十分です。
Re: (スコア:0)
iAPX 432 とか今の集積度とコンパイラ技術で作れば十分な性能が出せそうだよね。
Re: (スコア:0)
次世代8080として出発したアーキテクチャですからね、あれはZ80世代です無理に決まっています。(笑)
それに、あれをそのまま真似する必要もないと思うんです。
IBMの汎用機 Z/Architecture のような、VMを挟んでの互換性を保つようにして、CPUメーカーはVMとセットで供給するようにして、ここでエラッタ対応とかもしてしまう。
ハードウェアで容易に実装可能なパーツ的命令だけを実装して、VMで活用するようにし、パーツ的命令には直接触らないというルールでやっても良いと思います。
ちなみに malloc の場合は、重いけれどもプログラム内で連発する命令ではなく、前後に依存性が無いので、小さい回路規模でもうまく処理時間を裏側に隠せるのでは？と思いました。
Re: (スコア:0)
そんなのもどっかでやってたよね。
トランスメタとか言ったっけ?
Re: (スコア:0)
排他制御ですごく遅くなるよそれ
Re: (スコア:0)
普通のmallocでも排他制御は必要不可欠ですよ
ちなみに、このあらかじめ確保しておいたメモリを返すだけなら、メモリ管理処理CPUをコプロセッサ的に汎用CPUと繋いでしまえばなんと排他制御不要できます。
Re: (スコア:0)
マルチスレッドの排他制御が遅いってんで、排他制御の少ないjemallocが出てきた
コプロでやるならメモリバリアが必要だ
トーシロは黙っとけ
Re: (スコア:0)
>コプロでやるならメモリバリアが必要だ
要りませんよ、専用1CPUでメモり管理を全部やるんだから、他のCPUから管理情報をアクセスする必要などハナから無いので。
Re: (スコア:0)
専用1CPUでやるからシングルスレッドでしか動かなくて、排他制御なんてわざわざ用意するまでもなくハードウェアが他のプロセスを待たせてくれるんですね、わかります。
それロックかかってるのと同じで全く速くない
Re: (スコア:0)
そもそもmallocを使うのは、ハードウェアに制限がある場合でしょ
専用CPUなんて搭載する予算なんかないよ
Re: (スコア:0)
ロック処理をして 1CPU しか同時に実行できない、というのは間違っていて、
いまどきは標準の malloc でも複数 CPU からメモリーを確保できます。
Re: (スコア:0)
それでも数千命令程度のコードを通過するでしょう。
スタックフレームの変数を確保するのにそのmallocは使いたくない。
目標は一命令で即時確保です。
スタックにスタックフレーム確保する速度と同等なレベルのパフォーマンスが欲しい。
そこまで行けば、世界が広がるから。
Re: (スコア:0)
あんたが考えている数千命令ってどんな具合だ
擬似コードでいいからmallocとfreeのコードを書いてみろ
Re: (スコア:0)
目標は一命令で即時確保です。
それでも数千命令程度のストールが発生するでしょう。
Re: (スコア:0)
あらかじめ用意済みのメモリーを返すだけなのでストールしません即実行可能です
mallocのデバッガで追跡してみるとロック処理が大半、しかしロックすら必要ありません。従って数千命令も大幅に減ります。
Re: (スコア:0)
そういうのは拡張機能やフレームワークあたりでやるべきで、mallocみたいなもんは単純コンパクトであるべきかと。
Re: (スコア:0)
「あらかじめ確保しておいたメモリーの先頭番地を返すだけ」、「free要求が来たら、とりあえず解放キューに追加する」、どちらも、汎用命令セット上にロックフリーなデータ構造で実装できることです。1クロックとまではいきませんが、僅かな命令数で書けます。あとのバックグラウンド処理はCPUの暇なコアにスレッドを割り当てて実行すればよく、わざわざ専用CPUを作る必要性が見いだせません。
Re: (スコア:0)
そもそもだけど、MMUってないやってるんだっけ。
仮想アドレスで管理された物理アドレスを渡すわけでしょ。これはmalloc()でないのかえ。
Re: (スコア:0)
MMUがやるのは仮想アドレスと物理アドレスの相互変換。
メモリブロックを受け渡しするわけじゃないから、メモリブロックを割り当てるmallocとは無関係。