パスワードを忘れた? アカウント作成
13942721 story
プログラミング

Microsoft、高速なmallocを公開 82

ストーリー by hylom
普及するか 部門より

Microsoftが、汎用な高速メモリアロケータという「mimalloc」をオープンソースで公開した(GitHubのmimallocページマイナビニュース)。ライセンスはMITライセンス。

特徴として、コード行数が少なく、セキュアであること、高速であることなどが挙げられている。アーキテクチャ的にはメモリを小さいリストで管理したり、不要になったメモリをすぐに解放するといった方針でデザインされているそうだ。

対応OSはWindowsおよびmacOS、Linux、BSD等となっている。

  • by nnnhhh (47970) on 2019年06月25日 13時31分 (#3639917) 日記

    マイクロソフトはXが好きだからxmallocにしたかっただろうに
    もう取られちゃってんだなぁ

    ここに返信
  • by Anonymous Coward on 2019年06月25日 14時30分 (#3639959)

    https://github.com/microsoft/mimalloc/issues/11 [github.com]

    MSさぁ…
    ChromeやChromiumがデフォルトでtcmallocでビルドするように
    おたくの新生Edge?とかいうゴミをこさえる為にだけ使いなよ >>>>mimalloc

    ここに返信
    • by Anonymous Coward

      実際のアプリケーションじゃなくて、特殊なベンチマークテスト持ってこられても・・・って感じのコメントついてるやん

      • by Anonymous Coward

        そうは読めなかった。mallocはどこかでシステムコールを使わざるを得ないわけだけど、そこがボトルネックになるのは火を見るより明らかだから、避ける努力をしないと。

      • by Anonymous Coward

        同じ人がHacker Newsにも書き込んでるけど、まともに相手されてない感じ。

        https://news.ycombinator.com/item?id=20249743 [ycombinator.com]

        「一応確認だけど、メモリ管理部分じゃなくて、アプリ全体が2倍遅くなったっていうの?マジで?」
        「ああそうだけど」
        (以後コメントなし)

        これが2日前。

  • by minet (45149) on 2019年06月25日 18時44分 (#3640162) 日記

    mimalloc (pronounced "me-malloc")

    へぇ、マイクロソフトだからmy-malloc(マイマロック)かと思ったら、me-malloc(ミーマロック)なんですね。

    ここに返信
  • メモリーも大量に使えるようになってきたので・・・
    最小確保単位が128byteととかでなく1024byteとかでも問題なくなり始めている、そこで
    ガベコレもmallocも、専用CPUを1つ搭載して、各種処理を裏側でやってしまうと良いのではと思っている。
    大半のオブジェクトやスタックフレームを格納できる程度のサイズ(1024byte程度)を、バックグラウンドで100個くらい確保してあらかじめ溜め込んでおく。
    そして、malloc要求が来たら、1024byte以下のサイズを要求された場合、あらかじめ確保しておいたメモリーの先頭番地を返すだけ、それ以上のサイズの要求が来たらソフトウェア処理、これで見かけ上1clockで実行する形にする。
    free要求が来たら、とりあえず解放キューに追加する、これもバックグラウンドで解放していく。
    専用CPUは1つで十分、どうせマルチCPUで処理するとしても lock 処理をして同時に1CPUしか実行できないのだから、メモリー管理用の1CPUにリクエストを投げ込んでも一緒だから。
    スタックフレームの確保もSPレジスタを使うのではなく malloc によって確保して統一的にしてしまえばと思い始めています。

    ここに返信
    • by Anonymous Coward

      仮想記憶について勉強してから
      出直した方がいいですよ

      • by Anonymous Coward

        ページングサイズを小さくするという考えですか?
        オーバーヘッドが大きくて実用性がないんじゃないですかね
        もしくは大量のCAMを搭載するという事になるんでしょうが、こんどは消費電力がヤバイ事になりそうな予感。

        • by Anonymous Coward

          あなたが言っていることが理解できません

          判ることは以下の3点だけです
          - あなたの文章は原理を説明できてない
          - あなたはOSの仕組み,例えば仮想記憶の仕組み(ページテーブルのハードウェアとか)や,ユーザ空間とカーネル空間の違いを理解してない
          - スタックが1024byte単位でOKとか,基本的に考え方が30年ぐらい古い

          • 私にはあなたの言っている事の方がよくわからないです
            今回の話は本質的には仮想記憶があってもなくても関係ないですし、「仮想記憶について勉強してから」と書かれたので仮想記憶を利用したmallocを提案しているのかな?と思ってこう返答しました、私は普通に仮想記憶もページングの仕組みも知っています。
            そもそもmallocに仮想記憶とか意味不明でしたから、そんなものそもそもmallocには必要ないですよね?

            1024byteとかいったのは、多くのオブジェクトがそのくらいのサイズがあれば良くて、スタックフレーム(要するにサブルーチン内で使われた自動変数の全体、実態は構造体みたいな仕組みになっている)、ここにある変数のサイズも極端に大きいという事はなく多くのオブジェクトと同一サイズ程度だなぁと書いていて思うわけ。
            そして、あらかじめ確保して待機させておくなら、速度的にもメモリスラッシング対策的にもサイズは統一しておいた方が良いなという事で、1024byteとか書いてみた。
            実際には多くのコードで統計を取って、8割型の class や スタックフレーム(サブルーチンの自動変数)が収まるようなサイズに決定すればと思う。
            足りなければ普通のアルゴリズムでmallocするのであって、スタックが1024byte以外許さないとかいう話ではないです。

    • by Anonymous Coward

      ハードウェアでメモリ確保というと68000系のLINK/UNLINK命令のこと、、、じゃなかったのか。
      # SP移動するだけだが。

      > スタックフレームの確保もSPレジスタを使うのではなく malloc によって確保して統一的にしてしまえばと思い始めています。

      コルーチンあるやつは、だいたいこうなってない?

      • by Anonymous Coward

        スタックフレームをスタック上に確保すると、再帰をするコードで簡単にスタックがあふれます。
        メモリー容量も増えたので・・・と、スタックサイズを大きくしようと考えると、こんどはスレッド毎にスタックが必要なので、昨今のマルチCPUを生かしたコードだと余りうれしくない事態になります。
        そこで、スタックフレームをヒープ上に確保できれば、再帰型のコードを書きやすくなりますが、スタック上に確保するのは現行非常に高速ですから、その利点を捨ててまでヒープ上にスタックフレームを確保したいとは思えません。
        しかし1Clockでヒープが確保できるとすれば・・・これは有りかなと。

        • by Anonymous Coward

          何を言ってるのかわからん。
          プロセス単位で保護が効くから他のプロセスとメモリ空間を共有したりしないし。
          プロテクトモードが無い時代の話か?

          • by Anonymous Coward

            マルチスレッドプログラミングをすると、当然スレッドを複数確保します。
            スタックは、各スレッドにそれぞれ指定の最大容量が必要です。
            スタックは非常に深いネストを作らない限り殆ど消費されません、再帰コードの為だけに確保するとすればそれは膨大な無駄となります。
            ですから、現行のプログラムでは、LISPのような再帰前提の言語でもなければ極度に深い再帰はできません。自前でスタックを実装する必要が生じます。
            しかし、ヒープに確保できればCのような言語でもLISPのような深い再帰コードを書く事が可能になります。

            • by Anonymous Coward

              別にスレッド毎にスタックサイズ1GiB割り当ててもかまわんでしょ。
              物理メモリが固定で割り当てられるわけじゃないし。

              • by Anonymous Coward

                > 物理メモリが固定で割り当てられるわけじゃないし。

                同感です

                多分この方は,カーネル側のメモリ管理(仮想メモリと実メモリの対応づけ)と
                ユーザ側のメモリ管理(今回のタレコミはこっち側の話)が区別できていません

                基礎知識が足りてないので,これ以上まともな話をするのは無理でしょう

              • by Anonymous Coward

                64bitでVirtual Addressに問題ないとしても、スタックをdedaultで広げるのと、
                間違って無限たらい回し関数とか作ったときに、すぐに気づけないし
                stack overflowする前にスラッシングしたりして被害が広がるよ。

        • by Anonymous Coward

          > そこで、スタックフレームをヒープ上に確保できれば、再帰型のコードを書きやすくなりますが、スタック上に確保するのは現行非常に高速ですから、その利点を捨ててまでヒープ上にスタックフレームを確保したいとは思えません。

          だから、コルーチンとか扱うときは、今もそうなってるよねって話でしょ。
          名称は「スタックフレーム」のままでも、関数から戻ったとか、呼び元が終了したって、その関数が終了したわけじゃないので「スタック」ではないんだから。

    • by Anonymous Coward

      むかし、OSの機能をマイクロプロセッサに取り込もうとして大失敗した石がありましてね

      • by Anonymous Coward

        インテルの大失敗がありますね、でも昔と今では集積度が全然違います。
        PS2でも、DSPをCPU上に搭載しましたが失敗などありません。
        あのDSPでも無理すれば書けます、しかしFPUなんか必要ありませんし、整数部は16ビットではなく64bitにして足し算引き算シフトくらいあれば十分です。

        • by Anonymous Coward

          iAPX 432 とか今の集積度とコンパイラ技術で作れば十分な性能が出せそうだよね。

    • by Anonymous Coward

      排他制御ですごく遅くなるよそれ

      • by Anonymous Coward

        普通のmallocでも排他制御は必要不可欠ですよ
        ちなみに、このあらかじめ確保しておいたメモリを返すだけなら、メモリ管理処理CPUをコプロセッサ的に汎用CPUと繋いでしまえばなんと排他制御不要できます。

        • by Anonymous Coward

          マルチスレッドの排他制御が遅いってんで、排他制御の少ないjemallocが出てきた
          コプロでやるならメモリバリアが必要だ
          トーシロは黙っとけ

          • by Anonymous Coward

            >コプロでやるならメモリバリアが必要だ
            要りませんよ、専用1CPUでメモり管理を全部やるんだから、他のCPUから管理情報をアクセスする必要などハナから無いので。

            • by Anonymous Coward

              専用1CPUでやるからシングルスレッドでしか動かなくて、排他制御なんてわざわざ用意するまでもなくハードウェアが他のプロセスを待たせてくれるんですね、わかります。
              それロックかかってるのと同じで全く速くない

    • by Anonymous Coward

      そもそもmallocを使うのは、ハードウェアに制限がある場合でしょ
      専用CPUなんて搭載する予算なんかないよ

    • by Anonymous Coward

      ロック処理をして 1CPU しか同時に実行できない、というのは間違っていて、
      いまどきは標準の malloc でも複数 CPU からメモリーを確保できます。

      • by Anonymous Coward

        それでも数千命令程度のコードを通過するでしょう。
        スタックフレームの変数を確保するのにそのmallocは使いたくない。
        目標は一命令で即時確保です。
        スタックにスタックフレーム確保する速度と同等なレベルのパフォーマンスが欲しい。
        そこまで行けば、世界が広がるから。

    • by Anonymous Coward

      そういうのは拡張機能やフレームワークあたりでやるべきで、mallocみたいなもんは単純コンパクトであるべきかと。

  • by Anonymous Coward on 2019年06月25日 15時17分 (#3639990)

    そういえば最後に明示的にmalloc(3)を呼び出すコードを
    書いたのっていつだっけ? もう10年以上前のような気が…

    # 最近そういう事を考えなくていい言語ばかり使ってる。

    ここに返信
    • by Anonymous Coward

      最近の C++ だと、new/delete もあまり書かないなぁ。

  • だいたいのプログラマーそういうコードを書きたいと思っていても取捨選択による妥協が必要になるわけですが、これは何処を妥協してるんでしょうね
    (コード本体が)小さい・シンプル・高速なら2の累乗でドカンとsbrkして使い回す古式ゆかしいmallocが健闘しそうに思えますが

    ここに返信
  • by Anonymous Coward on 2019年06月25日 17時56分 (#3640128)

    MicrosoftのOSS製品はWindowsや.NET版を作ってくれるのが嬉しい。今までこういうのはだいたい蚊帳の外だったからな。

    ここに返信
typodupeerror

皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー

読み込み中...