Voici un morceau de code C ++ qui montre un comportement très particulier. Pour une raison étrange, le tri des données miraculeusement rend le code presque six fois plus rapide:
#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;
}- Sans
std::sort(data, data + arraySize);, le code s'exécute en 11,54 secondes. - Avec les données triées, le code s'exécute en 1,93 secondes.
Au départ, je pensais que cela pourrait être juste une anomalie de langage ou de compilateur, j'ai donc essayé 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);
}
}Avec un résultat similaire mais moins extrême.
Ma première pensée a été que le tri amène les données dans le cache, mais j'ai pensé à quel point c'était stupide parce que le tableau venait d'être généré.
- Que se passe-t-il?
- Pourquoi le traitement d'un tableau trié est-il plus rapide que le traitement d'un tableau non trié?
Le code résume certains termes indépendants, donc l'ordre ne devrait pas avoir d'importance.
170
Woops ... re: Meltdown and Specter
—
KyleMit
@SachinVerma Du haut de ma tête: 1) La JVM pourrait être finalement assez intelligente pour utiliser des mouvements conditionnels. 2) Le code est lié à la mémoire. 200M est beaucoup trop grand pour tenir dans le cache CPU. Les performances seront donc goulotées par la bande passante mémoire au lieu de se ramifier.
—
Mysticial
@ Mysticial, environ 2). Je pensais que le tableau de prédiction garde une trace des modèles (quelles que soient les variables réelles qui ont été vérifiées pour ce modèle) et modifie la sortie de prédiction en fonction de l'historique. Pourriez-vous s'il vous plaît me donner une raison, pourquoi un très grand tableau ne bénéficierait pas de la prédiction de branche?
—
Sachin Verma
@SachinVerma Oui, mais lorsque la baie est si grande, un facteur encore plus important entre probablement en jeu: la bande passante mémoire. La mémoire n'est pas plate . L'accès à la mémoire est très lent et la bande passante est limitée. Pour simplifier à l'excès, il n'y a que tant d'octets qui peuvent être transférés entre le processeur et la mémoire dans un laps de temps fixe. Un code simple comme celui de cette question atteindra probablement cette limite même s'il est ralenti par des erreurs de prévision. Cela ne se produit pas avec un tableau de 32 768 (128 Ko) car il s'intègre dans le cache L2 du CPU.
—
Mysticial
Il y a une nouvelle faille de sécurité appelée BranchScope: cs.ucr.edu/~nael/pubs/asplos18.pdf
—
Veve
