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

Ответ 1

Ничего глубокого, я уверен, это вопрос выбора и зрелости. В конце концов, 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 за последние несколько лет.

Ответ 2

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

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

Python:

• Анализ кода в АСТ
• Преобразование АСТ в байт-код
• Выполнить байт-код на виртуальной машине

Ruby (до 1.9):

• Анализ кода в АСТ
• Интерпретировать АСТ непосредственно путем рекурсивного обхода

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

Ruby 1.9 переместился в YARV, что также основано на VM. Ruby 1.9 быстрее 1.8. Здесь цитата от создателя YARV, Koichi Sasada:

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

Интересным моментом является то, что Python VM также основана на стеке, как YARV.

Ответ 3

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

Ответ 4

Я прочитал ответы, и я вижу, что большинство людей говорят "о, вы не должны сравнивать с 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 примерно на 2x быстрее, чем Ruby 1.8, но все еще медленнее - на 2 раза медленнее, чем на Python.

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

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

Ответ 5

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