Почему порядок циклов влияет на производительность при итерации по двумерному массиву?

Ничего общего с сборкой. Это связано с пропуском кеша.

Многомерные массивы C сохраняются с последним измерением как самым быстрым. Таким образом, первая версия пропустит кеш на каждой итерации, тогда как вторая версия не будет. Поэтому вторая версия должна быть значительно быстрее.

Смотрите также: http://en.wikipedia.org/wiki/Loop_interchange.

Версия 2 будет работать намного быстрее, потому что она использует ваш кеш компьютера лучше, чем версия 1. Если вы думаете об этом, массивы - это просто смежные области памяти. Когда вы запрашиваете элемент в массиве, ваша ОС, вероятно, принесет страницу памяти в кеш, содержащий этот элемент. Однако, поскольку следующие несколько элементов также находятся на этой странице (поскольку они смежны), следующий доступ уже будет в кеше! Это то, что делает версия 2, чтобы ускорить ее.

Версия 1, с другой стороны, обращается к столбцам элементов, а не к ряду. Этот вид доступа не соприкасается с уровнем памяти, поэтому программа не может использовать кэширование ОС как можно больше.

Причина - доступ к локальным данным в кеш-памяти. Во второй программе вы сканируете линейно по памяти, что дает преимущества от кеширования и предварительной выборки. Ваша первая схема использования памяти программы намного более распространена и, следовательно, имеет худшее поведение в кэше.

Помимо других отличных ответов на кеш-хиты, существует также возможная разница в оптимизации. Ваш второй цикл, скорее всего, будет оптимизирован компилятором в нечто эквивалентное:

  for (j=0; j<4000; j++) {
    int *p = x[j];
    for (i=0; i<4000; i++) {
      *p++ = i+j;
    }
  }

Это менее вероятно для первого цикла, потому что ему нужно каждый раз увеличивать указатель "p" на 4000.

EDIT: p++ и даже *p++ = .. можно скомпилировать в одну инструкцию процессора в большинстве процессоров. *p = ..; p += 4000 не может, поэтому в оптимизации его меньше. Это также сложнее, потому что компилятор должен знать и использовать размер внутреннего массива. И это не происходит часто во внутреннем цикле в нормальном коде (это происходит только для многомерных массивов, где последний индекс поддерживается постоянным в цикле, а второй - последним), поэтому оптимизация меньше приоритета,

Эта строка виновника:

x[j][i]=i+j;

Вторая версия использует непрерывную память, поэтому будет значительно быстрее.

Я пробовал с помощью

x[50000][50000];

а время исполнения - 13 секунд для версии 1 против 0,6 для версии 2.

_{Я пытаюсь дать общий ответ.}

Потому что i[y][x] является сокращением для *(i + y*array_width + x) в C (попробуйте стильный int P[3]; 0[P] = 0xBEEF;).

Когда вы перебираете y, вы перебираете куски размером array_width * sizeof(array_element). Если у вас это в вашем внутреннем цикле, у вас будут array_width * array_height итерации по этим фрагментам.

Перевернув порядок, вы будете иметь только array_height chunk-итераций, и между любой итерацией блоков вы будете иметь array_width итераций только sizeof(array_element).

В то время как на действительно старых x86-процессорах это не имело особого значения, в настоящее время "x86" делает много предварительной выборки и кэширования данных. Вероятно, вы получаете много пропусков кеша в своем более медленном итерационном порядке.