Senior C++ — Perguntas de entrevista C++

Como cache misses moldam a forma como você organiza os dados?

Um miss para a memória principal custa da ordem de algumas centenas de ciclos, então uma estrutura teoricamente melhor pode perder feio para um array contíguo. Isso leva a organizar os dados de acordo com como serão percorridos — structure-of-arrays quando você acessa um campo através de muitos objetos, empacotar os campos quentes juntos, e evitar perseguir ponteiros no loop interno. False sharing é o mesmo problema invertido: duas threads escrevendo em variáveis diferentes na mesma linha de cache se serializam sobre ela, e a solução é padding até uma linha de cache.

Quando lock-free vale a pena, e qual a diferença para wait-free?

Lock-free garante que alguma thread progride; wait-free garante que toda thread progride num número limitado de passos. Lock-free vale a pena sob contenção real numa estrutura pequena e bem entendida — uma fila, um contador — onde um mutex domina de forma mensurável. Não vale a pena por padrão: o código é difícil de escrever corretamente, difícil de testar, e um mutex bem usado é rápido no caso sem contenção, então a resposta honesta geralmente começa com uma medição.

Explique o memory ordering em `std::atomic`.

seq_cst é o padrão e dá uma única ordem total entre todas as threads — correto, e o mais fácil de raciocinar. Os pares acquire/release estabelecem um happens-before entre o store que libera e o load que adquire, que é o que um lock faz internamente e é suficiente para a maioria dos padrões produtor-consumidor. relaxed só garante atomicidade, sem ordem, e é apropriado para coisas como um contador de estatísticas. Enfraquecer o ordering é uma otimização medida, não um ponto de partida.

Um projeto leva vinte minutos para compilar. Como você ataca isso?

Meça primeiro — quais translation units e quais headers dominam. Depois corte o grafo de headers: forward declarations em vez de includes, PIMPL nas classes amplamente incluídas, e tirar os templates dos headers onde o custo de instanciação é real. Depois vêm as vitórias mecânicas — precompiled headers, ccache, paralelismo, unity builds, e um linker como lld ou mold. Módulos resolvem isso corretamente onde a toolchain está pronta para eles.

O código está mais lento do que deveria. Qual é o seu método?

Comece com uma medição reproduzível, porque a intuição sobre performance em C++ erra com frequência suficiente para ser perigosa. Faça profiling para encontrar onde o tempo realmente vai, depois olhe o algoritmo antes das microotimizações. Verifique o que o otimizador fez em vez de assumir — o código gerado responde perguntas que ler o fonte não consegue. E controle o ambiente: flags de compilação, caches quentes, frequency scaling e ruído de outros processos, senão eles vão produzir números que não são reais.