A energia é uma preocupação onipresente e é impossível otimizar o consumo de energia de um sistema sem considerar o sistema como um todo. Grandes avanços foram feitos na otimização de uma implementação de hardware, mas isso não é mais suficiente. O sistema completo deve ser otimizado.

Há implicações de longo alcance nisso, algumas das quais estão abrindo caminho para a computação de domínio específico. A mudança para a esquerda desempenha um papel, mas, mais importante ainda, significa que todas as partes que desempenham um papel no consumo total de energia para uma tarefa definida devem trabalhar em conjunto para atingir esse objetivo.

A energia está rapidamente se tornando uma consideração de primeira classe. “À medida que a eficiência energética se torna uma preocupação crítica em todos os domínios da computação, os arquitetos são frequentemente solicitados a considerar o custo energético dos algoritmos para design de hardware e software”, afirma Guillaume Boillet, diretor sênior de gerenciamento de produtos e marketing estratégico da Arteris. “O foco está mudando da otimização apenas para eficiência computacional (velocidade, rendimento, latência) para otimização também para eficiência energética (joules por operação). Isso requer considerar fatores como o número de acessos à memória, a paralelização da computação e a utilização de aceleradores de hardware especializados que podem oferecer computação com maior eficiência energética para determinadas tarefas.”

Isso muda o foco da implementação de hardware para a análise arquitetural de hardware e software. “Durante os estágios posteriores do fluxo de design, as oportunidades de otimização diminuem”, diz William Ruby, diretor de gerenciamento de produtos do Grupo EDA de Synopsys. “Você pode ter mais oportunidades de otimização automática, mas está limitado a uma melhoria percentual menor. Ao considerar a curva de poupança potencial (ver figura 1), não se trata de uma curva suave desde a arquitectura até à aprovação. Há um ponto de inflexão na síntese. Antes de o design ser mapeado para uma implementação, você tem muito mais graus de liberdade, mas depois desse ponto de inflexão, as coisas caem drasticamente.”

Fig.1: Oportunidades para economia de energia durante as fases de projeto. Fonte: Sinopse

A grande barreira é que antes do ponto de inflexão, a potência torna-se dependente da atividade, o que torna a otimização automática muito mais difícil. “Durante o desenvolvimento de RTL, verificações dinâmicas orientadas por vetores podem ser usadas para descobrir desperdícios e realizar reestruturação lógica, controle de clock, controle de operador e outras técnicas para reduzi-lo”, diz Qazi Ahmed, principal gerente de produto da Siemens EDA. “Também é importante compreender que a energia é sensível ao caso de uso e deve ser perfilada com cargas de trabalho reais orientadas por software para garantir que todos os cenários possíveis sejam cobertos. Isto é especialmente verdadeiro no contexto do SoC completo, onde o envelope de potência pode ser completamente diferente do que a análise orientada por vetores sintéticos no nível IP pode mostrar.”

“Serão necessários mais planejamento, criação de perfil e otimização iniciais”, diz Tim Kogel, engenheiro principal de prototipagem virtual da Synopsys.

Kogel apontou vários níveis que precisam ser abordados:

• No nível da macroarquitetura, para análise de compensações de alto custo e seleção de elementos de processamento dedicados;
• No nível da microarquitetura, otimizar o conjunto de instruções e unidades de execução para a aplicação alvo;
• No nível algorítmico, selecionar e otimizar algoritmos para eficiência computacional e acessos à memória, e
• No nível do software, fornecer feedback aos desenvolvedores sobre como otimizar seu software em termos de potência e energia.

“Isso exigirá ferramentas conscientes de potência e energia para prototipagem virtual e desenvolvimento de software para gerar os dados, a partir dos quais a implementação de hardware e software pode ser otimizada”, observou ele.

Mapeamento de software
Decidir o que deve estar no software é uma tarefa inicial. “Eu quero ter um núcleo DSP para descarregar a CPU?” pergunta Ruby da Synopsys. “Como isso afeta meu consumo de energia? Quero implementar um acelerador de hardware ou quero executar todas essas funções em software? O custo de energia do software executado na CPU não é zero.”

À medida que os sistemas se tornam cada vez mais definidos pelo seu software, é aí que a consideração da energia tem de começar. “O software é um elemento-chave quando se trata de economizar energia e melhorar o desempenho”, afirma Vincent Risson, principal arquiteto sênior de CPU da Braço. “Aplicativos com uso intensivo de computação geralmente se beneficiam significativamente da otimização de aplicativos. Isso pode ser estático em termos de bibliotecas altamente ajustadas ou estruturas dinâmicas que permitem que a computação seja direcionada ao mecanismo de processamento ideal. Por exemplo, os dispositivos móveis foram padronizados em uma arquitetura de sistema de CPU que fornece aos processadores de aplicativos desempenho de computação diferente, ao mesmo tempo em que está em conformidade com um ISA e configuração comuns. Isso permite que os aplicativos sejam migrados dinamicamente para os processadores com eficiência ideal. Os mecanismos fornecidos para introspecção e versatilidade, proporcionados pela combinação de software e hardware heterogêneo, proporcionarão oportunidades para melhorar a eficiência no futuro.”

Freqüentemente, há mais de uma classe de processador que o software pode executar. “Podemos escolher, com base nos tipos de cargas de trabalho que estamos vendo, onde um determinado aplicativo deve ser executado”, diz Jeff Wilcox, colega e CTO do grupo de engenharia de design para arquiteturas SoC de clientes da Intel. “Se exceder as necessidades de um núcleo menor, núcleos maiores podem ser acionados. Há telemetria e caracterização da carga de trabalho para tentar descobrir onde as coisas devem ser executadas para serem mais eficientes em termos de energia. Muitas das cargas de trabalho que vemos agora são diferentes. Mesmo que sejam agentes simétricos trabalhando na mesma carga de trabalho, eles têm dependências entre si. Cada vez mais cargas de trabalho exigem agentes assimétricos, onde temos GPUs, NPUs, IPUs disponíveis e onde esses tipos de cargas de trabalho cooperam com a CPU. Isso é algo muito mais difícil de otimizar. Chegamos ao ponto em que temos os ganchos para entender os desafios de desempenho e potência, mas ainda estamos construindo as ferramentas para realmente entender como digeri-los e otimizá-los completamente.”

A dificuldade aqui é que a arquitetura da carga de trabalho pode depender da arquitetura do hardware. “Há muitos desenvolvimentos no campo da IA, e não é apenas o tamanho do modelo que é importante”, diz Renxin Xia, vice-presidente de hardware da Untether AI. “É igualmente importante como os modelos são construídos e se são construídos de forma energeticamente eficiente. Isso é mais difícil de responder porque depende da arquitetura. Os custos de energia de um algoritmo executado em uma GPU podem ser muito diferentes do custo de energia desse algoritmo executado em uma memória na arquitetura computacional.”

Foco em software
O consenso geral é que nada disto é possível sem mais cooperação hardware-software. “O codesenvolvimento de hardware e software é necessário para obter essas melhorias funcionais”, diz Sailesh Kottapalli, pesquisador sênior da unidade de data center da Intel. “Apenas tentar fazer isso de forma transparente no hardware já está atingindo seus limites. Veja o que está acontecendo na IA. Se o hardware fosse o único elemento, não veríamos a enorme progressão que estamos a ver. Muito disso são melhorias algorítmicas. Com algoritmos de software, se você reduzir o comprimento do caminho, poderá obter o mesmo resultado com menos instruções e menor trabalho de software. Às vezes, quando você obtém clareza sobre isso, podemos descobrir que para esses algoritmos existe um novo conjunto de instruções ideal, uma nova microarquitetura, e então você pode otimizar ainda mais isso no hardware.”

Requer uma grande mudança nos fluxos de desenvolvimento de software. “No passado, as arquiteturas e os fluxos de software eram otimizados para produtividade, ou seja, processadores de uso geral programados com linguagens de alto nível, usando as ferramentas de software mais rápidas e baratas”, diz Kogel, da Synopsys. “A orientação geral era fornecer o máximo de flexibilidade e produtividade possível e otimizar apenas o que for absolutamente necessário. Isso precisa ser revertido para fornecer apenas a flexibilidade necessária e, caso contrário, usar implementações dedicadas.”

Para muitas funções de software, o acesso à memória é o maior consumidor de energia. “Uma função de software pode ser implementada de diferentes maneiras e isso resulta em diferentes fluxos de instruções com diferentes perfis de potência e energia”, diz Ruby da Synopsys. “Você precisa pesar ou atribuir custos maiores às instruções de acesso à memória. Você precisa ter cuidado ao modelar as coisas. Mesmo que seja apenas a CPU, você precisa modelar os custos de energia no contexto do sistema.”

No futuro, a precisão dos resultados também poderá ser um fator que poderá ajudar na otimização. “É possível obter economias substanciais de energia otimizando o software para utilizar melhor os recursos de hardware disponíveis”, afirma Boillet, da Arteris. “Isso inclui otimizações de compilador, refatoração de código para reduzir a complexidade computacional e algoritmos projetados especificamente para serem eficientes em termos de energia. Este último pode ser alcançado com computação aproximada para aplicações que podem tolerar algum nível de imprecisão, como processamento multimídia, aprendizado de máquina e análise de dados de sensores.”

Análise
Tudo começa com análise. “Podemos criar um modelo virtual do sistema”, diz Ruby. “Então podemos definir casos de uso, que neste contexto são na verdade uma sequência de modos de operação do design. Isso ainda não é software. Você tem o sistema descrito como uma coleção de modelos, tanto modelos de desempenho quanto modelos de potência. E lhe dará um perfil de potência baseado nesses modelos e no caso de uso que você definiu. A próxima alternativa é um tipo semelhante de descrição de sistema virtual. Agora, você executa uma carga de trabalho de software real contra isso. Se você for ainda mais fundo, se quiser mais visibilidade, detalhes mais refinados, você pode pegar a descrição RTL do design, talvez ainda não seja final, talvez ainda seja cedo, mas contanto que esteja quase balançando, você pode colocá-lo em um emulador e execute o trabalho real. Depois de fazer isso, o emulador irá gerar um banco de dados de atividades. Existem recursos de análise de energia orientados à emulação que podem receber uma grande quantidade de dados, centenas de milhões de ciclos de clock de dados de carga de trabalho e gerar um perfil de energia. Há um espectro de coisas que podem ser feitas.”

Em alguns casos, esse pode não ser um período de tempo suficientemente longo. “A maior parte de nossa análise térmica é baseada em análise de circuito fechado, construída em dados de silício, e não em simulação de pré-silício, devido aos comprimentos de traço necessários e à quantidade de tempo necessária para a análise”, diz Kottapalli da Intel. “Não há como simularmos por tanto tempo, para estabelecer um perfil térmico realista. Usamos dados de perfil do silício, usando diferentes tipos de cargas de trabalho e rastreamentos, e depois analisamos quais soluções precisamos construir.”

É mais fácil quando os prazos são mais curtos. “As decisões arquitetônicas fundamentais precisam ser consideradas com algum tipo de visão poderosa em mente”, diz Ruby. “Você precisa de um modelo mais abstrato e de nível superior de todas as partes do seu sistema, incluindo todos os núcleos de processamento e o subsistema de memória, porque a forma como isso é organizado é muito, muito importante. Quanta memória é realmente necessária? Estas são decisões arquitetônicas fundamentais. Você precisa ter alguns dados de potência associados a esses componentes. Quanta energia a CPU está consumindo nesta carga de trabalho específica ou nessa carga de trabalho específica? E quanto ao núcleo do DSP, ao hardware, à memória, à rede no chip – quanto cada um deles consome ao realizar cada operação? Eles são necessários para tomar decisões arquitetônicas fundamentais.”

São necessárias muitas novas ferramentas relacionadas à energia. “Embora existam ferramentas EDA para lidar com transientes de alta velocidade e alta densidade de potência, existem muitos outros desafios”, diz Wilcox da Intel. “Alguns dos outros desafios são a dinâmica constante de tempo mais longo ou como gerenciar as coisas no SoC. Não tenho visto tanta coisa no espaço da EDA que esteja ajudando nisso. Estamos criando mais ferramentas internas para tentar desenvolver essas capacidades.”

Embora tenham sido desenvolvidas ferramentas para o lado do hardware dessas compensações arquitetônicas, existem poucas ferramentas hoje para ajudar no lado do software. “Precisamos que nossos engenheiros de software produzam o código correto o mais rápido possível”, diz Ruby. “O que acredito ser realmente necessário é algum tipo de tecnologia complementar para o desenvolvedor de software. Assim como temos ferramentas de análise de potência RTL para o hardware, os sistemas de desenvolvimento de software precisam de algum tipo de perfil de potência que lhes diga quanta energia esse código está consumindo. Como vivemos na era da IA, seria legal ter a tecnologia de IA analisando o código. Você obtém uma estimativa do consumo de energia e alguma tecnologia de IA pode dizer que, se você reestruturar seu código, dessa forma, poderá economizar muita energia.”

Conclusão
O mundo do hardware está atingindo barreiras relacionadas à potência e à energia. Os limites e preocupações térmicas estão crescendo nessa comunidade. Sem levá-los em consideração, a funcionalidade do hardware não pode crescer. Mas estas não atingiram o nível de preocupações a nível do sistema. Até que todas as partes que contribuem para o consumo de energia se sentem na mesma sala e projetem o sistema para ser energeticamente eficiente, não veremos verdadeiras soluções para o problema.

Há um segundo lado nisso também. Todas as pessoas que produzem as ferramentas que essas pessoas usam também precisam entrar na mesma sala e desenvolver fluxos que permitam que todos tenham sucesso. Embora tenha havido algum progresso entre a EDA e o mundo dos sistemas para resolver alguns dos desafios térmicos, há menos progresso a nível arquitetónico e quase nenhum progresso entre os mundos do hardware e do software. Protótipos virtuais que se concentram na funcionalidade não são suficientes. Eles precisam ser estendidos à potência e energia do sistema, e isso não pode ser feito sem o envolvimento dos desenvolvedores do compilador. Há uma oportunidade na computação de domínio específico, porque essas pessoas estão tomando uma nova direção em hardware como resultado desses problemas, e isso pode ser importante o suficiente para que façam progressos nas áreas adjacentes. Mas tudo parece permanecer muito tempo no futuro.

Leitura relacionada
O aumento do preço do poder em chips
Mais dados requerem processamento mais rápido, o que leva a uma série de problemas – nem todos óbvios ou mesmo solucionáveis.

• Conteúdo com tecnologia de SEO e distribuição de relações públicas. Seja amplificado hoje.
• PlatoData.Network Gerativa Vertical Ai. Capacite-se. Acesse aqui.
• PlatoAiStream. Inteligência Web3. Conhecimento Amplificado. Acesse aqui.
• PlatãoESG. Carbono Tecnologia Limpa, Energia, Ambiente, Solar, Gestão de resíduos. Acesse aqui.
• PlatoHealth. Inteligência em Biotecnologia e Ensaios Clínicos. Acesse aqui.
• Fonte: https://semiengineering.com/optimizing-energy-at-the-system-level/