Вот фрагмент кода C ++, который демонстрирует очень своеобразное поведение. По какой-то странной причине сортировка данных чудесным образом делает код почти в шесть раз быстрее:
#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);
}
}С похожим, но менее экстремальным результатом.
Моей первой мыслью было, что сортировка переносит данные в кеш, но потом я подумал, насколько это глупо, потому что массив только что сгенерирован.
- Что здесь происходит?
- Почему обработка отсортированного массива быстрее, чем обработка несортированного массива?
Код суммирует некоторые независимые термины, поэтому порядок не должен иметь значения.
170
Woops ... re:
—
Обвал
@SachinVerma Не в моей голове: 1) JVM может быть достаточно умным, чтобы использовать условные движения. 2) Код связан с памятью. 200M слишком велик, чтобы поместиться в кэш процессора. Таким образом, производительность будет ограничена пропускной способностью памяти вместо ветвления.
—
Мистика
@ Мистик, около 2). Я думал, что таблица прогнозирования отслеживает шаблоны (независимо от фактических переменных, которые были проверены для этого шаблона) и изменяет вывод прогноза на основе истории. Не могли бы вы дать мне причину, почему сверхбольший массив не выиграл бы от предсказания ветвления?
—
Сачин Верма
@SachinVerma Да, но когда массив такой большой, в игру вступает еще больший фактор - пропускная способность памяти. Память не плоская . Доступ к памяти очень медленный, и пропускная способность ограничена. Чтобы упростить вещи, существует только так много байтов, которые могут быть переданы между процессором и памятью за фиксированное время. Простой код, подобный приведенному в этом вопросе, вероятно, достигнет этого предела, даже если он замедлен из-за неправильных прогнозов. Этого не происходит с массивом 32768 (128 КБ), потому что он помещается в кэш L2 ЦП.
—
Мистик
Существует новый недостаток безопасности называется BranchScope: cs.ucr.edu/~nael/pubs/asplos18.pdf
—
Veve
