07.04.2015

Второй тест: 32 vs 64

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

Сортировка 32 не опт. 64 не опт. Выигрыш, разы 32 опт. 64 опт. Выигрыш, разы Эффект опт., 32 разы Эффект отп, 64, разы
Прямым включением (50 тыс.) 4.92 3.71 1.33 1.20 1.66 0.73 4.09 2.24
Шейкерная (50 тыс.) 8.44 6.85 1.23 2.80 2.97 0.94 3.01 2.30
Быстрая наихудший (50 тыс.) 2.69 2.69 1.00 0.62 0.75 0.82 4.35 3.58
Пирамидальная (20 млн.) 3.56 3.87 0.92 2.17 2.75 0.79 1.65 1.41
Быстрая (20 млн.) 3.16 3.35 0.94 1.84 2.02 0.91 1.72 1.66
Сортируются массивы 32-битных целых чисел, размер массивов для каждого случае приведен в скобках. Ну и он совпадает с тем, что привел Иван Колесников в комментарии к предыдущему посту, чисто для сравнения.


Выводы: мое предположение совершенно не оправдалось.  То есть пропускная способность между процессором и кэшем вполне достаточна для вдвое более длинных указателей в 64-битной архитектуре.
А все дело в более низком качестве 64-битного компилятора по сравнению с 32-битным, по крайней мере в Delphi XE5.

Интересные факты:
  1. Без оптимизации на Дельфи 64-битный код выполняется быстрее 32-битного. После оптимизации все меняется с точностью до наоборот.
  2. Даже в наихудшем случае быстрая сортировка (напомню, сложность у нее порядка O(n^2)) работает все же быстрее простых методов сортировки с такой же оценкой сложности. Правда, для простых методов был взят наихудший случай, когда данные отсортированы в обратном порядке.
  3. Простые методы сортировки оптимизируются гораздо более эффективно, чем сложные.
  4. При этом наихудший вариант быстрой сортировки, когда в качестве опорного всегда выбирается первый элемент сортируемой части массива, показал такое же улучшение в результате оптимизации, как и простые методы. Не говорит ли это о том, что такой вариант быстрой сортировки может быть легко приведен к более простому варианту?
Грусть-печаль короче. Попробовать ради смеха на ассемблере под 64 бита что ли быструю сортировку накидать? )))

4 комментария:

  1. Эти результаты более ожидаемы мной. Жаль за Delphi, когда-то была отличная среда разработки, но почему-то так и не прижилась в больших компаниях. Как я понимаю сейчас у них свой 64-bit компилятор на Windows, но в интернете есть слухи что собираюстся заиспользовать LLVM, может тогда будет лучше оптимизировать.

    Опечатка: 2 колонки "64 не опт.", вторая должна быть "64 опт."

    > 2. Даже в наихудшем случае быстрая сортировка работает все же быстрее простых методов сортировки с такой же оценкой сложности.

    Думаю это потому что данные уже отсортированы и не нужно тратить время на запись в память.

    Ради интереса запустил свой тест на рабочем десктопе (Intel(R) Xeon(R) CPU W3565 @ 3.20GHz, 8MB cache) и все в разы быстрее:

    Быстрая (20М):

    Без оптимизации (-O0): 32-bit: 1516 ms, 64-bit: 1594 ms (+5%)
    Полная оптимизация (-O2): 32-bit: 617 ms, 64-bit: 542 ms (-12%)
    Агрессивная оптимизация (-O3): 32-bit: 619 ms, 539 ms (-12%)

    Быстрая наихудший (50К):

    Без оптимизации (-O0): 32-bit: 3040 ms, 64-bit: 3056 ms (+1%)
    Полная оптимизация (-O2): 32-bit: 1108 ms, 64-bit: 1113 ms (+0%)
    Агрессивная оптимизация (-O3): 32-bit: 1131 ms, 64-bit: 1101 ms (-3%)

    Это конечно очевидно что рабочий комп быстрее моего старенького ноута, но я не ожидал что сортировка будет на столько быстрее (в 7,8 раз): 4228мс на ноуте и 539мс на десктопе. Похоже это как раз большой кэш Xeon-а дал такой результат, ведь частота всего в 1,5 раза больше, а доп. ядра не используются. Также видно что 64-bit на 20М записей дают 12% выигрыш после оптимизации. Наверное большой кэш позволил заиспользовать пополной доп. регистры.

    ОтветитьУдалить
    Ответы
    1. Да Делфи и сейчас не плоха. Когда-то Borland Pascal был вообще не оптимизирующим компилятором и ничего. )) Высокая производительность нужна сейчас в каких-то специальных случаях, а в большинстве прикладных задач разницы в 0.1 сек. никто и не заметит.
      А не прижилась Делфи в больших компаниях, мне кажется, из-за исторических моментов. Хоть языки C и Pascal появились примерно в одно время, но первый был разработан в производственной среде, а второй - в академической. Вот и сложилось соответствующее отношение, которое дальше только укреплялось.

      Да, по поводу того, почему быстрее работает быстрая в наихудшем случае, ты прав. Там совершенно нет операций обмена.

      Насчет причины того, что Xeon настолько быстрее, я бы высказал другое предположение. Возможно, кроме всего прочего, также он больше инструкций умеет выполнять за такт и лучше предсказывает переходы, в отличие от твоего старенького ноута. А вот связь большого кэша и дополнительных регистров для меня как-то не очевидна. Хоть кэш есть, хоть нет его, регистры будут использоваться все равно одинаково и в одинаковом количестве.

      Удалить
    2. Про регистры извиняюсь, я как-то коряво написал... Большой кэш и быстрая память на десктопе существенно ускорили подсистему памяти и вклад процессора во время работы просто стал более заметен. В моем тесте разница времени выпонения между 64-bit и 32-bit на ноуте -200мс (-5%, вроде и нет разницы то...), а на xeone даже меньше, всего -120мс (но зато целых -12%, уже не свалишь на погрешность :)).

      Удалить
    3. Это да, подсистема памяти там получше конечно. Ну и вообще, Xeon удивительно быстр. Возможно, быстродействие памяти при сортировке вообще имеет определяющее значение, так как вычислений практически нет, основные операции - это обмены и сравнения.

      Удалить