Быстрая реализация большого целочисленного счетчика (в C / C ++)

Моя цель заключается в следующем,

Создавайте последовательные значения, чтобы каждый новый никогда не генерировался раньше, пока не будут созданы все возможные значения. На этом этапе счетчик снова запускает ту же последовательность. Главное здесь, что все возможные значения генерируются без повторения (пока период не исчерпан). Не имеет значения, проста ли последовательность 0, 1, 2, 3,... или в другом порядке.

Например, если диапазон может быть представлен просто unsigned, то

void increment (unsigned &n) {++n;}

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

typedef std::array<uint64_t, 4> ctr_type;
static constexpr uint64_t max = ~((uint64_t) 0);
void increment (ctr_type &ctr)
{
    if (ctr[0] < max) {++ctr[0]; return;}
    if (ctr[1] < max) {++ctr[1]; return;}
    if (ctr[2] < max) {++ctr[2]; return;}
    if (ctr[3] < max) {++ctr[3]; return;}
    ctr[0] = ctr[1] = ctr[2] = ctr[3] = 0;
}

Поэтому, если ctr начинается со всех нулей, то сначала ctr[0] увеличивается один за другим, пока не достигнет max, а затем ctr[1] и т.д. Если все 256 бит установлены, то мы перезагружаем его на все ноль и начинаем заново.

Проблема в том, что такая реализация на удивление медленная. Моя текущая улучшенная версия похожа на следующее:

void increment (ctr_type &ctr)
{
    std::size_t k = (!(~ctr[0])) + (!(~ctr[1])) + (!(~ctr[2])) + (!(~ctr[3]))
    if (k < 4)
        ++ctr[k];
    else
        memset(ctr.data(), 0, 32);

}

Если счетчик обрабатывается только с помощью указанной выше функции increment и всегда начинается с нуля, тогда ctr[k] == 0 если ctr[k - 1] == 0. И, таким образом, значение k будет индексом первого элемента, который меньше максимального.

Я ожидал, что первое будет быстрее, так как неверное предсказание ветки произойдет только один раз за каждые 2 ^ 64 итерации. Второе, хотя неверное предсказание происходит только каждые 2 ^ 256 итераций, оно не должно иметь значения. И кроме ветвления, ему нужно четыре побитового отрицания, четыре булево отрицание и три добавления. Это может стоить гораздо больше, чем первое.

Тем не менее, как clang, gcc, так и intel icpc генерируют двоичные файлы, а второй - намного быстрее.

Мой главный вопрос: кто-нибудь знает, есть ли более быстрый способ реализовать такой счетчик? Не имеет значения, начинается ли счетчик путем увеличения первых целых чисел или если он реализован как массив целых чисел вообще, пока алгоритм генерирует все 2 ^ 256 комбинаций из 256 бит.

Что усложняет ситуацию, мне также требуется неравномерное приращение. Например, каждый раз, когда счетчик увеличивается на K где K > 1, но почти всегда остается константой. Моя текущая реализация аналогична предыдущей.

Чтобы предоставить некоторый контекст, одно место, использующее счетчики, использует их в качестве входных данных для инструкций AES-NI aesenc. Таким образом, __m128i целое число 128 бит (загруженное в __m128i), после прохождения раундов 10 (или 12 или 14, в зависимости от размера ключа) команд, генерируется 128-bits целое число 128-bits. Если я сгенерирую одно целое число __m128i сразу, тогда стоимость increment имеет мало значения. Однако, поскольку aesenc имеет довольно небольшую задержку, я генерирую целые числа по блокам. Например, у меня может быть 4 блока, ctr_type block[4], инициализированный эквивалентно следующему,

block[0]; // initialized to zero
block[1] = block[0]; increment(block[1]);
block[2] = block[1]; increment(block[2]);
block[3] = block[2]; increment(block[3]);

И каждый раз, когда мне нужен новый вывод, я increment каждый block[i] на 4 и генерирую сразу 4 __m128i. По инструкциям чередования, в общем, я смог увеличить пропускную способность и сократить циклы на байты вывода (cpB) с 6 до 0,9 при использовании 2 64-битных целых чисел в качестве счетчика и 8 блоков. Однако, если вместо этого использовать 4 32-битных целых числа в качестве счетчика, пропускная способность, измеренная как байты в секунду, уменьшается до половины. Я знаю, что в x86-64 в некоторых ситуациях 64-битные целые числа могут быть быстрее 32 бит. Но я не ожидал, что такая простая операция приращения будет иметь такое большое значение. Я тщательно тестировал приложение, и increment действительно замедляет работу программы. Поскольку загрузка в __m128i и сохранение вывода __m128i в используемые 32- __m128i или 64- __m128i целые числа выполняются с помощью выровненных указателей, единственная разница между 32-битной и 64-битной версиями заключается в том, как счетчик увеличивается. Я ожидал, что ожидаемый AES-NI после загрузки целых чисел в __m128i должен доминировать в производительности. Но при использовании 4 или 8 блоков это явно не так.

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