Ось фрагмент коду С ++, який показує дуже своєрідну поведінку. З якоїсь дивної причини сортування даних дивом робить код майже в шість разів швидшим:
#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;
}- Без
std::sort(data, data + arraySize);цього код працює за 11,54 секунди. - З відсортованими даними код працює за 1,93 секунди.
Спочатку я думав, що це може бути просто аномалія мови чи компілятора, тому я спробував 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);
}
}З аналогічним, але менш екстремальним результатом.
Моя перша думка полягала в тому, що сортування вносить дані в кеш, але потім я подумав, як це нерозумно, тому що масив був просто створений.
- Що відбувається?
- Чому обробка відсортованого масиву швидша, ніж обробка несортованого масиву?
Код підсумовує деякі незалежні терміни, тому порядок не має значення.
169
Woops ... re: Meltdown and Spectre
—
KyleMit
@SachinVerma Вгорі голови: 1) JVM, нарешті, може бути досить розумним, щоб використовувати умовні рухи. 2) Код пов'язаний з пам'яттю. 200M занадто великий, щоб вміститись у кеш процесора. Таким чином, продуктивність буде обмежена пропускною здатністю пам’яті, а не розгалуженням.
—
Містичний
@ Містичне, про 2). Я подумав, що таблиця прогнозування відстежує шаблони (незалежно від фактичних змінних, які перевірялися для цього шаблону) та змінює вихід прогнозування на основі історії. Скажіть, будь ласка, причину, чому надзвичайно великий масив не отримає користі від гілок прогнозування?
—
Сачін Верма
@SachinVerma Це так, але коли масив настільки великий, в гру вступає ще більший фактор - пропускна здатність пам'яті. Пам'ять не рівна . Доступ до пам'яті відбувається дуже повільно, і пропускна здатність обмежена. Щоб надто спростити речі, є лише стільки байтів, які можна перенести між процесором та пам'яттю за певний час. Простий код, подібний до цього в цьому питанні, ймовірно, досяг цієї межі, навіть якщо його сповільнить помилкові прогнози. Це не відбувається з масивом 32768 (128 КБ), оскільки він вписується в кеш-пам'ять L2 ЦП.
—
Містичний
Існує новий недолік безпеки називається BranchScope: cs.ucr.edu/~nael/pubs/asplos18.pdf
—
Veve
