Los últimos días quedan antes de Joker, y realmente quería llevar a Habr no una entrevista ordinaria, sino un juego poderoso. Recientemente, la gente ha estado interesada en los servidores de Arm, y sucedió que tenemos verdaderos expertos en este tema.
Alexander (
alexbel ) Belokrylov y Lesha Voytylov, junto con Grigory Labzovsky, quien dirigió el centro de desarrollo de Oracle en San Petersburgo, fundaron BellSoft hace poco más de un año. Ahora la compañía está operando, desarrollándose con éxito y ya ha ganado fama en el mundo de Java.
Por el volumen de compromisos en OpenJDK durante el año pasado, llegaron en quinto lugar, y ahora solo Oracle, Red Hat, SAP y Google están por delante:
Debe comprender que BellSoft no es solo Arm:
- Se ha lanzado Liberica JDK 11 , se admiten Linux x86_64, Windows, Linux ARMv8, Linux ARMv7 (incluido Raspberry Pi). Las compilaciones se diseñarán para Mac y Solaris Sparc.
- Las imágenes para todas las arquitecturas se publican en Docker Hub para Debian, CentOS, Alpine. La imagen de Alpine está hecha de la versión lite con
--compress 2 por lo tanto, es significativamente más pequeña que el JDK habitual.
En esta entrevista, solo tocaremos a Arm y dejaremos el resto para la próxima vez.
Así que hoy en nuestro estudio virtual:
Alexander Belokrylov
Lesha Voytylov
Oleg Chirukhin - editores del grupo JUG.ru
¿Cuéntanos más sobre la empresa?
La empresa BellSoft se dedica a varias áreas. Probablemente todo el mundo sabe que Oracle en San Petersburgo tenía una experiencia muy seria de bajo nivel en el desarrollo de Java Runtime, en el desarrollo de compiladores, en el desarrollo de sistemas de servicio Oracle Cloud. Y esta experiencia de Oracle migró a BellSoft. Hoy, nuestra empresa está desarrollando Java Runtime, somos un contribuyente activo de OpenJDK, estamos desarrollando los compiladores gcc y llvm, contribuiremos a la pila de Apache, Graal. Nos dedicamos a la construcción de sistemas de análisis de big data, sistemas de recomendación y hemos construido un pequeño proyecto en IoT, para recopilar datos de dispositivos del mundo real. En algún momento, vimos que Oracle dejó de lanzar una distribución Java para plataformas Arm, y lanzamos nuestra propia distribución, que se llamaba Liberica JDK para Raspberry Pi. Desde entonces, lo apoyamos con éxito.
Echemos un vistazo más de cerca. ¿Qué es una pila de Apache, por ejemplo?
Comenzamos a contribuir a la Fundación Apache con Hadoop; mucho está relacionado con ciertas partes de este proyecto. OpenJDK y grandes proyectos de Apache, aunque no directamente, pero están altamente interconectados.
¿Por qué podría ser todo esto necesario? Por ejemplo, algunas clases que los ralentizan pueden ser overclockeados?
Sí, esta es una de las áreas en las que estamos trabajando: mejorar la productividad. Por ejemplo, las partes específicas de la plataforma, cuya aceleración en OpenJDK puede ayudar a acelerar Hadoop. Si está interesado, podemos hablar al respecto.
Cuando resuelve problemas de rendimiento, tiene sentido ver algo cercano. Tal vez hay el mismo problema en alguna parte. Muy a menudo ve que después de haber corregido en un lugar, necesita corregir en un par de lugares, para que en general mejore. A veces (y muy a menudo) la optimización del rendimiento se descompone en contribuciones a varios proyectos. Si desea mejorar, por ejemplo, el rendimiento de la checksum de checksum , mire al final de la pila. Digamos que es Java. Si miras un poco más alto, será Hadoop, Spark u otra cosa. Por lo general, al comprender cómo mejorar un lugar, puede comprender cómo hacerlo en otro lugar. Por supuesto, tiene sentido en este caso ir y mejorar allí también.
Todo el mundo sabe que eres Liberica :-) Hablemos de esto.
Sí, somos Liberica JDK. Liberica comenzó con el hecho de que vimos que no hay puerto para ARM32, y debe hacerse con urgencia, porque el Raspberry Pi se quedó sin Java 9 y Java 10. Esto fue en 2017 cuando salió Java 9. Ahora Liberica JDK admite muchas arquitecturas y sistemas operativos.
Se hizo evidente que Oracle no iba a desarrollar más el código para Arm, y comenzamos a distribuir activamente y lanzar nuestra distribución para cerrar esta brecha. Quedó claro que la gente lo necesita.
Entonces, ¿ahora hay varias distribuciones de Arm?
Sí, hay varias distribuciones de Java para Arm, son diferentes. En el nuestro, realmente obtienes lo que solía ser parte del kit de distribución de puertos de Oracle. Nuestra distribución tiene JavaFX, entrada / salida del dispositivo y una API integrable. Este es un paquete, y todo funciona con módulos, comenzando con JDK 9. Usando un sistema modular, puede construir Runtime como lo desee. Si lo desea, puede hacer un pequeño tiempo de ejecución de 16 megabytes. Si desea habilitar más funciones, por ejemplo, un servidor web, debe gastar unos 32 megabytes de espacio estático. Puede obtener un tiempo de ejecución que funcione para sus necesidades.
Por lo que entendí, estábamos hablando de servidores del ejército. No quiere decir que los hayamos usado masivamente. ¿Cuéntame sobre el servidor? ¿En la vida real existen?
Esta historia ha existido por muchos años. El primer servidor Arm se creó sobre la base de la arquitectura ARMv7 de 32 bits. Era una caja terriblemente ruidosa, que prácticamente no funcionaba, porque el BIOS, Linux no funcionaba allí, todo desapareció después de unas horas. La empresa que lo inició, Calxeda, cerró con el tiempo. Pero la idea de desarrollar una arquitectura alternativa para servidores se sembró en la sociedad. Arm finalmente lanzó una nueva especificación para la arquitectura ARMv8, que admite 32 y 64 bits. Basado en la versión de 64 bits de esta especificación, varios fabricantes ahora están construyendo sus implementaciones de procesador para servidores. Por ejemplo, Ampere Computing, Cavium, que ahora es comprada por Marvell, y Qualcomm. Y hay otra compañía: AMD, hace unos años, también lanzó servidores basados en la arquitectura Arm. En mi opinión, todavía continúan haciendo esto.
Si eliminas una letra L de Marvell, obtienes superhéroes. Una buena manera de recordar los nombres de todas estas oficinas.
Los superhéroes allí son en realidad Cavium / Marvell, debido a todos ellos fueron ellos quienes lograron ensamblar el chip más productivo de hasta 128 hilos en una CPU, y un rendimiento comparable o mejor con Xeon Gold y Platinum. Puedes poner varias CPU en un servidor, obtienes una cosa monstruosa con memoria rápida que puede usarse para tareas serias.
¿Cómo crece el límite de escalabilidad para aplicaciones comunes? ¿Cuánta CPU tiene sentido quedarse en un servidor?
Todo depende de la tarea para la que desea construir el servidor. Diferentes fabricantes se guían por diferentes nichos, pero si hablamos de Cavium / Marvell, se guían claramente por el nicho de la informática, donde debe masticar rápidamente una gran cantidad de datos en paralelo. No se centran en el rendimiento súper grande de un solo hilo (al mismo tiempo, es muy bueno), es decir, en general, para que esta CPU muestre un alto rendimiento con un consumo de bajo costo.
¿Por qué armar, no Intel? Tenemos maravillosos servidores Intel, ¿por qué inventar algo más?
Es difícil y fácil responder esta pregunta. En primer lugar, un lugar sagrado no está vacío. Vemos que AMD también está tratando de construir algún tipo de Intel alternativo para aplicaciones de servidor. Y, por supuesto, siempre habrá alguna pieza alternativa del mercado de fabricantes alternativos.
Nadie quiere vivir con un monopolista.
Muy verdadero comentario. Todos los consumidores de procesadores, y estos son principalmente proveedores de la nube, desean una oportunidad para una alternativa. Para que pueda elegir, compare el costo con los costos y para aplicaciones específicas elija una arquitectura más rentable.
¿Y qué hay de los costos? ¿Cuánto más caro que las soluciones Intel?
Esta es una pregunta difícil. En primer lugar, como dijo Alexey, los fabricantes son suficientes. Está claro que ahora los fabricantes de procesadores de brazo no compiten entre sí, sino que compiten con alguien más. Ocupan nichos ligeramente diferentes. Si Cavium es computación de alto rendimiento, entonces Qualcomm son servidores de rango medio, Ampere son estaciones de trabajo o servidores de gama baja.
Si no recuerdo mal, el precio de la CPU de Ampere Computing es de $ 600-900, y compiten con Intel, una CPU que cuesta alrededor de $ 1,500. El cavio es un poco caro. Nuevamente, competirán con Intel, que es significativamente más caro. Debe comprender que el precio del servidor no es solo el precio de la CPU. El precio del servidor también es memoria, discos, soporte, consumo. Si gana con un parámetro, por ejemplo, el costo de la CPU, está bien, pero será un poco más barato. Si gana de dos maneras, por ejemplo, al ser más barato y ofrecer un rendimiento aún mejor, lo mirarán más de cerca. Y si en tres, por ejemplo, también puede hacer todo esto con menos consumo de energía, entonces esta ya es una aplicación para la victoria.
Además del hierro y su soporte, el soporte en software también es importante. No puede ejecutar en Arm todo lo que ahora gira en Intel.
Por supuesto Debo decir que el ecosistema de software de Arm ha avanzado mucho. Si hace cinco años hubo problemas para levantar una pieza de hierro, ahora no hay tales problemas. Usted acaba de llegar y todo funciona de manera inmediata para usted. Todo a lo que está acostumbrado funciona: Linux, Docker, Kubernetes, Xen, Java, Hadoop, Spark, Kafka, cualquier cosa.
¿Qué hay de Java? Cuéntanos cómo funciona, ¿en qué se diferencia del "habitual"?
No es diferente, esta es su principal ventaja. Es lo suficientemente productivo para hacer frente a las tareas que se asignan a Java para servidores. Transfiere su aplicación (espero que no tenga una parte nativa, de lo contrario tendrá que volver a compilarla), al servidor Arm, verifique el rendimiento y, en la mayoría de los casos, regocíjese. Recientemente, se publicó un artículo en el que comparamos el rendimiento del servidor Arm con el servidor Intel . El artículo salió en la revista Java.
¿Oracle te permitió esencialmente anunciarte en tu propio diario? En serio
Aparentemente, hay una demanda. Resulta que los servidores Java Arm para cargas de trabajo Java funcionan bastante bien. Son iguales, o incluso mejores que las contrapartes de Intel.
¿Quién debería leer tu artículo?
Para aquellos que quieran ver, pruebe la nueva arquitectura, si es adecuada para sus cargas. Pruebe Java y esos mismos servidores Arm. Conduzca Arm Server Cloud en Google, y obtendrá varios proveedores de nube, puede sostener una tarjeta y probar lo que necesita.
¿Java ya está preinstalado allí?
Si OpenJDK llano.
¿El OpenJDK regular y su distribución de Liberica son lo mismo? Vi que están tus commits, ¿es eso o algo más?
En general, la historia de los puertos Arm y OpenJDK es bastante interesante y adornada. Inicialmente, Oracle desarrolló el puerto Arm, y cuando Arm lanzó la arquitectura ARMv8, se agregó un puerto adicional a este puerto Arm que permitió que Java se ejecutara en ARMv8. Paralelamente a esto, Red Hat también trabajó en esta dirección y vertió su puerto en OpenJDK para esta arquitectura. Dio la casualidad de que la comunidad se centró en el puerto de Red Hat. Por lo tanto, ahora tenemos el accesorio que estaba en OpenJDK para el puerto ARM32, que en realidad duplicaba la funcionalidad del puerto aarch64; lo eliminaremos de allí en JDK 12. Al hacerlo, tenemos JEP 340.
Debo decir que Oracle vertió en OpenJDK todos sus logros desde puertos integrados, todos Arm antes de detener el soporte. Ahora se vierten todas las características para Arm que se hicieron en Oracle.
Esto es lógico, porque son los fabricantes de hierro y los fabricantes de especificaciones los que deberían estar interesados principalmente en que el ecosistema de software funcione en su hardware y sea compatible con sus especificaciones. Para esto, el código debe estar abierto.
Vi infografías que mostraban cifras sorprendentes de que cierta compañía BellSoft, ubicada en San Petersburgo, inundó una gran cantidad de compromisos.
Sí, estamos entre los 5 mejores confirmadores de OpenJDK. Naturalmente, Oracle está fuera de competencia, hay alrededor de 4 mil compromisos por año.
Luego viene Red Hat, SAP, Google y BellSoft. No llegamos a Google un poco. Y justo después de nosotros está IBM.
¿Qué porcentaje de sus empleados solía trabajar en Oracle?
100 por ciento BellSoft está formado por antiguos empleados de Oracle.
Esta es una competencia desleal porque Google no está compuesto por el 100 por ciento de los empleados de Oracle. ¿Qué tipo de confirmaciones, dime? ¿Cómo lograr tal éxito? ¿Cómo entrar en los 5 mejores committers?
Trabajamos en varias direcciones. Ahora la dirección principal donde van nuestros commits es el puerto ARM64, que es el mismo puerto del servidor. Es interesante para los productores de hierro. Están interesados en que Java trabaje rápidamente en su hardware, haga frente a las cargas. Lo segundo que comprometemos es el puerto ARM32, que admitimos, este es el puerto incrustado. El tercero es commits destinados a soportar, arreglar y mejorar la funcionalidad general de Java.
Acabamos de hablar de 64 bits en los servidores. ¿Por qué el puerto de 32 bits sigue vivo?
Porque se usa en incrustado.
Porque muchas empresas han implementado una CPU para la arquitectura ARMv7 para aplicaciones integradas. Tienen una gran cantidad de chips en sus almacenes. Si la memoria me sirve bien, entonces de toda la variedad de estos chips es ARM32, el más popular es ARMv5. Esta arquitectura ha existido durante muchos años, pero, sin embargo, las CPU son bastante baratas y los fabricantes todavía están considerando crear nuevos dispositivos en esta arquitectura.
¿De qué cantidades estamos hablando cuando hablamos de construcción? ¿Puede una persona común comprar algo para sí misma y experimentar?
La plataforma ARM32 más popular es la Raspberry Pi, comenzando desde la segunda versión, la segunda y la tercera versión, además de todo esto es compatible con el puerto ARM32. Una de nuestras distribuciones es la de ARM32 que se prueba y se ejecuta en Raspberry Pi. Vemos que esta es la plataforma más común para una amplia audiencia y, por lo tanto, lanzamos el puerto específicamente para Raspberry Pi. Tenemos puertos más específicos para hierro altamente especializado, pero esa es otra historia.
Quizás no necesites comprar. Puedes ver lo que tienes en el enrutador de tu casa. Es muy probable que haya algo así.
¿Cuánto deberían corresponder las habilidades de desarrollador allí?
Necesitas ser un desarrollador de Java.
¿Necesita formas difíciles de conocer la ley de Kirchhoff para codificar?
Solo tiene una computadora a la que puede conectarse a través de SSH. No hay necesidad de flashearlo. Usted toma una tarjeta microSD con una imagen de Linux para Raspberry Pi, la inserta y todo comienza. Esta es la principal ventaja de la Raspberry Pi en comparación con todas las otras computadoras de placa única. La simplicidad de su configuración, obteniendo un sistema viable.
¿Y cómo trabajar con sensores? Hacemos todo esto por el bien de los sistemas externos, ¿verdad?
La Raspberry Pi tiene un sistema GPIO y pines a los que puede conectar cualquier cosa. En lo que generalmente todos los entusiastas conectan todos los periféricos a la Raspberry Pi.
¿Cómo se ve la API? ¿Qué se debe escribir, como "obtenme un número del termostato"?
Debe leer la hoja de datos del termostato y comprender qué son los registros, cómo inicializarlo, cómo configurarlo. Si I2C, llame al método para la configuración, pase todos los parámetros allí. Luego dígale i2c.open y trabaje con él como un objeto Java.
¿Es posible escribir envoltorios de objetos hermosos alrededor de termostatos para trabajar en un modelo puramente objeto? ¿Se puede hacer para no leer más la hoja de datos, para cerrarla con una fachada?
Sería bueno que el fabricante de este sensor hiciera una configuración lista para usar, y nosotros, como programadores de Java, simplemente la tomamos y la usamos. La biblioteca funciona con un sensor, una biblioteca para trabajar con otro sensor. Tal biblioteca o algo parecido a esto se llama Pi4J. Se está desarrollando ahora no tan rápido como en los días en que Oracle movía Java incrustado, pero aún no murió, periódicamente aparecen algunas actualizaciones. Hay una opción: trabajar con algo que está en OpenJDK - GPIO, o trabajar con la biblioteca Pi4J.
Si soy un fabricante de hardware, no sé nada sobre Java, pero me gustaría que los programadores de Java lo usen, ¿a quién debo contactar? ¿Contactarte? ¿O hay especialistas que hacen esto?
Sí, somos tales especialistas.
Hasta ahora no hemos corrido lejos. Recuerdo que tenías algunos de tus JEP, ¿verdad?
OpenJDK versión 11 incluye 17 JEP. 14 fue creado por Oracle, 1 - Google, 1 - Red Hat, 1 - BellSoft en conjunto con Cavium. Nuestro JEP es una mezcolanza de mejoras de rendimiento de Java en la plataforma ARM64 para cargas de trabajo específicas. JEP, respectivamente, se llama Mejorar intrínseca Aarch64 . En resumen, hemos mejorado el rendimiento de las operaciones con String, con matrices y un poco con matemáticas y trigonometría.
¿Qué son los intrínsecos? No todos lo saben.
Cuando la máquina virtual considera el seno, en lugar de ejecutar el código Java directo, puede sustituir la inserción del ensamblador optimizado por una arquitectura específica.
¿Qué llama directamente al procesador que tiene el comando seno?
Lo cual lo calculará de acuerdo con un algoritmo complejo. Hay intrínsecos que llaman algún tipo de comando ensamblador. Por ejemplo, intrínsecos asociados con el cálculo de sumas de verificación. Dichas instrucciones de montaje existen para casi todas las arquitecturas. Hay intrínsecos más complejos cuando, para obtener un buen aumento del rendimiento, escriba muchas páginas de ensamblador.
Y el cifrado, ¿está en hardware?
Sí, esto suele ser una llamada a las instrucciones existentes de un procesador en particular. A veces, trabaje con extensiones en esos chips donde están.
Volviendo a su JEP: ¿cómo determinar qué código es tan popular que vale tanto el código duro?
Gran pregunta Cuando comenzamos a optimizar algo para las plataformas ARM64, no teníamos una gran cantidad de herramientas, además de perf. Sí, y él no trabajaba en todas partes. No había implementación de JFR para el puerto ARM64; Oracle aún no lo había puesto en código abierto para ese momento. Varias herramientas para medir el rendimiento que solíamos usar, por ejemplo, async-profiler, honest-profiler, tampoco funcionaron para las plataformas ARM64. Lo primero que hicimos fue obtener todas estas herramientas en esta arquitectura.
¿Por qué no trabajar fuera de la caja?
Porque hay algún tipo de parte específica de la CPU.
A continuación, ejecute estas herramientas en la carga de trabajo que está tratando de optimizar, mire la pantalla durante mucho tiempo, intente comprender qué métodos están calientes allí, qué lugares están calientes en ellos. Hay casos simples en los que no se implementan algunas inserciones de ensamblador para una arquitectura específica. En este caso, el retroceso ocurre en el código Java. Simplemente implementando estos insertos de ensamblador puede obtener un aumento en el rendimiento. Hay lugares más complicados en los que necesita comprender qué nueva inserción de ensamblador necesita en Java para crear para todas las arquitecturas. Tal trabajo
¿Conjunto de datos de Sam dónde obtener? ¿Desinflar todo el github y ejecutarlo bajo JIT?
Está claro que algunos puntos de referencia o cargas de trabajo se están optimizando. Puntos de referencia conocidos - SpecJBB, SpecJVM. Hay cargas de trabajo específicas que interesan a clientes específicos. Simplemente ejecute estas cargas de trabajo y observe los cuellos de botella.
Todos estos SpecJVM son pruebas muy antiguas, ¿verdad? ¿Qué pasa con las nuevas lambdas, arroyos, grandes citas?
Nada No esta ahi.
¿Y dónde conseguirlo?
Nuevas cargas de trabajo.
Por ejemplo, apachevsky stack?
Si Hadoop TeraSort, . .
, ? , JEP.
, , . , , , . , , . , , . Panama, Intel.
, ? , , - ?
Math.sin , Java- sin .
- , sin ?
Si , .
- , , ?
C2, .
- . , ?
.
, Linaro Connect OpenJDK ARM64. Linaro Foundation Arm-.
?
Arm, . .
?
. . Joker, .
!
, . floating point. , , , . — , . , , — . , .
. , , ?
Si 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, , , . , , - — .
- ?
Si 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- .
, . , .
.
Si -, 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? , » . .