Luchian explica por qué ocurre este comportamiento, pero pensé que sería una buena idea mostrar una posible solución a este problema y, al mismo tiempo, mostrar un poco acerca de los algoritmos de caché inconsistente.
Su algoritmo básicamente hace:
for (int i = 0; i < N; i++)
for (int j = 0; j < N; j++)
A[j][i] = A[i][j];
que es simplemente horrible para una CPU moderna. Una solución es conocer los detalles sobre su sistema de caché y modificar el algoritmo para evitar esos problemas. Funciona muy bien siempre que sepa esos detalles ... no especialmente portátil.
¿Podemos hacer algo mejor que eso? Sí se puede: Un enfoque general para este problema son cache oblivious algorithms que, como su nombre lo dice evita depender de tamaños de caché específicos [1]
La solución se vería así:
void recursiveTranspose(int i0, int i1, int j0, int j1) {
int di = i1 - i0, dj = j1 - j0;
const int LEAFSIZE = 32; // well ok caching still affects this one here
if (di >= dj && di > LEAFSIZE) {
int im = (i0 + i1)/2;
recursiveTranspose(i0, im, j0, j1);
recursiveTranspose(im, i1, j0, j1);
} else if (dj > LEAFSIZE) {
int jm = (j0 + j1)/2;
recursiveTranspose(i0, i1, j0, jm);
recursiveTranspose(i0, i1, jm, j1);
} else {
for (int i = i0; i < i1; i++)
for (int j = j0; j < j1; j++)
mat[j][i] = mat[i][j];
}
}
un poco más compleja, pero una prueba corta muestra algo bastante interesante en mi antigua E8400 con el lanzamiento de VS2010 x64, testcode para MATSIZE 8192
int main() {
LARGE_INTEGER start, end, freq;
QueryPerformanceFrequency(&freq);
QueryPerformanceCounter(&start);
recursiveTranspose(0, MATSIZE, 0, MATSIZE);
QueryPerformanceCounter(&end);
printf("recursive: %.2fms\n", (end.QuadPart - start.QuadPart)/(double(freq.QuadPart)/1000));
QueryPerformanceCounter(&start);
transpose();
QueryPerformanceCounter(&end);
printf("iterative: %.2fms\n", (end.QuadPart - start.QuadPart)/(double(freq.QuadPart)/1000));
return 0;
}
results:
recursive: 480.58ms
iterative: 3678.46ms
edición: Acerca de la influencia del tamaño: es mucho menos pronunciada aunque todavía apreciable en algún grado, eso se debe a que estamos utilizando la solución iterativa como un nodo hoja en lugar de recurrir a 1 (la optimización habitual para los algoritmos recursivos). Si establecemos LEAFSIZE = 1, la memoria caché no tiene ninguna influencia para mí [8193: 1214.06; 8192: 1171.62ms, 8191: 1351.07ms
- eso está dentro del margen de error, las fluctuaciones están en el área de 100 ms; este "punto de referencia" no es algo con lo que estaría demasiado cómodo si quisiéramos valores completamente precisos])
[1] Fuentes para esto: Bueno, si no puede obtener una conferencia de alguien que trabajó con Leiserson y co en esto ... Supongo que sus documentos son un buen punto de partida. Esos algoritmos todavía se describen muy raramente: CLR tiene una sola nota al pie sobre ellos. Aún así es una gran manera de sorprender a la gente.
Editar (nota: yo no soy el que ha escrito esta respuesta, sólo quería añadir este):
Aquí hay un completo en C++ versión del código anterior:
template<class InIt, class OutIt>
void transpose(InIt const input, OutIt const output,
size_t const rows, size_t const columns,
size_t const r1 = 0, size_t const c1 = 0,
size_t r2 = ~(size_t) 0, size_t c2 = ~(size_t) 0,
size_t const leaf = 0x20)
{
if (!~c2) { c2 = columns - c1; }
if (!~r2) { r2 = rows - r1; }
size_t const di = r2 - r1, dj = c2 - c1;
if (di >= dj && di > leaf)
{
transpose(input, output, rows, columns, r1, c1, (r1 + r2)/2, c2);
transpose(input, output, rows, columns, (r1 + r2)/2, c1, r2, c2);
}
else if (dj > leaf)
{
transpose(input, output, rows, columns, r1, c1, r2, (c1 + c2)/2);
transpose(input, output, rows, columns, r1, (c1 + c2)/2, r2, c2);
}
else
{
for (ptrdiff_t i1 = (ptrdiff_t) r1, i2 = (ptrdiff_t) (i1 * columns);
i1 < (ptrdiff_t) r2; ++i1, i2 += (ptrdiff_t) columns)
{
for (ptrdiff_t j1 = (ptrdiff_t) c1, j2 = (ptrdiff_t) (j1 * rows);
j1 < (ptrdiff_t) c2; ++j1, j2 += (ptrdiff_t) rows)
{
output[j2 + i1] = input[i2 + j1];
}
}
}
}
Tu código se ve poco amigable para la caché. – CodesInChaos
@CodeInChaos y lo es. –
Es más o menos el mismo problema que esta pregunta: http://stackoverflow.com/questions/7905760/matrix-multiplication-small-difference-in-matrix-size-large-difference-in-timi – Mysticial