剖析我的代码开放源代码和第三方代码封闭源代码的内存使用情况的最佳策略

问题描述

| 我很快将要负责对用C / C ++编写并使用CUDA来利用GPU处理的代码进行适当的内存配置。 我最初的想法是创建宏和运算符重载，这将使我能够跟踪源代码中对malloc，free，delete和new调用的调用。我将能够包括一个不同的标头，并使用

__FILE__ and __LINE__

宏将内存调用打印到日志文件中。可以在以下位置找到这种策略：http://www.almostinfinite.com/memtrack.html 在第三方库中跟踪链接使用情况的最佳方法是什么？我假设我只能跟踪函数调用前后的内存使用情况，对吗？在我的宏/超载场景中，我可以简单地跟踪请求的大小以找出所需的内存量。我怎么能知道第三方库使用了多少？根据我的理解，跟踪“免费”并不能真正让您了解在任何特定时间使用了多少代码，因为它不一定会返回给操作系统。感谢您对此事的讨论。 我真的不想使用诸如Totalview或valgrind之类的任何内存分析工具，因为它们通常会执行许多其他事情（边界检查等），这似乎会使软件运行非常缓慢。这样做的另一个原因是，我希望它在某种程度上是线程安全的-该软件使用我认为可以生成进程的MPI。我将尝试实时进行分析，以便可以转出日志文件或其他进程可以读取的文件，以在软件运行时可视化内存使用情况。这也将主要在linux环境中运行。 谢谢     

解决方法

        也许valgrind和Massif工具？     ,        要跟踪Linux上我的程序的实时内存消耗，我只需阅读ѭ1。这是一个相当轻巧的操作，如果您要跟踪的第三方库进行了后续工作，则在您的情况下可以忽略不计。如果您想在第三方库工作期间获得内存信息，则可以将“ 2”文件读入独立线程或其他进程中。 （内存峰值很少在函数调用之前或之后追加！） 对于CUDA / GPU，我认为gDEBugger可以为您提供帮助。我不确定，但是内存分析仪不会对性能产生太大影响。     ,        您可以尝试使用Google \的PerfTools \'堆分析器： http://google-perftools.googlecode.com/svn/trunk/doc/heapprofile.html 它非常轻巧；它实际上替换了malloc / calloc / realloc / free以添加检测代码。它主要在Linux平台上进行了测试。 如果您使用调试符号进行编译，并且您的第三方库带有debug-version变体，则PerfTools应该做得很好。如果您没有调试符号库，则无论如何都应使用调试符号来构建代码。它将为您提供代码的详细编号，所有剩余的内容都可以作为第三方库的属性。     ,        如果您不想使用“外部”工具，则可以尝试使用以下工具： 跟踪 它为malloc，realloc和free安装处理程序，并将每个操作记录到文件中。有关代码用法示例，请参见我列出的Wikipedia。 dmalloc 这是一个可以在代码中使用的库，它可以发现内存泄漏，一次性错误和无效地址的使用。您也可以在编译时使用-DDMALLOC_DISABLE禁用它。 无论如何，我宁愿不采用这种方法。相反，我建议您在valgrind（或任何等效工具）下的测试服务器上运行应用程序时，尝试对应用程序进行压力测试，并确保您正在正确地进行内存分配，然后让应用程序在不检查任何内存分配的情况下运行最大限度地提高生产速度。但是，实际上，这取决于您的应用程序做什么以及您的需求是什么。     ,        也许链接器选项--wrap = symbol可以为您提供帮助。真正好的例子可以在这里找到： 人     ,        您可以使用Visual Studio 2010 Premium和Ultimate中包含的探查器。 它允许您在不同的性能评估方法之间进行选择，最可能对您有用的是CPU采样，因为它可以在任意时间间隔冻结程序并找出当前正在执行的功能，从而不会使程序运行速度大大降低。     ,我相信这个问题有两个非常不同的答案。一种用于C / C ++领域。还有一秒钟用于CUDA土地。 在CPU上： 我已经为自己的new和Delete编写了替代品。他们非常缓慢，并没有太大帮助。我已经使用了totalview。我喜欢TotalView进行OpenMP调试，但是我同意进行内存调试非常慢。我从未尝试过valgrind。我听说过类似的事情。 我遇到的唯一值得调试的内存调试工具是Intel Parallel Inspector的Memory Checker。注意：由于我是学生，所以能够以便宜的价格获得教育许可证。也就是说，这太神奇了。我花了十二分钟才发现内存泄漏被掩埋在五十万行代码中-我没有释放抛出的错误对象，而该错误对象却被我捕获并忽略。我非常喜欢这个软件，以至于当我的raid失败/ Win 7吞噬了我的计算机（想同时进行自动更新和raid重建）时，我停止了一切并重建了计算机，因为我知道重建双启动将花费更少的时间（48小时）以外的其他方式来查找内存泄漏。如果您不相信我的古怪说法，请下载评估版。 在GPU上： 我觉得你不走运。对于CUDA中的所有内存问题，我基本上不得不自行开发自己的工具和3 around等周围的包装器。这不是很漂亮。 nSight确实为您提供了一些东西，但在这一点上，仅是“这是您现在已经分配了多少权限”而已。在此令人遗憾的是，我使用CUDA遇到的几乎每个性能问题都是直接取决于我的内存访问模式（即我的线程块大小）。