En nuestra aplicación, nos estamos ejecutando en un servidor dual Xeon con memoria configurada como 12 gb local para cada procesador y un bus de memoria que conecta los dos Xeon. Por razones de rendimiento, queremos controlar dónde asignamos un bloque de memoria grande (> 6 gb). A continuación se muestra el código simplificado:Tiempo de acceso a la memoria lento con VirtualAllocExNuma en Windows 7/64
DWORD processorNumber = GetCurrentProcessorNumber();
UCHAR nodeNumber = 255;
GetNumaProcessorNode((UCHAR)processorNumber, &nodeNumber);
// get amount of physical memory available of node.
ULONGLONG availableMemory = MAXLONGLONG;
GetNumaAvailableMemoryNode(nodeNumber, &availableMemory)
// make sure that we don't request too much. Initial limit will be 75% of available memory
_allocateAmt = qMin(requestedMemory, availableMemory * 3/4);
// allocate the cached memory region now.
HANDLE handle = (HANDLE)GetCurrentProcess();
cacheObject = (char*) VirtualAllocExNuma (handle, 0, _allocateAmt,
MEM_COMMIT | MEM_RESERVE ,
PAGE_READWRITE| PAGE_NOCACHE , nodeNumber);
El código como está, funciona correctamente con VS2008 en Win 7/64.
En nuestra aplicación este bloque de memoria funciona como una memoria caché para objetos estáticos (1-2mb ea) que normalmente se almacenan en el disco duro. Mi problema es que cuando transferimos datos al área de caché usando memcpy, lleva> 10 veces más tiempo que si asignamos memoria usando new char[xxxx]. Y ningún otro código cambia.
No entendemos por qué sucede esto. ¿Alguna sugerencia sobre dónde mirar?
No. Eso no es lo que pretendía. Pensé que el almacenamiento en memoria caché de disco de la memoria bloqueada, no CPU. Eso solucionó la mayoría de mis problemas de rendimiento. Gracias. –