Отвечать на этот вопрос без какой-либо дополнительной информации - это как гадать на кофейной гуще. Какой CPU - если это древний Pentium D с допотопным конвейером и глупыми регистрами - одно дело, а если это новейший Core i7 на Haswell - другое. Что до настроек - вот честно, "стандартные" вообще ни о чём не говорит. Я уже не говорю, что было бы не плохо указать количество опытов с максимальным и минимальным - вполне возможно глупые ОС с планировщиком как-то неудачно распределяют время. Любой ответ, который можно тут указать может быть техническим грамотным, но совершенно не соответствующий истине.
Рискну предположить такой расклад - об оптимизациях мы почти ничего не знаем и делаем "стандартную" дебаговую сборку. В этих случаях транслятор вставляет в код специальные метки, по которым можно будет сопоставить инструкции с файлом и номером строки. Понятное дело, что в объектные файлы попадут и холостые циклы и бесполезные разыменования. Ни о каких кэшированиях или перестановках не может быть и речи - что попросили, то получили.
Теперь давайте вместе подумаем о том, какие различия между x86-64 и x86. На самом деле, вопрос поставлен не очень корректно - x86-64 почти полностью включает в себя x86. Из изменённого - размер указателя (адреса), да немного переделана логика регистров (хотя все они на месте, просто добавилось ещё лишние несколько десятков) - теперь часть аргументов в функцию передаётся через дополнительные регистры, тогда как в x86 все идут через стек. Однако получить здесь преимущество не так уж и просто - процессор тоже не дурак, в случае линейной обработки информации (или любая длительная работа с небольшими участками памяти) он прекрасно всё кэширует и работа со стеком в общем случае не сильно медленнее работы с регистрами.
Теперь смотрим на
код. Что там? Куча адресной арифметики, немного функций, да и аргументов почти нет. 8 миллионов слов? Не думаю что рекурсия вынудит вылезти стеку за пределы кэша, так что есть подозрение о паритете архитектур в данном случае. Однако большое количество адресной арифметики и увеличенный размер адреса в битах... во сколько раз? В два раза?
Ну да ладно, ясное дело, сложение реализовано за 1 такт. Скорее всего. Конечно, здесь вопрос процессора, но даже узнав модель будет сложно узнать наверняка, разве только синтетическим тестом (много раз обращаться по адресу - сумме двух случайных чисел). Да и Windows 8.1 никогда не был стандартом производительности (скорее с точностью наоборот), и VC++ никогда не был лучшим компилятором.
Попробуйте gcc (меня разве только интересует откуда на Windows взялся gcc) с флагом -O3. И посмотрите машинный код для 64 бита и 32 бита (можно пользоваться
objdump из binutils или посмотреть машинный код в IDE Visual Studio - точно расположение кнопки не помню, но можно поискать в менюшках). Скорее всего причина не одна, их множество. Так, вызов функции сопровождается сохранением контекста, тогда как в x64 регистров больше, больше и контекст. Собираем такие моменты по крупицам... Вот и получаем.
P.S. Давным давно, разговаривал с преподавателем. Простая перекомпиляция под 64 бита ускорила код на 30%. Это был колхозный кодек, немного похожий на libx264 (от туда была сдёрнута часть кода). Естественно, проект собирался со всеми оптимизациями, со всем расширениями инструкций - со всем, чем можно. И сборка под платформу x86-64 (с SSE, MMX, FMA и прочие). Жутко наукоёмкий разношёрстный код (писали все - от зелёных аспирантов, до ровесников Страуструпа и профессоров университета) - туева хуча функций, структур, объединений и очень, очень много параметров, многие из которых передают в аргументы функций. Ну и целевая платформа - жутко порезанный и переделанный Windows Embedded - там просто не чего было планировать.
