antonio leandro

comentariotechen

Brendan Gregg

Engenheiro de performance australiano, criador do flame graph e uma das referências em observabilidade de sistemas; passou por Netflix e Intel e entrou na OpenAI em 2026. Publica pouco e longo, quase sempre sobre o custo real de rodar software em produção.

10 textos no acervo · publica a cada ~64 dias · último em

escrito por pipeline de llm, revisado por antonio leandro antes de publicar

o que esta fonte defende

Há uma tese recorrente e ela é fácil de enunciar: a diferença entre o que uma máquina poderia fazer e o que ela faz em produção é enorme, mensurável e quase sempre ignorada — e fechar essa diferença é trabalho de engenharia, não de sorte. Gregg volta a esse ponto por caminhos diferentes. Em “Third Stage Engineering” ele o desenha como um foguete de três estágios: hardware, software e tuning, cada estágio dependendo do anterior e o último sendo o mais barato e o mais negligenciado. Em “When to Hire a Computer Performance Engineering Team” o mesmo argumento vira orçamento: um time pequeno se paga contra a conta de infraestrutura de uma empresa grande. Em “AI Flame Graphs” vira consumo elétrico nacional. É o mesmo raciocínio, escalado.

O método por trás da tese é igualmente estável, e é anterior a tudo o que ele escreveu aqui: primeiro tornar visível, depois otimizar. O flame graph — e sua extensão para GPU, demonstrada rodando Doom — existe porque a intuição do engenheiro sobre onde o tempo é gasto costuma estar errada, e porque um perfil só é útil se couber numa imagem que alguém consegue ler. A defesa do eBPF em “No More Blue Fridays” é a mesma convicção aplicada a um problema de segurança: se código de terceiros precisa rodar no kernel, que rode num ambiente verificado e limitado em vez de num módulo capaz de derrubar a máquina. Ferramenta como argumento, não como acessório.

O que muda ao longo do arquivo é o objeto e a plateia. Os textos mais antigos são de engenheiro de sistemas falando com engenheiros de sistemas — kernel, CPU, eBPF. Os mais recentes deslocam o foco para aceleradores e para o custo da IA, e passam a falar com quem decide: um diagrama apresentado à liderança executiva da Intel, um conselho público sobre como dar feedback ao novo CEO, um texto sobre quando uma empresa deve montar um time. A justificativa também migra de dinheiro para energia — “não é só sobre economizar custo, é sobre salvar o planeta”, escreve ao anunciar a entrada na OpenAI. É a mesma engenharia, com um argumento moral novo colado por cima; vale ler com a ressalva de que quem faz esse argumento também trabalha para quem constrói os datacenters em questão.

Uma parte do arquivo não é técnica nem pretende ser: os textos sobre três anos de trabalho remoto extremo da Austrália para um empregador americano, a saída da Intel, a chegada na OpenAI. São dez textos no total, publicados a cada dois meses em média — um blog de posts raros e longos, não de fluxo. Quem procura tutorial vai achar pouco; quem procura o raciocínio por trás das ferramentas acha o essencial.

por tema

o custo da ia como problema de engenharia (2 textos)

O argumento que hoje organiza o resto do trabalho dele: datacenters de IA consomem uma quantidade de energia que cresce rápido demais para ser tratada como detalhe de operação, e cada ponto percentual de eficiência recuperado vale, em escala, mais do que qualquer economia que a engenharia de performance já perseguiu. Em ‘AI Flame Graphs’ ele chega a citar estimativas — extremas, e ele admite que são extremas — de que reduzir pela metade o custo de recursos da IA cortaria mais de 10% do consumo elétrico dos Estados Unidos até 2030.

É esse raciocínio que ele dá como motivo para entrar na OpenAI, com foco inicial na performance do ChatGPT. Vale registrar a posição de onde o argumento é feito: quem defende que a eficiência dos datacenters é uma questão planetária passou a ser pago por uma das empresas que mais os expande.

flame graphs: ver antes de otimizar (1 texto)

A ferramenta pela qual ele é mais conhecido parte de uma desconfiança simples: engenheiros erram ao adivinhar onde o tempo é gasto. O flame graph resolve isso comprimindo um perfil inteiro numa única imagem legível. Em ‘Doom GPU Flame Graphs’ ele estende a técnica à GPU — com suporte à Intel Battlemage, agora em código aberto — e a combina com o FlameScope para analisar a performance de um jogo do stack completo, do shader ao driver.

A escolha do Doom como exemplo não é só nostalgia: é um caso em que o leitor já tem intuição sobre o que deveria estar lento, e pode comparar essa intuição com o que o perfil mostra.

ebpf contra a sexta-feira azul (1 texto)

Escrito dias depois da falha de atualização da CrowdStrike em julho de 2024, o texto faz uma previsão em vez de uma lamentação: no futuro, atualizações que envolvem código de kernel serão feitas via eBPF, e computadores deixarão de travar por causa delas. O ponto técnico é que o eBPF roda código de terceiros dentro do kernel sob um verificador, com limites de execução — o que impede boa parte das falhas que um módulo de kernel convencional pode causar.

É o texto mais programático do arquivo e o que mais claramente contraria uma prática estabelecida da indústria de segurança de endpoint.

hardware, software, tuning: os três estágios (2 textos)

‘Third Stage Engineering’ é a formulação mais clara da tese central. A performance real de qualquer hardware em produção é produto de três investimentos em sequência — o hardware, o software que roda nele, e o tuning — e Gregg os desenha como um foguete de três estágios, sendo o terceiro o mais barato e o mais frequentemente pulado. O diagrama é deliberadamente simples; ele conta que o apresentou à liderança executiva da Intel e só então percebeu que valia publicar.

O texto sobre dar feedback à Intel vem do mesmo impulso: o CEO Lip-Bu Tan pediu publicamente franqueza brutal dos clientes, e Gregg escreve para quem tem essa chance não desperdiçá-la com reclamações genéricas. Nos dois casos o assunto é o mesmo — como fazer um argumento de performance chegar a quem decide o orçamento.

quando montar um time de performance (1 texto)

Conselho dirigido a empresas que consideram criar a função e não sabem justificá-la. A resposta dele é econômica: grandes empresas de tecnologia nos EUA contratam engenheiros de performance — sob esse nome ou outro — para impedir que custo de infraestrutura e latência de serviço cresçam sem controle, e o cálculo de quando isso compensa é feito comparando o salário do time com a conta que ele reduz.

É a parte do arquivo mais útil para quem lidera e menos para quem só quer a técnica. Publicado como primeira de duas partes.

trabalho remoto extremo e as mudanças de emprego (2 textos)

A parte pessoal do arquivo, e a mais concreta. Em três anos trabalhando da Austrália para a Intel, sem escritório local, ele participou de 77 reuniões que começaram entre 1h e 6h da manhã — cerca de uma a cada duas semanas, seguidas do expediente normal a partir das 7h, de segunda a sábado. Ele faz questão de dizer que não está reclamando e que não considera trabalhar demais; o texto é um relato de custo real, não um manifesto contra remoto.

O post de saída da Intel funciona como balanço de três anos e meio: AI flame graphs abertos, GPU FlameScope, estratégia de nuvem, palestras. É a única vez em que ele lista o próprio trabalho de forma corrida, e serve bem de índice para quem chega agora.

os “brendans virtuais” (1 texto)

Existem hoje agentes de IA de engenharia de performance treinados no trabalho dele — alguns são auxiliares que interpretam flame graphs ou métricas de eBPF, outros se apresentam como um Brendan virtual capaz de tunar qualquer coisa como o original faria. O texto trata dos dois casos de forma diferente: os primeiros ele considera úteis; contra os segundos, faz a ressalva de que a promessa não se sustenta.

É um texto raro no arquivo por não ser sobre máquinas, e sim sobre o que acontece quando um corpo de trabalho técnico vira material de treino e depois produto com o nome do autor.

onde ela discorda de outras fontes do acervo

Duas divergências reais aparecem no arquivo. A mais clara é com a indústria de segurança de endpoint: em ‘No More Blue Fridays’, escrito logo após a falha da CrowdStrike, Gregg sustenta que módulos de kernel de terceiros são uma prática que deveria acabar e ser substituída por eBPF — posição que contraria diretamente a arquitetura de vários produtos de segurança em uso hoje, e que na época foi contestada por quem defende que a visibilidade necessária a esses produtos exige acesso irrestrito ao kernel. A segunda é com fornecedores de agentes de IA que se vendem como ‘Brendans virtuais’: ele afirma publicamente que a promessa de tunar qualquer sistema como ele faria não se sustenta, o que é uma discordância nomeada com produtos construídos sobre o trabalho dele.

linha do tempo