32 vs 64: что дальше?

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

На самом деле, проверить, на мой взгляд, достаточно просто. Но, перед тем, как проверять, хочется немного пованговать и проверить, угадаю я или нет.

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

1. Сортировка простым включением. Проста, как три копейки. Переменных нужно не много, пишется двумя циклами без вызовов процедур. Поэтому вангую, что 32-битный и 64-битный вариант покажут одинаковую скорость работы, +- 5%.

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

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

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