¿Por qué algunos lenguajes de programación son "más rápidos" o "más lentos" que otros?

Me he dado cuenta de que algunas aplicaciones o algoritmos que se basan en un lenguaje de programación, por ejemplo, C ++ / Rust, se ejecutan más rápido o más rápido que los creados en Java, Node.js, que se ejecutan en la misma máquina. Tengo algunas preguntas con respecto a esto:

1. ¿Por qué pasó esto?
2. ¿Qué gobierna la "velocidad" de un lenguaje de programación?
3. ¿Tiene esto algo que ver con la gestión de la memoria?

Realmente agradecería si alguien me explicara esto.

En el diseño y la implementación del lenguaje de programación, hay una gran cantidad de opciones que pueden afectar el rendimiento. Solo mencionaré algunos.

Finalmente, cada idioma debe ejecutarse ejecutando código de máquina. Un lenguaje "compilado" como C ++ se analiza, decodifica y traduce al código de máquina solo una vez, en tiempo de compilación. Un lenguaje "interpretado", si se implementa de forma directa, se decodifica en tiempo de ejecución, en cada paso, cada vez. Es decir, cada vez que ejecutamos una declaración, el intérprete tiene que verificar si es un if-then-else, o una asignación, etc. y actuar en consecuencia. Esto significa que si hacemos un bucle 100 veces, decodificamos el mismo código 100 veces, perdiendo el tiempo. Afortunadamente, los intérpretes a menudo optimizan esto mediante, por ejemplo, un sistema de compilación justo a tiempo. (Más correctamente, no existe un lenguaje "compilado" o "interpretado": es una propiedad de la implementación, no del lenguaje. Aún así,

Diferentes compiladores / intérpretes realizan diferentes optimizaciones.

Si el lenguaje tiene administración de memoria automática, su implementación debe realizar la recolección de basura. Esto tiene un costo de tiempo de ejecución, pero alivia al programador de una tarea propensa a errores.

Un lenguaje puede estar más cerca de la máquina, permitiendo que el programador experto micro-optimice todo y exprima más rendimiento de la CPU. Sin embargo, es discutible si esto es realmente beneficioso en la práctica, ya que la mayoría de los programadores en realidad no se optimizan micro y, a menudo, el compilador puede optimizar un buen lenguaje de nivel superior mejor que lo que haría un programador promedio. (Sin embargo, ¡a veces estar más lejos de la máquina también puede tener sus beneficios! Por ejemplo, Haskell tiene un nivel extremadamente alto, pero gracias a sus opciones de diseño puede presentar hilos verdes muy livianos).

La verificación de tipo estático también puede ayudar en la optimización. En un lenguaje interpretado de tipo dinámico, cada vez que se computa x - y, el intérprete a menudo tiene que verificar si ambos x,yson números y (por ejemplo) generar una excepción de lo contrario. Esta verificación se puede omitir si los tipos ya se verificaron en tiempo de compilación.

Algunos idiomas siempre informan errores de tiempo de ejecución de una manera sensata. Si escribe a[100]en Java donde atiene solo 20 elementos, obtendrá una excepción de tiempo de ejecución. En C, eso causaría un comportamiento indefinido, lo que significa que el programa podría fallar, sobrescribir algunos datos aleatorios en la memoria o incluso realizar absolutamente cualquier otra cosa (el estándar ISO C no plantea límites). Esto requiere una verificación de tiempo de ejecución, pero proporciona una semántica mucho mejor al programador.

Sin embargo, tenga en cuenta que, al evaluar un idioma, el rendimiento no lo es todo. No te obsesiones con eso. Es una trampa común intentar micro-optimizar todo, y aún así no detectar que se está utilizando un algoritmo / estructura de datos ineficiente. Knuth dijo una vez que "la optimización prematura es la raíz de todo mal".

No subestimes lo difícil que es escribir un programa correctamente . A menudo, puede ser mejor elegir un lenguaje "más lento" que tenga una semántica más amigable para los humanos. Además, si hay algunas partes críticas de rendimiento específicas, siempre se pueden implementar en otro idioma. Solo como referencia, en el concurso de programación ICFP 2016 , estos fueron los idiomas utilizados por los ganadores:

1   700327  Unagi                       Java,C++,C#,PHP,Haskell
2   268752  天羽々斬                     C++, Ruby, Python, Haskell, Java, JavaScript
3   243456  Cult of the Bound Variable  C++, Standard ML, Python

Ninguno de ellos usó un solo idioma.

¿Qué gobierna la "velocidad" de un lenguaje de programación?

No existe la "velocidad" de un lenguaje de programación. Solo existe la velocidad de un programa particular escrito por un programador particular ejecutado por una versión particular de una implementación particular de un motor de ejecución particular que se ejecuta dentro de un entorno particular.

Puede haber grandes diferencias de rendimiento al ejecutar el mismo código escrito en el mismo idioma en la misma máquina usando diferentes implementaciones. O incluso usando diferentes versiones de la misma implementación. Por ejemplo, ejecutar exactamente el mismo punto de referencia ECMAScript en la misma máquina usando una versión de SpiderMonkey de hace 10 años frente a una versión de este año probablemente producirá un aumento de rendimiento en cualquier lugar entre 2 × –5 ×, tal vez incluso 10 ×. ¿Eso significa que ECMAScript es 2 veces más rápido que ECMAScript, porque ejecutar el mismo programa en la misma máquina es 2 veces más rápido con la implementación más reciente? Eso no tiene sentido.

¿Tiene esto algo que ver con la gestión de la memoria?

Realmente no.

¿Por qué pasó esto?

Recursos. Dinero. Microsoft probablemente emplea a más personas que preparan café para sus programadores compiladores que toda la comunidad PHP, Ruby y Python combinada tiene personas trabajando en sus máquinas virtuales.

Para más o menos cualquier característica de un lenguaje de programación que afecte el rendimiento de alguna manera, también hay una solución. Por ejemplo, C (estoy usando C aquí como sustituto de una clase de lenguajes similares, algunos de los cuales incluso existían antes de C) no es seguro para la memoria, por lo que múltiples programas de C que se ejecutan al mismo tiempo pueden pisotear la memoria del otro Entonces, inventamos memoria virtual y hacemos que todos los programas de C pasen por una capa de indirección para que puedan fingir que son los únicos que se ejecutan en la máquina. Sin embargo, eso es lento, por lo que inventamos la MMU e implementamos memoria virtual en hardware para acelerarla.

¡Pero! ¡Los idiomas seguros para la memoria no necesitan todo eso! Tener memoria virtual no les ayuda en nada. En realidad, es peor: la memoria virtual no solo no ayuda a los lenguajes seguros para la memoria, la memoria virtual, incluso cuando se implementa en hardware, también afecta el rendimiento. Puede ser especialmente perjudicial para el rendimiento de los recolectores de basura (que es lo que utilizan un número significativo de implementaciones de lenguajes seguros para la memoria).

Otro ejemplo: las CPU de uso general modernas y modernas emplean trucos sofisticados para reducir la frecuencia de errores de caché. Muchos de esos trucos equivalen a tratar de predecir qué código se ejecutará y qué memoria se necesitará en el futuro. Sin embargo, para los idiomas con un alto grado de polimorfismo de tiempo de ejecución (p. Ej., Lenguajes OO) es realmente muy difícil predecir esos patrones de acceso.

Pero, hay otra manera: el costo total de las fallas de caché es el número de fallas de caché multiplicado por el costo de una falla de caché individual. Las CPU convencionales intentan reducir la cantidad de fallas, pero ¿qué pasaría si pudiera reducir el costo de una falla individual?

La CPU Azul Vega-3 fue diseñada específicamente para ejecutar JVM virtualizadas, y tenía una MMU muy poderosa con algunas instrucciones especializadas para ayudar a la recolección de basura y la detección de escape (el equivalente dinámico al análisis de escape estático) y potentes controladores de memoria, y todo el sistema Todavía podría progresar con más de 20000 errores de caché pendientes en vuelo. Desafortunadamente, como la mayoría de las CPU específicas del idioma, su diseño fue simplemente gastado y forzado por los "gigantes" Intel, AMD, IBM y similares.

La arquitectura de la CPU es solo un ejemplo que tiene un impacto en lo fácil o difícil que es tener una implementación de alto rendimiento de un lenguaje. Un lenguaje como C, C ++, D, Rust que se ajuste bien al modelo de programación de CPU convencional moderno será más fácil de crear que un lenguaje que tenga que "luchar" y eludir la CPU, como Java, ECMAScript, Python, Ruby PHP.

Realmente, todo es cuestión de dinero. Si gasta la misma cantidad de dinero para desarrollar un algoritmo de alto rendimiento en ECMAScript, una implementación de alto rendimiento de ECMAScript, un sistema operativo de alto rendimiento diseñado para ECMAScript, una CPU de alto rendimiento diseñada para ECMAScript como se ha gastado durante el último décadas para hacer que los lenguajes tipo C sean rápidos, entonces es probable que vea un rendimiento igual. Es solo que, en este momento, se ha gastado mucho más dinero haciendo que los lenguajes similares a C sean rápidos que los lenguajes similares a ECMAScript rápidos, y las suposiciones de los lenguajes similares a C se incorporan a toda la pila desde MMU y CPU a sistemas operativos y sistemas de memoria virtual hasta bibliotecas y frameworks.

Personalmente, estoy más familiarizado con Ruby (que generalmente se considera un "lenguaje lento"), por lo que daré dos ejemplos: la Hashclase (una de las estructuras de datos centrales en Ruby, un diccionario de valores clave) en Rubinius La implementación de Ruby está escrita en Ruby 100% puro, y tiene aproximadamente el mismo rendimiento que elHashclase en YARV (la implementación más utilizada), que está escrita en C. Y hay una biblioteca de manipulación de imágenes escrita como una extensión C para YARV, que también tiene una "versión alternativa" pura (lenta) de Ruby para implementaciones que no no es compatible con C, que utiliza un montón de trucos de Ruby altamente dinámicos y reflexivos; una rama experimental de JRuby, que utiliza el marco de interpretación Truffle AST y el marco de compilación Graal JIT de Oracle Labs, puede ejecutar esa "versión alternativa" pura de Ruby tan rápido como el YARV puede ejecutar la versión C altamente optimizada original. Esto es simplemente (bueno, cualquier cosa menos) logrado por algunas personas realmente inteligentes que hacen cosas realmente inteligentes con optimizaciones dinámicas de tiempo de ejecución, compilación JIT y evaluación parcial.

Teóricamente, si escribe código que hace exactamente lo mismo en dos idiomas y compila ambos utilizando un compilador "perfecto", el rendimiento de ambos debería ser el mismo.

En la práctica, hay varias razones por las que el rendimiento será diferente:

1. Algunos idiomas son más difíciles de optimizar.

   Esto incluye características especialmente que hacen que el código sea más dinámico (escritura dinámica, métodos virtuales, punteros de función), pero también, por ejemplo, recolección de basura.

   Hay varias formas de hacer que el código use tales funciones rápidamente, pero generalmente sigue siendo al menos algo más lento que sin usarlas.

2. Algunas implementaciones de lenguaje tienen que compilarse en tiempo de ejecución.

   Esto se aplica especialmente a los lenguajes con máquinas virtuales (como Java) e idiomas que ejecutan el código fuente, sin paso intermedio para binario (como JavaScript).

   Tales implementaciones de lenguaje tienen que hacer más trabajo en tiempo de ejecución, lo que afecta el rendimiento, especialmente el tiempo de inicio / rendimiento poco después del inicio.

3. Las implementaciones de lenguaje intencionalmente dedican menos tiempo a las optimizaciones de lo que podrían.

   Todos los compiladores se preocupan por el rendimiento del compilador en sí, no solo del código generado. Esto es especialmente importante para los compiladores de tiempo de ejecución (compiladores JIT), donde tomar demasiado tiempo para compilar ralentiza la ejecución de la aplicación. Pero se aplica a los compiladores anticipados, como los de C ++ también. Por ejemplo, la asignación de registros es un problema de NP completo, por lo que no es realista resolverlo perfectamente y en su lugar se utilizan las heurísticas que se ejecutan en un tiempo razonable.

4. Diferencias en idiomas en diferentes idiomas.

   El código escrito en el estilo común para un determinado idioma (código idiomático) usando bibliotecas comunes puede resultar en una diferencia en el rendimiento, porque dicho código idiomático se comporta de manera sutilmente diferente en cada idioma.

   Como ejemplo, considere vector[i]en C ++, list[i]en C # y list.get(i)en Java. El código C ++ probablemente no verifica el rango y no realiza llamadas virtuales, el código C # realiza la verificación de rango, pero no las llamadas virtuales y el código Java realiza la verificación de rango y es una llamada virtual. Los tres lenguajes admiten métodos virtuales y no virtuales, y tanto C ++ como C # pueden incluir la verificación de rango o evitarlo al acceder a la matriz subyacente. Pero las bibliotecas estándar de estos lenguajes decidieron escribir estas funciones equivalentes de manera diferente y, como consecuencia, su rendimiento será diferente.

5. Algunos compiladores pueden faltar algunas optimizaciones.

   Los escritores de compiladores tienen recursos finitos, por lo que no pueden implementar todas las optimizaciones posibles, incluso ignorando los otros problemas. Y los recursos que tienen podrían centrarse en un área de optimización más que en otras. Como consecuencia, el código escrito en diferentes idiomas puede tener un rendimiento diferente debido a las diferencias en sus compiladores, incluso si no hay una razón fundamental por la que un idioma sea más rápido o incluso más fácil de optimizar que el otro.

Esta es una pregunta muy general, pero en su caso la respuesta podría ser simple. C ++ compila en código máquina, donde Java compila en código de bytes Java, que luego se ejecuta en una máquina virtual Java (aunque también hay una compilación justo a tiempo, que compila aún más el código de bytes Java en código máquina nativo). Otra diferencia podría ser la recolección de basura, que es un servicio que solo proporciona Java.

Su pregunta es demasiado general, así que me temo que no puedo darle una respuesta exacta que necesita.

Para mi mejor explicación, echemos un vistazo a la plataforma C ++ y .Net.

C ++, muy cerca del código de máquina y una de las programaciones favoritas en el pasado (¿hace más de 10 años?) Debido al rendimiento. No se necesitan muchos recursos para desarrollar y ejecutar el programa C ++ incluso con el IDE, se consideran muy livianos y muy rápidos. También puede escribir código C ++ en la consola y desarrollar un juego desde allí. En términos de memoria y recursos, olvidé aproximadamente cuánta capacidad se necesita en una computadora, pero la capacidad es algo que no se puede comparar con la generación actual de lenguaje de programación.

Ahora echemos un vistazo a .Net. El requisito previo para el desarrollo de .Net es un IDE gigante que consista no solo en un tipo de lenguajes de programación. Incluso si solo desea desarrollar en, digamos C #, el IDE en sí incluirá muchas plataformas de programación de forma predeterminada, como J #, VB, dispositivos móviles, etc. A menos que realice una instalación personalizada y solo instale exactamente lo que desea, siempre que tenga la experiencia suficiente para jugar con la instalación IDE.

Además de instalar el software IDE en sí, .Net también viene con una gran capacidad de bibliotecas y marcos con el fin de facilitar el acceso a cualquier tipo de plataforma que los desarrolladores necesitan Y no necesitan.

Desarrollar en .Net puede ser una experiencia divertida porque muchas funciones y componentes comunes están disponibles por defecto. Puede arrastrar y soltar y usar muchos métodos de validación, lectura de archivos, acceso a la base de datos y mucho más en el IDE.

Como resultado, es una compensación entre los recursos informáticos y la velocidad de desarrollo. Esas bibliotecas y marcos ocupan memoria y recursos. Cuando ejecuta un programa en .Net IDE, puede consumir toneladas de tiempo tratando de compilar las bibliotecas, los componentes y todos sus archivos. Y cuando realiza la depuración, su computadora requiere muchos recursos para administrar el proceso de depuración en su IDE.

Por lo general, para realizar el desarrollo .Net, necesita una buena computadora con algo de Ram y procesador. De lo contrario, es mejor que no programes nada. En este aspecto, la plataforma C ++ es mucho mejor que .Net. Aunque todavía necesita una buena computadora, la capacidad no será demasiado preocupante en comparación con .Net.

Espero que mi respuesta pueda ayudar con su pregunta. Avísame en caso de que quieras saber más.

EDITAR:

Solo una aclaración a mi punto principal, principalmente respondo a la pregunta de "¿Qué rige la velocidad de la programación".

En el punto de vista IDE, el uso de lenguaje C ++ o .Net en el IDE relativo no afecta la velocidad de escritura del código, pero afectará la velocidad de desarrollo porque el compilador de Visual Studio tarda más tiempo en ejecutar el programa, pero el IDE C ++ es mucho más ligero y consumen menos recursos informáticos. Entonces, a la larga, puede hacer la programación más rápido con el tipo C ++ de IDE en comparación con .Net IDE, que depende en gran medida de las bibliotecas y el marco. Si toma el tiempo de espera del IDE para iniciar, compilar, ejecutar el programa, etc., afectará la velocidad de la programación. A menos que "la velocidad de programación" se centre solo en la "velocidad de escritura de código".

La cantidad de bibliotecas y el marco en Visual Studio también consumen la capacidad de la computadora. No estoy seguro de si esto responde a la pregunta de "administración de memoria", pero solo quiero señalar que Visual Studio IDE puede tomar muchos recursos al ejecutarlo y, por lo tanto, ralentizar la "velocidad de programación" general. Por supuesto, esto no tiene nada que ver con la "velocidad de escritura del código".

Como habrás adivinado, no sé demasiado de C ++, ya que solo lo uso como ejemplo, mi punto principal es sobre el tipo de IDE pesado de Visual Studio que consume recursos de la computadora.

Si se me ocurrió la idea y no respondí la pregunta de inicio del hilo, pido disculpas por la larga publicación. Pero le aconsejaría al iniciador de hilos que aclare la pregunta y pregunte exactamente qué necesita saber sobre "más rápido" y "más lento"