software - ¿Por qué el rubí es mucho más lento en Windows?

tag editor download (6)

Al principio, debe hacer una distinción entre el antiguo intérprete de MRI (versiones hasta 1.8) y el YARV más nuevo, que es el intérprete oficial de Ruby 1.9. Hay grandes mejoras de rendimiento y un diseño diferente en Ruby 1.9, por lo que uno necesita saber de qué versión está hablando. Supongo que lo que ha leído se refiere a la versión 1.8.x, que es la única que tiene un instalador de un solo clic hasta el momento.

Además, sería bueno saber si estás hablando sobre el rendimiento de Ruby on Rails o sobre Ruby en general. Sé que debe haber una distinción clara entre estos dos, pero debido a que Ruby on Rails es el uso principal de Ruby, la gente a menudo habla sobre su desempeño como si estuvieran hablando acerca del desempeño de Ruby.

En cuanto al compilador, Ruby se puede construir utilizando cualquier versión reciente de Visual Studio, que es más que excelente. Supongo que si existe tal diferencia de rendimiento, uno debe mirar la implementación del intérprete y ver si hay algo que pueda marcar la diferencia entre un sistema POSIX y uno de Windows.

¿Cuáles son las causas técnicas específicas de que Ruby sea mucho más lento en Windows? Las personas informan acerca de una caída de velocidad de 3X desde Linux / OSX y hay algunas discusiones vagas sobre Ruby usando un compilador para versiones de Windows que produce código lento pero no puedo encontrar ningún detalle específico.

¿Alguien sabe los detalles? No estoy interesado en hurf durf Windoze apesta yuk yuks.

El aumento de rendimiento no es del 300%, en general, en cambio, está más cerca del 50% -100%. La explicación de Casual Jim es uno de los motivos por los que las secuencias de comandos de procesamiento de datos son más lentas en Windows en comparación con las variantes de Unix y Linux.

En el caso más general, lo único que se me ocurre es que el desarrollo de Ruby está centrado en Linux, lo que ha llevado a muchos Unix-ismos en la forma en que Ruby se creó. Además, dado que la mayoría de los desarrolladores activos no son usuarios de Windows, existe muy poca experiencia en optimización de Windows en el equipo, y la mayoría de las decisiones de optimización del rendimiento se centran en acelerar las cosas en los sistemas Unix.

Un ejemplo específico de esto es que Ruby utiliza el paso del parámetro copy-on-write, que, de acuerdo con lo que leo, no se puede realizar correctamente en Windows, lo que provoca una gran sobrecarga en las llamadas a métodos.

Sin embargo, no puedo entender lo que Casual Jim hizo para merecer el voto de -8.

La compresión automática de archivos ntfs en Windows estaba ralentizando todo para mí. comienza a funcionar automáticamente cuando tiene poco espacio en HD ... y luego necesita descomprimir y volver a comprimir archivos sobre la marcha, a medida que accede a ellos, desperdiciando ciclos de CPU.

Ejecute el siguiente comando para descomprimir una unidad ntfs completa desde su raíz (es decir, "C: /") y ver si hay alguna diferencia, para mí hizo una gran diferencia y devolvió la velocidad de ruby / rails a lo que estaba acostumbrado antes !

comando es:

compact /u /s /i

No completamente para su pregunta, pero hubo una gran discusión sobre el podcast de Deep Fried Bytes que discutió la misma pregunta en el contexto de IronPython. Entiendo que tu pregunta pertenece a Ruby, pero puede haber problemas relacionados que también afecten a Ruby.

Además, la discusión hace un buen trabajo de mirar un poco más profundo que "Windows es una mierda", por lo que vale la pena echarle un vistazo.

No he trabajado mucho con el código fuente del intérprete de YARV, por lo que los siguientes comentarios pertenecen solo al intérprete de 1.8.6 MIR.

En el curso de tratar de escribir una extensión C para Ruby en Visual Studio, descubrí con horror que los archivos binarios de Windows descargables de Ruby 1.8.6 se compilan con Visual C ++ 6.0, que se lanzó poco después del final de la Segunda Guerra Mundial . Desde entonces, los compiladores (y los procesadores a los que apuntan) han avanzado considerablemente. Mientras que las versiones de Linux obtienen la última bondad de gcc, la compilación de Windows cojea junto con la tecnología de compilación del siglo pasado. Esa es una razón. (Descargo de responsabilidad: supuestamente 1.9 debe construirse con mingw, del cual no soy fan, pero que también debe ser mejor que VC6)

Sin saber qué operaciones en particular encuentras más lentas en Windows es difícil hacer más comentarios, pero notaré que encontré que la implementación de E / S en Ruby es considerablemente menos eficiente con las E / S de archivos locales y de red. Nunca profundicé en la implementación de las primitivas de E / S lo suficiente como para ver por qué, pero supongo que las implementaciones suponen que las construcciones rápidas de IO en Linux son las construcciones de IO rápidas en Windows, que casi nunca es el caso.

Supongo que hay algunas opciones posibles, y probablemente todas se suman:

Ruby, desarrollado principalmente en Linux, termina optimizado mecánicamente para ello. El código se prueba regularmente para Windows y todo funciona, pero el resultado es que el desarrollador pasará más tiempo optimizando Linux que Windows.
Para mi experiencia, las versiones recientes de gcc (4.3 y superior) producen código más eficiente que las versiones recientes de Visual Studio (al menos 2005). Mis pruebas incluyeron tanto el gasto de casos como el de un día para encontrar las mejores opciones para la optimización del código.
En relación con el punto 1, si compila el mismo proyecto usando gcc para Windows o Linux, generalmente observo una caída de rendimiento de aproximadamente 20% en Windows en comparación con Linux. Aquí nuevamente, supongo que esto se debe a que Linux (o Unices en general) es un objetivo principal para gcc, Windows es un puerto. Se pierde menos tiempo optimizando para Windows que Linux.

Al final, si uno quisiera optimizar Ruby para Windows, una cantidad significativa de tiempo (y dinero, hasta donde yo sé, los perfiladores en Windows no se obtienen de forma gratuita) se tendrá que gastar usando un generador de perfiles y optimizando los cuellos de botella. . Y todo tendrá que probarse en Linux para asegurarse de que no haya pérdida de rendimiento.

Por supuesto, todo lo que debe probarse nuevamente con su nuevo intérprete YARV .