Ini adalah bagian dari kode C ++ yang menunjukkan beberapa perilaku yang sangat aneh. Untuk beberapa alasan aneh, mengurutkan data secara ajaib membuat kode hampir enam kali lebih cepat:
#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;
}- Tanpa
std::sort(data, data + arraySize);, kode berjalan dalam 11,54 detik. - Dengan data yang diurutkan, kode ini berjalan dalam 1,93 detik.
Awalnya, saya pikir ini mungkin hanya sebuah anomali bahasa atau kompiler, jadi saya mencoba 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);
}
}Dengan hasil yang serupa tetapi tidak terlalu ekstrem.
Pikiran pertama saya adalah penyortiran membawa data ke dalam cache, tetapi kemudian saya berpikir betapa konyolnya karena array baru saja dihasilkan.
- Apa yang sedang terjadi?
- Mengapa memproses array yang diurutkan lebih cepat daripada memproses array yang tidak disortir?
Kode ini merangkum beberapa istilah independen, jadi urutannya tidak masalah.
170
Woops ... re: Meltdown dan Spectre
—
KyleMit
@SachinVerma Dari atas kepala saya: 1) JVM mungkin akhirnya cukup pintar untuk menggunakan gerakan bersyarat. 2) Kode ini terikat memori. 200M terlalu besar untuk muat dalam cache CPU. Jadi kinerjanya akan terhambat oleh bandwidth memori dan bukannya percabangan.
—
Mysticial
@ Mysticial, sekitar 2). Saya pikir tabel prediksi melacak pola (terlepas dari variabel aktual yang diperiksa untuk pola itu) dan mengubah output prediksi berdasarkan sejarah. Bisakah Anda memberi saya alasan, mengapa array super besar tidak akan mendapat manfaat dari prediksi cabang?
—
Sachin Verma
@SachinVerma Ya, tapi ketika arraynya besar, faktor yang lebih besar kemungkinan ikut bermain - bandwidth memori. Memori tidak rata . Mengakses memori sangat lambat, dan ada sejumlah bandwidth yang terbatas. Untuk menyederhanakan banyak hal, hanya ada begitu banyak byte yang dapat ditransfer antara CPU dan memori dalam jumlah waktu yang tetap. Kode sederhana seperti yang ada di pertanyaan ini mungkin akan mencapai batas itu walaupun itu diperlambat oleh salah duga. Ini tidak terjadi dengan array 32768 (128KB) karena cocok dengan cache L2 CPU.
—
Mysticial
Ada kelemahan keamanan baru yang disebut BranchScope: cs.ucr.edu/~nael/pubs/asplos18.pdf
—
Veve
