Ecco un pezzo di codice C ++ che mostra alcuni comportamenti molto particolari. Per qualche strana ragione, l'ordinamento miracoloso dei dati rende il codice quasi sei volte più veloce:
#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;
}- Senza
std::sort(data, data + arraySize);, il codice viene eseguito in 11,54 secondi. - Con i dati ordinati, il codice viene eseguito in 1,93 secondi.
Inizialmente, ho pensato che potesse trattarsi solo di un'anomalia del compilatore o del linguaggio, quindi ho provato 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 risultato simile ma meno estremo.
Il mio primo pensiero è stato che l'ordinamento porta i dati nella cache, ma poi ho pensato a quanto fosse sciocco perché l'array è stato appena generato.
- Cosa sta succedendo?
- Perché l'elaborazione di un array ordinato è più veloce dell'elaborazione di un array non ordinato?
Il codice sta riassumendo alcuni termini indipendenti, quindi l'ordine non dovrebbe avere importanza.
170
Woops ... re: Meltdown and Spectre
—
KyleMit,
@SachinVerma In cima alla mia testa: 1) La JVM potrebbe essere finalmente abbastanza intelligente da usare le mosse condizionate. 2) Il codice è associato alla memoria. 200M è troppo grande per adattarsi alla cache della CPU. Quindi le prestazioni saranno strozzate dalla larghezza di banda della memoria anziché dalla ramificazione.
—
Mistico il
@ Mysticial, circa 2). Ho pensato che la tabella di previsione tenesse traccia dei modelli (indipendentemente dalle variabili effettive verificate per quel modello) e modificasse l'output della previsione in base alla cronologia. Potrebbe per favore darmi una ragione, perché un array super grande non trarrebbe beneficio dalla previsione del ramo?
—
Sachin Verma,
@SachinVerma Lo fa, ma quando l'array è così grande, probabilmente entra in gioco un fattore ancora più grande: la larghezza di banda della memoria. La memoria non è scarica . L'accesso alla memoria è molto lento e la larghezza di banda è limitata. Per semplificare eccessivamente le cose, ci sono solo così tanti byte che possono essere trasferiti tra CPU e memoria in un determinato periodo di tempo. Un codice semplice come quello in questa domanda probabilmente colpirà quel limite anche se è rallentato da previsioni errate. Ciò non accade con un array di 32768 (128 KB) perché si adatta alla cache L2 della CPU.
—
Mistico il
C'è un nuovo difetto di sicurezza chiamato BranchScope: cs.ucr.edu/~nael/pubs/asplos18.pdf
—
Veve
