アカウント名:
パスワード:
もうストレージこんだけ速くてデカい時代になってるんだからさ全部メモリマップドIOにしてOSやハードウェアが裏でごにょごにょやってくれる方が楽じゃね？
読み込みはともかく書き込みはどうすんだよ
memory mapped I/O って、普通は uncached にするので目に見えて遅くなります。framebuffer なんかはさすがに遅すぎるってんで uncached じゃなくて write-combined にしますが、それでもちょっと遅い。
HPE の The Machine の場合、大量のノードから共有されるんで、単純に cached にすると memory consistency を保つためのプロトコルでネットワークが飽和しちゃって実用的性能出せないような。だからといってアプリ側で明示的に cache flush / invalidate した時だけアクセスするようにすると、それって read/writeと同じじゃんってことになりそうでメリットが薄れますね。
なるほど、ありがとうございます。ググったらhttps://lwn.net/Articles/655437/ [lwn.net]が出てきました。
こんな感じhttps://github.com/FabricAttachedMemory/libfam-atomic/blob/3362941b36a... [github.com]でアクセスするんですね。使いものになる性能出すためにはこれが現実的なアプローチだけど、メモリマップしてアクセスするという言葉で想像するのとはだいぶ違うプログラミングスタイルだなあ。
分散メモリをMPIみたいなメッセージパッシング式のプログラミングスタイルで使うのと比べて性能面でどうなのか気になるところです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ見習い
そろそろファイルやめよう (スコア:0)
もうストレージこんだけ速くてデカい時代になってるんだからさ
全部メモリマップドIOにしてOSやハードウェアが裏でごにょごにょやってくれる方が楽じゃね？
Re: (スコア:0)
読み込みはともかく書き込みはどうすんだよ
Re: (スコア:0)
memory mapped I/O って、普通は uncached にするので目に見えて遅くなります。
framebuffer なんかはさすがに遅すぎるってんで uncached じゃなくて write-combined にしますが、それでもちょっと遅い。
HPE の The Machine の場合、大量のノードから共有されるんで、単純に cached にすると memory consistency を保つための
プロトコルでネットワークが飽和しちゃって実用的性能出せないような。
だからといってアプリ側で明示的に cache flush / invalidate した時だけアクセスするようにすると、それって read/writeと
同じじゃんってことになりそうでメリットが薄れますね。
Re:そろそろファイルやめよう (スコア:1)
そこが新規性なの
Re:そろそろファイルやめよう (スコア:1)
なるほど、ありがとうございます。
ググったら
https://lwn.net/Articles/655437/ [lwn.net]
が出てきました。
こんな感じ
https://github.com/FabricAttachedMemory/libfam-atomic/blob/3362941b36a... [github.com]
でアクセスするんですね。
使いものになる性能出すためにはこれが現実的なアプローチだけど、メモリマップしてアクセスするという言葉で想像するのとはだいぶ違うプログラミングスタイルだなあ。
分散メモリをMPIみたいなメッセージパッシング式のプログラミングスタイルで使うのと比べて性能面でどうなのか気になるところです。