Estaría muy agradecido si pudiera comparar el O’Rourke's Perl solution ganador Lundh's Python solution, ya que no conozco a Perl lo suficiente como para entender lo que está pasando allí. Más específicamente, me gustaría saber qué le dio a Perl la ventaja de la versión 3x: superioridad algorítmica, calidad de las extensiones C, ¿otros factores?Comparación de las soluciones de Python y Perl al desafío Wide Finder
Perl está muy optimizado para el procesamiento de texto. Hay tantos factores que es difícil decir cuál es la diferencia exacta. El texto se representa de forma completamente diferente internamente (utf-8 versus utf-16/utf-32) y los motores de expresiones regulares son completamente diferentes también. El motor de expresión regular de Python es personalizado y no tanto como el perl. Hay muy pocos desarrolladores trabajando en ello (creo que no se mantiene) en contraste con Perl, que es básicamente el "núcleo del lenguaje".
Después de todo Perl es el lenguaje de procesamiento de texto.
La mejor implementación de expresiones regulares de perl es una parte de la historia. Sin embargo, esto no puede explicar por qué la implementación de Perl tiene una mejor escala. La diferencia se agranda con más procesadores. Por alguna razón, la implementación de Python tiene un problema allí.
La implementación de Perl utiliza la llamada al sistema mmap. Lo que hace esa llamada es establecer un puntero que para el proceso parece ser un segmento normal de memoria o búfer para el programa. Mapea el contenido de un archivo en una región de la memoria. Hay ventajas de rendimiento de hacer esto frente a IO de archivo normal (leer): una es que no hay llamadas de biblioteca de espacio de usuario necesarias para acceder a los datos, otra es que a menudo hay menos operaciones de copia necesarias (por ejemplo, mover datos entre kernel y espacio de usuario).
Las cadenas y expresiones regulares de Perl están basadas en bytes de 8 bits (en oposición a utf16 para Java, por ejemplo), por lo que el 'tipo de carácter' nativo de Perl es la misma codificación del archivo mmapped.
Cuando el motor de expresiones regulares opera en la variable respaldada mmap, accede directamente a los datos del archivo a través de la región de memoria embebida, sin pasar por las funciones IO de Perl o incluso las funciones IO de libc.
El mmap es probablemente el principal responsable de la diferencia de rendimiento frente a la versión de Python que utiliza las bibliotecas Python IO normales, que además introducen la sobrecarga de buscar saltos de línea.
El programa Perl también es compatible con -J para paralelizar el procesamiento, donde el oepen "- |" provoca una bifurcación() donde el identificador de archivo en el padre es para el stdout del niño. Los procesos secundarios serializan sus resultados a stdout y el padre los deserializa para coordinar y resumir los resultados.
La versión de Python también usa mmap. Y la expresión regular de Python también opera en mmap directamente. – Constantin
La implementación de Perl utiliza la llamada al sistema mmap.
Esto. Evita la copia de búfer y proporciona E/S asíncronas.
La versión de Python también está basada en mmap. ¿Pero puede dar más detalles sobre "mmap proporciona asincronización de E/S para la versión de Perl"? – Constantin
Many-core Engine (MCE) ha sido lanzado para Perl. MCE lo hace bastante bien, incluso cuando lee directamente desde el disco con 8 trabajadores (caché en frío). Compare con wf_mmap. MCE sigue un modelo de cola de banco cuando lee datos de entrada. Mire debajo de la carpeta de imágenes para ver las diapositivas.
El código fuente está alojado en http://code.google.com/p/many-core-engine-perl/
La documentación de Perl se puede leer en https://metacpan.org/module/MCE
Una implementación del ancho Finder con MCE está previsto en los ejemplos/tbray/
https://metacpan.org/source/MARIOROY/MCE-1.514/examples/tbray/
Disfruta MCE.
Script....: baseline1 baseline2 wf_mce1 wf_mce2 wf_mce3 wf_mmap
Cold cache: 1.674 1.370 1.252 1.182 1.174 3.056
Warm cache: 1.236 0.923 0.277 0.106 0.098 0.092
Los registros de muestras son ASCII, hasta donde yo sé, y la versión de Python utiliza cadenas de bytes sin ninguna conversión Unicode. Así que creo que no hay "utf-8 versus utf-16" aquí. – Constantin
Estoy de acuerdo con constantin. No veo que unicode tenga que ver con eso. –