A arte da computação de alto desempenho

• The Art of HPC é uma série de livros didáticos sobre computação de alto desempenho criada por Victor Eijkhout, do TACC, reunindo em um fluxo contínuo desde os fundamentos da computação científica até programação paralela e ferramentas de desenvolvimento
• O primeiro volume é um livro de base em computação científica que aborda como arquitetura de computadores, aritmética, álgebra linear e EDO/EDP se articulam em computações de grande escala
• O segundo volume explica MPI e OpenMP como foco central da programação paralela, e também inclui breves seções sobre PETSc, Kokkos, Sycl e Co-array Fortran
• O terceiro volume trata de C++17 e Fortran2008 usados em programação científica e de engenharia, podendo ser lido tanto por iniciantes quanto por programadores C
• O quarto volume apresenta ferramentas de fluxo de trabalho de desenvolvimento necessárias para o trabalho real em HPC, como compiladores, sistemas de build e gerenciamento de código-fonte

---

Estrutura da coleção The Art of HPC

• The Art of HPC é uma série de livros didáticos sobre computação de alto desempenho criada por Victor Eijkhout, do TACC
• A série divide por volume os temas de fundamentos da computação científica, programação paralela, linguagens de programação científica e o ecossistema de desenvolvimento em HPC

Escopo por volume

• Volume 1: The Science of Computing

  • Aborda o conhecimento geral de base necessário para entender computação científica
  • Inclui arquitetura de computadores, arquitetura de computadores paralelos, aritmética computacional, álgebra linear e EDO/EDP
  • Explica como cada elemento se combina em computação de grande escala, compondo junto com o Volume 2 o “o quê/por quê” e o “como” do HPC

• Volume 2: Parallel Programming for Science and Engineering

  • É o volume que trata da programação paralela, essencial na computação científica
  • Apresenta principalmente as versões modernas de MPI e OpenMP
  • Também inclui breves seções sobre PETSc, Kokkos, Sycl e Co-array Fortran
  • MPI e OpenMP são tratados em C, Fortran e C++, e MPI também inclui Python

• Volume 3: Introduction to Scientific Programming

  • Com base em C/C++ e Fortran, muito usados em programação científica e de engenharia, ensina C++17 e Fortran2008 modernos
  • Adota uma abordagem que prefere C++17 a C
  • Pode ser lido tanto como uma introdução à programação científica desde o início quanto como um livro de aprendizado de C++ para programadores C
  • Inclui vários projetos longos de programação

• Volume 4: HPC Carpentry

  • Foca no fato de que o ecossistema de computação científica não é composto apenas por linguagens de programação e sistemas de programação paralela
  • Apresenta elementos necessários para o fluxo de trabalho científico, como compiladores, sistemas de build e gerenciamento de código-fonte
  • Em vez de ser uma obra de referência exaustiva, está mais próximo de uma coletânea introdutória voltada ao fluxo de trabalho científico

[GN⁺]

Opiniões no Hacker News

• O lado de hardware/data centers desse tema é igualmente interessante.
  Antigamente, eu trabalhava na AWS na área de software/serviços e, de vez em quando, entrava escondido para assistir a apresentações da equipe de data centers.
  A maior percepção foi que aumentar a capacidade computacional em um data center é, na prática, mais um problema de termodinâmica do que de computação em si. A densidade dos nós ficou tão alta que colocar energia para dentro e retirar calor — além de acrescentar todo tipo de redundância — é extremamente difícil. Mesmo quando se encontra uma ineficiência, não dá para corrigi-la como se fosse uma atualização de software.
  Isso foi há cerca de 10 anos, então algumas coisas podem ter mudado, mas é surpreendente que a Amazon, que começou como uma livraria on-line, esteja na linha de frente da resolução de problemas de termodinâmica.

  • Seymour Cray já dizia, desde a década de 1970, que o maior problema era a dissipação de calor.
    No Cray-2, ele adotou uma abordagem ainda mais extrema: uma arquitetura de resfriamento que mergulhava pilhas densas de placas de circuito em um líquido especial não condutivo chamado Fluorinert™: “The Cray-2's unusual cooling scheme immersed dense stacks of circuit boards in a special non-conductive liquid called Fluorinert™”
  • Sempre me perguntei por que o resfriamento líquido não é usado de forma mais ampla em data centers.
    A água tem uma capacidade térmica muito alta e consegue resfriar rapidamente grandes volumes até a temperatura ideal. Ventiladores e ar-condicionado ainda seriam necessários para remover o calor de componentes que não podem usar resfriamento líquido, mas em componentes de alto consumo de energia, como CPUs ou GPUs/motores de computação, seria possível retirar uma enorme quantidade de calor de forma rápida e direta.
    A complexidade e o risco de vazamentos seriam um problema, mas, em data centers na escala da Amazon, não acho que isso seria uma preocupação tão grande.
  • Há bons dados ou visualizações que mostrem a escala desse problema?
    Fico curioso para saber como são as tecnologias de resfriamento de ponta.

• É interessante quando HPC às vezes parece bastante abstraído do hardware
  Os livros parecem tratar bastante de programação SPMD, algoritmos e estruturas de dados, paralelismo de tarefas, sincronização etc., mas parecem trazer pouco sobre detalhes de arquitetura de computadores, como subsistemas de memória de supercomputadores, interconexões de alta largura de banda como CXL e arquitetura de GPUs
  Fico curioso se as abstrações e ferramentas já são boas o suficiente para não ser preciso se preocupar com esses detalhes, ou se os profissionais de HPC também mexem bastante em botões de caixa-preta para extrair desempenho

  • Na maior parte do HPC, não dá para maximizar paralelismo e throughput sem entender profundamente a arquitetura e o comportamento do hardware
    Como princípio geral, para ter escalabilidade ideal, a topologia do software precisa corresponder o máximo possível à topologia do hardware. Software de HPC eficiente é fortemente influenciado pelas características do hardware
    Quando eu escrevia código para hardware novo de HPC, as pessoas sempre se surpreendiam quando eu pedia a documentação do hardware e da arquitetura do sistema, não a documentação de programação. Entender o projeto do hardware deixava claro, a partir de primeiros princípios, como o software deveria ser projetado em cima dele. A documentação de programação tinha muitas meias-verdades feitas para parecer mais fácil para o desenvolvedor do que realmente era
    Algumas plataformas de HPC, para parecerem “fáceis de usar”, comunicavam de forma consistentemente errada o que o desenvolvedor precisava fazer para obter desempenho máximo; quando o software era escrito da forma sugerida pelo marketing, ele às vezes falhava feio por não alcançar o desempenho que o silício era capaz de entregar
    É possível escrever código de HPC sobre abstrações, e muita gente de fato faz isso, mas a perda de desempenho e escalabilidade muitas vezes vem em múltiplos inteiros inevitáveis. Como em outros tipos de software, essas perdas muitas vezes eram aceitáveis quando permitiam que desenvolvedores menos experientes projetassem o código
    HPC também é como qualquer outro software: há muita gente que, embora seja formalmente desenvolvedora profissional, tem dificuldade em entregar bons resultados de forma consistente. Uma parte considerável do hardware caro usado em HPC existe para mitigar perdas de desempenho causadas por mau projeto de software
    Se você quer desempenho máximo, não há atalho além de entender de verdade como o hardware funciona. Não é diferente de software comum; em HPC, o sistema de hardware é apenas maior e mais complexo
  • Comecei a trabalhar com HPC há uns dois anos, em um cluster de cerca de 500 nós de uma empresa Fortune 100. Na verdade, eu estava procurando um trabalho 100% Linux, e até agora tem sido divertido
    Mas foi diferente do que eu esperava. Achei que faria mais trabalho voltado a desempenho, analisaria números e espremeria até o último pouco de performance do cluster. Para ser sincero, no começo nem monitoramento havia. Eu mesmo montei, mas ele quase não é usado. De vez em quando a diretoria pergunta “quão ocupado está o cluster”, por motivos como justificar orçamento
    A maior parte da “otimização” é verificar se as pessoas não estão pedindo 384 CPUs quando o script delas só usa 16, ou testar até quantas CPUs algum software consegue rodar sem degradação de desempenho. Abri o profiler da Intel exatamente duas vezes
    A maior parte do trabalho é mais ajudar os pesquisadores. Normalmente, executamos programas comerciais ou open source e resolvemos problemas, ou pegamos código escrito por outra equipe em outro cluster e fazemos compilar e rodar no nosso. Fuço código Python horroroso e tento compilar projetos em C++ feitos para clusters mais modernos em um ambiente CentOS 7
    É divertido à sua maneira. Como já trabalhei com várias linguagens, gosto de fazer as coisas funcionarem e de investigar crashes e stack traces. Quando você lida com máquinas grandes, seu senso de normalidade fica distorcido ao ver um servidor com “apenas” 128 GB de RAM ou 20 TB de disco
    O assustador é que esses resultados são usados no mundo real, mas às vezes as pessoas que rodam as simulações não fazem isso direito. Já encontrei código errado, código-fonte misturado, uso de dados diferentes daqueles que achavam estar usando e até um bug enorme que existia havia 3 anos. Aí fico pensando se todo o trabalho feito nessa área não fica invalidado
    A desvantagem é que muitos empregos em HPC exigem mestrado, mesmo quando são basicamente só operação de cluster. Não entendo bem. Eu não escrevo o software que executo, nem opero um cluster TOP500 de última geração. É só conectar várias máquinas em rede e rodar código
  • Há muitas abstrações, mas, para saber qual abstração usar, ainda é preciso conhecer bastante o hardware
    Pela minha experiência trabalhando com desenvolvedores CUDA, eles mexem em muitos botões para extrair desempenho. Shmoo Plot(https://en.wikipedia.org/wiki/Shmoo_plot, também chamado de “wedge” em alguns setores) é uma das ferramentas centrais da otimização cotidiana
    Só não sei se eu chamaria isso de caixa-preta. No fim, talvez seja parecido. Mesmo sabendo o que os botões fazem e como funcionam, e fazendo palpites bem fundamentados, é comum medir e se surpreender bastante. A primeira regra da otimização é medir
    Sempre me lembro do primeiro capítulo do “Black Book”, de Michael Abrash, “The Best Optimizer is Between Your Ears” http://twimgs.com/ddj/abrashblackbook/gpbb1.pdf. Embora seja focado em jogos de PC, não em HPC moderno, é um texto excelente que mostra bem a filosofia de alto desempenho
    Quanto às abstrações, o ajuste mais pesado de botões é melhor deixar para o fim do processo de otimização. Isso porque, se você refatorar ou mudar algo, terá de refazer o ajuste. Pequenas mudanças em register spilling ou no padrão de acesso ao cache podem zerar completamente ajustes finos como configuração de threads, cache e tamanho da memória compartilhada
    Ainda assim, uma quantidade moderada de ajuste de botões ao longo do caminho é necessária. Serve para conferir e equilibrar as coisas e para ganhar intuição sobre o espaço de desempenho ao redor do código
  • Como administrador de HPC, normalmente dou suporte a pesquisadores da “cauda longa da ciência”
    No hardware x86_64 atual, não existe algo como um subsistema de memória de supercomputador. É apenas um sistema NUMA sofisticado, e o maior problema é manter a memória perto dos cores, ou seja, manter os dados localmente dentro daquele nó NUMA para reduzir a latência
    O mapeamento de recursos é tratado pelo scheduler. O scheduler conhece o hardware, cria um cgroup que satisfaça os requisitos e seja o mais otimizado possível, e executa a aplicação dentro desse cgroup

Atualmente, o rei das interconexões de alto desempenho é o InfiniBand, que acelera MPI no nível da malha. Dá para fazer envio de mensagens, broadcast e redução de resultados muito rapidamente. Quando a mensagem chega, ela já está reduzida; ao fazer broadcast, basta enviar uma única mensagem, e o broadcast acontece na camada de malha. Placas IB com múltiplos contextos têm muitas filas, permitindo executar vários jobs MPI em um único nó/placa com isolamento por fila/contexto
Ao usar um framework para workloads em GPU, a estrutura e as otimizações geralmente são tratadas automaticamente nesse nível. O trabalho difícil costuma ficar com os desenvolvedores do framework. O driver da NVIDIA também é pura magia negra e cuida de parte das otimizações. A conexão entre GPUs fica a cargo da malha física e é gerenciada pelo driver e por seus próprios daemons
Se o gargalo estiver na CPU, as bibliotecas geralmente já foram ajustadas manualmente pelo fornecedor. É o caso de Intel MKL, BLAS, Eigen etc.; pessoalmente, no Eigen que usei, havia dicas e otimizações específicas por processador
O que é preciso observar é compilar o código para a arquitetura correta e garantir que o hardware em que ele será executado consiga atender aos requisitos. Por exemplo, não fazer acessos aleatórios demais à memória, ajustar bem o prefetcher e o preditor de desvios se quiser ir “o mais rápido possível” no nó, e não abusar do acesso ao disco
No lado da computação numérica, o essencial é manter as tarefas independentes para permitir paralelismo em nível de instrução/vetorização, não fazer cálculos desnecessários e não abusar de MPI — ou seja, reduzir a comunicação entre nós ao estritamente necessário
É fácil falar, mas, quando você se acostuma, pensar nessas coisas vira uma segunda natureza. Isso, se esse tipo de trabalho combina com o seu gosto

• Sim e não
  MPI e OpenMP são os principais meios de abstrair o hardware em HPC. MPI é uma abstração para computação paralela com memória distribuída, enquanto OpenMP é uma abstração para computação paralela com memória compartilhada. Muitos pesquisadores escrevem código só com esses dois, e também é comum usar ambos no mesmo código. Ao usá-los, na maior parte do tempo não é preciso se preocupar com detalhes da arquitetura
  Ainda assim, pesquisadores que gostam de otimizar mais mexem em muitos pequenos detalhes estruturais para extrair mais desempenho. Por exemplo, desenrolamento de loops é bem comum e, pessoalmente, acho que pode ser bastante confuso. Lembro vagamente de ter ouvido que, por causa de uma arquitetura específica de CPU, alguém preferia adições a multiplicações para tentar vetorizar as operações, mas nunca vi isso na prática
  Evitar cache misses também é um tema importante. Certos códigos são escritos para manter as informações mais necessárias no cache da CPU, e não na memória. A maioria dos códigos lida com isso apenas garantindo percurso por colunas em operações de arrays em Fortran e por linhas em C, mas o conceito pode ser levado além. Se você conhece o tamanho do cache do processador, também pode otimizar certas operações para manter todas as informações necessárias dentro do cache e minimizar cache misses. Nunca vi isso na prática, mas era um tema bastante discutido numa aula de computação científica que fiz em 2013
  O uso ou não de uma GPU específica depende muito do problema que você está tentando resolver. Alguns problemas rodam muito bem em GPU; outros são difíceis demais. Infelizmente, não conheço bem essa parte

• Fico impressionado com o Victor por ter reunido um material tão excelente
  Não o conheço pessoalmente, mas, na década de 1990, durante meu doutorado na UT Austin, concluí minha pesquisa usando recursos administrados pelo TACC (Cray Y-MP, IBM SP/2 Winterhawk e o hostname Lonestar, que na época se referia ao Cray T3E). Um dos membros da minha banca de doutorado ainda está lá. Se minha memória não falha, naquela época o TACC era chamado de HPCC ou CHPC
  Naquele tempo, o programador precisava paralelizar o código manualmente e, no meu caso, usei MPI no Cray T3E em ambiente UNICOS. Como a área ainda estava no início, também era necessário ter algum entendimento de hardware. Resolvi os problemas lendo os fichários cinza da Cray e o livro de Gropp e outros que eu tinha em mãos, e, claro, o contato bem informado que mencionei antes também ajudou muito

  • O Lonestar5 voltou a ser Cray. O Lonestar6 atual é um cluster AMD Milan com imersão em óleo equipado com GPUs A100
    O tempo nunca para
  • Trabalhei com ele por meio do TACC em grandes simulações e, em agradecimento pela ajuda, comprei a edição impressa do volume 1 desta série
    Fica um pouco fora da minha área, mas achei muito interessante. Pretendo olhar os demais também, e recomendo que qualquer pessoa interessada dê uma conferida

• Tenho interesse na parte de gerenciamento de hardware em HPC
  Tenho curiosidade sobre como os problemas são detectados e diagnosticados, como são mapeados para ações como reinicialização/reinstalação/reparo, como essas tarefas são agendadas e otimizadas para oferecer o melhor nível de serviço
  Também me interessa como isso é feito quando há vários objetivos a otimizar simultaneamente, como disponibilidade de nós e throughput total, como diferentes topologias afetam os pontos acima, que impacto têm outras restrições e, de modo geral, como esse tipo de problema é tratado do ponto de vista da dinâmica de sistemas
  Não encontrei muitos materiais que tratem bem dessas informações. Se alguém conhecer algum, gostaria que indicasse

  • Se você quer uma perspectiva mais de engenharia, além das redes folded-Clos não bloqueantes comuns ou da Lei de Little, precisa mergulhar em teoria das filas
    Teoria das filas parece trivial e fácil quando se aprende pela primeira vez, mas há muitos problemas em aberto
    Por exemplo, métricas de desempenho de um sistema com tempos de chegada aleatórios, tempos de serviço independentes e k servidores (M/G/k) ainda são um problema em aberto
    https://www.sciencedirect.com/science/article/pii/S0895717704905341
    Ao contrário do que se poderia esperar, há realmente muitos problemas em aberto em teoria das filas
  • Quando entrevistei na Meta e na nVidia alguns meses atrás, isso parecia ser um grande tema
    A Meta tinha alguns bons vídeos no YouTube explicando o problema de lidar com GPUs nessa escala
  • Mark Russinovich faz quase todos os anos uma boa apresentação sobre os bastidores do Azure e os sistemas que o sustentam. [1] é um exemplo, e vale procurar as apresentações de outros anos também
    A Meta também publica muitos artigos, posts de blog e projetos open source em seu site de engenharia [2]
    James Hamilton, da AWS, também faz apresentações sobre infraestrutura quase todos os anos. Vale assistir às de vários anos [3]
    [1] https://youtu.be/69PrhWQorEM?si=u7vh_Um6SQNoyeFH
    [2] https://engineering.fb.com/category/data-center-engineering/
    [3] https://youtu.be/AyOAjFNPAbA?si=nFRJVcQI4EiamC-O
  • Este artigo da Microsoft [1] foi o mais legal que vi nessa área
    Basicamente, ele otimiza no nível da carga de trabalho, aqui tarefas de deep learning, permitindo redimensionamento de tarefas e preempção
    [1] https://arxiv.org/pdf/2202.07848.pdf
  • Vale conferir o projeto openbmc e a associação DTMF

• Em 2013, fiz uma disciplina de computação científica
  Era uma disciplina oferecida em conjunto para ciência da computação e matemática aplicada. O problema é que a área como um todo era ampla demais, então muitos tópicos, incluindo HPC e programação paralela, foram tratados de forma bastante superficial. Não me arrependo de tê-la cursado, mas ela era ampla demais para as aplicações que eu buscava
  Faz anos que não vejo quais disciplinas estão sendo oferecidas, mas, quando eu era pós-graduando, uma disciplina dedicada a computação paralela ao longo de um semestre inteiro teria sido realmente útil. Especialmente uma aula que se aprofundasse em algoritmos e estruturas de dados específicos de computação paralela e distribuída
  Na disciplina de computação científica que cursei, esses assuntos foram tratados de forma superficial demais, como se fosse possível saber exatamente como paralelizar corretamente já na primeira tentativa. Depois disso, como muitos profissionais de HPC, aprendi muito ao longo dos anos sozinho e com colegas, mas estes livros teriam sido muito valiosos como parte de uma disciplina dedicada de um semestre

• É impressionante que o autor tenha produzido livros tão abrangentes, incluindo até treinamento em C++ e ferramentas Unix, e os tenha compartilhado gratuitamente
  Mesmo que não sejam específicos de HPC, há algo para todo programador aprender
  Como material relacionado, há também o livro “Matters Computational”, de Jorg Arndt, e a biblioteca FXT: https://www.jjj.de/fxt/

• Fico curioso para saber como veem o método de ensino de C++ usado aqui. Há alguma desvantagem específica?
  Uso Python há muito tempo, também mexo um pouco com C, C++ e CUDA, e faço pesquisa em nível de aplicação (ML/DL) em ambientes de HPC. Quero melhorar minhas habilidades em C++, e, ao folhear os 3 volumes, eles parecem exatamente no meu nível. Não avançam devagar demais e, em vez de buscar abrangência, ensinam as boas práticas que o autor defende

  • Como programador e educador de C++, esses 3 livros me parecem um material didático para iniciantes bem estruturado. Provavelmente você já sabe a maior parte
    Procurei loops for baseados em intervalo, std::array e std::span, e fiquei satisfeito em ver que todos estão lá
    Como este livro tem relação com HPC, eu acrescentaria algumas coisas. Seria bom haver explicações sobre otimização de valor de retorno, semântica de movimento e, na seção sobre funções recursivas, otimização de chamada de cauda
    Como material para iniciantes, recomendo fortemente
  • Chama a atenção que o volume 2 de “The Art of HPC”, “Parallel Programming for Science Engineering”, cubra MPI e OpenMP em C, Fortran, C++ e, no caso de MPI, Python: https://theartofhpc.com/pcse/index.html
    A propósito, MPI é apenas uma das formas de fazer HPC em Python
    Se me lembro bem, o ipyparallel consegue executar tarefas MPI por cima de um túnel próprio
    Capítulos sobre dask-scheduler, CuDF, CuGraph (NetworkX), DaskML, CuPy e dask-labextension deixariam o conteúdo mais atualizado
    Como o Dask não cuida do armazenamento de dados por você, é responsabilidade do usuário garantir que o armazenamento de dados antes de cada barreira não vire um gargalo de desempenho
    High Performance Computers na documentação do Dask: https://docs.dask.org/en/stable/deploying-hpc.html
    A fonte de números aleatórios também pode ser um gargalo. Não dá para saber antes de perfilar as tarefas em todo o cluster
    Sobre ferramentas de tracing baseadas em eBPF: https://news.ycombinator.com/item?id=31688180
    Depois disso, também seria bom haver conteúdo sobre GitOps e ChatOps, revisão de código e revisões, cotas de recursos de projeto etc.

• Há 10 anos, me ofereceram dividir a função de monitor de uma disciplina de pós-graduação em HPC, mas recusei
  Pelo que vi por alto, posso dizer honestamente que, se este livro existisse na época, eu teria aceitado a oportunidade
  A forma de enquadrar como uma arte, que parece à la Knuth, a perspectiva comparando com marcenaria e a necessidade de você se tornar uma pessoa de DevOps melhor do que o seu próprio responsável por DevOps, tudo isso junto é convincente
  Aplaudo a realização do autor. A UT Austin parece ter feito em ciência da computação algo parecido com o que a North Texas State fez em música

• A UT Austin é uma instituição realmente excelente em HPC e métodos computacionais

  • Quase qualquer BLAS que você queira usar tem alguma ligação, em algum grau, com o TACC da UT Austin

• Quando entrei em uma pequena empresa que dava suporte a engenheiros de HPC de uma grande montadora, fiquei surpreso com a quantidade de scripts desenvolvidos internamente em torno do escalonador LSF
  Muito mais tarde, ao mexer com SLURM em um minicluster pessoal, descobri que as versões do software de escalonamento em geral não são compatíveis entre si. Ou seja, não era possível usar uma versão dentro do cluster e outra nas máquinas cliente externas
  Por isso era necessário um software de cola para enviar tarefas ao escalonador de fora e buscar os resultados depois. Pessoalmente, acho que isso diminui o valor do escalonador
  Eu imaginava que, depois de uns 30 anos de computação distribuída de alto desempenho, os requisitos já seriam bem conhecidos e que pelo menos os comandos e protocolos de troca de dados estariam fixos. Mas parece que não

  • A autenticação em clusters, na verdade, ainda é um ponto problemático em todas as interações. Na maioria dos sistemas, o menor denominador comum é conseguir entrar no nó de login por SSH. A partir daí, os principais comandos de tarefas, como sbatch/squeue, são bastante estáveis
    No passado também houve tentativas de padronizar uma API básica de gerenciamento de tarefas, e o DRMAA é um exemplo notável. No entanto, o DRMAA v2 foi implementado apenas pelo Grid Engine e, na prática, era uma leve abstração da API interna, por isso não obteve suporte de primeira classe em Slurm/PBS/LSF
    No Slurm, a API REST é vista como o caminho daqui para frente. O problema de autenticação é repassado via proxy Apache/NGINX, da forma que o administrador quiser integrar. As APIs básicas de submissão e status de tarefas já se estabilizaram o suficiente para que praticamente qualquer versão de uma aplicação cliente consiga consumi-las no futuro