Первый тест: 32 vs 64

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

Краткая предыстория. Когда давно я с сыном соревновался, смогу ли я написать сжатие Хаффманом лучше, чем он. Хотя детали уже не помню, может все было совсем не так. Недавно просматривая свой старый код, решил портировать его под 64 бита и немного оптимизировать.

Вот что получилось (время операции указано в секундах, программа компилировалась на Delphi XE5):

Операция	32 bit	64 bit	Потери производительности
Сжатие	0.62	0.92	47.02%
Восстановление	2.81	4.30	53.16%
Замедление	4.515512	4.704038

В последней строчке показано, во сколько раз распаковка данных медленней, чем сжатие. Просто для информации. Сжимался 8-битный файл изображения в формате tif размером 57 Мбайт, после сжатия размер файла составил 46 Мбайт. В данном случае тестировалась именно сама операция сжатия, без учета построения дерева Хаффмана.

Как видите 64-битная архитектура для данного примера оказалась существенно медленнее. Почему так? На мой взгляд, причина именно в лимитировании скорости работы памяти. И дело тут не только в использовании ссылок, но и  в вызове процедур или функций. Каждый такой вызов приводит как минимум к двум обращениям к памяти, а обычно существенно больше.

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

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

На самом деле причины в низкой производительности могут быть и другие, выше я привел только свои предположения. Как думаете вы, с чем связаны такие результаты 64-битного кода?

Если мое предположение верно, то на 64-битной архитектуре лучше в самом деле пользоваться массивами, даже при работе с древовидными структурами. Дело в том, что при обращении к массиву достаточно загрузить одну ссылку на его начало, а адреса ячеек массива очень эффективно рассчитываются современными процессорами без дополнительных обращений к памяти.

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

Так что не нужно думать, что 64-битная программа будет быстрее 32-битной. Понятно, что у 64-разрядного процессора есть много разных преимуществ, но только реализуются они не так уж и часто. Это задачи, обрабатывающие очень большие объемы данных, более 4 Гбайт, а также вычисления с большой точностью, например, шифрация данных. В обыденной жизни такие задачи встречаются не так уж и часто.

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