在C ++中进行特征分解，我使用例程“zhpev”。此例程嵌入在较大软件的dll文件中，并在运行时期间用尽。在~5000次“zhpev”调用后，我测量了运行时间。对于前900次运行时评估，一切都很好。运行时间约为0.7秒，变化不大。然而，900次运行时评估，运行时间突然从0.7秒增加到2.7秒，且变化很大。
我做了以下观察：
很抱歉，由于我正在使用的项目太大，我无法发布任何代码。
我很感激能帮助我阻止这种奇怪行为的任何暗示！
修改 例程“zhpev”适用于复杂的Hermitian矩阵，其大小为32x32，精度为double。因此，一次处理的数据块相当小。
更新 1）分页不是问题所在。我在系统选项中禁用了分页文件。运行时问题仍未解决。 2）在不同的Windows计算机上运行应用程序也会导致相同的运行时问题。但是，运行时间增加的开始现在在1400运行时评估之后发生。
更新 我发现只有在线程内部调用“zhpev”时才会出现运行时问题。有了这个，我可以创建一个小代码示例，我遇到了同样的问题。
让我解释一下我的代码
这是我的代码
#include <windows.h>
#include <tchar.h>
#include <strsafe.h>
#include "stdafx.h"
#include "mkl_lapack.h"
#include "mkl_service.h"
#include <time.h>
#include <stdio.h>
#include <iostream>
#include <fstream>
#include <stdlib.h>
#include <iostream>
using namespace std;
#define CACHE_LINE 32
#define CACHE_ALIGN __declspec(align(CACHE_LINE))
#define MAX_THREADS 2
#define BUF_SIZE 255
DWORD WINAPI MyThreadFunction( LPVOID lpParam );
void ErrorHandler(LPTSTR lpszFunction);
// !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
// This is the critical function.
void Eigendecomposition();
// !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
typedef struct MyData {
int val1;
int val2;
} MYDATA, *PMYDATA;
int _tmain()
{
PMYDATA pDataArray[MAX_THREADS];
DWORD dwThreadIdArray[MAX_THREADS];
HANDLE hThreadArray[MAX_THREADS];
std::ofstream ofs;
double tstart;
double tend;
double proc_time_pure;
for(int j=0;j<10000;j++){
// Start one iteration
tstart = clock();
// Create MAX_THREADS worker threads.
for( int i=0; i<MAX_THREADS; i++ )
{
pDataArray[i] = (PMYDATA) HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY,
sizeof(MYDATA));
if( pDataArray[i] == NULL )
{
ExitProcess(2);
}
pDataArray[i]->val1 = i;
pDataArray[i]->val2 = i+100;
// Create the thread to begin execution on its own.
hThreadArray[i] = CreateThread(
NULL, // default security attributes
0, // use default stack size
MyThreadFunction, // thread function name
pDataArray[i], // argument to thread function
0, // use default creation flags
&dwThreadIdArray[i]); // returns the thread identifier
if (hThreadArray[i] == NULL)
{
ErrorHandler(TEXT("CreateThread"));
ExitProcess(3);
}
} // End of main thread creation loop.
// Wait until all threads have terminated.
WaitForMultipleObjects(MAX_THREADS, hThreadArray, TRUE, INFINITE);
for(int i=0; i<MAX_THREADS; i++)
{
CloseHandle(hThreadArray[i]);
if(pDataArray[i] != NULL)
{
HeapFree(GetProcessHeap(), 0, pDataArray[i]);
pDataArray[i] = NULL; // Ensure address is not reused.
}
}
tend = clock();
proc_time_pure = tend-tstart;
// Print processing time into console and write it into a file
printf(" Processing time: %4.3f \n", proc_time_pure/1000.0);
ofs.open ("Processing_time.txt", std::ofstream::out | std::ofstream::app);
ofs << proc_time_pure/1000.0 << " ";
ofs.close();
}
return 0;
}
DWORD WINAPI MyThreadFunction( LPVOID lpParam )
{
HANDLE hStdout;
PMYDATA pDataArray;
TCHAR msgBuf[BUF_SIZE];
size_t cchStringSize;
DWORD dwChars;
hStdout = GetStdHandle(STD_OUTPUT_HANDLE);
if( hStdout == INVALID_HANDLE_VALUE )
return 1;
pDataArray = (PMYDATA)lpParam;
// !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
// Critical function
Eigendecomposition();
// !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
return 0;
}
void ErrorHandler(LPTSTR lpszFunction)
{
// Retrieve the system error message for the last-error code.
LPVOID lpMsgBuf;
LPVOID lpDisplayBuf;
DWORD dw = GetLastError();
FormatMessage(
FORMAT_MESSAGE_ALLOCATE_BUFFER |
FORMAT_MESSAGE_FROM_SYSTEM |
FORMAT_MESSAGE_IGNORE_INSERTS,
NULL,
dw,
MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),
(LPTSTR) &lpMsgBuf,
0, NULL );
// Display the error message.
lpDisplayBuf = (LPVOID)LocalAlloc(LMEM_ZEROINIT,
(lstrlen((LPCTSTR) lpMsgBuf) + lstrlen((LPCTSTR) lpszFunction) + 40) * sizeof(TCHAR));
StringCchPrintf((LPTSTR)lpDisplayBuf,
LocalSize(lpDisplayBuf) / sizeof(TCHAR),
TEXT("%s failed with error %d: %s"),
lpszFunction, dw, lpMsgBuf);
MessageBox(NULL, (LPCTSTR) lpDisplayBuf, TEXT("Error"), MB_OK);
// Free error-handling buffer allocations.
LocalFree(lpMsgBuf);
LocalFree(lpDisplayBuf);
}
void Eigendecomposition(){
const int M = 32;
typedef MKL_Complex16 double_complex;
const char jobz = 'V';
const char uplo = 'L'; // lower triangular part of input matrix is used
const MKL_INT dim = M;
const MKL_INT ldz = M;
const MKL_INT LWORK = (2*M-1);
const MKL_INT LRWORK = (3*M-2);
MKL_INT info = 0;
double_complex A_H_MKL[(M*M+M)/2];
CACHE_ALIGN double_complex work[LWORK];
CACHE_ALIGN double rwork[LRWORK];
double D[M];
double_complex U[M][M];
for(int i=0;i<500;i++ ){
// Create the input matrix
for (int tmp=0; tmp < (M*M+M)/2; tmp++){
A_H_MKL[tmp].real = 1 ;
A_H_MKL[tmp].imag = 0;}
// This is the mkl function
zhpev(&jobz, // const char* jobz,
&uplo, // const char* uplo,
&dim, // const MKL_INT* n,
(double_complex *)&A_H_MKL[0], // double_complex* ap,
(double *)&D[0], // double* w,
(double_complex *)&U[0][0], // double_complex* z,
&ldz, // const MKL_INT* ldz,
work, // double_complex* work,
rwork, // double* rwork,
&info); // MKL_INT* info
}
}
答案 0 :(得分：0)
因为我缺乏细节，所以我只能尝试给出一般答案。我已经在我的评论中提到内存碎片可能导致更长的运行时间周期。同样，缓存可能会成为软件执行过程中的瓶颈。您的应用程序的其他部分如何运作？他们还会大量处理数据吗？
Stackoverflowers已经在许多线程中讨论过缓存主题。阅读例如What is cache friendly code。我认为有些帖子非常有用，可能会帮助您理解您的问题。
答案 1 :(得分：0)
正如诺曼纽斯已经说过的，如果没有真正看到你的代码和zhpev的实现，很难猜出可能是什么问题。但是，除了内存碎片和缓存问题之外，问题可能与Hermitian矩阵的属性有关。
从我所读到的关于zhpev的内容来看，毫无疑问它是基于一些迭代的数值分析方法。因此，根据所使用方法的属性，zhpev收敛所需的时间（迭代次数）可能会根据输入矩阵的属性而变化很大。
其他矩阵属性的原因可能是zhpev手头有几种数值方法，并且基于输入矩阵分析，它选择能够最好地利用它的属性来更快地计算它。
您声明输入数据对性能问题没有影响，但是您能确定吗？在计算过程中，你的Hermitian矩阵不会以某种方式发展吗？是否可以在每次使用相同的矩阵并比较结果时间的同时获取zhpev以及实际的特征值计算？ （当然，你需要确保它不会被优化）
答案 2 :(得分：0)
我在代码中发现了这个错误。我在使用windows函数CreatThread创建的线程中运行eigendecomposition例程。但是，没有函数来结束线程，例如WaitForMultipleObjects-routine。对于我的应用程序的所有其他部分，这不是问题，但特征分解遇到困难。