Скорость обработки файлов Python 3.3 по сравнению с Fortran 77

Странный вопрос это, я знаю.

У меня есть кодовая база на фортране 77, которая по большей части анализирует большие недвоичные файлы, выполняет некоторые манипуляции с этими файлами, а затем выполняет большую запись файлов. Кодовая база не выполняет никаких манипуляций с матрицами или обработки чисел. Этот унаследованный код находится на Фортране, потому что многие другие базы кода действительно требуют серьезной обработки чисел. Первоначально это было просто написано на фортране, потому что было знание фортрана.

Мое предложение состоит в том, чтобы полностью переписать это на python (скорее всего, 3.3). Сопровождение кода на Фортране так же сложно, как и следовало ожидать, а тесты настолько плохи, насколько вы можете себе представить. Очевидно, что python очень поможет здесь.

Есть ли какие-либо удары по производительности (или даже прирост) с точки зрения скорости обработки файлов в python? В настоящее время большая часть времени работы этой системы приходится на чтение/запись файлов.

заранее спасибо


python migration io fortran legacy
person Fraser    schedule 04.10.2013    source источник
comment
Для задач, связанных с вводом-выводом, вы, вероятно, не заметите разницы. К сожалению, любые предположения о реальной производительности будут просто предположениями. Нет априорных причин полагать, что обработка текста в f77 лучше или хуже, чем в Python.   -  person msw    schedule 04.10.2013
comment
Сильно зависит от типа ввода-вывода, форматированного или неформатированного. какой у вас случай? Тем не менее, я думаю, что необработанный ввод-вывод Python легко достигает пика, за исключением параллельных файловых систем и так далее.   -  person Anycorn    schedule 04.10.2013
comment
Несколько месяцев назад возник похожий вопрос. Самая большая проблема с fortran заключалась в том, что, с одной стороны, каждая операция ввода-вывода могла быть окружена операциями блокировки и т. д., а с другой стороны, в зависимости от компилятора, вывод мог не буферизоваться по умолчанию. В конце концов, я бы не ожидал прироста производительности...   -  person Stefan    schedule 04.10.2013
comment
Очень полезные комментарии, спасибо. Я сделаю надлежащую бенчмаркинг и получу некоторые цифры для этого. Приятно знать, что никто не думает, что производительность снизится.   -  person Fraser    schedule 07.10.2013

Ответы (2)


arrow_upward
3
arrow_downward

Части ввода-вывода стандартной библиотеки Python реализованы как эффективный код C, поэтому я видел лучшую производительность, чем, например, в. Java, особенно в тех случаях, когда программа связана с вводом-выводом (в отличие от процессора).

Re:

В настоящее время большая часть времени работы этой системы приходится на чтение/запись файлов.

Кроме того, если ваша логика обрабатывает файл как поток, а не содержимое файла в целом, вы можете увидеть улучшение производительности при переходе на Python, если вы используете правильные инструменты для работы. В основном идея состоит в том, чтобы читать входные данные порциями, обрабатывать их и сразу же записывать результат в выходной файл. Это сводит к минимуму использование памяти и задержку, особенно если ваш конвейер состоит из нескольких шагов. Генераторы Python позволяют писать такую ​​логику очень чистым, удобочитаемым и лаконичным образом, чего вы не найдете в Fortran или C, по крайней мере, без особых дополнительных усилий по построению такой абстракции (и даже тогда вы получите очень волшебный и/или загадочный код).

См. http://www.dabeaz.com/generators/ для действительно хороший текст об обработке файлов в Python с помощью генераторов.

Кроме того, в зависимости от характера и сложности ваших алгоритмов обработки вы можете обнаружить, что другие абстракции (например, сопрограммы< /strong>) или библиотеки (gevent, numpy и т. д.), доступные в Python, помогут вам повысить общую производительность, потому что так проще понять и реорганизовать код. (Конечно, это справедливо для любого сравнения языков высокого и низкого уровня.)

Кроме того, проверьте PyPy: он может предоставлять (иногда значительный ) повышение производительности по сравнению с CPython в части обработки чисел без каких-либо дополнительных усилий с вашей стороны (не говоря уже о том, что вы не могли или не должны оптимизировать свой код для JIT-компилятора PyPy :)).

Кроме того, есть Cython, который позволяет вам писать обычный Python, смешивая его с частями, которые будут преобразованы напрямую. в код Си. Это имеет преимущество в лучшей ремонтопригодности и удобочитаемости по сравнению с Fortran (и C) с производительностью C, позволяя вам использовать большинство, если не все высокоуровневые конструкции Python, а также вызывать непосредственно чистый код Python, а также чистый Код/библиотеки C (и, возможно, код/библиотеки Fortran: http://www.sfu.ca/~mawerder/notes/calling_fortran_from_python.html). Вы также можете просто написать части вашего кода, критически важные для производительности (привязанные к ЦП), на Cython и вызывать их непосредственно из Python.

person Erik Kaplun    schedule 07.10.2013

arrow_upward
1
arrow_downward

В общем, если ваш конкретный компилятор и доступный набор инструментов не делают особенно контрпродуктивных вещей, один язык программирования может выполнять ввод-вывод так же быстро, как и другой. Во многих языках программирования наивный подход может быть неоптимальным — как и все аспекты программирования, связанные с производительностью, это то, что решается с помощью соответствующего проектирования и надлежащего использования доступных инструментов (таких как параллельная обработка, использование буферизованных и т. д.). например, многопоточный ввод-вывод).

Python не особенно плох в операциях ввода-вывода, предлагает буферизованный ввод-вывод и возможности многопоточности, и его легко расширять с помощью C (и поэтому, вероятно, не так сложно взаимодействовать с Fortran). Python, вероятно, будет совершенно разумной технологией для постепенной замены частей вашей кодовой базы — действительно, если вы сможете сначала сделать ввод-вывод быстрым в python, вы, вероятно, сможете скомпилировать расширение, которое в конечном итоге вызовет ваш код Fortran.

person Marcin    schedule 07.10.2013