Производительность программы при компиляции 32/64bit

[Sharfik]

Есть ПК с 64битной системой. Что это дает? Дает больше выделяемой оперативной памяти. И чисто логически я решил что и программа при компиляции в 64битном режиме должна работать лучше, шустрее.
Попутно наклепал "попугаеметр". Он выполняет цикл обрабатывая одни и те же данные много раз, делая сложение, вычитание, поиск текста, создание md5 хеш файла exe. И все это на время.
И вот результаты очень неприятные получаются:

;=================
; 32bit
;=================
Razen 7 5700U(8/16;)/SSD PCI-E/16Gb; Выполнено за 15 сек.
Core i7 11700K(8/16; No Turbo Boost)/SSD PCI-E/16Gb; Выполнено за 5 сек.
Core i7 11700K(8/16; Turbo Boost)/SSD PCI-E/16Gb; Выполнено за 4 сек.
;=================
; 64bit
;=================
Razen 7 5700U(8/16;)/SSD PCI-E/16Gb; Выполнено за 19 сек.
Core i7 11700K(8/16; No Turbo Boost)/SSD PCI-E/16Gb; Выполнено за 7 сек.
Core i7 11700K(8/16; Turbo Boost)/SSD PCI-E/16Gb; Выполнено за 5 сек.

Вроде и не должно быть ограничений для работы с оперативной памятью, можно не бояться падения из-за потолка 4Гб, но в тоже время производительность неоптимизированных простых действий падает И все из-за размерности String в варианте 64 бит.

[SSerge]

Sharfik
Еще и памяти в 64-битном режиме должно заметно больше употребляться.
И вообще, всегда подчеркивалось, что 64-битная ОС при одной и той же программе скомпилированной на 64 бита = больше размер кода, как в памяти так и на диске + больше необходимой памяти на данные при тех же данных. + обязательство на выравнивание данных и дыры между блоками - иначе вообще неоптимально.

Что касается строк в FPC...
Он на программах, работающих с интенсивной рекомбинацией строковых данных, едва ли не в разы сливает по скорости обработки строковых данных сишарпу и яве... Ибо такова реализация.

[runewalsh]

У меня числодробилки работают на 64 битах гораздо быстрее, чем на 32, часто в 2 раза или ещё лучше.

Флоатовые — из-за использования XMM-регистров вместо FPU, ещё лучше при -CfAVX2 -CpCOREAVX2 -OpCOREAVX2: с векторизацией всё запущено, но AVX улучшает и скалярные вычисления. Программы с AVX не будут работать на старых процессорах, но можно скомпилировать две версии и выбирать лаунчером.

Целочисленные — просто из-за удвоенного количества регистров.

С тем, чтобы размер структур, указателей и тем более кода (+20% каких, подумаешь) на что-то влиял, почти не сталкивался, а если и сталкивался, было несоизмеримо со случаями ускорения. 19 секунд вместо 15 — это 25%, не прям «несоизмеримо», но не так много.

Но да, я предпочитаю использовать индексы 32-битного (если 4 млрд точно хватит) или вообще переменного (когда их большая пачка) размера вместо указателей, а со строками по возможности работать через

Код: Выделить всё

type
   StringView = record
      p: PChar;
      n: SizeUint;
      operator :=(const s: string): StringView;
      ...много методов, подражающих методам string, но работающих с её срезом...
   end;


как раз чтобы обойти основные проблемы cо скоростью 64 бит и скоростью строк (в целом это 2 разные проблемы).

[Alex2013]

Многопоточность в 64-х разрядном режиме заметно шустрее (если верить тестам), а все прочие как когда. ( но память в 64-х разрядном режиме ест примерно раза в четыре больше почти без вариантов и хотя сейчас сейчас это обычно не критично учитывать нужно )
Зы
Кстати , интересно как именно увеличение потребления памяти в 64-х разрядном режиме влияет на производительность ? (С одной стороны приходится прокачивать больше данных, но с другой памяти выделяется банально больше + нет затрат на эмуляцию 32-х разрядного режима который в современных процессорах давно уже "не родной" )

[Sharfik]

Кстати , интересно как именно увеличение потребления памяти в 64-х разрядном режиме влияет на производительность ? (С одной стороны приходится прокачивать больше данных, но с другой памяти выделяется банально больше + нет затрат на эмуляцию 32-х разрядного режима который в современных процессорах давно уже "не родной" )

Скорее всего родно, просто "не жирный".

[Seenkao]

32-х битный формат будет работать быстрее при идентичных командах. 64-х битный формат более удобен (на данное время) в многопоточности. Но я думаю, что 32-х битная многопоточность всё равно будет быстрее работать, чем 64-х битная.

Суть в том, что у 64-х битного формата надо больше тратить времени на передачу данных (в два раза минимум). А обмен данными остался на той же скорости (утрировано). Точнее чтобы 64-х битный формат заработал с той же скоростью, что и 32-х, то и передача данных должна быть в два раза быстрее. А значит полностью вытеснять 32-х битый формат (что зачастую не выгодно на данное время).