¿Qué bloquea Ruby, Python para obtener la velocidad de Javascript V8? [cerrado]

Hay mucho más impetusetu para optimizar altamente los interpretadores de JavaScript, por lo que vemos tantos recursos que se ponen en ellos entre Mozilla, Google y Microsoft. JavaScript tiene que ser descargado, analizado, compilado y ejecutado en tiempo real mientras un ser humano (generalmente impaciente) lo está esperando, tiene que ejecutarse MIENTRAS una persona está interactuando con él, y está haciendo esto en un entorno de cliente-fin incontrolado que podría ser una computadora, un teléfono o una tostadora. Tiene que ser eficiente en para funcionar bajo estas condiciones de manera efectiva.

Python y Ruby se ejecutan en un entorno controlado por el desarrollador/implementador. Un servidor robusto o un sistema de escritorio generalmente donde el factor limitante será cosas como memoria o E / S de disco y no tiempo de ejecución. O donde se pueden utilizar optimizaciones que no son del motor, como el almacenamiento en caché. Para estos idiomas, probablemente tenga más sentido centrarse en el conjunto de funciones de lenguaje y biblioteca sobre la optimización de velocidad.

El beneficio secundario de esto es que tenemos dos grandes motores JavaScript de código abierto de alto rendimiento que pueden y están siendo reutilizados para todo tipo de aplicaciones como Node.js.

Buena parte tiene que ver con la comunidad. Python y Ruby en su mayor parte no tienen respaldo corporativo. A nadie se le paga por trabajar en Python y Ruby a tiempo completo (y especialmente no se le paga por trabajar en CPython o MRI todo el tiempo). V8, por otro lado, está respaldado por la compañía de TI más poderosa del mundo.

Además, V8 puede ser más rápido porque lo único que importa a la gente de V8 es el intérprete they no tienen una biblioteca estándar en la que trabajar, sin preocupaciones sobre el diseño del lenguaje. Sólo escriben al intérprete. Eso es.

No tiene nada que ver con el derecho de propiedad intelectual. Tampoco Python es co-desarrollado por Google guys (su creador trabaja allí junto con algunos otros committers, pero no se les paga para trabajar en Python).

Otro obstáculo para la velocidad de Python es Python 3. Su adopción parece ser la principal preocupación de los desarrolladores del lenguaje to hasta el punto de que han congelado el desarrollo de nuevas características del lenguaje hasta que otros las implementaciones se ponen al día.

En cuanto a los detalles técnicos, no se mucho sobre Ruby, pero Python tiene una serie de lugares donde se podrían usar optimizaciones (y Unladen Swallow, un proyecto de Google, comenzó a implementarlas antes de morder el polvo). Estas son algunas de las optimizaciones que planearon. Podría ver a Python ganando velocidad V8 en el futuro si un JIT a la PyPy se implementa para CPython, pero eso no parece probable para los próximos años (el enfoque en este momento es Adopción de Python 3, no un JIT).

Muchos también sienten que Ruby y Python podrían beneficiarse enormemente de eliminar sus respectivos bloqueos de intérprete global.

También debe entender que Python y Ruby son lenguajes mucho más pesados que JS provide proporcionan mucho más en el camino de la biblioteca estándar, las características del lenguaje y la estructura. El sistema de clases de orientación a objetos por sí solo agrega una gran cantidad de peso (en el buen sentido, creo). Casi pienso en Javascript como un lenguaje diseñado para ser embebido, como Lua (y en muchos sentidos, son similares). Ruby y Python tienen un conjunto de características mucho más rico, y esa expresividad generalmente va a venir a costa de la velocidad.

El rendimiento no parece ser un foco importante de los desarrolladores principales de Python, que parecen sentir que "lo suficientemente rápido" es lo suficientemente bueno, y que las características que ayudan a los programadores a ser más productivos son más importantes que las características que ayudan a las computadoras a ejecutar código más rápido.

De hecho, sin embargo, hubo un proyecto de Google (ahora abandonado), unladen-swallow, para producir un intérprete de Python más rápido compatible con el intérprete estándar. PyPy es otro proyecto que pretende produce un Python más rápido. También está Psyco, el precursor de PyPy, que puede proporcionar mejoras de rendimiento a muchos scripts de Python sin cambiar todo el intérprete, y Cython, que le permite escribir bibliotecas C de alto rendimiento para Python usando algo muy parecido a la sintaxis de Python.

Pregunta Engañosa. V8 es una implementación JIT (un compilador just in time) de JavaScript y en su nodo de implementación no navegador más popular.js se construye alrededor de un bucle de eventos. CPython no es un JIT & no evented. Pero estos existen en Python más comúnmente en el proyecto PyPy, un JIT compatible con CPython 2.7 (y que pronto será 3.0+). Y hay un montón de bibliotecas de servidores evented como Tornado, por ejemplo. Existen pruebas del mundo real entre PyPy running Tornado vs Node.js and the las diferencias de rendimiento son leves.

Acabo de encontrar esta pregunta y también hay una gran razón técnica para la diferencia de rendimiento que no se mencionó. Python tiene un ecosistema muy grande de potentes extensiones de software, pero la mayoría de estas extensiones están escritas en C u otros lenguajes de bajo nivel para el rendimiento y están fuertemente vinculadas a la API de CPython.

Hay muchas técnicas bien conocidas (JIT, recolector de basura moderno, etc.) que podrían usarse para acelerar la implementación de CPython, pero todas requieren cambios sustanciales en la API, rompiendo la mayoría de las extensiones en el proceso. CPython sería más rápido, pero mucho de lo que hace a Python tan atractivo (la extensa pila de software) se perdería. Por ejemplo, hay varias implementaciones de Python más rápidas por ahí, pero tienen poca tracción en comparación con CPython.

Debido a las diferentes prioridades de diseño y los objetivos del caso de uso, creo.

En general, el propósito principal de los lenguajes de scripting (también conocidos como lenguajes dinámicos) es ser un "pegamento" entre llamadas de funciones nativas. Y estas funciones nativas a) cubrirán las áreas más críticas / de uso frecuente y b) serán lo más efectivas posible.

Aquí hay un ejemplo: jQuery ordenar causando iOS Safari para congelar La congelación allí es causada por el uso excesivo de llamadas get-by-selector. Si get-by-selector ser implementado en código nativo y efectivamente, no será ningún problema en absoluto.

Considere la demostración de ray-tracer que se usa con frecuencia para la demostración de V8. En Python world se puede implementar en código nativo ya que Python proporciona todas las facilidades para las extensiones nativas. Pero en V8 realm (client side sandbox) no tiene otras opciones en lugar de hacer que la VM sea [sub]efectiva como sea posible. Y así la única opción ver implementación de ray-tracer es mediante el uso de código de script.

So diferentes prioridades y motivaciones.

En Sciter he hecho una prueba implementando bastante completo jQurey core de forma nativa. En tareas prácticas como ScIDE (IDE hecho de HTML/CSS/Script) Creo que dicha solución funciona significativamente mejor que cualquier optimización de VM.

Como otras personas han mencionado, Python tiene un compilador JIT performante en la forma de PyPy.

Hacer puntos de referencia significativos siempre es sutil, pero resulta que tengo un punto de referencia simple de K-significa escrito en diferentes idiomas - lo puedes encontrar aquí. Una de las limitaciones era que los diversos lenguajes deberían implementar el mismo algoritmo y deberían esforzarse por ser simples e idiomáticos (en lugar de optimizados para la velocidad). He escrito todos los implementaciones, así que sé que no he engañado, aunque no puedo afirmar para todos los idiomas que lo que he escrito es idiomático (solo tengo un conocimiento pasajero de algunos de ellos).

No pretendo ninguna conclusión definitiva, pero PyPy fue una de las implementaciones más rápidas que obtuve, mucho mejor que Node. CPython, en cambio, estaba en el extremo más lento de la clasificación.

La declaración no es exactamente verdadera

Al igual que V8 es solo una implementación para JS, CPython es solo una implementación para Python. Pypy tiene rendimientos que coinciden con los de V8.

Además, existe el problema del rendimiento percibido : dado que V8 no bloquea de forma nativa, Web dev conduce a proyectos más eficientes porque ahorra la espera de E / S. Y V8 se utiliza principalmente para dev Web donde IO es clave, por lo que lo comparan con proyectos similares. Pero puedes usar Python en muchos, muchos otros áreas que web dev. E incluso puede usar extensiones C para muchas tareas, como cálculos científicos o cifrado, y procesar datos con excelentes perfs.

Pero en la web, los proyectos más populares de Python y Ruby están bloqueando. Python, especialmente, tiene el legado del estándar síncrono WSGI, y frameworks como el famoso Django se basan en él.

Puedes escribir Python asíncrono (como Twisted, Tornado, gevent o asyncio) o Ruby. Pero no se hace a menudo. El mejor las herramientas siguen bloqueando.

Sin embargo, son algunas de las razones por las que las implementaciones predeterminadas en Ruby y Python no son tan rápidas como V8.

Experiencia

Como Jörg W Mittag señaló, los chicos que trabajan en V8 son genios VM. Python es dev por un montón de gente apasionada, muy buena en muchos dominios, pero no están tan especializados en el ajuste de VM.

Recursos

La Python Software foundation tiene muy poco dinero : menos de 40k en un año para invierte en Python. Esto es un poco loco cuando piensas que grandes jugadores como Google, Facebook o Apple están usando Python, pero es la fea verdad: la mayoría del trabajo se hace gratis. El lenguaje que impulsa Youtube y que existía antes de Java ha sido hecho a mano por voluntarios.

Son voluntarios inteligentes y dedicados, pero cuando identifican que necesitan más jugo en un campo, no pueden pedir 300k para contratar a un especialista de primera categoría para esta área de experiencia. Tienen que buscar a alguien. quién lo haría gratis.

Mientras esto funcione, significa que tienes que ser muy cuidadoso con tus prioridades. Por lo tanto, ahora tenemos que mirar :

Objetivos

Incluso con las últimas características modernas, escribir Javascript es terrible. Tiene problemas de alcance, muy pocas colecciones, una terrible manipulación de cadenas y matrices, casi ninguna lista estándar aparte de la fecha, las matemáticas y las expresiones regulares, y ningún azúcar sintáctico, incluso para operaciones muy comunes.

Pero en V8, tienes velocidad.

Esto se debe a que, la velocidad era el principal objetivo de Google, ya que es un cuello de botella para la representación de la página en Chrome.

En Python, la usabilidad es el objetivo principal. Porque casi nunca es el cuello de botella en el proyecto. El recurso escaso aquí es tiempo de desarrollador. Está optimizado para el desarrollador.

Porque las implementaciones de JavaScript no necesitan preocuparse por la compatibilidad hacia atrás de sus enlaces.

Hasta hace poco los únicos usuarios de las implementaciones de JavaScript han sido los navegadores web. Debido a los requisitos de seguridad, solo los proveedores de navegadores web tenían el privilegio de ampliar la funcionalidad escribiendo enlaces a los tiempos de ejecución. Por lo tanto, no había necesidad de mantener la API C de los enlaces compatibles con versiones anteriores, era permisible solicitar a los desarrolladores del navegador web actualizar su código fuente a medida que evolucionaban los tiempos de ejecución de JavaScript; de todos modos estaban trabajando juntos. Incluso V8, que fue un recién llegado al juego, y también liderado por un desarrollador muy experimentado, ha cambiado la API a medida que se hizo mejor.

OTOH Ruby se usa (principalmente) en el lado del servidor. Muchas extensiones ruby populares se escriben como enlaces C (considere un controlador RDBMS). En otras palabras, Ruby nunca habría tenido éxito sin mantener la compatibilidad.

Hoy en día, la diferencia todavía existe hasta cierto punto. Desarrolladores usando node.js se quejan de que es difícil mantener sus extensiones nativas compatibles con versiones anteriores, ya que V8 cambia la API con el tiempo (y esa es una de las razones nodo.js ha sido bifurcado). IIRC ruby sigue adoptando un enfoque mucho más conservador a este respecto.

V8 es rápido debido al JIT, cigüeñal, el tipo de inferencer y código optimizado para datos. Punteros etiquetados, Nan-etiquetado de dobles. Y, por supuesto, hace optimizaciones de compiladores normales en el medio.

Los motores simples ruby, python y perl no hacen ninguna de esas, solo optimizaciones básicas menores.

La única máquina virtual importante que se acerca es luajit, que ni siquiera hace inferencia de tipos, plegado constante, etiquetado NaN ni enteros, sino que usa código y datos pequeños similares estructuras, no tan gordas como las malas lenguas. Y mi prototipo de lenguajes dinámicos, potion y p2 tienen características similares a luajit, y superan a v8. Con un sistema de tipo opcional, "gradual typing", podría superar fácilmente a v8, ya que puede omitir el cigüeñal. Ver dart.

Los backends optimizados conocidos, como pypy o jruby todavía sufren de varias técnicas de sobreingeniería.