Сколько NumPy и SciPy находится в C? - PullRequest
18 голосов
/ 01 декабря 2009

Запрограммированы ли части NumPy и / или SciPy на C / C ++?

А как соотносятся накладные расходы на вызов C из Python с накладными расходами на вызов C из Java и / или C #?

Мне просто интересно, является ли Python лучшим вариантом, чем Java или C # для научных приложений.

Если я посмотрю на перестрелки , Питон проигрывает с огромным отрывом. Но я думаю, это потому, что они не используют сторонние библиотеки в этих тестах.

Ответы [ 5 ]

17 голосов
/ 01 декабря 2009
  1. Я бы поставил под сомнение любой тест, который не показывает исходный код для каждой реализации (или я что-то упустил)? Вполне возможно, что одно или оба этих решения плохо написаны, что может привести к несправедливой оценке производительности одного или обоих языков. [Редактировать] Упс, теперь я вижу источник. Однако, как отмечали другие, он не использует библиотеки NumPy / SciPy, поэтому эти тесты не помогут вам принять решение.
  2. Я полагаю, что подавляющее большинство NumPy и SciPy написаны на C и упакованы в Python для простоты использования.
  3. Вероятно, от того, что вы делаете на каком-либо из этих языков, зависит количество накладных расходов для конкретного приложения.

Я использую Python для обработки и анализа данных уже пару лет, поэтому я бы сказал, что он определенно подходит для цели.

Чего вы пытаетесь достичь в конце дня? Если вам нужен быстрый способ разработки читабельного кода, Python является отличным вариантом и, конечно, достаточно быстрым для первого удара в том, что вы пытаетесь решить.

Почему бы не использовать bash для каждого небольшого подмножества вашей проблемы и сравнивать результаты с точки зрения времени разработки и времени выполнения? Тогда вы можете принять объективное решение, основываясь на некоторых соответствующих данных ... или, по крайней мере, это то, что я бы сделал: -)

5 голосов
/ 02 февраля 2010

Большая часть NumPy находится на C, но большая часть кода C является «образцом» для обработки всех «грязных» деталей интерфейса Python / C. Я думаю, что отношение C к Python составляет около 50/50 АТМ для NumPy.

Я не слишком знаком с низкоуровневыми деталями на основе vm, но считаю, что стоимость интерфейса будет выше из-за ограничений, наложенных на jvm и .clr. Одной из причин того, почему numpy часто быстрее аналогичных сред, является представление памяти и то, как массивы распределяются / передаются между функциями. В то время как большинство сред (Matlab и R, как я полагаю) используют Copy-On-Write для передачи массивов между функциями, NumPy использует ссылки. Но делать это, например, в JVM будет сложной (из-за ограничений на использование указателя и т. д.). Это выполнимо (существует ранний порт NumPy для Jython), но я не знаю, как они решают эту проблему. Может быть, C ++ / Cli сделает это проще, но у меня нет опыта работы с этой средой.

5 голосов
/ 02 декабря 2009

Здесь лучшее сравнение здесь (не тест, но показывает способы ускорения Python). NumPy в основном написан на C. Основным преимуществом Python является то, что существует ряд способов очень простого расширения вашего кода с помощью C (ctypes, swig, f2py) / C ++ (boost.python, weave). inline, weave.blitz) / Fortran (f2py) - или даже просто добавив аннотации типов в Python, чтобы их можно было обработать в C (cython). Я не думаю, что есть много вещей, сравнительно простых для C # или Java - по крайней мере, которые так безоблачно обрабатывают передачу числовых массивов разных типов (хотя я предполагаю, что сторонники поспорили бы, поскольку у них нет потери производительности Python, там меньше необходимости к).

5 голосов
/ 01 декабря 2009

Многое написано на С или фортране. Вы можете переписать горячие циклы в C (или использовать один из нескольких способов ускорить Python, мой любимый метод увеличения / увеличения), но действительно ли это важно?

Ваше научное приложение будет запущено один раз. Все остальное - просто отладка и разработка, и на Python это может быть намного быстрее.

0 голосов
/ 06 февраля 2012

Это всегда зависит от вашей собственной способности обрабатывать язык, поэтому язык может генерировать быстрый код. Исходя из моего опыта, Numpy в несколько раз медленнее, чем хорошие реализации .NET. И я ожидаю, что JAVA будет такой же быстрой. Их оптимизирующие компиляторы JIT значительно улучшились за эти годы и дают очень эффективные инструкции.

С другой стороны, numpy поставляется с синтаксисом, который проще использовать для тех, кто настроен на языки сценариев. Но если речь идет о разработке приложений, эти преимущества часто превращаются в препятствия, и вы будете стремиться к безопасности типов и корпоративным IDE. Кроме того, синтаксический разрыв уже закрывается с C #. Растет число научных библиотек для Java и .NET . Лично я склоняюсь к C #, потому что он обеспечивает лучший синтаксис для многомерных массивов и почему-то кажется более «современным». Но, конечно, это только мой личный опыт.

...