アカウント名:
パスワード:
最初、データベースソフト等データの一貫性が必要なソフト向けに、ファイルシステムやキャッシュとかすっ飛ばしてRawアクセスするAPIとおもったら、想像とまったく違うAPIだった
FSCTL_MARK_HANDLEとFSCTL_GET_RETRIEVAL_POINTERS使えば昔から可能なことだそれはMS製品がとっくにやってることなんだからさhttps://techcommunity.microsoft.com/t5/failover-clustering/cluster-sha... [microsoft.com]
WindowsでRawアクセスが可能なこと自体は正しいけど、FSCTL_MARK_HANDLEとFSCTL_GET_RETRIEVAL_POINTERSはどこから出てきたの?あなたの貼ったリンク先には一言も説明されていないし、どちらも明らかにファイルシステムを意識する機能なんだけど https://docs.microsoft.com/en-us/windows/win32/api/winioctl/ni-winioct... [microsoft.com] https://docs.microsoft.com/en-us/windows/win32/api/winioctl/ni-winioct... [microsoft.com]
Windowsでは単にボリューム自体をファイルのように開くことでRaw
ファイルシステム上のファイル対してファイルシステムを介さずにアクセスするのにこれらを使う
RAWボリュームは可搬性が悪いのでWindows向けソフトでは普通は使わない
ファイルが連続していなくてフラグメンテーション起こしていたら厄介それはどうするんだろうそれと、1レベルくらいは仮想化入っているよね# シリンダ・トラック・セクタでアクセス?
(あえてDirectStorageの説明はよまない)
わかった、あれだ、CPUをバスリクエストで止めてDMAで一気に読み込み/書き込みをするんだな。
そこで緑電子がボードを開発して・・・
すでにこのAPIを使ったDBの高速化案件がウォーミングアップを始めてるに違いない
> ファイルシステムやキャッシュとかすっ飛ばしてRawアクセスするAPIとおもったら、
それは「ダイレクト・アクセス」ってやつで、太古の昔からある概念では?
アプリケーションの起動を加速するとして昔流行ったReadyBoostのDirectX版といったところだ。ReadyBoostではログを解析して先読みによる自動制御だったが、DirectStorageは必要なデータを一番知っているのはアプリだというところからアプリがより細かく制御できるようになっている点が進歩といったところだろう。
ということは、HDDにゲームをインストールしていた場合には効果絶大だが、そもそもゲームをSSDにインストールしていた場合には効果がそれほどでもないのかな。まあ、ゲームアプリが巨大化しているし、HDDにインストールしていてもSSDによる高速化の恩恵を得られるなら、便利だろう。
何も考えずに同期読み込み、みたいな感じにはならないのか
RTX IOの類https://ascii.jp/elem/000/004/025/4025926/をDirect X経由で扱えるようにしたついでにNVMeのような高IOPSのストレージに最適化したって感じではないかと。アプリケーションの動作を高速化するのもIO処理の改善で実現するのも一緒ですが後は全然別物ですな。ReadyBoostはメモリにデータをキャッシュする方式だけどDirectStorageはメインメモリを経由しないので。NVMeみたいな高IOPSストレージってahciとかSATAみたいな低IOPSを前提にした制御方式と相性悪いんですよね。制御がボトルネックになっちゃうから。ゲーム以外で相性が良さそうなのはCG制作GPGPUですかね。んでもってGPGPUといえばまいにんぐ〜。
DB用では、NVDIMM-Nで不揮発メモリにDBを置いてRawアクセスする方法が別途ある。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり
DB用APIかとおもった (スコア:0)
最初、データベースソフト等データの一貫性が必要なソフト向けに、
ファイルシステムやキャッシュとかすっ飛ばしてRawアクセスするAPIとおもったら、
想像とまったく違うAPIだった
Re:DB用APIかとおもった (スコア:1)
FSCTL_MARK_HANDLEとFSCTL_GET_RETRIEVAL_POINTERS使えば昔から可能なことだそれは
MS製品がとっくにやってることなんだからさ
https://techcommunity.microsoft.com/t5/failover-clustering/cluster-sha... [microsoft.com]
Re: (スコア:0)
WindowsでRawアクセスが可能なこと自体は正しいけど、FSCTL_MARK_HANDLEとFSCTL_GET_RETRIEVAL_POINTERSはどこから出てきたの?
あなたの貼ったリンク先には一言も説明されていないし、どちらも明らかにファイルシステムを意識する機能なんだけど
https://docs.microsoft.com/en-us/windows/win32/api/winioctl/ni-winioct... [microsoft.com]
https://docs.microsoft.com/en-us/windows/win32/api/winioctl/ni-winioct... [microsoft.com]
Windowsでは単にボリューム自体をファイルのように開くことでRaw
Re:DB用APIかとおもった (スコア:1)
ファイルシステム上のファイル対してファイルシステムを介さずにアクセスするのにこれらを使う
RAWボリュームは可搬性が悪いのでWindows向けソフトでは普通は使わない
Re: (スコア:0)
ファイルが連続していなくてフラグメンテーション起こしていたら厄介
それはどうするんだろう
それと、1レベルくらいは仮想化入っているよね
# シリンダ・トラック・セクタでアクセス?
Re: (スコア:0)
(あえてDirectStorageの説明はよまない)
わかった、あれだ、CPUをバスリクエストで止めてDMAで一気に読み込み/書き込みをするんだな。
Re:DB用APIかとおもった (スコア:1)
Re: (スコア:0)
そこで緑電子がボードを開発して・・・
Re: (スコア:0)
すでにこのAPIを使ったDBの高速化案件がウォーミングアップを始めてるに違いない
Re: (スコア:0)
> ファイルシステムやキャッシュとかすっ飛ばしてRawアクセスするAPIとおもったら、
それは「ダイレクト・アクセス」ってやつで、太古の昔からある概念では?
ReadyBoostのDirectX版 (スコア:0)
アプリケーションの起動を加速するとして昔流行ったReadyBoostのDirectX版といったところだ。
ReadyBoostではログを解析して先読みによる自動制御だったが、DirectStorageは必要なデータを一番知っているのはアプリだというところからアプリがより細かく制御できるようになっている点が進歩といったところだろう。
Re: (スコア:0)
ということは、HDDにゲームをインストールしていた場合には効果絶大だが、そもそもゲームをSSDにインストールしていた場合には効果がそれほどでもないのかな。まあ、ゲームアプリが巨大化しているし、HDDにインストールしていてもSSDによる高速化の恩恵を得られるなら、便利だろう。
Re: (スコア:0)
HDDにゲームをインストールしてる場合は関係ない
SSDにインストールされている場合に高速化する
要は
1) メインメモリを経由せず直接VRAMにデータを送る
2) 圧縮ファイルの解凍処理をCPUじゃなくてGPUでやる
の2点がメリットで
HDDの場合はセクタの割り出し待ちでどうせCPU時間はヒマしてるからその間にやればいいだけだけど、SSDだと瞬速で読み出せちゃうんでそんなことにCPU使わずにGPUでやりたいって話。
Re: (スコア:0)
何も考えずに同期読み込み、みたいな感じにはならないのか
Re: (スコア:0)
RTX IOの類https://ascii.jp/elem/000/004/025/4025926/をDirect X経由で扱えるようにしたついでにNVMeのような高IOPSのストレージに最適化したって感じではないかと。
アプリケーションの動作を高速化するのもIO処理の改善で実現するのも一緒ですが後は全然別物ですな。
ReadyBoostはメモリにデータをキャッシュする方式だけどDirectStorageはメインメモリを経由しないので。
NVMeみたいな高IOPSストレージってahciとかSATAみたいな低IOPSを前提にした制御方式と相性悪いんですよね。制御がボトルネックになっちゃうから。
ゲーム以外で相性が良さそうなのはCG制作GPGPUですかね。んでもってGPGPUといえばまいにんぐ〜。
NVDIMM-N (スコア:0)
DB用では、NVDIMM-Nで不揮発メモリにDBを置いてRawアクセスする方法が別途ある。