请看下方更新
当运行Fortran代码时,我发现系统CPU使用率很高。"用户CPU使用率"占用了大约一个核(系统是运行Linux的Intel i7,有4个核心/ 8个线程),而系统CPU却占用了大约2个核心(因此总CPU使用率约为75%)。有人能解释一下这是从哪里来的,以及这是否是"正常"行为吗?
我使用gfortran编译代码(优化关闭-O0,尽管这部分似乎并不重要),并链接BLAS、LAPACK和一些(其他)C函数。我的代码本身没有使用任何并行化,链接的代码也没有(据我所知)。至少我没有使用任何并行化的库版本。
代码本身涉及组装和求解有限元系统,并使用了大量(?)的分配和内置函数调用(matmul,dot_product),尽管总体RAM使用率非常低(约200MB)。我不知道这些信息是否足够/有用,但我希望有人知道那里出了问题。
此致敬礼, Ben
更新 我认为我已经追踪到(部分)问题,它来自于LAPACK中DSYEV的调用(计算实对称矩阵A的特征值,在我的情况下是3x3)。
program test
implicit none
integer,parameter :: ndim=3
real(8) :: tens(ndim,ndim)
integer :: mm,nn
real(8), dimension(ndim,ndim):: eigvec
real(8), dimension(ndim) :: eigval
character, parameter :: jobz='v' ! Flags calculation of eigenvectors
character, parameter :: uplo='u' ! Flags upper triangular
integer, parameter :: lwork=102 ! Length of work array
real(8), dimension(lwork) :: work ! Work array
integer :: info
tens(1,:) = [1.d0, 2.d0, 3.d0]
tens(2,:) = [2.d0, 5.d0, 1.d0]
tens(3,:) = [3.d0, 1.d0, 1.d0]
do mm=1,5000000
eigvec=tens
! Call DSYEV
call dsyev(jobz,uplo,ndim,eigvec,ndim,eigval,work,lwork,info)
enddo
write(*,*) eigvec
write(*,*) int(work(1))
endprogram test
编译和链接是通过以下方式完成的
gfortran test.f90 -o test -llapack
这个程序占用了我很高的%sys CPU使用率。有人能够验证一下吗?(显然LAPACK是运行代码所必需的)这是“正常”的情况还是我的代码/系统/库出了问题...? 更新2 受@roygvib评论的鼓舞,我在另一个系统上运行了代码。在第二个系统上,无法复现高CPU sys使用率。比较这两个系统,我似乎找不到这个问题的根源。它们都运行相同的操作系统版本(Linux Ubuntu),相同的gfortran版本(4.8),内核版本,LAPACK和BLAS。唯一的“主要”区别是:有缺陷的系统的处理器是i7-4770,而另一个系统是i7-870。在有缺陷的系统上运行测试代码给我%user 16s和%sys 28s。在i7-870上,它是%user 16s%sys 0s。将代码运行四次(并行运行)使每个进程的总时间分别为在另一个系统上的约18s和在有缺陷的系统上的约44s。
有什么其他措施可以寻找问题? 更新3 我认为我们正在接近: 在另一个系统上构建测试程序,并与LAPACK和BLAS库进行静态链接,
gfortran test.f90 -O0 /usr/lib/liblapack.a /usr/lib/libblas.a -Wl,--allow-multiple-definition
在有漏洞的系统上运行该代码,可以得到约为0的%sys时间(正如所期望的那样)。另一方面,在有漏洞的系统上使用静态链接到LAPACK和BLAS的测试程序并在另一个系统上运行代码会返回高CPU使用率。因此,很明显,这些库似乎存在差异,对吗? 在有漏洞的系统上构建静态版本会导致文件大小约为18MB,而在另一个系统上只有100KB。此外,我必须包含
。-Wl,--allow-multiple-definition
只需在另一台系统上运行命令(否则会抱怨 xerbla 的多重定义),而在出现故障的系统上,我必须(明确地)链接到 libpthread
gfortran test.f90 -O0 /usr/lib/liblapack.a /usr/lib/libblas.a -lpthread -o test
有趣的是,
apt-cache policy liblapack*
对于这两个系统,它们返回相同的版本和repo目的地(libblas*也是如此)。还有其他的想法吗?也许有其他命令可以检查库版本,我不知道吗?
nmon
开发人员的评论:https://dev59.com/V1bTa4cB1Zd3GeqP-Wvg#5738139。如果没有重现问题的方法,这个问题很可能会被视为离题(尽管它可能很有趣)。祝你好运。 - shellter