Сравнение решений Python и Perl с задачей Wide Finder
Я был бы очень признателен, если бы вы могли сравнить выигрышный Решение O’Rourke на Perl с Решение Lundh на Python, поскольку я недостаточно хорошо знаю Perl, чтобы понять, что там происходит. В частности, я хотел бы знать, что дало Perl версии 3-кратное преимущество: алгоритмическое превосходство, качество расширений C, другие факторы?
Ответы 5
Perl сильно оптимизирован для обработки текста. Факторов так много, что сложно сказать, в чем разница. Внутри текст представлен совершенно по-другому (utf-8 по сравнению с utf-16 / utf-32), и механизмы регулярных выражений тоже совершенно разные. Механизм регулярных выражений Python является настраиваемым и используется не так часто, как Perl. Над ним работает очень мало разработчиков (я думаю, что он в значительной степени не поддерживается), в отличие от Perl, который по сути является «ядром языка».
В конце концов, Perl - это язык обработки текста то.
Я согласен с Константином. Я не понимаю, какое отношение к этому имеет юникод.
Лучшая реализация Perl с регулярными выражениями - это одна часть истории. Однако это не может объяснить, почему реализация Perl лучше масштабируется. Чем больше процессоров, тем больше разница. По какой-то причине у реализации python есть проблема.
Реализация Perl использует системный вызов mmap. Этот вызов устанавливает указатель, который на процесс кажется обычным сегментом памяти или буфером для программы. Он отображает содержимое файла в область памяти. Это дает преимущества в производительности по сравнению с обычным файловым вводом-выводом (чтение) - первое состоит в том, что для получения доступа к данным не требуются вызовы библиотек пользовательского пространства, другое заключается в том, что часто требуется меньше операций копирования (например, перемещение данных между ядро и пользовательское пространство).
Строки и регулярные выражения Perl основаны на 8-битных байтах (в отличие, например, от utf16 для Java), поэтому собственный «символьный тип» Perl является той же кодировкой, что и файл mmapped.
Когда обработчик регулярных выражений затем работает с переменной, поддерживаемой mmap, он получает прямой доступ к данным файла через усиленную область памяти - без прохождения функций ввода-вывода Perl или даже функций ввода-вывода libc.
Mmap, вероятно, в значительной степени отвечает за разницу в производительности по сравнению с версией Python, использующей обычные библиотеки ввода-вывода Python, которые дополнительно вводят накладные расходы на поиск разрывов строк.
Программа Perl также поддерживает -J для распараллеливания обработки, где oepen "- |" вызывает fork (), где дескриптор файла в родительском элементе относится к stdout дочернего элемента. Дочерние процессы сериализуют свои результаты в стандартный вывод, а родительский де-сериализует их для координации и суммирования результатов.
Версия Python также использует mmap. Регулярное выражение Python также напрямую работает с mmap.
The Perl implementation uses the mmap system call.
Этот. Он избегает копирования буфера и обеспечивает асинхронный ввод-вывод.
Версия Python также основана на mmap. Но не могли бы вы уточнить «mmap обеспечивает асинхронный ввод-вывод для версии Perl»?
Для Perl выпущен многоядерный движок (MCE). MCE неплохо справляется с этим, даже при чтении напрямую с диска с 8 рабочими (холодный кеш). Сравните с wf_mmap. MCE следует модели очередей банка при чтении входных данных. Найдите слайды в папке изображений.
Исходный код размещен на http://code.google.com/p/many-core-engine-perl/
Документацию по Perl можно прочитать по адресу https://metacpan.org/module/MCE
Реализация Wide Finder с MCE представлена в разделе examples / tbray /
https://metacpan.org/source/MARIOROY/MCE-1.514/examples/tbray/
Наслаждайтесь 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
Насколько мне известно, образцы журналов представляют собой ASCII, а версия Python использует байтовые строки без какого-либо преобразования Unicode. Поэтому я считаю, что здесь нет «UTF-8 против UTF-16».