Ускорение ассемблера x64 Добавление цикла

Я почти уверен, что memcpy быстрее, потому что он не зависит от извлекаемых данных, прежде чем он сможет выполнить следующую операцию.

Если вы можете организовать свой код так, чтобы он делал что-то вроде этого:

mov rax, QWORD PTR [rdx+r11*8-64]
mov rbx, QWORD PTR [rdx+r11*8-56]
mov r10, QWORD PTR [r8+r11*8-64]
mov r12, QWORD PTR [r8+r11*8-56]
adc rax, r10
adc rbx, r12
mov QWORD PTR [rcx+r11*8-64], rax
mov QWORD PTR [rcx+r11*8-56], rbx

Я не уверен на 100%, что смещение -56 подходит для вашего кода, но концепция "правильная".

Я бы также рассмотрел кэш-попадания/кеш-коллизии. Например. если у вас есть три блока данных [что, казалось бы, у вас есть], вы убедитесь, что они НЕ выровнены по одному и тому же смещению в кеше. Плохим примером может быть, если вы выделяете все свои блоки в размере, кратном размеру кеша, из одного и того же места в кеше. Перераспределение и УБЕДЕНИЕ, что ваши различные блоки данных смещены не менее чем на 512 байт [поэтому выделите 4 КБ сверхразмера и округлите до 4 КБ граничный начальный адрес, затем добавьте 512 во второй буфер и 1024 в третий буфер]

Если ваши данные достаточно велики (больше, чем кеш L2), вы можете использовать MOVNT для извлечения/сохранения ваших данных. Это позволит избежать чтения в кеш - это ТОЛЬКО полезно, когда у вас очень большие данные, когда следующее чтение просто приведет к тому, что что-то еще, что вы можете найти «полезным», будет удалено из кеша, и вы не получите вернуться к нему до того, как вы выкинули его из кеша, поэтому сохранение значения в кеше на самом деле не поможет...

Изменить: использование SSE или аналогичного не поможет, как описано здесь: Может быть длинное целое подпрограммы выигрывают от SSE?

Самая сложная зависимость — распространение переноса между каждым блоком памяти; Я бы попытался сначала найти способ справиться с этим.

Следующий фрагмент имитирует распространение переноса, но с «преимуществом» в том, что флаг переноса не используется. Это можно распараллелить для трех или четырех отдельных потоков, каждый из которых производит половину, переносящую около 25 000 десятичных цифр (или 10 000 байтов) друг от друга. Тогда вероятность того, что эти переносы повлияют только на один байт, слово, двойное слово и т. д., асимптотически достигнет нуля.

 long long carry=0;
 for (int i=0;i<N;i++) {
     carry += (long long)*a++ + (long long)*b++;
     *c++ = carry; carry>>=32;
 }

Согласно моему профилированию, сложение без переноса с использованием xmm займет ~ 550 мс (1e9 слов), симуляция переноса займет ~ 1020 мс, а 4-сторонняя параллельная версия займет ~ 820 мс (без какой-либо оптимизации ассемблера).

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

Попробуйте сначала выполнить предварительную выборку данных (вы можете попытаться сначала прочитать больше блоков данных в регистры x64, а затем выполнить вычисления), проверить, правильно ли данные выровнены в памяти, поместить код цикла в метку, выровненную до 16, попытаться удалить адресацию SIB.

Вы также можете попытаться сократить свой код до:

mov rax, QWORD PTR [rdx+r11*8-64]
adc rax, QWORD PTR [r8+r11*8-64]
mov QWORD PTR [rcx+r11*8-64], rax