Почему моя версия Python медленнее, чем моя версия Perl? [закрытый]

Вся эта микромаркировка может стать немного глупой!

Например, просто переключение на для в обоих Python & Perl обеспечивает большой скачок скорости. Оригинальный пример с Perl был бы вдвое быстрее, если бы использовался для :

my $j = 0;

for my $i (1..100000000) {
    ++$j;
}

print $j;

И я могу сбрить немного больше с этим:

++$j for 1..100000000;
print $j;

И становясь еще глупее, мы можем снизить скорость до 1 секунды ;-)

print {STDOUT} (1..10000000)[-1];

/I3az/

ref: Использован Perl 5.10.1.

питон медленнее, чем перл. Он может быть быстрее развиваться, но не выполняется быстрее - это один бенчмарк http://xodian.net/serendipity/index.php?/archives/27-Benchmark-PHP-vs.-Python-vs.-Perl-vs.-Ruby.html -edit - ужасный бенчмарк, но это, по крайней мере, реальный бенчмарк с числами, а не какая-то догадка. Для плохих теорий нет ни исходника, ни теста, кроме как в цикле.

Я не во всем знаком с Python, но моей первой идеей об этом эталоне была разница между числами на Perl и Python. В Perl у нас есть числа. Они не являются объектами, и их точность ограничена размерами, накладываемыми архитектурой. На Python у нас есть объекты с произвольной точностью. Для маленьких чисел (тех, которые умещаются в 32 бита) я бы ожидал, что Perl будет быстрее. Если мы пройдемся по целочисленным размерам архитектуры, Perl-скрипт даже не будет работать без некоторой модификации.

Я вижу аналогичные результаты для оригинального бенчмарка на моем MacBook Air (32-битном) с использованием Perl 5.10.1, который я скомпилировал сам, и Python 2.5.1, который поставлялся с Leopard:

Однако, я добавил произвольную точность в программу на Perl с помощью bignum

 use bignum;

Теперь я задаюсь вопросом, будет ли Perl-версия когда-нибудь закончена. :) Я сообщу некоторые результаты, когда она закончит, но похоже, что это будет разница в порядках.

Некоторые из вас, возможно, видели мой вопрос о Какие пять вещей вы ненавидите в вашем любимом языке?. Номера по умолчанию Перла - одна из вещей, которые я ненавижу. Я никогда не должен думать об этом, и это не должно быть медленным. В Перле я проигрываю и на том, и на другом. Обратите внимание, однако, что если бы мне понадобилась числовая обработка в Perl, я мог бы использовать PDL.

Питон действительно намного медленнее, чем Perl?

Посмотрите на игру Computer Language Benchmarks Game - "Сравните производительность ≈30 языков программирования, использующих ≈12 ошибочных бенчмарков и ≈1100 программ".

Это всего лишь крошечные бенчмаркинговые программы, но они все равно делают гораздо больше, чем фрагмент кода, который вы засекли по таймеру -

http://shootout. alioth.debian.org/u32/python.php

To OP, в Python этот кусок кода:

j = 0
for i in range(10000000):
    j = j + 1
print j

тот же самый, что и

print range(10000001)[-1]

, который на моей машине,

$ time python test.py
10000000

real    0m1.138s
user    0m0.761s
sys     0m0.357s

работает примерно 1 с. range() (или xrange) является внутренним для Python и "внутренним", он уже может генерировать последовательность чисел для вас. Поэтому вам не нужно создавать свои собственные итерации, используя собственный цикл. Теперь, вы идете и находите Perl эквивалент, который может работать в течение 1 с, чтобы получить тот же самый результат

Python работает очень быстро, если вы используете правильный синтаксис языка Python. Это примерно описывается как « питонический ».

Если вы реструктурируете свой код таким образом, он будет работать как минимум в два раза быстрее (ну, на моей машине так и есть):

j = 0
for i in range(10000000):
    j = j + 1
print j

Каждый раз, когда вы какое-то время используете python, вы должны проверить, можете ли вы также использовать " для X в диапазоне () ".

Придирчивый ответ заключается в том, что вы должны сравнить его на идиоматический Python:

• Исходный код на моей машине занимает 34 секунд.
• Цикл for ( ответ Флориана ) с + = и xrange () занимает 21 .
• Помещение всего этого в функцию сокращает время до 9 секунд!
  Это намного быстрее, чем Perl (15 секунд на моей машине)!
  Объяснение: Локальные переменные Python намного быстрее глобальных переменных .
  (Честно говоря, я также пробовал функцию в Perl - без изменений)

• Избавление от переменной j сократило ее до 8 секунд:

  print sum (1 для i в xrange (100000000) )

Python обладает тем странным свойством, что более короткий код более высокого уровня имеет тенденцию быть самым быстрым: -)

Но реальный ответ заключается в том, что ваш «микротест» бессмыслен. Реальный вопрос скорости языка: какова производительность среднего реального приложения? Чтобы знать это, вы должны принять во внимание:

• Типичное сочетание операций в сложном коде. Ваш код не содержит структур данных, вызовов функций или операций ООП.

• Достаточно большая кодовая база, чтобы почувствовать эффекты кеширования - многие оптимизации интерпретатора жертвуют памятью на скорость, которая не измеряется какими-либо крошечными тестами.

• Оптимизация возможности : после написания кода, ЕСЛИ он недостаточно быстр, насколько быстрее вы сможете это сделать?

  Например. насколько сложно переложить тяжелую работу на эффективные библиотеки C.

Тесты PyPy и Octane являются хорошими примерами того, как выглядят реалистичные тесты скорости языка.

Если вы хотите поговорить о вычислении чисел, Python IS на удивление популярен среди ученых. Они любят его за простой псевдоматематический синтаксис и короткую кривую обучения, а также за отличную библиотеку numpy для обработки массивов и простоту обертывания другого существующего кода C.

И еще есть Psyco JIT , который, вероятно, запустит ваш игрушечный пример менее чем за 1 секунду, но я не могу проверить его сейчас, потому что он работает только на 32-битной x86.
РЕДАКТИРОВАТЬ : Теперь пропустите Psyco и используйте PyPy , кроссплатформенную, активно улучшающую JIT.

Python не особенно быстр в числовых вычислениях, и я уверен, что он медленнее, чем Perl, когда дело касается обработки текста.

Поскольку вы опытный специалист по Perl, я не знаю, применимо ли это к вам, но программы на Python в конечном итоге, как правило, более удобны в обслуживании и их быстрее разрабатывать. Скорость «достаточна» для большинства ситуаций, и у вас есть возможность перейти на C, когда вам действительно требуется повышение производительности.

Обновление

Хорошо. Я только что создал большой файл (1 ГБ) со случайными данными (в основном ascii) и разбил его на строки одинаковой длины. Это должно было имитировать файл журнала.

Затем я запустил простые программы на perl и python, которые построчно ищут в файле существующий шаблон.

В Python 2.6.2 результаты были

real    0m18.364s
user    0m9.209s
sys 0m0.956s

, а в Perl 5.10.0

real    0m17.639s
user    0m5.692s
sys 0m0.844s

Программы следующие (пожалуйста, дайте мне знать, если я делаю что-нибудь глупое)

import re
regexp = re.compile("p06c")

def search():
    with open("/home/arif/f") as f:
        for i in f:
            if regexp.search(i):
                print "Found : %s"%i

search()

и

sub search() {
  open FOO,"/home/arif/f" or die $!;
  while (<FOO>) {
    print "Found : $_\n" if /p06c/o;
  }
}

search();

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

Спасибо, Крис.

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

Для повышения производительности вы должны использовать локальное распределение, например, создание функции. Переводчик Python хранит локальные переменные в массиве, с гораздо более быстрым доступом.
Однако следует отметить, что это деталь реализации CPYSHON; Я подозреваю, что Ironpython, например, приведет к совершенно другому результату.

Наконец, для получения дополнительной информации по этой теме, я предлагаю вам интересное эссе из GVR, о оптимизации в Python: Python Patterns - оптимизация Anecdote .