静态和动态仪器的优缺点
有许多静态和动态仪表工具。 Soot 是 Java 字节码的静态检测工具。 Pin 和 Valgrind 是二进制文件的动态检测工具。
静态和动态仪器工具的优缺点是什么？我认为静态检测工具在运行时性能方面更好，而动态工具更强大。请比较一下他们的能力和表现。
另外，使用检测工具与编写 LLVM pass 有什么区别？
There are many static and dynamic instrumentation tools. Soot is a static instrumentation tool for Java bytecode. Pin and Valgrind are dynamic instrumentation tools for binaries.
What are pros and cons for static and dynamic instrumentation tools? I think static instrumentation tools are better in terms of runtime performance, whereas dynamic tools are more powerful. Please compare them in terms of ability and performance.
Plus, what is the difference using instrumentation tools from writing LLVM pass?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
静态仪器的优点是分析不依赖于输入。分析发生在原始代码上，包括代码的所有路径。全覆盖。这种类型的检测通常会重写二进制文件，以便在运行时不需要另一个进程来执行。这也意味着代码将运行得很快，唯一的开销来自注入的代码。静态检测的缺点是由于缺乏运行时信息而导致分析不详细，因此有时很难实现您的目标。
另一方面，动态检测确实包含代码运行时的每个细节和信息。在大多数情况下，执行动态检测的工具很容易编写。另一方面，由于执行路径依赖于给定的输入，因此无法实现完整的代码覆盖。此外，需要附加外部进程并对原始进程进行检测这一事实也会使事情变得更慢。
AFAIC，LLVM pass 用于静态检测，因为生成的代码是在编译时生成的，并且已经写入最终的二进制文件中，并且肯定包括静态检测技术的所有优点和缺点。
总而言之，这取决于您需要什么。您应该为您的工作选择正确的工具。
The pros of static instrumentation is the fact that the analysis is not dependent on the input. The analysis happens on the original code and includes all paths of the code. Full coverage. This type of instrumentation usually rewrites the binary which is ready for execution without the need of another process at run-time. That also means that the code will run fast, with the only overhead coming from the injected code. The drawback of static instrumentation is the not detailed analysis which is caused due to the lack of run-time information and because of that, sometimes is very difficult to achieve your goals.
On the other side, dynamic instrumentation does includes every detail and information during the run-time of the code. In the most cases, the tools that perform dynamic instrumentation are easy to write. On the other hand, isn't able to achieve full code coverage due to the fact that the execution path is dependent on the inputs given. Also the fact that there's a need for an external process to be attached and instrument the original one makes things slower.
AFAIC, LLVM passes are used for static instrumentation, because the code generated is at compile time and is already written in the final binary and for sure includes all the pros and cons of static instrumentation techniques.
To conclude, it's a matter of what you need. You should choose the right tool for your job.
我假设需要发现需要大量时间的代码，并且您可以对其进行优化以节省时间。这与仅仅计时例程是不同的目标。
我对静态分析器持怀疑态度，因为一切都取决于输入数据组合。
动态仪器尝试测量函数的属性，例如：自身时间和总时间、绝对时间、平均值和百分比。还有调用计数以及每个例程在调用图中的角色。
动态检测（a href="https://stackoverflow.com/questions/1777556/alternatives-to-gprof/1779343#1779343">gprof）已成为-几十年来的事实标准，但它远非最终定论。一方面，重要的是要认识到它为您提供的大多数统计数据都没有抓住您最初的需求。
如今（恕我直言）您需要一个采样分析器来对调用堆栈进行采样，而不仅仅是程序计数器。它应该根据挂钟时间进行采样，而不仅仅是 CPU 时间。不需要以高频率抽取样本。当应用程序等待用户输入时，它应该抑制采样。它应该为您提供行或指令级别的信息，而不仅仅是功能级别的信息。它应该为您提供的一行代码的最重要的统计数据是包含该代码行的样本的百分比，因为这是对该行进行优化后可以节省的时间的最直接衡量标准。
一些分析器可以做到这一点，特别是 Oprofile 和 RotateRight/Zoom。
I'm assuming the need is to discover code that takes significant time and that you could optimize to save that time. That is a different goal from just timing routines.
I'm skeptical of static analyzers because everything depends on the input data mix.
Dynamic instrumentation tries to measure properties of functions, such as: self time and total time, absolute, average, and percent. Also call counts, and each routine's role in the call graph.
Dynamic instrumentation (a la gprof) has been the de-facto standard for decades, but it is very far from being the last word. For one thing, it is important to realize that most of the statistics it gives you are missing the point in terms of your original need.
These days (IMHO) you need a sampling profiler that samples the call stack, not just the program counter. It should sample on wall-clock time, not just CPU time. Samples need not be drawn at high frequency. It should suppress sampling when the app is waiting for user input. It should give you information at the line or instruction level, not just the function level. The most important statistic it should give you for a line of code is the percentage of samples containing it, because that is the most direct measure of the time that can be saved if that line is optimized.
A few profilers can do this, Oprofile and RotateRight/Zoom in particular.