Microsoft、高速なmallocを公開 82
ストーリー by hylom
普及するか 部門より
普及するか 部門より
Microsoftが、汎用な高速メモリアロケータという「mimalloc」をオープンソースで公開した（GitHubのmimallocページ、マイナビニュース）。ライセンスはMITライセンス。
特徴として、コード行数が少なく、セキュアであること、高速であることなどが挙げられている。アーキテクチャ的にはメモリを小さいリストで管理したり、不要になったメモリをすぐに解放するといった方針でデザインされているそうだ。
対応OSはWindowsおよびmacOS、Linux、BSD等となっている。
miはmicrosoftのmiなのか (スコア:2)
マイクロソフトはXが好きだからxmallocにしたかっただろうに
もう取られちゃってんだなぁ
Re: (スコア:0)
msmallocとか、mallocxもアリじゃないかと思うんだけど。
Re: (スコア:0)
xiaomi が miナントカって一杯取ってそう
商標とか
Re: (スコア:0)
My Documents
My Pictures
My Malloc
Re: (スコア:0)
mallocExでよかったのに...
Re: (スコア:0)
世のなかには勝手な拡張に対して最後にExってつける奴が意外と居るから、その辺りは沢山ありそうだ。
Re:miはmicrosoftのmiなのか (スコア:1)
元コメは16ビット時代のWindowsAPIの拡張版としてWin32APIに「ナントカEx」がたくさんできたことを指しているのだと思うよ。
うじゃうじゃ
Re:miはmicrosoftのmiなのか (スコア:1)
「マイクロソフトはX好きだよね」→「Exつけたやつもあるよね」
みたいなゆるいネタだったのに、マジなコメントがつく流れになったことを反省してます
うじゃうじゃ
Re: (スコア:0)
Win32APIがそういういい加減な名前付けをしてたので広まったのかもなあ
Re: (スコア:0)
マイクロソフトはXが好きだから
Xwindowのことですね!
Re: (スコア:0)
Xが好きってDirectXとかActiveXの時代でしょ。何年前だよ…。今はPowerとかだと思う。PowerShell、PowerBI、PowerQuery、PowerApps。
Re:miはmicrosoftのmiなのか (スコア:2)
MSXもあったしXBoxがまだ頑張ってるし…
Powerも好きなのかもしれないですね
Re:miはmicrosoftのmiなのか (スコア:1)
いまはOneから360への過渡期じゃないでしょうか？
Re:miはmicrosoftのmiなのか (スコア:2)
Powerが好きなのはMSがっていうより、アメリカ人全般らしいよ。
#PowerBook、PowerVR、Powerbeats、POWER…
ためしてみたらjemallocより2倍遅くなりました (スコア:1)
https://github.com/microsoft/mimalloc/issues/11 [github.com]
MSさぁ…
ChromeやChromiumがデフォルトでtcmallocでビルドするように
おたくの新生Edge？とかいうゴミをこさえる為にだけ使いなよ >>>>mimalloc
Re: (スコア:0)
実際のアプリケーションじゃなくて、特殊なベンチマークテスト持ってこられても・・・って感じのコメントついてるやん
Re: (スコア:0)
そうは読めなかった。mallocはどこかでシステムコールを使わざるを得ないわけだけど、そこがボトルネックになるのは火を見るより明らかだから、避ける努力をしないと。
Re: (スコア:0)
同じ人がHacker Newsにも書き込んでるけど、まともに相手されてない感じ。
https://news.ycombinator.com/item?id=20249743 [ycombinator.com]
「一応確認だけど、メモリ管理部分じゃなくて、アプリ全体が2倍遅くなったっていうの？マジで？」
「ああそうだけど」
（以後コメントなし）
これが2日前。
読み (スコア:1)
へぇ、マイクロソフトだからmy-malloc（マイマロック）かと思ったら、me-malloc（ミーマロック）なんですね。
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)
メモリ共有されてる前提で話してるっぽいので、
その文脈だと番兵処理くらいしか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)
むかし、OSの機能をマイクロプロセッサに取り込もうとして大失敗した石がありましてね
Re: (スコア:0)
インテルの大失敗がありますね、でも昔と今では集積度が全然違います。
PS2でも、DSPをCPU上に搭載しましたが失敗などありません。
あのDSPでも無理すれば書けます、しかしFPUなんか必要ありませんし、整数部は16ビットではなく64bitにして足し算引き算シフトくらいあれば十分です。
Re: (スコア:0)
iAPX 432 とか今の集積度とコンパイラ技術で作れば十分な性能が出せそうだよね。
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みたいなもんは単純コンパクトであるべきかと。
軟弱モノ (スコア:0)
そういえば最後に明示的にmalloc(3)を呼び出すコードを
書いたのっていつだっけ? もう10年以上前のような気が…
# 最近そういう事を考えなくていい言語ばかり使ってる。
Re: (スコア:0)
最近の C++ だと、new/delete もあまり書かないなぁ。
フットプリントが小さくてシンプルでセキュアで高速で… (スコア:0)
だいたいのプログラマーそういうコードを書きたいと思っていても取捨選択による妥協が必要になるわけですが、これは何処を妥協してるんでしょうね
(コード本体が)小さい・シンプル・高速なら２の累乗でドカンとsbrkして使い回す古式ゆかしいmallocが健闘しそうに思えますが
Windows版が作られるのが良いな (スコア:0)
MicrosoftのOSS製品はWindowsや.NET版を作ってくれるのが嬉しい。今までこういうのはだいたい蚊帳の外だったからな。