Aquí hay un fragmento de código C ++ que muestra un comportamiento muy peculiar. Por alguna extraña razón, ordenar los datos milagrosamente hace que el código sea casi seis veces más rápido:
#include <algorithm>
#include <ctime>
#include <iostream>
int main()
{
// Generate data
const unsigned arraySize = 32768;
int data[arraySize];
for (unsigned c = 0; c < arraySize; ++c)
data[c] = std::rand() % 256;
// !!! With this, the next loop runs faster.
std::sort(data, data + arraySize);
// Test
clock_t start = clock();
long long sum = 0;
for (unsigned i = 0; i < 100000; ++i)
{
// Primary loop
for (unsigned c = 0; c < arraySize; ++c)
{
if (data[c] >= 128)
sum += data[c];
}
}
double elapsedTime = static_cast<double>(clock() - start) / CLOCKS_PER_SEC;
std::cout << elapsedTime << std::endl;
std::cout << "sum = " << sum << std::endl;
}- Sin
std::sort(data, data + arraySize);, el código se ejecuta en 11.54 segundos. - Con los datos ordenados, el código se ejecuta en 1.93 segundos.
Inicialmente, pensé que esto podría ser solo una anomalía de lenguaje o compilador, así que probé Java:
import java.util.Arrays;
import java.util.Random;
public class Main
{
public static void main(String[] args)
{
// Generate data
int arraySize = 32768;
int data[] = new int[arraySize];
Random rnd = new Random(0);
for (int c = 0; c < arraySize; ++c)
data[c] = rnd.nextInt() % 256;
// !!! With this, the next loop runs faster
Arrays.sort(data);
// Test
long start = System.nanoTime();
long sum = 0;
for (int i = 0; i < 100000; ++i)
{
// Primary loop
for (int c = 0; c < arraySize; ++c)
{
if (data[c] >= 128)
sum += data[c];
}
}
System.out.println((System.nanoTime() - start) / 1000000000.0);
System.out.println("sum = " + sum);
}
}Con un resultado similar pero menos extremo.
Mi primer pensamiento fue que la clasificación lleva los datos al caché, pero luego pensé lo tonto que era porque la matriz acababa de generarse.
- Que esta pasando?
- ¿Por qué procesar una matriz ordenada es más rápido que procesar una matriz no ordenada?
El código está resumiendo algunos términos independientes, por lo que el orden no debería importar.
170
Woops ... re: Meltdown and Spectre
—
KyleMit
@SachinVerma Fuera de mi cabeza: 1) La JVM podría ser finalmente lo suficientemente inteligente como para usar movimientos condicionales. 2) El código está vinculado a la memoria. 200M es demasiado grande para caber en la memoria caché de la CPU. Por lo tanto, el rendimiento se verá afectado por el ancho de banda de la memoria en lugar de la ramificación.
—
Mysticial
@ Mysticial, alrededor de 2). Pensé que la tabla de predicción realiza un seguimiento de los patrones (independientemente de las variables reales que se verificaron para ese patrón) y cambia la salida de predicción en función del historial. ¿Podría darme una razón, por qué una matriz súper grande no se beneficiaría de la predicción de rama?
—
Sachin Verma
@SachinVerma Lo hace, pero cuando la matriz es tan grande, probablemente entra en juego un factor aún mayor: el ancho de banda de la memoria. La memoria no es plana . El acceso a la memoria es muy lento y hay una cantidad limitada de ancho de banda. Para simplificar demasiado las cosas, solo se pueden transferir tantos bytes entre la CPU y la memoria en un período de tiempo fijo. Un código simple como el de esta pregunta probablemente alcanzará ese límite, incluso si las predicciones erróneas lo ralentizan. Esto no sucede con una matriz de 32768 (128 KB) porque cabe en el caché L2 de la CPU.
—
Mysticial
Hay una nueva falla de seguridad llamada BranchScope: cs.ucr.edu/~nael/pubs/asplos18.pdf
—
Veve
