p******e
发帖数: 528 | 1 比方说我有一个在单机上运行的并行程序，我想知道制约这个程序速度的瓶颈是在
CPU的运算速度还是内存读写速度。请问有没有什么测试程序能告诉我它的瓶颈
在哪里。 |
d*******3
发帖数: 6550 | 2 你是想测第三方软件还是你自己写的？
第三方的话最简单的就是看资源管理器cpu和内存占用的变化咯 |
p******e
发帖数: 528 | 3 主要还是第三方的，我还没有想过怎么自己去写这个测试的步骤。我用linux的环境。我
试过用i7z，这是一个测试CPU load的程序。当我运行一个瓶颈在内存的程序的时候。
我可以看到CPU不总是100%的占满。但是当我用top或者htop的时候，就看不到这个现象。
所以我觉得用top看到的不一定准确。其实我想知道有没有什么一般的规则，比方说如果
一个程序的数据吞吐量很大的话，（远大于CPU cache的size），那么这个程序的瓶颈
几乎就肯定是在内存方面。
【在 d*******3 的大作中提到】
: 你是想测第三方软件还是你自己写的？
: 第三方的话最简单的就是看资源管理器cpu和内存占用的变化咯
|
y**b
发帖数: 10166 | 4 除了top，free看内存消耗很管用
一旦swap大了，不仅程序性能急剧下降，系统都可能失去反应 |
d***a
发帖数: 13752 | 5 你说的要求，包含了两个不同的概念：一个是内存够不够大，另一个是内存访问是不是
瓶颈。
前者可以通过top看到，内存不够大会产生很多I/O访问，系统层的CPU占用率就低。CPU
占用率100%，只是说这个程序没有太多的I/O，内存是足够大了。
后者可以用performance counter monitor工具来看CPI和内存访问频率。一个占用CPU
100%的程序，也有可能CPI极低，时间都花在内存访问上了。
。我
象。
如果
【在 p******e 的大作中提到】
: 主要还是第三方的，我还没有想过怎么自己去写这个测试的步骤。我用linux的环境。我
: 试过用i7z，这是一个测试CPU load的程序。当我运行一个瓶颈在内存的程序的时候。
: 我可以看到CPU不总是100%的占满。但是当我用top或者htop的时候，就看不到这个现象。
: 所以我觉得用top看到的不一定准确。其实我想知道有没有什么一般的规则，比方说如果
: 一个程序的数据吞吐量很大的话，（远大于CPU cache的size），那么这个程序的瓶颈
: 几乎就肯定是在内存方面。
|
u**n
发帖数: 44 | 6 On linux, you may run oprofile to profile your program to understand time
consumed by your functions.
Also see this:
https://www.akkadia.org/drepper/cpumemory.pdf
【在 p******e 的大作中提到】
: 比方说我有一个在单机上运行的并行程序，我想知道制约这个程序速度的瓶颈是在
: CPU的运算速度还是内存读写速度。请问有没有什么测试程序能告诉我它的瓶颈
: 在哪里。
|
p******e
发帖数: 528 | 7
CPU
我知道我运行的程序所用的内存没有超过机器的内存大小，因为我用htop看过，
硬盘上的swap空间确实是没有被动用过。但是由于程序用的数据量比较大，
做过分析的人告诉我说实际上CPU在很大的时间内是在等待和内存交换数据，
所以升级CPU对于性能的提升有限。
CPU
我找到了一些分析的程序，像perf，glances。不过看了得仔细的看说明来学一下这些
工具
怎么用.
【在 d***a 的大作中提到】
: 你说的要求，包含了两个不同的概念：一个是内存够不够大，另一个是内存访问是不是
: 瓶颈。
: 前者可以通过top看到，内存不够大会产生很多I/O访问，系统层的CPU占用率就低。CPU
: 占用率100%，只是说这个程序没有太多的I/O，内存是足够大了。
: 后者可以用performance counter monitor工具来看CPI和内存访问频率。一个占用CPU
: 100%的程序，也有可能CPI极低，时间都花在内存访问上了。
:
: 。我
: 象。
: 如果
|
p******e
发帖数: 528 | 8 多谢。我回来学一学这个oprofile怎么使用。
【在 u**n 的大作中提到】
: On linux, you may run oprofile to profile your program to understand time
: consumed by your functions.
: Also see this:
: https://www.akkadia.org/drepper/cpumemory.pdf
|
u**n
发帖数: 44 | 9 Then you may revisit your algorithm and data structure, make it cache
friendly. There are also prefetch instructions which might help hide memory
access latency.
【在 p******e 的大作中提到】
: 多谢。我回来学一学这个oprofile怎么使用。
|
d***a
发帖数: 13752 | 10 是这样。用top看到CPU占用率100%，只是说程序没有浪费时间在I/O上。用top是看不到
内存系统性能的。
如前所说，要用performance counter monitor工具来看内存访问频率和CPI。perf可以
。glances和top类似，不是做这个用的。
【在 p******e 的大作中提到】
: 多谢。我回来学一学这个oprofile怎么使用。
|
j*****I
发帖数: 2626 | 11 用top或者类似的看virtual page.如果virtual page一直太大，可能是这个app耗内存
，或者内存管理有问题。内存问题最后多多少少会引起swap,看page fault number.
至于CPU运算速度，我觉得你想的说的是程序的算法效率或者复杂度相对于CPU的问题？
这个通过简单的用系统的工具看指标我觉得意义不是很大。
【在 p******e 的大作中提到】
: 比方说我有一个在单机上运行的并行程序，我想知道制约这个程序速度的瓶颈是在
: CPU的运算速度还是内存读写速度。请问有没有什么测试程序能告诉我它的瓶颈
: 在哪里。
|
