MIT のエンジニア チームは、データをより効率的に操作するためのオブジェクト指向メモリ階層を開発しました。 この記事では、それがどのように配置されているかを理解します。
/ /PD
ご存知のとおり、最新の CPU のパフォーマンスの向上には、メモリへのアクセス時の遅延の対応する減少が伴いません。 年ごとの指標の変化の差は最大 10 倍に達する場合があります (）。 その結果、ボトルネックが発生し、利用可能なリソースを最大限に活用できなくなり、データ処理が遅くなります。
パフォーマンス上のペナルティは、いわゆる解凍遅延です。 場合によっては、準備的なデータ解凍に最大 64 プロセッサ サイクルかかることがあります。
比較用: 浮動小数点数の加算と乗算 XNUMXサイクルを超えないでください。 問題は、メモリが固定サイズのデータ ブロックを処理するのに対し、アプリケーションはさまざまな種類のデータを含む可能性があり、サイズが互いに異なるオブジェクトを処理することです。 この問題を解決するために、MIT エンジニアはデータ処理を最適化するオブジェクト指向のメモリ階層を開発しました。
テクノロジーの仕組み
このソリューションは、ホットパッド、ジップパッド、COCO 圧縮アルゴリズムの XNUMX つのテクノロジーに基づいています。
ホットパッドは、スクラッチパッド レジスタ メモリのソフトウェア主導の階層です (）。 これらのレジスタはパッド（パッド）と呼ばれ、L1 から L3 までの XNUMX つがあります。 これらには、さまざまなサイズのオブジェクト、メタデータ、ポインターの配列が格納されます。
本質的に、このアーキテクチャはキャッシュ システムですが、オブジェクトを操作できるように強化されています。 オブジェクトが配置されるパッドのレベルは、オブジェクトが使用される頻度によって異なります。 いずれかのレベルが「オーバーフロー」すると、システムは Java や Go の「ガベージ コレクター」と同様のメカニズムをトリガーします。 どのオブジェクトが他のオブジェクトよりも使用頻度が低いかを分析し、それらのオブジェクトをレベル間で自動的に移動します。
Zippad はホットパッドに基づいて動作し、階層の最後の 3 レベル (LXNUMX パッドとメイン メモリ) に出入りするデータをアーカイブおよび解凍します。 XNUMX 番目と XNUMX 番目のパッドには、データが変更されずに保存されます。
Zippad はオブジェクトを最大 128 バイトまで圧縮します。 大きなオブジェクトはいくつかの部分に分割され、メモリの異なる領域に配置されます。 開発者が書いているように、このアプローチにより、効率的に使用されるメモリの係数が増加します。
オブジェクトを圧縮するには、COCO (Cross-Object COmpression) アルゴリズムが使用されます。これについては後で説明しますが、システムは または 。 COCO アルゴリズムは、差分圧縮のバリエーションです (）。 オブジェクトを「ベース」と比較し、重複するビットを削除します。以下の図を参照してください。
MIT のエンジニアによると、MIT のオブジェクト指向メモリ階層は従来のアプローチより 17% 高速です。 その構造は現代のアプリケーションのアーキテクチャに非常に近いため、新しい方法には可能性があります。
まず、ビッグデータや機械学習アルゴリズムを扱う企業がこのテクノロジーを使い始めることが期待されています。 もう XNUMX つの潜在的な方向性はクラウド プラットフォームです。 IaaS プロバイダーは、仮想化、ストレージ システム、コンピューティング リソースをより効率的に操作できるようになります。
追加のリソースとリソース:
出所： habr.com