Python с Numpy/Scipy против чистого С++ для анализа больших данных

Выполнение Python на относительно небольших проектах заставляет меня оценить динамически типизированный характер этого языка (нет необходимости в коде декларации для отслеживания типов), что часто приводит к более быстрому и менее болезненному процессу разработки на этом пути. Однако я чувствую, что в гораздо более крупных проектах это может быть помехой, поскольку код будет работать медленнее, чем говорят, его эквивалент в С++. Но опять же, используя Numpy и/или Scipy с Python, вы можете заставить свой код работать так же быстро, как и родная программа на С++ (где иногда код С++ иногда требует больше времени для разработки).

Я публикую этот вопрос после прочтения комментария Джастина Пила по теме "Является ли Python быстрее и легче С++?, где он заявляет:" Кроме того, люди, которые говорят о том, что Python медленны для серьезного хруста, не использовали модули Numpy и Scipy. В наши дни Python действительно снимается в научных вычислениях. Конечно, скорость исходит от использования модулей, написанных на C или библиотеках, написанных в Фортране, но, по-моему, красота языка сценариев ". Или, как пишет S. Lott, в той же теме, что касается Python:"... поскольку он управляет памятью для меня, мне не нужно делать какое-либо управление памятью, экономя часы на то, чтобы преследовать утечки ядра". Я также изучил вопрос о производительности Python/Numpy/С++, посвященный " "Бенчмаркинг" (python vs. С++ с использованием BLAS) и (numpy)" где пишет JF Sebastian "... Нет никакой разницы между С++ и numpy на моей машине."

Оба эти потока заставили меня задаться вопросом, есть ли какие-либо реальные преимущества, связанные с пониманием С++ для программиста на Python, который использует Numpy/Scipy для создания программного обеспечения для анализа "больших данных", где производительность, очевидно, имеет большое значение (но также код читабельность и скорость разработки)?

Примечание. Мне особенно интересно обрабатывать огромные текстовые файлы. Текстовые файлы порядка 100K-800K строк с несколькими столбцами, где Python может занять хорошие пять минут, чтобы проанализировать файл длиной всего 200 тыс. Строк.

ОТВЕТЫ

Ответ 1

Прежде всего, если основная часть вашей "работы" связана с обработкой огромных текстовых файлов, это часто означает, что ваше единственное значимое узкое место в скорости - это скорость вашего ввода-вывода на диске, независимо от языка программирования.

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

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

Ответ 2

Короткий ответ заключается в том, что для простых задач тогда не должно быть большой разницы. Если вы хотите сделать что-то сложное, вы быстро столкнетесь с резкими различиями в производительности.

В качестве простого примера попробуйте добавить три вектора вместе

a = b + c + d

В python, как я понимаю, это обычно добавляет b в c, добавляет результат в d, а затем указывает на этот окончательный результат. Каждая из этих операций может быть быстрой, поскольку они просто обрабатываются в библиотеке BLAS. Однако, если векторы большие, то промежуточный результат не может быть сохранен в кеше. Перемещение этого промежуточного результата в основную память происходит медленно.

Вы можете сделать то же самое на С++, используя valarray, и это будет равномерно медленным. Однако вы также можете сделать что-то еще

for(int i=0; i<N; ++i)
  a[i] = b[i] + c[i] + d[i]

Это избавляет от промежуточного результата и делает код менее чувствительным к скорости в основной памяти.

Выполнение эквивалентной вещи в python возможно, но конструкции цикла python не так эффективны. Они делают приятные вещи, например, проверки границ, но иногда быстрее запускать с отключенными безопасностями. Например, Java выполняет достаточную работу для удаления проверок границ. Поэтому, если у вас достаточно интеллектуальный компилятор /JIT, петли python могут быть быстрыми. На практике это не сработало.

Ответ 3

Python определенно сохранит ваше время разработки, он также обеспечит вам гибкость, если вы просто сравниваете здесь два языка, хотя он все еще не может соответствовать мощности и производительности C/С++, но кто интересуется этим возрастом высокой памяти, кластеров, кеширования и параллельной обработки? Другим недостатком С++ может быть возможная авария, а затем отладка и исправление с большими данными может стать кошмаром.

Но, сказав, что я не видел места, где есть один размер, доступно все решение, ни один язык программирования не содержит решений для каждой проблемы (если вы не старый разработчик C, который хотел бы создать базу данных в C а также:) вы должны сначала определить все проблемы, требования, тип данных, будь то структурированные или неструктурированные, какие текстовые файлы вам нужно манипулировать, каким образом и порядок, расписывает проблему и так далее. Затем вам нужно создать полный стек приложений с помощью некоторых наборов инструментов и языков сценариев. Как всегда, вы можете всегда вкладывать больше денег в аппаратные средства или даже покупать какой-то дорогой инструмент, такой как Ab Initio, который дает вам возможность загружать и анализировать эти большие текстовые файлы и манипулировать данными, если вам не нужны реальные возможности сопоставления шаблонов на самом деле biggg файлы данных, python будет прекрасно сочетаться с другими инструментами. Но я не вижу ни одного ответа "да/нет", в некоторых ситуациях питон может быть не лучшим решением.