¿Por qué Java no se considera apropiado para ML / ciencia de datos / aprendizaje profundo?

Machine Learning tiene que ver con el rendimiento
Java estándar carece de bibliotecas de aceleración de hardware como BLAS

Además, el recolector de basura lo ralentiza y evita optimizar el acceso a la memoria para evitar fallas en la página

Tenga en cuenta que java no estándar aprovecha blas, como con spark-ml

Biblioteca de aprendizaje automático (MLlib)
“MLlib utiliza el paquete de álgebra lineal Breeze, que depende de netlib-java, y jblas. Netlib-java y jblas dependen de las rutinas nativas de Fortran”

Entonces esto es similar a los enlaces numpy de python

La biblioteca Mahout-Collections se basa en COLT
Aprendizaje automático escalable y minería de datos

(que está diseñado en base al proyecto CERN COLT)
Colt – Bienvenido

Puede ver algunas de las optimizaciones, como el uso de direccionamiento abierto para evitar específicamente el auto-boxeo de Java, y el hecho de que la mayoría de las colecciones se basan en primitivas directamente y no implementan la interfaz estándar java.utils (incluso cuando podrían)

Entonces, sí, se puede usar Java, pero no los idiomas y bibliotecas estándar de Java.

Principalmente porque las herramientas no existían. Ahora los marcos como Deeplearning4j facilitan el aprendizaje automático en Java.

Durante años, Java no tenía un marco de cómputo científico para unirse como Python tiene con Numpy, que ha obstaculizado los esfuerzos para crear ML / DL en Java.

Trasportamos Numpy a Java cuando creamos ND4J: N-Dimensional Arrays para Java, y nuestro propósito era construir un marco de cómputo numérico que pudiera manejar matrices n-dimensionales de manera distribuida en Hadoop y Spark. Es esencialmente una DSL en Java.

Como otras personas han dicho aquí, Java solo sirve como un contenedor para lenguajes más rápidos y de bajo nivel como C / C ++ / Fortran. Herramientas como javacpp sirven como gran código de pegamento entre Java y C ++.

Para los millones de programadores que escriben Java, han internalizado la tipificación estática y conocen Maven, no creo que eso suponga un problema para adoptar Java para ML. En todo caso, Maven hace que la construcción sea mucho más fácil.

Es importante diferenciar entre Spark y MLLib. Mientras que Spark despega claramente, MLLib no necesariamente.

Siento que Charles pierde el punto crítico de por qué Java no se usa y cómo se vincula con el rendimiento. Tiene razón en que Java no vencerá a C / C ++ / Fortran en rendimiento, lo que significa que necesitaría envolver algo de código C / C ++ / Fortran. Pero eso no es realmente un factor decisivo, como señalan sus propias notas sobre MLLib. De hecho, es exactamente lo que R / Matlab / Python hace sin mayores problemas (siempre y cuando tengan mejores interfaces C que la JVM) y nadie (excepto la gente de Julia) dice “no los use porque sus bibliotecas no son código nativo. ”

Lo que es un factor decisivo es que Java es un lenguaje malo para usar para pegar código C / C ++ / Fortran. Java es más rápido que el código nativo de R / Python / Matlab, pero si simplemente lo está envolviendo, eso no importa mucho y está utilizando Java como lenguaje de script. Java es un lenguaje de script terrible. Sin REPL (al menos no de forma nativa), solo tipeo estático (gran cantidad de sobrecarga mental), compilación, gestión de dependencia fea (buena suerte explicando Maven a las personas), no puede anular cosas como “+”, etc., etc. diseñado para ser un lenguaje de secuencias de comandos de pegamento.

La razón por la que despegan cosas como MLLib y Spark es porque no son Java. Son Scala con una API Java secundaria. Scala es mucho mejor lenguaje de escritura de pegamento que Java. Tomar un golpe de rendimiento para tener un mayor porcentaje de código nativo no es realmente malo.

Las pilas de “Big Data” se crean casi exclusivamente con tecnología basada en Java. Es absolutamente apropiado en el contexto de trabajar con grandes cantidades de datos.

Sin embargo, si está haciendo ML y Data Science en “Small Data”, no dude en utilizar cualquiera de las plataformas menos escalables que existen.