Python медленнее, чем Java/C#? [закрытый]

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

Я думаю напротив. Я могу сделать простую программу в Python быстрее, чем в Java, и те сценарии Python работают действительно быстро.

, Конечно, на Ваш вопрос без примеров трудно ответить. Возможно, Вы нашли медленную библиотеку, ошибка и т.д. Предоставляют нам больше подробной информации.

Я думаю, что это в конечном счете, что Python не идет насколько это может с оптимизацией. Большинство методов оптимизации, которые распространены, для статических языков. Там методы оптимизации для динамических языков, но современные, кажется, как очень не используют их, как они могли. У Steve Yegge есть превосходное сообщение в блоге на предмете .

РЕДАКТИРОВАНИЕ : Я просто хотел указать, что я не обязательно заявляю это, чтобы быть критически настроенным по отношению к Python. Я предпочитаю простоту по ненужной скорости любой день.

Это не имеет никакого отношения к самим языкам, это - просто то, что реализация java и система во время выполнения (JVM) является очень высококачественной, и что много ресурсов инвестировали в устойчивость, масштабируемость и повышения производительности за эти годы.

Контраст, что к тому, что реализация CPython просто недавно реализованная, например, поточная отправка в ее интерпретаторе, который дал ему повышение производительности до 20% для определенных проблем. Это не хорошая вещь, поскольку это звучит, это плохо, потому что такая основная оптимизация должна быть там со дня один.

Это сводится к тому, что фаза компиляции имеет меньшую информацию для работы с, и следовательно время выполнения должно сделать, больше работы в случае утки ввело языки (с динамическим контролем типов).

Таким образом, если я делаю вызов метода foo.bar (), в случае Java или C++, вызов к панели может быть оптимизирован в процессе компиляции путем обнаружения типа "нечто" и затем непосредственно вызова метода в ячейке памяти, где компилятор знает, что это будет найдено. Начиная с Python или любого другого компилятора динамически типизированного языка не знает то, что вводит объектное нечто, принадлежит, это должно сделать проверку типа во времени выполнения и затем искать адрес метода панели и затем вызвать его.

существуют другие трудности, с которыми борется разработчик компилятора Python также, хотя тот выше, надо надеяться, соответственно дает признак. Таким образом, даже с лучшими разработчиками компилятора, статически типизированные языки, вероятно, будут работать намного лучше во времени выполнения.

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

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

Однако я предположил бы, что помехи по сравнению с динамическим характером могут иметь непосредственное отношение к нему. Для невиртуальных вызовов скомпилированный в JIT C#/Java является чрезвычайно дешевым, поскольку он может быть определен точно в разовом JIT. Даже виртуальные вызовы просто включают единственный уровень перенаправления. Когда привязка становится динамичной, существует более широкий диапазон вещей рассмотреть.

я не знаю, что достаточно деталей о Python утверждает, что поняли его точное поведение во время выполнения, которое я подозреваю, может меняться в зависимости от версии и реализации также. Существует такая вещь как "код байта Python", который тогда выполнен виртуальной машиной - выполняет ли эта виртуальная машина на самом деле JIT-компиляцию или не является другим вопросом.

Это не действительно корректно для выяснения, почему Python медленнее, чем Java/C#. Как быстро Java? Ну, наивные интерпретаторы приблизительно в десять раз медленнее, чем оптимизированные компиляторы. Я полагаю, что существует Java bytcode интерпретатор, записанный в JavaScript - который, вероятно, не очень быстр. Так, намеченный вопрос, кажется, "Почему система языка CPython медленнее, чем эквивалентный Sun, IBM и Oracle время выполнения Microsoft.NET и JRE?"

я полагаю, что корректный ответ является нетехническим. Самый быстрый Java и время выполнения.NET быстрее, потому что у них есть многочисленные полностью занятые технические команды, разрабатывающие их в производительности конкурентной среде.

Динамические системы языка легко реализовать. Любой идиот может сделать это. Я имею. Статические системы языка более сложны к разработке и реализации. Простая статическая система будет иметь тенденцию работать намного быстрее, чем эквивалентный просто рабочий динамический эквивалент. Однако для высоко оптимизированных динамических систем возможно работать почти как быстро. Я понимаю, что некоторая реализация Smalltalk была довольно хороша. Часто заключаемый в кавычки пример разработанной динамической системы LISP-компьютер MIT .

, Кроме того, если настоящий пехотинец делается кодом библиотеки, то система языка не может иметь значения. С другой стороны, язык может поощрить (или дать время (!)) разработать более эффективные алгоритмы, которые могут легко вытереть различия в производительности постоянного множителя.

Что Вы получили существует ясный пример записи Java в Python:

 def __init__(self,size):  
     self.first = None  
     last = None  
     for i in range(size):  
         current = Person(i)  
         if self.first == None : self.first = current  
         if last != None :  
             last.next = current  
             current.prev = last  
         last = current  
     self.first.prev = last  
     last.next = self.first  

 def __init__(self,size):  
     chain = [Person(i) for i in range(size)]
     self.first = chain[0]
     chain = zip(chain, chain[1:].append(chain[0]))
     for p,n in chain:
        p.next = n
        n.prev = p

Поскольку он интерпретируется и не компилируется ... он должен быть медленнее во время выполнения.

В качестве таблицы, упомянутой в книге Code Complete (второе издание) , стр. 600,

C # равен C ++ во времени выполнения (1: 1). И Python медленнее, чем в сто раз, чем C ++ во время выполнения (> 100: 1).

И Java медленнее, чем C ++, в полтора раза (1,5: 1).

Эта статистика в среднем. Я не знаю, кто сделал это исследование, но кажется интересным.

На этот тип вопросов нельзя ответить только с помощью качественных рассуждений, вам нужны хорошие тесты для подтверждения. Вот один набор, который сравнивает Python 3 и C # Mono и обнаруживает, что Python в 3–300 раз медленнее. Результаты Python и Java аналогичны. (Применяются обычные предостережения об интерпретации тестов.)

Эти тесты также сообщают размер исходного кода, а Python был значительно более кратким, чем Java и C #.

Как упоминалось в других ответах, это зависит от системы времени выполнения, а также от решаемой задачи. Так что стандартный (C) Python не обязательно медленнее, чем Java или C #. Некоторые из его модулей реализованы на C. Таким образом, скорость нативной реализации сочетается с языком Python.

Мы провели небольшой эксперимент: мы сравнили время выполнения факторных вычислений на разных языках. Фактически тест был предназначен для оценки производительности реализаций целых чисел произвольной точности.

testee. language arbitrary-precision integers run-time

     1. Java     java.math.BigInteger         JRE 6.13
     2. .NET     System.Numerics.BigInteger   MS CLR 4.0
     3. Python   long                         Active Python 2.6.2.2
     4. Squeak   BigInt                       Squeak 3.10.2
     5. .NET     Mono.Math.BigInteger         MS CLR 4.0

results:

                 1)         2)       3)       4)        5)
   10.000!      343 ms    137 ms    91 ms  1.200 ms    169 ms
   20.000!    1.480 ms    569 ms   372 ms  1.457 ms    701 ms
   30.000!    3.424 ms  1.243 ms   836 ms  3.360 ms  1.675 ms
   40.000!    6.340 ms  2.101 ms 1.975 ms  6.738 ms  3.042 ms
   50.000!   10.493 ms  3.763 ms 3.658 ms 10.019 ms  5.242 ms
   60.000!   15.586 ms  7.683 ms 5.788 ms 14.241 ms 10.000 ms

alt text http://www.mycsharp.de/wbb2/attachment.php?attachmentid=6909&sid=0d5aa62b522d005d9e7089785b5d19f1

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

Кроме того, Python-тип "целых чисел произвольной точности" является встроенным long . Следовательно, вам даже не нужна специальная обработка типов, которая требуется для класса Java BigInteger.