caching - コンパイル用の RAM ドライブ - そのようなものはありますか?

Question

~~Stack Overflow に関する質問の 1 つに対する回答~~ (以下を参照)から、世界中のコーダーにとってかけがえのない素晴らしいソフトウェアのアイデアが浮かびました。

私は RAM ドライブソフトウェアを想像していますが、決定的な違いが 1 つあります。それは、ハードドライブ上の実際のフォルダーをミラーリングすることです。より具体的には、現在取り組んでいるプロジェクトを含むフォルダーです。このようにして、ビルドはほぼ瞬時に実行されます (または、少なくとも 2 桁高速になります)。RAM ドライブは、アイドル状態のリソースのみを使用して、バックグラウンドでその内容をハードディスクドライブと同期します。

簡単な Google 検索では何もわかりませんでしたが、Google の検索方法がわからないだけかもしれません。おそらく誰かがそのようなソフトウェアを知っていますか? できれば無料ですが、妥当な料金でもかまいません。

追加:最初に破棄したいくつかの解決策が提案されました。それらは次のようになります (順不同):

より高速なハードディスクドライブ ( SSDか 10K RPM) を購入します。ハードウェアソリューションは必要ありません。ソフトウェアが安価になる可能性があるだけでなく (フリーウェアですか?)、ハードウェアの変更が不可能ではないにしても歓迎されない環境 (オフィスなど) でも使用できます。
OS/HDD にキャッシングを任せてください。空き RAM の使用方法を OS/HDD の方がよく知っています。OS/HDD には、すべてをキャッシュし、将来どのデータが最も必要になるかを予測しようとする汎用キャッシュアルゴリズムがあります。彼らは、私にとって優先順位がプロジェクトフォルダーであることを知りません。そして、私たち全員がよく知っているように、とにかくあまりキャッシュしません。;)
周りにはたくさんの RAM ドライブがあります。それらのいずれかを使用します。すみません、それは無謀です。少し空き時間があるときはいつでも、データを HDD に同期する必要があります。停電が発生した場合、最後の 5 分間の作業を失うことは耐えられますが、最後のチェックイン以降のすべてではありません。

追加 2:思いついたアイデア - 通常の RAM ドライブとバックグラウンドフォルダーシンクロナイザーを使用します (ただし、バックグラウンドを意味します)。そのようなことはありますか？

追加 3:興味深い。仕事で単純なRAMドライブを試しました。再構築時間は ~14 秒から ~7 秒 (悪くはない) に短縮されますが、インクリメンタルビルドは依然として ~5 秒です - HDD と同じです。理由はありますか？とを使用aspnet_compilerしaspnet_mergeます。おそらく、彼らは他の場所にある他の一時ファイルで何かをしているでしょうか?

追加 4:ああ、素晴らしい新しい回答セットです! :) OK、否定論者の皆さんにもう少し情報があります。:)

このアイデアの主な理由の 1 つは、上記のソフトウェア (ビルド時間 14 秒) ではなく、当時私がアクセスできなかった別のソフトウェアです。この別のアプリケーションには 100 MB のコードベースがあり、完全なビルドには約 5 分かかります。ああ、それはDelphi 5にあるので、コンパイラはあまり高度ではありません。:) ソースを RAM ドライブに置くと、大きな違いが生じました。1分もかからなかったと思います。私は測定していません。したがって、OS の方がキャッシュをより適切に処理できると言うすべての人にとって、私は異議を唱えたいと思います。

関連する質問:

IDE を高速化するための RAM ディスク

最初のリンクに関する注意: リンク先 の質問は重複しているため削除されました。それは尋ねました：

コードのコンパイル中に何をしますか?

そして、私がリンクしたDmitri Nesterukの答えは次のとおりです。

私はほぼ瞬時にコンパイルします。私のプロジェクトが小さいことと、RAM ディスクを使用していることが原因の 1 つです。

score 20 · Accepted Answer

Linux では (どの OS を使用しているかについて言及したことがないため、これは関連する可能性があります)、RAM からブロックデバイスを作成し、他のブロックデバイス (つまり、HDD) と同じようにマウントできます。

次に、起動/シャットダウン時、および定期的にそのドライブとの間でコピーするスクリプトを作成できます。

~/codeたとえば、とがあるように設定できます~/code-real。~/code起動時にRAM ブロックがマウントされ、 ~/code-real(標準のハードドライブ上にある) すべてがコピーされます。シャットダウンすると、すべてがからにコピーされます ( rsyncの方が高速です) 。また、おそらくそのスクリプトを定期的に実行して、電源障害などの場合に多くの作業を失わないようにすることもできます.~/code~/code-real

私はもうこれを行いません ( 9.5 ベータ版が遅かったときにOperaで使用していましたが、もう必要ありません)。

LinuxでRAMディスクを作成する方法は次のとおりです。

score 16 · Accepted Answer

OS は、この特殊なケースよりもキャッシュのニーズを把握するのに優れていると示唆する人が多いことに驚いています。コンパイルのためにこれを行ったわけではありませんが、同様のプロセスでこれを行い、同期を自動化するスクリプトで RAM ディスクを使用することになりました。

この場合、最新のソース管理システムを使用すると思います。コンパイルのたびに、(必要に応じて実験的なブランチに沿って) ソースコードを自動的にチェックインし、コンパイルのたびにデータが保存されるようにします。

開発を開始するには、RAM ディスクを起動し、現在のベースラインを引き出します。編集、コンパイル、編集、コンパイルなどを行います - 編集が保存されている間ずっと。

満足したら最終チェックインを行ってください。通常のハードディスクドライブを使用する必要さえありません。

しかし、物事を自動化するバックグラウンドシンクロナイザーがあります。問題は、それらもプログラミング用に最適化されておらず、変更を検出するために時々ディレクトリとファイルのフルスキャンを実行する必要がある場合があることです。ソースコード管理システムは、まさにこの目的のために設計されているため、ビルドセットアップに存在していても、オーバーヘッドが低くなる可能性があります。

停電の場合のバックグラウンド同期タスクは未定義であることに注意してください。問題が発生した場合、保存されたものと保存されなかったものを把握する必要があります。定義済みのセーブポイント (コンパイルごと、または手動で強制) を使用すると、少なくともコンパイルできると思っていた状態であることがわかります。VCSを使用すると、以前のコードと簡単に比較して、既に適用した変更を確認できます。

score 7 · Accepted Answer

tmpfsによるemergeの高速化（Gentoo Linux wiki）を参照してください。

GentooでRAMドライブを使用してコンパイルを高速化することは、何十年も前に書かれたハウツーの主題でした。これは、行われたことの具体的な例を提供します。要点は、すべてのソースファイルとビルド中間ファイルがコンパイルのためにRAMディスクにリダイレクトされ、最終的なバイナリがインストールのためにハードドライブにリダイレクトされることです。

また、ソースをハードドライブに保持することを検討することをお勧めしますがgit push、最新のソースは、RAMディスクにあるクローンリポジトリに変更されます。クローンをコンパイルします。お気に入りのスクリプトを使用して、作成されたバイナリをコピーします。

それがお役に立てば幸いです。

score 4 · Accepted Answer

https://wiki.archlinux.org/index.php/Ramdiskを使用してRAMディスクを作成します。

次に、RAMディスクとの間でディレクトリを移動するためのこれらのスクリプトを作成しました。バックアップは、RAMディスクに移動する前にtarファイルで行われます。この方法の利点は、パスが同じままであるため、すべての構成ファイルを変更する必要がないことです。完了したら、を使用uramdirしてディスクに戻します。

編集：バックグラウンドで一定の間隔で与えられたコマンドを実行するCコードを追加しました。変更があればアーカイブを更新するためにtar一緒に送信しています。--update

この汎用ソリューションは、非常に単純なものに対する独自のソリューションを作成するよりも優れていると思います。接吻

パスをrdbackupdに変更してください

ramdir

#!/bin/bash

# May need some error checking for bad input.

# Convert relative path to absolute
# /bin/pwd gets real path without symbolic link on my system and pwd
# keeps symbolic link. You may need to change it to suit your needs.
somedir=`cd $1; /bin/pwd`;
somedirparent=`dirname $somedir`

# Backup directory
/bin/tar cf $somedir.tar $somedir

# Copy, tried move like https://wiki.archlinux.org/index.php/Ramdisk
# suggests, but I got an error.
mkdir -p /mnt/ramdisk$somedir
/bin/cp -r  $somedir /mnt/ramdisk$somedirparent

# Remove  directory
/bin/rm -r $somedir

# Create symbolic link. It needs to be in parent of given folder.
/bin/ln -s /mnt/ramdisk$somedir $somedirparent

#Run updater
~/bin/rdbackupd "/bin/tar -uf $somedir.tar $somedir" &

uramdir

#!/bin/bash

#Convert relative path to absolute
#somepath would probably make more sense
# pwd and not /bin/pwd so we get a symbolic path.
somedir=`cd $1; pwd`;

# Remove symbolic link
rm $somedir

# Copy dir back
/bin/cp -r /mnt/ramdisk$somedir $somedir

# Remove from ramdisk
/bin/rm -r /mnt/ramdisk$somedir

# Stop
killall rdbackupd

rdbackupd.cpp

#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <signal.h>
#include <sys/time.h>

struct itimerval it;
char* command;

void update_archive(int sig)
{
    system(command);
}

int main(int argc, char**argv)
{
    it.it_value.tv_sec     = 1;   // Start right now
    it.it_value.tv_usec    = 0;
    it.it_interval.tv_sec  = 60;  // Run every 60 seconds
    it.it_interval.tv_usec = 0;

    if (argc < 2)
    {
        printf("rdbackupd: Need command to run\n");
        return 1;
    }
    command = argv[1];

    signal(SIGALRM, update_archive);
    setitimer(ITIMER_REAL, &it, NULL); // Start

    while(true);

    return 0;
}

score 3 · Accepted Answer

これは何年も前に4GLマクロコンパイラで行っていました。マクロライブラリとサポートライブラリ、およびコードを RAM ディスクに配置すると、(80286 での) アプリケーションのコンパイルに 20 分から 30 秒かかります。

score 3 · Accepted Answer

私はあなたが探しているものを正確には持っていませんが、現在RamdiskとDRAM ramdiskの組み合わせを使用しています。これは Windows であるため、コアメモリには 3 GB という厳しい制限があります。つまり、RAM ディスクに大量のメモリを使用することはできません。9010 での 4 GB の追加は本当に素晴らしいです。IDE がすべての一時的なものをソリッドステート RAM ディスクとMavenリポジトリに保存できるようにしました。DRAM RAM ディスクには、フラッシュカードへのバッテリバックアップがあります。これは宣伝のように聞こえますが、実際には優れたセットアップです。

DRAM ディスクには 2 つの SATA-300 ポートがあり、ほとんどのテストで平均 0.0 ミリ秒のシークが得られます ;) クリスマスの靴下にいかがですか?

score 2 · Accepted Answer

私も同じ考えを持っていて、いくつかの調査をしました。私はあなたが探していることをする次のツールを見つけました：

しかし、2つ目は64ビットのWindows 7で動作することができず、現時点では維持されていないようです。

一方、VSuiteRAMディスクは非常にうまく機能します。残念ながら、 SSDディスクを装着した状態と比較してパフォーマンスが大幅に向上することは測定できませんでした。

score 2 · Accepted Answer

プロフィール。 各オプションを適切に測定してください。すでに拒否したものを購入し、測定して返品することもできるので、優れたデータから作業していることがわかります。
たくさんのRAMを入手してください。2GBDIMMは非常に安価です。4 GBDIMMは1個あたり100米ドル強ですが、それでも数年前のコンピューター部品の価格と比べるとそれほど多くはありません。最終的にRAMディスクを使用する場合でも、OSに任せる場合でも、これは役に立ちます。32ビットWindowsを実行している場合、3 GB程度を超えるものを使用するには、64ビットに切り替える必要があります。
Live Meshは、ローカルRAMドライブからクラウドまたは別のコンピューターに同期できるため、最新のバックアップが得られます。
コンパイラ出力のみを移動します。ソースコードを実際の物理ディスクに保持しますが、.obj、.dll、および.exeファイルをRAMドライブに作成するように指示します。
DVCSについて考えてみましょう。 実際のドライブからRAMドライブ上の新しいリポジトリにクローンを作成します。すべてのテストに合格するたびに、変更を親に「プッシュ」することがよくあります。

score 2 · Accepted Answer

OS は動作中にメモリにキャッシュします。RAM ディスクの方が高速に見えるかもしれませんが、それは「RAM ディスクへのコピー」と「RAM ディスクからのコピー」の時間を考慮していないためです。RAM を固定サイズの RAM ディスク専用にすることは、キャッシュに使用できるメモリを減らすだけです。OSは、RAMに何が必要かをよりよく知っています。

score 2 · Accepted Answer

はい、同じ問題に遭遇しました。そして、実りのないグーグル検索の後、RAMドライブを遅延バックアップするためのWindowsサービスを作成しました（実際には、RAMドライブはデスクトップなどにマウントできるため、任意のフォルダーです）。

http://bitbucket.org/xkip/transparentbackup フルスキャンの間隔を指定できます (デフォルトは 5 分)。通知されたファイルのみをスキャンする間隔 (デフォルトは 30 秒)。スキャンは、「アーカイブ」属性を使用して変更されたファイルを検出します (OS は、アーカイブ目的で特別にそのファイルをリセットします)。そのように変更されたファイルのみがバックアップされます。

このサービスは、ターゲットバックアップがソースのバックアップとまったく同じであることを確認するために、特別なマーカーファイルを残します。ソースが空で、マーカーファイルが含まれていない場合、サービスはバックアップからの自動復元を実行します。そのため、RAM ドライブを簡単に破棄し、自動データ復元で再度作成することができます。システムの起動時にパーティションを作成できる RAM ドライブを使用して、透過的に動作させることをお勧めします。

私が最近見つけた別のソリューションは、SuperSpeed SuperCacheです。

この会社にもRAMディスクがありますが、それは別のソフトウェアです。SuperCache を使用すると、追加の RAM をブロックレベルのキャッシュ (ファイルキャッシュとは大きく異なります) に使用できます。別のオプションとして、ドライブを RAM に完全にミラーリングできます。どのシナリオでも、ダーティブロックをハードディスクドライブにドロップして戻す頻度を指定できます。これにより、RAM ドライブと同様に書き込みが行われますが、ミラーシナリオでは、RAM ドライブからの読み取りも行われます。たとえば、2 GB (Windows を使用) などの小さなパーティションを作成し、パーティション全体を RAM にマップできます。

このソリューションの興味深い点と非常に便利な点の 1 つは、キャッシュとミラーリングのオプションをいつでも 2 回クリックするだけですぐに変更できることです。たとえば、ゲームや仮想マシン用に 2 GB を取り戻したい場合は、ミラーリングをすぐに停止して、メモリを解放して元に戻すことができます。開いているファイルハンドルも壊れません。パーティションは引き続き機能しますが、通常のドライブとして機能します。

編集: TEMP フォルダーを RAM ドライブに移動することも強くお勧めします。これは、コンパイラーは通常、temp で多くの作業を行うためです。私の場合、コンパイル速度がさらに 30% 向上しました。

score 1 · Accepted Answer

周りにはたくさんの RAMDrive があります。そのうちの 1 つを使用してください。すみません、それは無謀です。

ばかげている RAM ディスクで完全に作業する場合のみ..

疑似シェルスクリプト、ramMake:

# setup locations
$ramdrive = /Volumes/ramspace
$project = $HOME/code/someproject

# ..create ram drive..

# sync project directory to RAM drive
rsync -av $project $ramdrive

# build
cd $ramdrive
make

#optional, copy the built data to the project directory:
rsync $ramdrive/build $project/build

とは言っても、コンパイラは追加のスクリプトなしでこれを実行できる可能性があります。ビルド出力の場所を RAM ディスクに変更するだけです。の："。

score 1 · Accepted Answer

シングルコアマシンでも非常に有益なのは、並列 make です。ディスクI/Oは、ビルドプロセスにおいて非常に大きな要因です。CPU コアごとに 2 つのコンパイラインスタンスを生成すると、実際にパフォーマンスが向上します。1 つのコンパイラインスタンスが I/O でブロックされると、通常、もう 1 つのコンパイラインスタンスがコンパイルの CPU 集中部分に飛び込む可能性があります。

これをサポートするための RAM があることを確認する必要があります (最新のワークステーションでは問題にならないはずです)。

GNU makeでは、生成する同時プロセスの数は-j[n]where isを使用できます。[n]ただし、試す前に依存関係ツリーがあることを確認してください。そうしないと、結果が予測できない場合があります。

本当に便利なもう 1 つのツール (並列 make 方式) はdistccです。これは GCC でうまく動作します (GCC または同様のコマンドラインインターフェイスで何かを使用できる場合)。distcc は実際には、コンパイラのふりをしてリモートサーバー上でタスクを生成することにより、コンパイルタスクを分割します。GCC を呼び出すのと同じ方法で呼び出し、make の -j[n] オプションを利用して多くの distcc プロセスを呼び出します。

私の以前の仕事の 1 つで、かなり集中的な Linux オペレーティングシステムのビルドがあり、しばらくの間ほぼ毎日実行されていました。2 台の専用ビルドマシンを追加し、いくつかのワークステーションに distcc を配置してコンパイルジョブを受け入れることで、完全な OS + ユーザー空間ビルドのビルド時間を半日から 60 分未満に短縮することができました。

コンパイルを高速化するためのツールは他にもたくさんあります。RAM ディスクを作成する以上の調査が必要になる場合があります。OS が RAM を使用してディスクキャッシングを行っているため、ほとんど効果がないように見えます。OS 設計者は、ほとんどのワークロードに適切なキャッシングを行うために多くの時間を費やしています。彼らは（集合的に）あなたより頭がいいので、私は彼らよりうまくやろうとはしません。

RAM ディスク用に RAM を使い切ると、OS がデータをキャッシュしてコードを実行するための作業用 RAM が少なくなります -> そうでない場合よりもスワッピングが多くなり、ディスクパフォーマンスが低下します (注: 完全に破棄する前に、このオプションをプロファイリングする必要があります)。それ）。

score 1 · Accepted Answer

この問題に対する私の最終的な解決策は vmtouch です: https://hoytech.com/vmtouch/ このツールは現在のフォルダーを (RAM) キャッシュにロックし、vmtouch はバックグラウンドでデーモン化します。

sudo vmtouch -d -L ./

これをシェル rc に入れて、すばやくアクセスできるようにします。

alias cacheThis = 'sudo vmtouch -d -L ./'

独自の ramdisk-rsync-script の作成に多くの時間を無駄にしたくなかったので、既製のスクリプトをかなり長い間探しました。重要なコードが含まれていた場合、非常に不快なエッジケースを見逃していたと思います。そして、私は投票のアプローチが好きではありませんでした。

Vmtouch は完璧なソリューションのようです。さらに、固定サイズの ramdisk のようにメモリを浪費しません。1Gig のソース + ビルドフォルダーの 90% が既にキャッシュされているため、ベンチマークは行いませんでしたが、少なくとも高速に感じました ;)

score 1 · Accepted Answer

物理ディスク/パーティションをメンバーとして、RAM のチャンクをメンバーとして持つソフトウェア RAID 1 のようなものを構築できないかと思います。

Linux にこれを実行させるには、ちょっとした微調整といくつかの非常に奇妙な構成が必要になるに違いありません。しかし、それが努力する価値があるとは確信していません。

score 0 · Accepted Answer

発生するディスクの速度低下は主に書き込みであり、ウイルススキャナーが原因である可能性もあります。OSによっても大きく異なる可能性があります。

.o書き込みが最も遅いという考えで、中間（ファイルなど）とバイナリがRAMドライブなどの別の場所に出力を取得するビルドをセットアップしたくなるでしょう。

次に、このbin /中間フォルダーをより高速なメディアにリンクできます（シンボリックリンクまたはNTFSジャンクションポイントを使用）。

score 0 · Accepted Answer

これは、オペレーティングシステムやハードドライブが自動的に処理するディスクキャッシングのように思えます (確かに、パフォーマンスの程度は異なります)。

私のアドバイスは、ドライブの速度が気に入らない場合は、純粋にコンパイル目的で高速ドライブを購入することです。あなたの労力が減り、コンパイルの問題を解決できるかもしれません。

この質問が最初に尋ねられて以来、SSD と比較すると、回転するハードディスクは惨めな亀になっています。これらは、Newegg または Amazon から購入できる SKU で最初に要求された RAM ディスクに非常に近いものです。

score 0 · Accepted Answer

私の頭の上からいくつかのアイデア：

Sysinternals のProcess Monitor ( Process Explorer ではなく) を使用して、ビルド中に何が起こっているかを確認し%temp%ます。たとえば、が使用されているかどうかを確認できます (応答ファイルはおそらく FILE_ATTRIBUTE_TEMPORARY で作成され、可能であればディスクへの書き込みを防ぐ必要があることに注意してください。けれど）。私は自分%TEMP%を RAM ディスクに移動しました。これにより、一般的に若干のスピードアップが得られます。

ディスクイメージの自動ロード/保存をサポートする RAM ディスクを入手してください。これを行うためにブートスクリプトを使用する必要はありません。単一のディスクイメージの順次読み取り/書き込みは、多数の小さなファイルを同期するよりも高速です。

よく使用する/大きなヘッダーファイルを RAM ディスクに配置し、コンパイラの標準パスをオーバーライドして、RAM ドライブのコピーを使用します。ただし、OS が標準ヘッダーをキャッシュするため、初回ビルド後はそれほど改善されない可能性があります。

ソースファイルをハードドライブに保存し、RAM ディスクに同期します。その逆ではありません。フォルダー間のリアルタイム同期を行うには、 MirrorFolderを確認してください- フィルタードライバーを介してこれを実現するため、必要なものだけを同期します (変更のみを行います - 2 GB ファイルへの 4 KB の書き込みは、ターゲットフォルダーへの 4 KB の書き込みのみを引き起こします)。）。ソースファイルがハードディスク上にあるにもかかわらず、 IDEを RAM ドライブからビルドする方法を見つけてください。また、大規模なプロジェクトには大容量の RAM ドライブが必要になることを覚えておいてください。

score -2 · Accepted Answer

James Curran が言うように、ほとんどのプログラムは参照の局所性の法則に従っているため、頻繁に発生するコードとデータのページ数は、時間の経過とともに OS ディスクキャッシュによって管理可能なサイズに縮小されます。

RAM ディスクは、オペレーティングシステムが愚かなキャッシュ (Win 3.x、Win 95、DOS) などの制限付きで構築されている場合に役立ちました。RAM ディスクの利点はほぼゼロであり、大量の RAM を割り当てると、システムキャッシュマネージャーが使用できるメモリが消費され、システム全体のパフォーマンスが低下します。経験則は次のとおりです。カーネルにそれをさせます。これは、「メモリデフラグ」または「オプティマイザ」プログラムと同じです。実際には、これらのプログラムはページを強制的にキャッシュから追い出します (そのため、最終的にはより多くの RAM を取得します)。ページアウトされたコード/データを要求し始めます。

したがって、パフォーマンスを向上させるには、高速ディスク I/O ハードウェアサブシステム、おそらく RAID、高速 CPU、より優れたチップセット (VIA なし!)、物理 RAM などを入手してください。

caching - コンパイル用の RAM ドライブ - そのようなものはありますか?

18 に答える 18

ramdir

uramdir

Related

Reference