Os últimos dias ainda restam antes do Coringa, e eu realmente queria trazer para Habr não uma entrevista comum, mas um jogo poderoso. Recentemente, as pessoas se interessaram por servidores no Arm, e aconteceu que temos verdadeiros especialistas nesse tópico.
Alexander (
alexbel ) Belokrylov e Lesha Voitylov, juntamente com Grigory Labzovsky, que liderou o centro de desenvolvimento Oracle em São Petersburgo, fundaram a BellSoft há pouco mais de um ano. Agora a empresa está operando, desenvolvendo e já ganhou fama no mundo Java.
Pelo volume de confirmações no OpenJDK no ano passado, elas ficaram em quinto lugar, e agora apenas Oracle, Red Hat, SAP e Google estão à frente:
Você precisa entender que a BellSoft não é apenas Arm:
- Liberica JDK 11 foi lançado , Linux x86_64, Windows, Linux ARMv8, Linux ARMv7 (incluindo Raspberry Pi) são suportados. As compilações serão definidas para Mac e Solaris Sparc.
- Imagens para todas as arquiteturas são publicadas no Docker Hub para Debian, CentOS, Alpine. A imagem para Alpine é feita da versão lite com
--compress 2 portanto, é significativamente menor que o JDK usual.
Nesta entrevista, tocaremos apenas em Arm e deixaremos o resto para a próxima vez.
Então hoje em nosso estúdio virtual:
Alexander Belokrylov
Lesha Voytylov
Oleg Chirukhin - editores do grupo JUG.ru
Conte-nos mais sobre a empresa?
A empresa BellSoft está envolvida em várias áreas. Todo mundo provavelmente sabe que a Oracle em São Petersburgo tinha um conhecimento de baixo nível muito sério no desenvolvimento do Java Runtime, no desenvolvimento de compiladores, no desenvolvimento de sistemas de serviço em nuvem Oracle. E essa experiência da Oracle migrou para a BellSoft. Hoje, nossa empresa está desenvolvendo o Java Runtime, contribuindo ativamente com o OpenJDK, desenvolvendo os compiladores gcc e llvm, contribuindo para a pilha Apache, Graal. Estamos envolvidos na construção de sistemas de análise de big data, sistemas de recomendação e construímos um pequeno projeto em IoT, para coletar dados de dispositivos do mundo real. Em algum momento, vimos que a Oracle parou de lançar uma distribuição Java para plataformas Arm e lançamos nossa própria distribuição, chamada Liberica JDK para Raspberry Pi. Desde então, apoiamos com sucesso.
Vamos dar uma olhada. O que é uma pilha Apache, por exemplo?
Começamos a contribuir para a Apache Foundation com o Hadoop - muito está ligado a certas partes deste projeto. O OpenJDK e os grandes projetos Apache, embora não diretamente, são altamente interconectados.
Por que tudo isso é necessário? Por exemplo, algumas classes que as atrasam podem ser feitas com overclock?
Sim, esta é uma das áreas em que estamos trabalhando - melhorando a produtividade. Por exemplo, partes específicas da plataforma, cuja aceleração no OpenJDK pode ajudar a acelerar o Hadoop. Se estiver interessado, podemos conversar sobre isso.
Quando você resolve problemas de desempenho, faz sentido ver algo próximo. Talvez haja o mesmo problema em algum lugar. Muitas vezes você vê que, depois de corrigido em um lugar, é necessário corrigi-lo em alguns lugares, para que, em geral, fique melhor. Às vezes (e muitas vezes) a otimização do desempenho é decomposta em contribuições para vários projetos. Se você deseja melhorar, por exemplo, o desempenho da checksum de checksum , observe a parte inferior da pilha. Digamos que seja Java. Se você parecer um pouco mais alto, será o Hadoop, Spark ou outra coisa. Geralmente, entendendo como melhorar um lugar, você pode entender como fazê-lo em outro lugar. Obviamente, nesse sentido, faz sentido melhorar também.
Todo mundo sabe que você é Liberica :-) Vamos falar sobre isso.
Sim, somos o Liberica JDK. O Liberica começou com o fato de que vimos que não há porta para o ARM32, e isso precisa ser feito com urgência, porque o Raspberry Pi ficou sem o Java 9 e o Java 10. Isso foi em 2017 quando o Java 9. foi lançado. Agora, o Liberica JDK suporta muitas arquiteturas e sistemas operacionais.
Ficou claro que a Oracle não iria desenvolver ainda mais o código para Arm, e começamos a distribuir e liberar ativamente nossa distribuição para fechar essa lacuna. Ficou claro que as pessoas precisam.
Então, agora existem várias distribuições Arm?
Sim, existem várias distribuições Java para Arm, elas são diferentes. Na nossa, você realmente obtém o que costumava fazer parte do kit de distribuição de portas Oracle. Nossa distribuição possui JavaFX, entrada / saída de dispositivo e uma API incorporável. Este é um pacote e tudo funciona com módulos, começando com o JDK 9. Usando um sistema modular, você pode criar o Runtime como desejar. Se desejar, você pode criar um pequeno tempo de execução de 16 megabytes. Se você deseja ativar mais recursos, por exemplo, um servidor da Web, precisará gastar cerca de 32 megabytes de espaço estático. Você pode obter um Runtime funcional para suas necessidades.
Até onde eu entendi, estávamos conversando sobre servidores do exército. Para não dizer que os usamos maciçamente. Conte-me sobre o servidor? Na vida real eles existem?
Esta história existe há muitos anos. O primeiro servidor Arm foi criado com base na arquitetura ARMv7 de 32 bits. Era uma caixa terrivelmente barulhenta, que praticamente não funcionava, porque o BIOS, o Linux não funcionava lá, tudo desapareceu depois de algumas horas. A empresa que a iniciou, Calxeda, fechou com o tempo. Mas a idéia de desenvolver uma arquitetura alternativa para servidores foi semeada na sociedade. A Arm finalmente lançou uma nova especificação para a arquitetura ARMv8, que suporta 32 e 64 bits. Com base na versão de 64 bits desta especificação, vários fabricantes estão construindo suas implementações de processador para servidores. Por exemplo, a Ampere Computing, Cavium, que agora é comprada pela Marvell, e pela Qualcomm. E há outra empresa - a AMD, há alguns anos, também lançou servidores com base na arquitetura Arm. Na minha opinião, eles ainda continuam fazendo isso.
Se você remover uma letra L da Marvell, obterá super-heróis. Uma boa maneira de lembrar os nomes de todos esses escritórios.
Os super-heróis de fato são Cavium / Marvell, por causa de todos eles, eles conseguiram montar o chip mais produtivo de até 128 threads em uma CPU e um desempenho comparável ou melhor com o Xeon Gold e Platinum. Você pode colocar várias CPUs em um servidor, obtém uma coisa monstruosa com memória rápida que pode ser usada para tarefas sérias.
Como o limite de escalabilidade aumenta para aplicativos comuns? Quanta CPU faz sentido ficar em um servidor?
Tudo depende de qual tarefa você deseja construir o servidor. Fabricantes diferentes se concentram em nichos diferentes, mas se estamos falando sobre Cavium / Marvell, eles claramente se concentram no nicho da computação, onde você precisa coletar rapidamente uma grande quantidade de dados em paralelo. Eles não se concentram no desempenho super grande de um único encadeamento (ao mesmo tempo, é muito bom), ou seja, em geral, para que esta CPU mostre alto desempenho com baixo consumo de custo.
Por que Arm, não Intel? Temos servidores Intel maravilhosos, por que criar outra coisa?
É difícil e fácil responder a essa pergunta. Em primeiro lugar, um lugar sagrado não fica vazio. Vimos que a AMD também está tentando criar algum tipo de Intel alternativo para aplicativos de servidor. E, é claro, sempre haverá alguma peça alternativa do mercado de fabricantes alternativos.
Ninguém quer viver com um monopolista.
Observação muito verdadeira. Todos os consumidores de processadores, e principalmente os provedores de nuvem, querem uma oportunidade para uma alternativa. Para que você possa escolher, compare o custo com os custos e, para aplicativos específicos, escolha uma arquitetura mais lucrativa.
E quanto aos custos? Quanto mais caro que as soluções Intel?
Esta é uma pergunta difícil. Em primeiro lugar, como Alexey disse, os fabricantes são suficientes. É claro que agora os fabricantes de processadores Arm não competem entre si, mas competem com outra pessoa. Eles ocupam nichos ligeiramente diferentes. Se a Cavium é uma computação de alto desempenho, a Qualcomm é um servidor intermediário, o Ampere é uma estação de trabalho ou um servidor de baixo custo.
Se bem me lembro, o preço do próprio CPU da Ampere Computing é de US $ 600 a 900, e eles competem com a Intel, um CPU que custa cerca de US $ 1.500. Cavium é um pouco caro. Novamente, eles competirão com a Intel, que é significativamente mais cara. Você precisa entender que o preço do servidor não é apenas o preço da CPU. O preço do servidor também é memória, discos, suporte, consumo. Se você ganhar em um parâmetro, por exemplo, o custo da CPU - tudo bem, mas você ficará um pouco mais barato. Se você vencer de duas maneiras, por exemplo, sendo mais barato, oferecendo um desempenho ainda melhor, eles o examinarão mais de perto. E se em três, por exemplo, você também pode fazer tudo isso com menos consumo de energia, esse já é um pedido de vitória.
Além do ferro e seu suporte, o suporte em software também é importante. Você não pode rodar no Arm tudo o que agora gira na Intel.
Claro. Devo dizer que o ecossistema Arm de software avançou muito. Se há cinco anos houve problemas para levantar um pedaço de ferro, agora não existem problemas. Você veio e tudo saiu da caixa para você. Tudo com o qual você se acostuma - Linux, Docker, Kubernetes, Xen, Java, Hadoop, Spark, Kafka, qualquer coisa.
E o Java? Diga-nos como funciona, como é diferente do "habitual"?
Não é diferente, esta é a sua principal vantagem. É produtivo o suficiente para lidar com as tarefas atribuídas ao Java para servidores. Você transfere seu aplicativo (espero que ele não tenha uma parte nativa, caso contrário você precisará recompilá-lo), para o servidor Arm, verifique o desempenho e, na maioria dos casos, se regozije. Recentemente, foi publicado um artigo onde comparamos o desempenho do servidor Arm com o servidor Intel . O artigo saiu na Java Magazine.
A Oracle permitiu que você anunciasse essencialmente em seu próprio diário? Sério.
Aparentemente, há uma demanda. Acontece que os servidores Java Arm para cargas de trabalho Java funcionam muito bem. Eles são os mesmos, ou até melhores que os da Intel.
Quem deve ler seu artigo?
Para quem quiser ver, teste a nova arquitetura, se é adequada para suas cargas. Experimente o Java e os mesmos servidores Arm. Dirija o Arm Server Cloud para o Google e, com vários provedores de nuvem, você pode segurar um cartão e tentar o que precisa.
O Java já está pré-instalado lá?
Sim OpenJDK simples.
O OpenJDK regular e sua distribuição Liberica são a mesma coisa? Vi que existem seus commits - é isso ou alguma outra coisa?
Em geral, a história dos portos Arm e do OpenJDK é bastante interessante e ornamentada. Inicialmente, a Oracle desenvolveu a porta Arm e, quando a Arm lançou a arquitetura ARMv8, uma porta adicional foi adicionada a essa porta Arm que permitiu que o Java fosse executado no ARMv8. Paralelamente, a Red Hat também trabalhou nessa direção e despejou sua porta no OpenJDK para essa arquitetura. Aconteceu que a comunidade se concentrou no porto da Red Hat. Portanto, agora temos o acessório que estava no OpenJDK para a porta ARM32, que na verdade duplicou a funcionalidade da porta aarch64 - vamos removê-la de lá no JDK 12. Ao fazer isso, temos o JEP 340.
Devo dizer que a Oracle despejou no OpenJDK todas as suas conquistas do incorporado, todas as portas Arm antes de parar o suporte. Agora, todos os recursos do Arm que foram criados no Oracle foram inseridos.
Isso é lógico, porque são os fabricantes de ferro e os fabricantes de especificações que devem se interessar principalmente para que o ecossistema de software trabalhe em seu hardware e seja compatível com suas especificações. Para isso, o código deve estar aberto.
Vi infográficos mostrando números impressionantes de que uma certa empresa BellSoft, localizada em São Petersburgo, inundou um grande número de confirmações.
Sim, estamos entre os 5 principais comprometedores do OpenJDK. Naturalmente, a Oracle está fora de competição, existem cerca de 4 mil confirmações por ano.
Em seguida, vem a Red Hat, SAP, Google e BellSoft. Não chegamos nem um pouco ao Google. E logo depois de nós é a IBM.
Qual a porcentagem de seus funcionários que trabalhavam na Oracle?
100%. A BellSoft é composta por ex-funcionários da Oracle.
Essa é uma concorrência desleal, porque o Google não é composto por 100% dos funcionários da Oracle. Que tipo de confirmação, me diga? Como alcançar esse sucesso? Como entrar nos 5 principais comprometedores?
Trabalhamos em várias direções. Agora, a direção principal aonde nossos commits vão é a porta ARM64, que é a mesma porta do servidor. É interessante para os produtores de ferro. Eles estão interessados em Java trabalhando rapidamente em seu hardware, para lidar com as cargas. A segunda coisa que confirmamos é a porta ARM32, que apoiamos, esta é a porta incorporada. O terceiro consiste em comprometer-se a apoiar, corrigir e melhorar a funcionalidade geral do Java.
Acabamos de falar de 64 bits em servidores. Por que a porta de 32 bits ainda está ativa?
Porque é usado no incorporado.
Porque muitas empresas implementaram uma CPU para a arquitetura ARMv7 para aplicativos incorporados. Eles têm um grande número de chips em seus armazéns. Se a memória me servir bem, então toda a variedade desses chips é ARM32, o mais popular é o ARMv5. Essa arquitetura existe há muitos anos, mas, no entanto, as CPUs são bastante baratas e os fabricantes ainda estão pensando em criar novos dispositivos nessa arquitetura.
De que quantia estamos falando quando falamos de construção? Uma pessoa comum pode comprar algo para si e experimentar?
O mais popular da plataforma ARM32 é o Raspberry Pi, a partir da segunda versão - a segunda e a terceira versões, além de tudo isso é suportado pela porta ARM32. Uma de nossas distribuições é a do ARM32 testada e executada no Raspberry Pi. Vemos que esta é a plataforma mais comum para uma ampla audiência e, portanto, lançamos a porta especificamente para o Raspberry Pi. Temos portas mais específicas para ferro altamente especializado, mas isso é outra história.
Talvez você não precise comprar. Você pode ver o que você tem no seu roteador doméstico. É muito provável que exista algo assim.
Quanto as habilidades de desenvolvedor devem corresponder lá?
Você precisa ser um desenvolvedor Java.
Você precisa de maneiras complicadas de conhecer a lei de Kirchhoff para codificar?
Você apenas tem um computador ao qual pode se conectar via SSH. Não há necessidade de piscar. Você pega um cartão microSD com uma imagem do Linux para o Raspberry Pi, insere-o e tudo começa. Essa é a principal vantagem do Raspberry Pi em comparação com todos os outros computadores de placa única. A simplicidade de sua configuração, obtendo um sistema viável.
E como trabalhar com sensores? Fazemos tudo isso em prol de sistemas externos, certo?
O Raspberry Pi possui um sistema GPIO e pinos aos quais você pode conectar qualquer coisa. No que geralmente todos os entusiastas conectam todos os periféricos ao Raspberry Pi.
Como é a API? O que precisa ser escrito, como "tire um número do termostato"?
Você precisa ler a folha de dados do termostato e entender o que são os registros, como inicializá-lo, como configurá-lo. Se I2C, chame o método de configuração, passe todos os parâmetros para lá. Em seguida, diga a ele i2c.open e trabalhe com ele como um objeto Java.
É possível escrever invólucros de objetos bonitos em torno de termostatos para trabalhar em um modelo puramente de objetos? Isso pode ser feito para não ler mais a folha de dados e fechá-la com uma fachada?
Seria bom se o fabricante desse sensor fizesse uma configuração pronta e nós, como programadores Java, simplesmente o pegássemos e o usássemos. A biblioteca trabalha com um sensor, uma biblioteca para trabalhar com outro sensor. Essa biblioteca ou algo parecido com isso é chamado Pi4J. Ele está se desenvolvendo agora não tão rapidamente quanto nos dias em que a Oracle mudou o Java para o incorporado, mas ainda não morreu, algumas atualizações aparecem periodicamente. Há uma opção: trabalhar com algo que está no OpenJDK - GPIO ou trabalhar com a biblioteca Pi4J.
Se sou fabricante de hardware, não sei nada sobre Java, mas gostaria que os programadores de Java o usassem, com quem devo entrar em contato? Para entrar em contato com você? Ou existem especialistas que fazem isso?
Sim, somos tais especialistas.
Até agora, não corremos longe. Lembro que você teve alguns dos seus PECs, certo?
O OpenJDK versão 11 inclui 17 JEPs. 14 foi feita pela Oracle, 1 - Google, 1 - Red Hat, 1 - BellSoft em conjunto com a Cavium. Nosso JEP é uma miscelânea de aprimoramentos de desempenho Java na plataforma ARM64 para cargas de trabalho específicas. O JEP, respectivamente, é chamado de Improve Aarch64 Intrinsics . Em resumo, melhoramos o desempenho das operações com String, com matrizes e um pouco com matemática e trigonometria.
O que são intrínsecos? Nem todo mundo sabe.
Quando uma máquina virtual considera um seno, em vez de executar código Java direto, ela pode substituir a inserção otimizada do assembler por uma arquitetura específica.
Que chama diretamente o processador que possui o comando sine?
O qual o calculará de acordo com um algoritmo complexo. Existem intrínsecos que chamam algum tipo de comando assembler. Por exemplo, intrínsecos associados ao cálculo de somas de verificação. Essas instruções de montagem existem para quase todas as arquiteturas. Existem intrínsecas mais complexas quando, para obter um bom aumento de desempenho, escreva muitas páginas do assembler.
E criptografia, é em hardware?
Sim, isso geralmente é uma chamada para as instruções existentes de um processador específico. Às vezes - trabalhe com extensões nesses chips onde eles estão.
Voltando ao seu JEP: como determinar qual código é tão quente que vale tanto a pena?
Ótima pergunta. Quando começamos a otimizar algo para plataformas ARM64, não tínhamos um grande número de ferramentas, além do perf. Sim, e ele não trabalhou em todos os lugares. Não havia implementação de JFR para a porta ARM64; a Oracle ainda não a havia colocado em código aberto até aquele momento. Várias ferramentas para medir o desempenho que costumávamos usar, por exemplo, async-profiler, honest-profiler - elas também não funcionavam nas plataformas ARM64. A primeira coisa que fizemos foi obter todas essas ferramentas nessa arquitetura.
Por que não funciona fora da caixa?
Porque existe algum tipo de parte específica da CPU.
Em seguida, você executa essas ferramentas na carga de trabalho que está tentando otimizar, olha a tela por um longo tempo, tenta entender quais métodos estão quentes lá, quais lugares estão quentes neles. Existem casos simples em que algumas inserções do assembler para uma arquitetura específica não são implementadas. Nesse caso, o fallback ocorre no código Java. Apenas implementando essas inserções do assembler, você pode obter um aumento no desempenho. Existem lugares mais complicados quando você precisa entender o que o novo assembler insere em Java para criar para todas as arquiteturas. Tal trabalho.
Conjunto de dados Sam onde obter? Desinflar o github inteiro e executá-lo no JIT?
É claro que alguns benchmarks ou cargas de trabalho estão sendo otimizados. Benchmarks conhecidos - SpecJBB, SpecJVM. Existem cargas de trabalho específicas que interessam a clientes específicos. Basta executar essas cargas de trabalho e observar gargalos.
Todas essas SpecJVMs são testes muito antigos, certo? E as novas lambdas, fluxos, grandes datas?
Nada. Não está lá.
E onde conseguir?
Novas cargas de trabalho.
Por exemplo, pilha apachevsky?
SimO Hadoop possui uma referência padrão do TeraSort, que os fabricantes de hardware gostam de medir. Também uma das tarefas interessantes para otimização.
Quais são os principais recursos para otimizar agora? Por exemplo, o topo do mesmo JEP.
As principais áreas problemáticas para essa arquitetura que estavam lá, fechamos. É claro que ainda existe um campo não lavrado do que não fizemos e do que continuaremos a fazer. Continuaremos a trabalhar com trigonometria, veremos novas intrínsecas que aparecerão. Eles ainda não estão lá, mas entendemos que eles aparecerão em breve. Teremos que analisar o projeto do Panamá, com o qual a Intel está contribuindo ativamente.
Como o compilador verá o que você está fazendo? Relativamente, magicamente entende que você considera alguma fórmula conhecida e otimiza?
Math.sin , Java- sin .
- , sin ?
Sim , .
- , , ?
C2, .
- . , ?
.
, Linaro Connect OpenJDK ARM64. Linaro Foundation Arm-.
?
Arm, . .
?
. . Joker, .
!
, . floating point. , , , . — , . , , — . , .
. , , ?
Sim Arm … , — . , . - - , — . , , . , , . , Java- , .
, - , . ?
OpenJDK BellSoft.
, , ? ? Oracle, . JVM-?
, OpenJDK. ()
, 250 . ?
, 250 . .
— ? .
, . . , — . - .
, ?
.
?
. . , - , , . , , , . - . , . , , . , OpenJDK .
?
Mailing list. - mailing list, .
-?
Jira. OpenJDK Jira, , , .
Jira Jira, , ?
OpenJDK . , Jira.
? , , , , , Arm?
Arm, , , . shared-, , . , . .
, . , .
, . HotSpot, , , . , , - — .
- ?
Sim HotSpot tiers. smoke- . , , . , performance-, stress-.
. , , JDK, . JDK, . , ?
JDK, , JVM. JVM 4 : runtime, serviceability, garbage collector, compiler. - . , runtime. - out of order execution, , GC . , JIT, . community OpenJDK — JIT.
, , ?
, . , . . . , -, , .
? ? ? , , - ?
. , .
, , - , . .
. , OpenJDK Arm. , , IT. -, , Arm . , Arm, Arm , . , OpenJDK, Arm. , , . Arm Intel SPEC-. , . . !
, ?
, ?
, .
. . , ARM64? . , Arm .
.
— , , -, . ? - , Arm?
, .
?
Arm . . , , ? . .
, . , , , . - 10 , GPU - , . Cloud- . , , -. GPU, CPU. -, HTTP 404. , . , .
, - , ? - ?
. , . 30 ? . , . - , , . : 20% , 20%, — 10%, - . , Arm .
, Java, , . , , .
Arm , BellSoft — Arm, . OpenJDK, - . Liberica Liberica Arm 32 64, Liberica Linux (64 ), Windows Liberica Mac. Liberica Solaris Sparc. .
Liberica Mac? -.
? Oracle , … . ?
?
, Oracle. , Java- .
Java- .
, . , .
.
Sim -, support . - — , , Cloud-. , , - , .
, Oracle JDK , API. -XX:+UnlockCommercialFeatures . , . , Oracle , .
, Oracle - Oracle, . . Java , .
, , OpenJDK . . BellSoft , , .
, , . . , , OpenJDK — .
!
. , — . - ?
. , , , . .
- OpenJDK.
. ?
Liberica, . Raspberi Pi, Linux-. , Java, -.
Joker, , BellSoft — .
. , , . , :-) Joker — .
, . !
. Joker 2018 «, ARM? , » . .