带文件镜像的 ramdisk

发布于 2024-07-13 19:19:27 字数 259 浏览 8 评论 0原文

我想加快编译速度,所以我想我可以让我的文件构建在 ramdisk 上,但也可以将其自动刷新到文件系统,并在没有足够的 ram 时使用文件系统。

对于我正在编写的应用程序,我可能需要类似的东西,我希望将文件缓存在 RAM 中并刷新到 FS 中。 我有什么选择? 是否已经存在这样的东西? (也许是保险丝?)该应用程序是一个玩具应用程序(目前),我需要重复编译 C++ 代码。 众所周知,当在进行之前需要解决特定问题时,编译所需的时间就越长。 我们能完成的事情就越少。

I wanted to speed up compilation so i was thinking i could have my files be build on a ramdisk but also have it flushed to the filesystem automatically and use the filesystem if there is not enough ram.

I may need something similar for an app i am writing where i would like files to be cached in ram and flushed into the FS. What are my options? Is there something like this that already exist? (perhaps fuse?) The app is a toy app (for now) and i would need to compile c++ code repeatedly. As we know, the longer it takes to compile when there is a specific problem to solve before progressing. the less we can get done.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

悲欢浪云 2024-07-20 19:19:27

Ram 磁盘的文件系统缓存也走上了渡渡鸟的道路。 它可以比静态缓存做出更好的决策,了解其他程序对 RAM 的使用情况以及磁盘写入头的位置。 惰性回写是免费的。

Ram-disks went the way of the dodo with the file system cache. It can make much better decisions than a static cache, having awareness of RAM usage by other programs and the position of the disk write head. The lazy write-back is for free.

彼岸花似海 2024-07-20 19:19:27

编译受 CPU 限制,而不是磁盘限制。 如果您使用适当的构建标志来利用所有 CPU 内核,则可以轻松地在典型 PC 上使它们饱和。 除非你有某种超级计算机,否则我认为这不会加快速度太多。

对于 VS2008,此标志为 /MP 。 它也存在于 VS2005 上。

Compilation is CPU-bound, not disk bound. If you utilize all your CPU cores using the appropriate build flag, you can easily saturate them on typical PCs. Unless you have some sort of supercomputer, I don't think this will speed things up much.

For VS2008 this flag is /MP. It also exists on VS2005.

久伴你 2024-07-20 19:19:27

不确定它是否有助于回答大约 12 年前的问题,但现在我正在寻找一些软件来同步文件系统或目录来做到这一点。
这两个答案都是正确的,从某种意义上说,文件系统缓存将尝试预测您需要什么并在 RAM 中提供可用的内容,并且一般来说,构建软件有利于大量的多线程处理,可能会最大化您的 CPU。 但现在我正在使用 Unity 进行构建,并且无法控制构建优化。

也就是说,虚拟 RAM 磁盘具有优势,因为这些文件始终位于 RAM 中,这与必须处理竞争磁盘访问的资源和应用程序的文件系统缓存 (FSC) 不同。

另一个区别是,当应用程序关闭文件句柄或强制同步时,FSC 将尝试尽快将该文件获取到磁盘,以避免出现问题(电源故障等)。 我相信你可以改变 Linux 上的 FSC 行为。
同步到 RAM 磁盘不会写入磁盘,这可能是造成您在评论中所说的性能差异的原因。

也就是说,我仍然需要寻找一些东西来自动同步我的两个文件系统!

Not sure it helps answering a question from almost 12 years ago, but just now I was looking for some software to sync file systems or directories to do exactly that.
Both answers are correct, in the sense that the file system cache will attempt to predict what you need and make available in RAM, and, generally, building a software benefits a lot of multithreading, possibly maxing out your CPU. But right now I'm building with Unity and I don't have control over build optimization.

That said, a virtual RAM disk has advantages, because those files are always in RAM, different from file system cache (FSC) that has to deal with resources and applications competing for disk access.

Another difference is that when an application closes a file handle or forces a sync, FSC will attempt to get that files as soon as possible to the disk, in order to avoid problems (power failure and so on). I believe you can alter the FSC behavior on Linux.
A sync to a RAM disk does not write to disk, that may be responsible for the difference of performance you said in your comment.

That said, I still need to look for something to auto-sync my two file systems!

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文