デバイスの大容量記憶装置のパフォーマンスは、記録されたファイルの内容に依存しますか？ コンピューティングシステムの外部メモリの実装に関する独占が磁気ディスクドライブに属していたとき、そのような質問は奇妙に思えます。 明らかに、このようなデバイスでは、ファイル転送時間はそのサイズと断片化によって決定され、デバイスに追加の位置決めを強制します。 また、ファイルシステムレベルでデータのアーカイブまたは暗号化を実行するソフトウェアドライバーを考慮せずに、ハードウェアのパフォーマンスのみを取り上げる場合、コンテンツへの速度の依存の理由はありません。 SSDはどうですか？
Non-Blocking I / O exchange technologyを使用してjavaアプリケーションを作成することにより、この質問に対する答えを見つけようとしました。 その結果、
NIOBenchが登場しました
。NIOBenchを使用すると、さまざまなインターフェースを備えた磁気メディアおよびソリッドステートメディアの
ベンチマークを取得でき
ます。実際、外部ドライブ（おそらく、読み取り専用アクセス
規則を持つデバイスを除き、独自の計画もあります）
開発プロセス中に、テストスクリプトを決定する必要があるときに多くの状況が発生しました。 作業時間は実験室の壁の中に残し、テストパターンの選択などの重要な側面について詳しく説明します。 たとえば、AS SSDに実装されているため、ヒューリスティックな方法を使用する理由はありませんでした。実際、これは渡されたものの繰り返しです。 あなたのオプションを探すことにしました。 彼のプレゼンテーションに進む前に、少し退屈な思い出。
ゼロおよび1つの要因
ソリッドステートドライブで使用される最新の不揮発性フラッシュメモリチップには、ストレージマトリックスのプログラミングプロセスを最適に制御する独自の記録マシンが組み込まれています。 このようなチップの内部には、プログラマーの読み取り専用メモリ（ROM）のロジックの主要部分があります。 この状況は、電子デバイスをコンパクトにするだけでなく、メーカーの知的財産を保護し、チップを「ブラックボックス」に変えます。
したがって、明確にするために、電気的プログラミング、紫外線消去、2キロバイトの容量を備えた「アンティーク」なマイクロ回路を検討します。 明らかに、30年前のデバイスは現代のものとは大きく異なりますが、多くの物理的な原理と効果はその関連性を保持しています。
図 1 チップインターフェイスには、アドレス、データ、制御、電源のラインが含まれていますご存知のように、このようなチップを消去すると、メモリセルは0FFhまたは「すべてのユニット」に設定されます。 値が0FFhでなければならないバイトは、単に書き込むことができません。 さらに、バイトの書き込みに必要なプログラミングパルスの数および（または）持続時間は、このバイトのゼロと1の数の比率に依存します。 したがって、記録時間はデータに依存します。 記録されたデータの単位よりもゼロがはるかに多い場合、デバイス開発者はデータを逆形式で保存することを決定し、記録時間だけでなく、チップの寿命を節約し、消費電力の一部（微視的ではありますが）を節約することに注意してください。
圧縮係数
情報を
アーカイブするドライブは、ホストインターフェイスとフラッシュメモリアレイ間で実行されるデータストリームを分析および変換するアルゴリズムを必ず使用する必要があります。
これは、もちろん、デバイス開発者がこの効果を意図的に平準化しない限り、
エントロピーに応じてデータ処理時間が異なることを意味します。
NIOBenchテスト
NIOBenchベンチマークのバージョンv0.42では、テストパターン（コピーされたファイル）を擬似ランダムデータで埋めるためのスクリプトが実装されています。 デフォルトでは、ゼロはプレースホルダーとして使用されます。
2種類の乱数ジェネレーターがサポートされています。
- プログラムによるクラスメソッドjava.util.Random
- オプションでプロセッサがサポートするハードウェア、 RDRAND命令
RDRAND命令がサポートされていない場合、またはこのOSのネイティブライブラリがない場合、ハードウェアRNGオプションはアクティブになりません-ゼロフィルモードで、または擬似乱数でテストパターンを生成するソフトウェアでベンチマークを実行できます。
データオプションは、次の3つのテスト方法のいずれかを選択します。
- ゼロ -テストファイルをゼロで埋める
- ソフトウェアRNG（ランダム番号ジェネレーター） -java.util.Randomクラスのメソッドによってプログラムで取得された擬似ランダムデータでテストファイルを埋める
- ハードウェアRNG -RDRANDマシン命令を使用してハードウェアで受信した擬似ランダムデータでテストファイルを埋める
モード1および2は、すべてのプラットフォームでサポートされています。 プロセッサがRDRAND命令とこのOSのネイティブライブラリの存在をサポートしている場合、モード3がサポートされます。 このバージョンには、Windows 32/64用のネイティブライブラリがあります。 Linuxでは、RDRAND命令のサポートも計画されています。
ネイティブライブラリは、実行可能JARアーカイブの一部としてパッケージ化されます。 アセンブラーで記述されたプロシージャーであるJavaアプリケーションへの接続は、
JNI （
Java Native Interface ）仕様に基づいています。
結果について
テスト操作中、NIOBenchユーティリティウィンドウの上部のテーブルに結果が表示されます。 ベンチマーク統計は、平均速度、最小速度、および最大速度の列に投稿されます。 読み取り、書き込み、コピーの
中央値が行ごとに表示され、同じ操作を実行するプロセスで得られた平均値が表示されます。
ユーザーは、ベンチマーク実行のテキストレポートを保存できます。 [
カウント]フィールドで指定された各反復の結果を詳細に表示します。 中央値の計算に関係するデータには、文字「
M 」が付いています。
テストスクリプトを開発するときのタスクは、ドライブ（または一部のデータストレージシステムで可能なファイルAPIよりも低いレベルで動作するデータアーカイブスキーム）のパフォーマンスとそのデータへの依存を排他的に測定することでした。 この場合、結果の乱数ジェネレータ自体のパフォーマンスへの依存を除外する必要があります。 したがって、テストデータの配列は、測定動作中ではなく、アプリケーションの開始時に一度入力されます。 テスト方法を選択する[データ]オプションの状態に応じて、3つの事前準備された配列（ゼロ、ソフトRNG、ハードRNG）のいずれかが使用されます。 テストデータは1メガバイトの周期で繰り返されます。
開発およびデバッグ技術
Javaアプリケーションの作成とデバッグは、NetBeans 8.1で行われます。 アセンブラーライブラリはFASM Editor 2.0で記述され、Flat Assembler 1.71.49を使用して翻訳されます。 32ビットのアセンブラコードのデバッグは、OllyDbg v2.01で実行されます。 64ビットのアセンブラーコードのデバッグはFDBG v0025で実行されます。