¿Por qué el rubí es mucho más lento en windows?

Question

¿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.

Answer 1

Conjeturaría hay algunas opciones posibles, y que probablemente se suman:

1. Rubí siendo desarrollado principalmente en Linux, que 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.
2. Según mi experiencia, las versiones recientes de gcc (4.3 y posteriores) 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.
3. En relación con el punto 1, si compila el mismo proyecto usando gcc para Windows o Linux, normalmente 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 vienen gratis) tendrá que ser gastado usando un perfilador 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.

Answer 2

Primero tiene que hacer una distinción entre el anterior MRI interpreter (versiones hasta 1.8) y el más nuevo YARV, 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 se está hablando del rendimiento de Ruby on Rails o de 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.

Answer 3

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 puedo pensar 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 de parámetros de copiar-escribir, que, según lo que leo, no se puede realizar correctamente en Windows, lo que provoca una gran sobrecarga en las llamadas a métodos.

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

Answer 4

No completamente a su pregunta, pero hubo una gran discusión en el Deep Fried Bytes podcast 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 comprobarlo.

Answer 5

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

Mientras trataba de escribir una extensión C para Ruby en Visual Studio, descubrí con horror que los archivos binarios descargables de Windows 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 ser construido con mingw, del cual no soy fanático, pero también debe ser mejor que VC6)

Sin saber qué operaciones en particular encuentras más lentas en Windows es difícil comentar más, 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.

Answer 6

ntfs La compresión automática de archivos 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, perdiendo ciclos de CPU ...

Ejecute el siguiente comando para descomprimir un todo ntfs maneja desde su raíz (es decir, "C: \") y ve 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