Ecossistemas de software: princípios de construção

imagem



Este artigo está passando por momentos difíceis. Alguns meses atrás, pediram-me para escrever uma revisão sobre o assunto da construção de ecossistemas de software para diferentes arquiteturas. No início neguei e brinquei com o espírito que o ecossistema não é biologia. Não é nem tecnologia. Isso é exclusivamente sobre dinheiro. E às vezes sobre política. Então ele juntou sua vontade em um punho, pensamentos em uma pilha, sentou-se e escreveu tudo literalmente em um dia. Em inglês. A revisão foi então traduzida para o chinês e publicada. “A caminho”, o tradutor melhorou significativamente o texto e acrescentou alguns pensamentos interessantes. Então eu decidi que o texto poderia ser do interesse do público de Habr, e também útil para me referir a ele no futuro. E ele começou a esculpir a versão russa, munido do original inglês e da tradução chinesa. Foi a mesma luta com termos específicos em inglês (ecossistema SW? = Ecossistema de software,habilitando? = promoção, engenheiro de aplicação? = engenheiro de aplicação) e ainda hieróglifos obscuros. Como resultado, o texto em russo demorou mais do que o inglês e o chinês combinados ... Acontece.





Nas últimas quatro ou cinco décadas, vimos muitos esforços para trazer novas arquiteturas de processador e microcontrolador ao mercado. Muito poucos deles provaram ter sucesso a longo prazo. Dois dos exemplos mais reveladores são a arquitetura x86 para servidores e PCs e ARM para telefones celulares e microcontroladores. O resto ou ocupou (ocupou) um pequeno nicho, ou não existiu por muito tempo. Obviamente, um dos principais componentes do sucesso de uma arquitetura de computação como um todo é sua capacidade de atender às necessidades mais importantes do cliente em seu segmento. Para servidores, essa demanda é desempenho; para dispositivos móveis, baixo consumo de energia / longa duração da bateria. Mas outro fator importante é a presença de um rico ecossistema de software,o que permite que você desenvolva com eficácia um novo software, bem como porte o existente. A criação de um ecossistema é um processo muito demorado e caro, uma vez que todos os softwares aplicativos necessários devem ser desenvolvidos. Mas só assim a arquitetura pode ocupar o segmento de mercado-alvo. No entanto, uma vez que um ecossistema é desenvolvido, ele serve como um mecanismo de defesa natural, evitando que arquiteturas concorrentes entrem no mercado. Neste artigo, o autor resume as principais lições aprendidas com a experiência aplicada à tarefa de construir um ecossistema ARM no segmento de mercado de servidores.Mas só assim a arquitetura pode ocupar o segmento de mercado-alvo. No entanto, uma vez que um ecossistema é desenvolvido, ele serve como um mecanismo de defesa natural, evitando que arquiteturas concorrentes entrem no mercado. Neste artigo, o autor resume as principais lições aprendidas com a experiência aplicada à tarefa de construir um ecossistema ARM no segmento de mercado de servidores.Mas só assim a arquitetura pode ocupar o segmento de mercado-alvo. No entanto, uma vez que um ecossistema é desenvolvido, ele serve como um mecanismo de defesa natural, evitando que arquiteturas concorrentes entrem no mercado. Neste artigo, o autor resume as principais lições aprendidas com a experiência aplicada à tarefa de construir um ecossistema ARM no segmento de mercado de servidores.



O desafio de hoje



Hoje provavelmente estamos testemunhando o momento mais interessante do mercado de microeletricidade. Ao contrário de 5 anos atrás, quando a Intel controlava 95% do mercado corporativo, hoje temos mais inovações arquitetônicas do que nunca. O primeiro a mencionar os chips da série Ryzen , que competem seriamente com a Intel. No entanto, essa inovação não é arquitetônica: os processadores AMD usam o ecossistema x86 desenvolvido. Sua vantagem está em sua implementação eficiente. Outras inovações são mais interessantes porque exigem a construção de um novo ecossistema de software.



A "revolução da inteligência artificial" iniciada e liderada pela NVidia revolucionou o cenário do mercado de servidores. Ela criou um segmento totalmente novo, quase exclusivamente controlado por seu criador. É baseado em -plataforma de programação paralela CUDA . CUDA (introduzido pela primeira vez em 2007) é um dos exemplos interessantes de construção de um ecossistema, vamos examiná-lo com mais detalhes posteriormente. Por sua vez, a Intel está tentando introduzir sua própria GPU (baseada em parte no sistema gráfico Gen ) para competir no campo da inteligência artificial. A Intel lançou o kit de ferramentas OneAPI para criar o ambiente de programação . Este é um conceito ambicioso de um método universal para aceleradores de programação (GPU, AI, FPGA, etc.). Além disso, a Intel usa código aberto para OneAPI, o que torna a interface mais atraente do que os modelos de código fechado. O ponto central do conceito OneAPI éData Parallel C ++ . É um conjunto de extensões C ++ baseadas no padrão CYCL. Parece-me que o sucesso dessa interessante tentativa dependerá da inclusão dessas extensões em padrões C ++ futuros. E também da implementação efetiva da GPU da Intel. O exemplo mais recente é a penetração da arquitetura ARM no campo da inteligência artificial, nuvem e computação de alto desempenho. A arquitetura ARM é conhecida por seu sucesso em mercados de baixo consumo de energia e possui um ecossistema de software significativo. Portanto, uma tentativa de penetrar nos segmentos de mercado mais elevados parece natural. Este é o caso mais interessante para nós, e o consideraremos mais detalhadamente sob vários pontos de vista.



Tecnologia



Contexto tecnológico que apresentei aqui .



Economia



O aumento da concorrência da AMD para a Intel levou a uma significativa "guerra de preços" entre os gigantes dos processadores. Isso reduz a receita dos produtores, mas facilita a vida dos usuários finais. Pelo contrário, no campo da inteligência artificial, estamos vendo o domínio da NVidia, que dita o preço ao mercado. E aqui os consumidores estão procurando mais ativamente por sistemas alternativos.



Política



Em conexão com o aumento das tensões geopolíticas, China e Rússia definiram um curso para o desenvolvimento de um ecossistema 100% independente. No entanto, isso significa mais do que apenas independência de hardware. O software desempenha um papel igualmente importante. Muitos aplicativos precisam ser migrados ou substituídos para garantir a verdadeira independência. A imagem abaixo ilustra a situação na Rússia.



imagem



O fator político cria uma forte demanda por recursos para fechar as lacunas de software e suporte de longo prazo para esses esforços. Existem várias forças poderosas por trás da criação do ecossistema ARM. Mas também existem problemas muito sérios. Deixe-me citar alguns deles:



Problema típico do estágio inicial da galinha e do ovo



Alguns aplicativos comerciais de código fechado estão se tornando o padrão de fato para segmentos importantes. Por exemplo, SAP-Hana, Oracle para bancos de dados, VMWarepara virtualização, etc. Normalmente, os desenvolvedores não estão interessados ​​em portar e manter seus produtos em uma arquitetura que não tem participação de mercado suficiente. Por outro lado, os usuários finais não compram hardware não compatível com o software. Existem várias maneiras de quebrar esse círculo vicioso. A primeira é pagar (muito) dinheiro a empresas de software pela portabilidade. A segunda é criar uma solução competitiva que empurre o produto para fora do mercado ou force a portabilidade desejada. A terceira é convencer um dos grandes desenvolvedores de customização a "pressioná-lo". No entanto, nenhuma das rotas é fácil ou barata.



Software legado



A maioria dos aplicativos no mercado de servidores foi escrita e otimizada por décadas para a arquitetura x86 dominante. Explícita ou implicitamente, a aposta foi colocada mais no desempenho single-threaded do que no paralelismo maciço. Portanto, mesmo se o código-fonte estiver disponível, um retrabalho e otimização significativos podem ser necessários para executar com êxito em servidores ARM.



Existem muitos problemas no horizonte, e para resolvê-los devemos estudar



Lições do passado



A história de várias arquiteturas e ecossistemas de software é um tópico bastante interessante para eles, mas mesmo a cobertura mínima excede significativamente o volume deste artigo (o suficiente para várias dissertações). Portanto, descreverei vários casos notáveis ​​que podem nos ajudar a navegar nas circunstâncias atuais.



No início,



quando a Intel lançou seu primeiro processador 8080 de 8 bits em meados dos anos 70, ela tinha pouca vantagem arquitetônica sobre seus concorrentes, o Motorola 6800 ou o Zilog Z80.... Mesmo assim, a Intel foi a primeira a reconhecer a importância do software na promoção do hardware. Ela também foi a primeira a apresentar seu próprio compilador para acelerar, simplificar e reduzir o custo de desenvolvimento de software. Foram as ferramentas que criaram uma vantagem competitiva importante para a Intel e permitiram que ela tivesse sucesso desde o início. Mais tarde, a Intel introduziu o MKL para álgebra linear, VTunepara otimização de programa e muitas outras ferramentas que desempenharam um papel importante na formação do ecossistema x86. Além disso, a Intel garantiu a compatibilidade de suas ferramentas. Mais tarde, a Intel percebeu a importância do SO, que gerencia o funcionamento do hardware. Sua parceria com a Microsoft (Wintel) se tornou a força dominante no mercado de PCs por cerca de três décadas. Porém, com o desenvolvimento do mercado de servidores, o Linux e o código aberto em geral se tornaram muito relevantes. Assim, a Intel se tornou o principal contribuidor para o kernel Linux, e ainda está na posição número 1 (adivinha quem é o número 2?). Mais importante, a Intel sempre aderiu estritamente à compatibilidade binária (compatibilidade com versões anteriores) de suas plataformas. O fato de que binários criados para qualquer geração anterior de arquitetura funcionam em uma geração posterior fora da caixa,e permitiu que o x86 se tornasse a força dominante. Construir um ecossistema leva tempo, mas vale a pena.



Nascer e no pôr do sol



Este é o único contra-exemplo em que um ecossistema desenvolvido jogou contra seu criador. No início dos anos 2000, a Sun Microsystems tinha um nicho significativo no mercado de servidores SPARC. A empresa iniciou e desenvolveu o ecossistema Java . O problema, entretanto, é que a máquina Java é baseada em um interpretador, não em um compilador. Portanto, quando as circunstâncias forçaram a Sun a abrir o Java, foi o começo do fim. Ao implementar o interpretador Java para x86, a Intel gradualmente tirou a Sun do mercado de servidores. A lição a ser aprendida é que as linguagens interpretadas (tão populares hoje) não são defensoras eficazes da participação no mercado.



O sucesso da ARM no mercado de baixo consumo de energia



A arquitetura de estação de trabalho lidera o mercado de telefones celulares e tablets desde o início dos anos 2000. A natureza de seu domínio é muito diferente do x86 em PCs e servidores. ARM é uma comunidade aberta - a licença é relativamente barata, o que cria os pré-requisitos para um grande número de jogadores entrar no jogo. E o sistema operacional Android aberto reduz ainda mais a barreira de entrada. Ele também desempenhou um papel importante quando os principais participantes (Samsung, Qualcomm, Huawei etc.) perceberam a necessidade de uma aliança industrial para criar um ecossistema. Isso tornou possível construí-lo em um tempo muito curto.



Tentativa da Intel de invadir o mercado móvel



Por volta de 2007, a Intel (ou antes) percebeu o potencial do mercado de celulares e tablets e tentou conquistá-lo. O projeto foi baseado na arquitetura Atom (x86 com baixo consumo de energia) e tradução binária de ARM para x86 ( Houdini ). Esse mecanismo alavanca o ecossistema de software existente. Os aplicativos foram lançados em dispositivos Intel em tempo recorde. No entanto, dois fatos jogaram contra a Intel. O primeiro é a incapacidade de alcançar o ARM em termos de consumo de energia. O segundo é a complexidade da tradução binária de RISC para o conjunto de instruções CISC mais complexo... Essa tradução envolve sobrecarga significativa que pode ser inaceitável para algumas classes de aplicativos. Assim, a transmissão binária pode ser vista como uma ferramenta de entrada no mercado, mas dificilmente pode servir como uma solução de longo prazo.



Ecossistema CUDA



Embora o sucesso da Nvidia no segmento de IA seja inegável, o desenvolvimento de seu próprio ecossistema CUDA ainda levanta minhas dúvidas. Por exemplo, em HPC, a proporção de aplicativos que usam CUDA ainda é baixa. O motivo é o alto custo de portabilidade e manutenção de tais aplicativos. Alguns desenvolvedores portaram (com considerável ajuda dos engenheiros da NVidia) seus códigos, mas depois os abandonaram devido ao custo de suporte. Pelo contrário, no segmento de inteligência artificial, a posição da Nidia é extremamente forte. No entanto, os pesquisadores usam principalmente estruturas de nível superior ( TensorFlow , PyTorchetc.) e não programe diretamente em CUDA. Isso nos leva à conclusão de que escolher o nível certo de abstração para o “chicote de software” é de grande importância para o avanço do hardware.



De volta para o Futuro



Agora, voltemos à nossa tarefa, armados com as lições do passado.



Aliança da indústria



O maior problema com o ecossistema ARM no segmento de servidor, em oposição ao móvel, é que ele ainda está muito fragmentado. Precisamos de algum tipo de centro de atração para coordenar esforços. A aliança parece natural, visto que a participação de todos os fornecedores de ARM no mercado de servidores é de cerca de 1%. Eles simplesmente não têm razão para competir. A tarefa de construir um ecossistema em conjunto deve ter precedência sobre a diferenciação entre eles. Várias tentativas foram feitas para criar tal aliança.



Pode ser feita menção ao Open Green Computing Consortium (openGCC - é difícil para um programador pensar em um nome mais maluco) e nossos esforços recentes emARM Advanced Technology Committee dentro do APKIT . Este pode ser um bom começo, mas ambos são alianças locais. Open GCC é uma organização chinesa e APKIT é uma organização russa. A indústria dita a necessidade de uma aliança global que possa servir a vários propósitos:



Sincronização e influência regulatória



Em primeiro lugar, é necessário haver algum acordo entre os próprios fornecedores de ARM para garantir a portabilidade do software em plataformas de vários fornecedores. Em segundo lugar, proporcionará uma oportunidade de trabalhar com organismos de normalização internacionais e locais. Terceiro, enviará um sinal poderoso aos governos e comunidades de que o ecossistema ARM emergente pode servir como uma alternativa viável ao existente. Embora este fato não seja totalmente percebido.



Trabalhando com fornecedores de sistemas operacionais e aplicativos



Como vimos por experiência própria, os sistemas operacionais desempenham um papel central na construção de um ecossistema de software. Você também pode notar que os sistemas operacionais desenvolvidos por fornecedores de hardware não têm sido historicamente muito bem-sucedidos (com exceção da Apple). Portanto, trabalhar com fornecedores de sistemas operacionais é estrategicamente muito importante. Parte disso está acontecendo agora - patches, atualizações, aparecendo nas versões mais recentes do kernel Linux, compiladores e glibc, melhoram o desempenho dos sistemas ARM para uma ampla variedade de cargas de trabalho. Mas esse esforço ainda é muito fragmentado, com cada fornecedor fazendo isso por conta própria, o que geralmente leva muito tempo. A Alliance pode ajudar a sincronizar esses esforços e acelerar a adoção de atualizações.



Também vimos que resolver o problema do ovo e da galinha no início do avanço de uma arquitetura pode ser muito difícil. A aliança pode fornecer alavancagem adicional nas negociações com fornecedores de software e ajudar a dividir o fardo da promoção antecipada entre os fabricantes de hardware.



Sistema de distribuição de software O



terceiro ponto importante aqui é a distribuição de software. Hoje em dia, o software de servidor ARM é geralmente criado a partir da fonte, o que consome tempo e recursos de hardware. Já para x86, há um esquema prático baseado em RPM usado para distribuição. Fazer algo assim exigirá muito trabalho dos ISVs e dos fornecedores de sistemas operacionais. E a aliança pode ser muito útil para auxiliar nessa direção.



Criando ferramentas eficazes



No passado, as ferramentas de software provaram ser uma ferramenta confiável para o desenvolvimento de ecossistemas. Portanto, hoje a atenção a eles é de importância crítica. Um dos melhores exemplos é a Intel Corporation, que combinou desenvolvedores de software e engenheiros de aplicativos em uma organização, conforme mostrado abaixo. Vermelho indica interação crítica, verde indica regular, amarelo indica esporádica.



imagem



Isso garante uma estreita colaboração entre os desenvolvedores de ferramentas. Isso permite que os engenheiros de aplicação (AEs) usem as melhores ferramentas do setor. Os AEs que executam as mesmas cargas de trabalho compartilham conhecimento entre si e fornecem feedback consolidado aos arquitetos de hardware. Etc. Etc. Tudo isso levou a um fenômeno interessante: os engenheiros que trabalhavam em tal organização começaram a pensar não apenas em seus produtos, mas também no amplo cenário do ecossistema. Eles levam em consideração a interdependência entre si, bem como o impacto no ecossistema como um todo,

mas, para criar tal organização, é necessário um tipo de "linguagem comum" que todas as partes possam usar para se comunicar. Em algum ponto, o método de análise de microarquitetura TMAM se tornou tal.



imagem



TMAM fornece uma maneira de coletar, interpretar e usar eventos de microarquitetura para criar perfis e otimizar aplicativos.



imagem



A vantagem mais importante desse método é que ele dá uma imagem objetiva do que está acontecendo no hardware e permite que você aprimore tanto ele quanto o software. Mas, talvez mais importante, é um veículo único para construir uma organização eficaz de promoção de hardware.



Conclusão



Construir um ecossistema ARM no mercado de servidores parece promissor do ponto de vista econômico, político e tecnológico. No entanto, está ocorrendo em um cenário de forte competição da arquitetura x86 dominante. Além disso, os primeiros problemas do avanço da arquitetura ainda estão longe de ser resolvidos. No entanto, acredito que, no futuro, o ARM pode se tornar uma força séria no mercado de servidores. A criação de uma aliança industrial global e de uma organização eficaz para a construção de ecossistemas parece altamente desejável.



Construir um ecossistema ARM no mercado de servidores parece promissor do ponto de vista econômico, político e tecnológico. No entanto, está ocorrendo em um cenário de forte competição da arquitetura x86 dominante. Além disso, os primeiros problemas do avanço da arquitetura ainda estão longe de ser resolvidos. No entanto, acredito que, no futuro, o ARM pode se tornar uma força séria no mercado de servidores. A criação de uma aliança industrial global e de uma organização eficaz para a construção de ecossistemas parece altamente desejável.



A Rússia é vista como uma das arenas mais promissoras para a construção do ecossistema ARM de muitos pontos de vista. O compromisso do governo com a independência da informação fornece suporte de longo prazo para essa iniciativa. No entanto, o potencial do ecossistema ARM ainda não foi totalmente realizado no nível governamental. É necessário um trabalho sério para que nossa voz seja ouvida. Outra razão é o mercado relativamente grande e a variedade de marcas personalizadas, tanto privadas quanto públicas. Por exemplo, pode-se citar gigantes extratores de recursos (Gazprom, Lukoil, Rosneft), bancos líderes (Sberbank, VTB, Alpha), provedores de serviços móveis (MTC, Megafon, Beeline, Tele2). Há uma consciência crescente da necessidade de alternativas à infraestrutura existente (x86, IBM, Oracle), tanto em termos de segurança quanto em termos de preços.



E por último, mas não menos importante, recursos humanos. Existem muitos programadores na Rússia com experiência em resolver problemas de ecossistemas e pensam nesses termos.



All Articles