Como um experimento mental, estou tentando descobrir qual é a maneira mais eficiente de executar o bit a bit ou em máscaras de bits de tamanho relativamente grande (~1M elementos u64) em um único thread.
Estou executando-o no meu laptop com CPU i7-8750H a 2,2 GHz, que suporta AVX2, mas não AVX-512. Como mencionei antes, estou tentando descobrir o que posso extrair de um único thread. Além disso, tenho quase certeza de que compactar minhas máscaras de bits em algo como bitmaps rugindo provavelmente produzirá acelerações adicionais, pois eu teria que ingerir menos bytes na CPU. Mas gostaria de entender primeiro se há algo obviamente errado com o que estou fazendo na minha implementação atual bastante simples. Estou mirando x86-64.
Tentei estimar qual é o teto de velocidade dessa operação. Vamos começar com a suposição obviamente muito errada de que todos os dados já estão nos registradores. _mm256_or_si256
pode executar uma operação bit a bit ou em 4x u64
s. Vou assumir que posso executar apenas uma operação desse tipo por ciclo, o que provavelmente também está errado e posso fazer 2-3. Vamos usar u64
vetores de 1M s para nossos testes. Isso nos dá 1M / 4 per cycle = 250K cycles
. Sob carga, a taxa de clock da minha CPU fica em ~3GHz. Isso nos dá 250K cycles / 3Ghz ~ 0.00008(3)sec ~ 83µs
. Esse é o nosso teto ingenuamente rápido que usaremos como valor de referência.
Vamos transformá-lo em código. Usei o ChatGPT para gerar um grande pedaço dele, desculpe antecipadamente, não sou um desenvolvedor C++ e sou relativamente ignorante em desenvolvimento de baixo nível.
#include <iostream>
#include <vector>
#include <random>
#include <chrono>
#include <cstdint>
#include <immintrin.h>
std::vector<uint64_t> generate_random_u64s(size_t amount) {
std::vector<uint64_t> random_u64s;
random_u64s.reserve(amount);
std::random_device rd; // Obtain a random number from hardware
std::mt19937_64 eng(rd()); // Seed the generator
std::uniform_int_distribution<uint64_t> distr; // Define the range
for (size_t i = 0; i < amount; ++i) {
random_u64s.push_back(distr(eng));
}
return random_u64s;
}
void avx_bitwise_or(
const std::vector<uint64_t>& vector1,
const std::vector<uint64_t>& vector2,
std::vector<uint64_t>& result
) {
size_t size = vector1.size();
// Ensure result has enough space
if (result.size() != size) {
result.resize(size);
}
size_t i = 0;
for (; i + 4 <= size; i += 4) {
// Prefetch data into CPU cache
_mm_prefetch(reinterpret_cast<const char*>(&vector1[i + 256]), _MM_HINT_T0);
_mm_prefetch(reinterpret_cast<const char*>(&vector2[i + 256]), _MM_HINT_T0);
// Load vectors using AVX
__m256i vec1 = _mm256_loadu_si256(reinterpret_cast<const __m256i*>(&vector1[i]));
__m256i vec2 = _mm256_loadu_si256(reinterpret_cast<const __m256i*>(&vector2[i]));
// Perform bitwise OR operation
__m256i vec_result = _mm256_or_si256(vec1, vec2);
// Use non-temporal store to write result back to memory bypassing CPU cache
_mm256_stream_si256(reinterpret_cast<__m256i*>(&result[i]), vec_result);
}
// Handle remaining elements that don't fit in AVX registers
for (; i < size; ++i) {
result[i] = vector1[i] | vector2[i];
}
}
int main() {
std::cout << "Starting" << std::endl;
const size_t size = 1'000'000;
auto vector1 = generate_random_u64s(size);
auto vector2 = generate_random_u64s(size);
auto result = std::vector<uint64_t>(size);
auto start = std::chrono::high_resolution_clock::now();
const int repetitions = 10000;
for (int i = 0; i < repetitions; ++i) {
avx_bitwise_or(vector1, vector2, result);
}
auto duration = std::chrono::high_resolution_clock::now() - start;
uint32_t popcnt = 0;
for (const auto& x : result) {
popcnt += __builtin_popcountll(x); // Count the number of set bits (1s)
}
std::cout << "Popcnt is: " << popcnt << std::endl;
std::cout << "Time elapsed is: " << std::chrono::duration_cast<std::chrono::milliseconds>(duration).count() << " ms" << std::endl;
return 0;
}
Eu o construo com g++ -O3 -mavx2 -o experiment main.cpp
. Quando estou executando, leva cerca de 9 segundos para executar 10.000 iterações, o que é 900 µs por iteração. Isso é ~10+ vezes mais lento do que nossos cálculos ingênuos de trás do envelope. Tentei desenrolar os loops, mas não me deu nenhum resultado de desempenho tangível. Talvez eu tenha feito errado de alguma forma.
Vamos contrastar com o código que evita a leitura da memória:
uint64_t single_register_test (
const std::vector<uint64_t>& vector1,
const std::vector<uint64_t>& vector2
) {
size_t size = vector1.size();
// Load vectors using AVX, use only first 4 elements and ignore everything else
__m256i vec1 = _mm256_loadu_si256(reinterpret_cast<const __m256i*>(&vector1[0]));
__m256i vec_result = _mm256_loadu_si256(reinterpret_cast<const __m256i*>(&vector2[0]));
// Perform bitwise OR operation on the same data over and over again
for (size_t i = 0; i + 4 <= size; i += 4) {
vec_result = _mm256_or_si256(vec1, vec_result);
}
// Get first u64 from the result
auto result = _mm256_extract_epi64(vec_result, 0);
return result;
}
// ...........
auto start = std::chrono::high_resolution_clock::now();
const int repetitions = 100'000;
uint32_t popcnt_single = 0;
for (int i = 0; i < repetitions; ++i) {
auto x = single_register_test(vector1, vector2);
popcnt_single += __builtin_popcountll(x);
}
std::cout << "Popcnt single is: " << popcnt_single << std::endl;
auto duration = std::chrono::high_resolution_clock::now() - start;
Foram necessários cerca de 9 segundos para uma iteração de 100K para o mesmo 1M x u64
vetor, o que equivale a 90 µs por iteração, muito próximo do nosso valor de referência ingênuo de 83 µs.
Então, eu me pergunto o que posso fazer para aumentar ainda mais o desempenho do meu código que lê da memória? Há algo que eu possa fazer?
Seus arrays não cabem nem no cache L3, então seu gargalo é a largura de banda DRAM, não a computação.
Se seus dados coubessem no cache L1d, sua análise estaria correta.
Em velocidades de DRAM padrão, a largura de banda máxima teórica de memória dessa CPU é de 41,8 GB/s ( https://ark.intel.com/content/www/us/en/ark/products/134906/intel-core-i7-8750h-processor-9m-cache-up-to-4-10-ghz.html ), ou seja, cerca de 14 bytes por ciclo de clock a 3 GHz (leitura+escrita total - DRAM é half duplex).
E é uma CPU da família Skylake para desktop/laptop, então você pode esperar realisticamente chegar perto dessa largura de banda com apenas um núcleo, em um programa single-threaded. ( Diferentemente de um Xeon de vários núcleos .) Talvez 80 a 90% da largura de banda máxima teórica da DRAM.
Essa largura de banda de pico teórica de 14 B/c da DRAM é muito mais lenta do que as 2x cargas de 256 bits + 1x armazenamento de 256 bits por ciclo de clock que você está estimando para alimentar 1x
vpor
por ciclo; essa seria a largura de banda de pico L1d (96 B/ciclo).A computação não está nem remotamente perto de ser um gargalo com esse tamanho de array, apenas se você usasse arrays de cerca de 8K para que três deles pudessem caber no cache L1d.
Para matrizes menores, obviamente não use NT, também conhecidos como armazenamentos de fluxo; eles ignoram o cache e forçam a remoção se a linha de cache de destino estava ativa anteriormente.
Para matrizes maiores,
_mm256_stream_si256
deve ser mais rápido do que armazenamentos simples para isso. Com armazenamentos simples que não estão no cache, a CPU tem que ler os dados antigos no cache para que possa atualizar a parte da linha do cache que você está armazenando com um MESI Read For Ownership que também obtém propriedade exclusiva, então é permitido inverter a linha para Modified. Os armazenamentos NT apenas invalidam cópias em outros núcleos sem leitura.Para ir mais rápido no seu caso de uso real, você precisaria bloquear seu problema em cache (fazer mais com pedaços de seus dados enquanto eles estão ativos no cache). Ou aumentar a intensidade computacional combinando mais trabalho em uma passagem sobre os dados , por exemplo, popcount os vetores conforme você os gera, em vez de armazenar em uma matriz de resultados e lê-la. https://github.com/WojciechMula/sse-popcount/ tem um código bem otimizado para SSE4, AVX e AVX-512 com/sem VPOPCOUNT. Você pode adaptá-lo para receber 2 entradas e
or
em vez de apenas carregar de uma matriz.Perguntas e respostas relacionadas:
Falando nisso, estou surpreso que o GCC não consegue otimizar o loop na versão sem carga/armazenamento.
v |= x;
é idempotente após a primeira iteração. O Clang sabe disso e remove corretamente o loop. (E apenas ORs o elemento escalar que você extrai; o otimizador de embaralhamento do LLVM pode ver através dos intrínsecos de embaralhamento.) Eu tentei com algumas variações na condição de loop para ter certeza de que o GCC não estava sendo acionado por um loop possivelmente infinito (<= size
com um size_t não assinado), mas não é isso. https://godbolt.org/z/zxz8f86M9 . A saída asm do GCC tem uma cadeia de dependênciavpor
como sua fonte, então isso está medindovpor
a latência, mas não a taxa de transferência para a versão reg-reg. (Tudo bem: com 2 cargas porvpor
você não vai ficar mais rápido, exceto no Alder Lake e Zen 3 e posterior, e então apenas com dados quentes em L1d.)Seu benchmark evita muitas das armadilhas mencionadas em Modo idiomático de avaliação de desempenho?, por exemplo, usar
std::vector
para a saída faz o compilador escrever 0s antes da região temporizada, então você não está cronometrando falhas de página nem na primeira iteração do loop de repetição. E o loop de repetição dá bastante tempo para aquecimento do turbo e amortização de quaisquer efeitos de inicialização.