Почему Python быстрее, чем Ruby?

Потому что Ruby 1.8 не был действительно разработан с учетом производительности, в то время как Python был более оптимизирован. В частности, Ruby 1.8 делал реальную интерпретацию, а не компиляцию для виртуальной машины, как большинство языков в наши дни. Ruby 1.9 (с YARV VM) примерно так же быстр, как Python 3 (может быть, немного медленнее, но гораздо ближе), а другие реализации еще быстрее.

Одна из причин заключается в том, что Python компилируется в байткод, который затем выполняется высоко оптимизированной виртуальной машиной. AFAIK Ruby не работает таким образом в версии 1.8 и более ранних - но интерпретирует деревья на лету.

Подумайте об этом так:

Python:

1. Разбор кода на AST
2. Преобразование AST в байткод
3. Запуск байткода на ВМ

Ruby (до 1. 9):

1. Разбор кода в AST
2. Интерпретация AST непосредственно рекурсивным обходом

Не вдаваясь в подробности, шаг 2 в старом Ruby имеет много повторений, потому что ему приходится "понимать" AST каждый раз, когда он их видит (что во внутреннем цикле составляет много). Python "понимает" AST только один раз, а затем ВМ выполняет байткод так быстро, как только может (что в принципе не отличается от того, как работают ВМ Java и .NET).

Ruby 1.9 перешел на YARV, который также основан на ВМ. Ruby 1.9 быстрее, чем 1.8. Вот цитата от создателя YARV, Коичи Сасады:

Сначала YARV - это простая стековая машина. которая выполняет псевдопоследовательные инструкции. Старый интерпретатор (matzruby) обходит абстрактное синтаксическое дерево (AST) наивно. Очевидно, что это медленно. YARV компилирует этот AST в YARV байткод и запускает его.

Интересно отметить, что Python VM также основана на стеке, как и YARV.

Я читал ответы и вижу, что большинство людей говорят: «О, вы не должны сравнивать Ruby 1.8, вы должны использовать 1.9, это намного быстрее». Хорошо, хорошо, почему бы просто не взглянуть на некоторые тесты?

Итак, вот как Ruby 1.9 (YARV) работает против Ruby 1.8 (MRI): http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=yarv&lang2=ruby

И вот как Ruby 1.9 сравнивается с Python 2.x: http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=yarv&lang2=python

Напомним, Ruby 1.9 примерно в 2 раза быстрее , чем Ruby 1.8 - но все же медленнее - в 2 раза медленнее - чем Python.

PS. Думаю, мне нужно уточнить после возражений Чака: я не считаю выбивание компьютерного языка окончательным ответом на вопросы Жизни, Вселенной и всего остального . Отнюдь не. Буду рад ссылкам на другие объективные источники.

Я также был бы рад услышать неофициальные / субъективные результаты от людей здесь, на S / O, при условии, что они участвовали в более чем 50 обсуждениях Python или Ruby и их предвзятость Ruby / Python находится в пределах +/- 5 дБ (Ruby / Python Коэффициент рассчитывается как RPR = 10 * log10 (numTags ('Ruby') / numTags ('Python')) дБ; таким образом, для пользователя Chuck это будет 10 * log10 (225/13) = 12 дБ, у меня -10 - мы оба нельзя полагаться на объективное мнение): -)

Все больше людей работали над разработкой Python в течение многих лет, поэтому было сделано больше оптимизации. Языки одинаково гибки и выразительны, поэтому их производительность должна сходиться, поскольку все хорошие идеи оптимизации используются в обоих. Как отмечалось выше, Ruby 1.9 существенно сокращает разрыв в производительности с Python.

Ничего глубокого, я почти уверен - это строго вопрос выбора реализации и зрелости. В конце концов, не так давно Python во многих аспектах был гораздо медленнее! Вот, например:

$ py24 -mtimeit '[i+i for i in xrange(55)]'
100000 loops, best of 3: 10.8 usec per loop
$ py25 -mtimeit '[i+i for i in xrange(55)]'
100000 loops, best of 3: 9.83 usec per loop
$ py26 -mtimeit '[i+i for i in xrange(55)]'
100000 loops, best of 3: 8.12 usec per loop
$ py27 -mtimeit '[i+i for i in xrange(55)]'
100000 loops, best of 3: 6.35 usec per loop

Да, все на одной машине (Macbook Pro, 2.4 ГГц Intel Core 2 Duo, OSX 10.5), все "официальные" релизы для Mac от python.org (последний из каждого x в серии 2.x). У меня нет 2.3, чтобы проверить, но я ожидаю, что он будет немного медленнее, чем 2.4.

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

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