LINUX.ORG.RU

Что быстрее python или ruby?


0

0

Создал два файла:

1.py

#!/usr/bin/python
print 2**302400

и

1.rb

#!/usr/bin/ruby
print 2**302400;

Запускал таким образом:

date ; ./1.py ; date
date ; ./1.rb ; date

В результате 1.rb выполнился за 3 секунды, а 1.py выполнился за 6 секунд. Стало интересно с чем связано такая разница в скорости выполнения одной и той же операции. Тест проводил несколько раз, каждый раз один и тот же результат - 3 секунды ruby, 6 секунд python. Результат получился абсолютно одинаковый в обоих случаях (сравнивал редиректом в файлы и нахождением md5sum файлов)) не вручную же столько цифр)))).

Вобще не могу определиться что лучше использовать для 2 проектов: 1. веб парсер, работающий в несколько потоков 2. средних размеров веб приложение

Для 1 проекта собирался использовать perl исключительно из-за WWW::Mechanize, однако забросил это дело потому что язык ужасный, вместо того что бы упростить детали он их усложняет. Проще написать аналогичную библиотеку на другом нормальном языке программирования чем разобраться в этом перле.

Для 2 проекта собирался использовать PHP однако вовремя понял что проект для него слишком большой.

Ответ на: комментарий от mono

С++

Это и так понятно. Хотелось бы сравнения этих 2 языков. В гугле поискал, везде написано что python быстрее. Только вот в этом тесте что не так?

md5xxx1
() автор топика
Ответ на: комментарий от lenstr

Python 2.6.4

ruby 1.8.7 (2009-06-12 patchlevel 174) [x86_64-linux]

md5xxx1
() автор топика
Ответ на: комментарий от md5xxx1

тест ты выбрал неудачный. арифметику считать. проверь что-нибудь посложнее.

Ну и время лучше измерять time-ом.

mono ★★★★★
()
Ответ на: комментарий от mono

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

Как считать time'ом? Он показывает системные ресурсы а не время.

md5xxx1
() автор топика
Ответ на: комментарий от md5xxx1

Как считать time'ом? Он показывает системные ресурсы а не время.

time myprogram

он показывает время, а не системные ресурсы.

mono ★★★★★
()

> Вобще не могу определиться что лучше использовать для 2 проектов: 1. веб парсер, работающий в несколько потоков 2. средних размеров веб приложение

А зачем сравниваешь скорость возведения в степень?

tailgunner ★★★★★
()

Ты сравнил быстродействие встроенной в интерпретатор операции возведения в степень и работу с длинной арифметикой. Как часто ты будешь пользоваться этими операциями в своём парсере?

Раньше для питона был psyco (а-ля JIT), очень сильно оптимизировал математику.

suzuki
()

Лучше потестируй базовые конструкции языка. И погоняй какие-нибудь простенькие с точки зрения математики алгоритмы: вычисление частичных сумм каких-либо числовых рядов до какого-то n, например, чисел Фибоначчи. Возьми рекурсивный и нерекурсивный варианты. В таких тестах ruby1.8 будет в разы медленнее, чем python 2.6.4. В свою очередь, python 2.6.4 будет также в разы медленнее, чем ruby1.9.

twosev ★★
()
Ответ на: комментарий от suzuki

>Раньше для питона был psyco (а-ля JIT), очень сильно оптимизировал математику.

а сейчас разве нет? вроде есть.

mono ★★★★★
()

глупости это все, для твоих проектов разница в скорости выполнения будет некритичной.
бери тот, который знаешь. не знаешь ни того ни другого? бери питон, он проще, популярнее и имеет больше батареек. рубисты, ткните если что не так. // кстати, как у вас с модулями на Си?

val-amart ★★★★★
()

> В результате 1.rb выполнился за 3 секунды, а 1.py выполнился за 6 секунд.

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

Cy6erBr4in ★★★
()
Ответ на: комментарий от val-amart

Вопросом по поводу возведения в степень просто заинтересовался, ясно что для парсера это не критично.

Может кто нибудь посоветовать библиотеку для HTTP запросов на Python или Ruby, что бы она имела следущее: - возможность выбирать IP исходящего интерфейса на хосте с несколькими сетевыми интерфейсами - возможность устанавливать соединение через прокси - сохраняло куки между запросами Знаю что есть curl, очень не нравится что для того что бы получить куки надо создавать внешний файл куда он их будет сохранять, обходил это путём CURLOPT_HEADER = 1 что бы возвращался и заголовок тоже, выделение заголовка, и выделением cookies из него.

В то же время кроме curl'а не знаю ничего что бы позволяло выбирать source IP

md5xxx1
() автор топика
Ответ на: комментарий от md5xxx1

> да у тебя рантайм поднимался дольше, чем само вычисление заняло времени

На самом деле нет, если продублировать единственную строчку каждой программы то занимает 13 - python, 6 - ruby. Если удалить print, тогда вобще моментально, видимо оптимизация пропускает вычисление которое в дальнейшем не используется.

md5xxx1
() автор топика

Последние стабильные версии основных трансляторов обоих языков ~ равны по скорости. И эта скорость достаточно небольшая, чтобы выбирать язык ориентируясь на нее.

volh ★★
()
Ответ на: комментарий от val-amart

>бери питон, он проще, популярнее и имеет больше батареек.

Насчет популярнее тут без вопросов.

Насчет проще - можно поспорить. В руби много генетических перлизмов и кое-какой «вау-магии», но оно почти всегда unobtrusive и не касается тебя, пока сам не захочешь. Зато там нет путаницы с new-style и old-style классами, один встроенный тип списков, простая и всем понятная форма разделения доступа в классах ( public protected private ), etc.

Насчет батареек я тут уже создавал тему. Если под «батарейками» понимается наличие программ вообще и доступность в каждом дистрибутиве изкоробки - ок. Но если понимаются библиотеки - то уж давай конкретику, а то в той теме я так и не добился хоть какого-нибудь потока страждущих.

кстати, как у вас с модулями на Си?


Неплохо. Год с небольшим назад сделали человеческий FFI в главном интерпретаторе, потом подтянулись и другие, и теперь у нас во всех основных реализациях ( MRI aka default, JRuby и Rubinius ) одинаковый FFI и все сишные модули с ним написанные работают везде одинаково.

volh ★★
()
Ответ на: комментарий от volh

То что на руби в 2 раза быстрее всегда, а также то что программы запускаются на 2-ядерном процессоре, наводит на мысль что python использует только одно ядро в то время как ruby распараллеливает вычисления.

Пример посложнее:
[code]
par@maxlance ~/bench $ time ./1.py >/dev/null ; time ./1.rb >/dev/null

real   0m23.550s
user   0m23.550s
sys   0m0.000s

real   0m12.010s
user   0m11.960s
sys   0m0.030s
par@maxlance ~/bench $ cat 1.py
#!/usr/bin/python
for i in range(1,10000):
   print 2**i
par@maxlance ~/bench $ cat 1.rb
#!/usr/bin/ruby
for i in (1..10000) do
   print 2**i;
end
par@maxlance ~/bench $
[/code]

Короче ну и нафиг эти интерпретаторы оба. Так как C/C++ были моими первыми языками программирования, и я их знаю в несколько раз лучше чем python/ruby (хотя и не идеально) возьму так и быть C/C++ в оба проекта. Все библиотеки нашёл без проблем. Для бота http://www.mozilla.org/projects/netlib/ и для веб приложения http://www.webtoolkit.eu/wt

md5xxx1
() автор топика
Ответ на: комментарий от md5xxx1

PS. Как отредактировать сообщение? Какая то фигня с [code]...[/code] блоком.

md5xxx1
() автор топика
Ответ на: комментарий от suzuki

> Раньше для питона был psyco (а-ля JIT), очень сильно оптимизировал математику.

Сомневаюсь, что он как-то ускорит _одну_ очень долгую операцию.

const86 ★★★★★
()
Ответ на: комментарий от md5xxx1

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

Открой второй том Кнута и посмотри, сколько есть разных алгоритмов. А потом открой исходники питона и руби и посмотри, что там юзается.

const86 ★★★★★
()
Ответ на: комментарий от md5xxx1

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

Нет. Посчитать 2**n - раз плюнуть. А вот конвертнуть его в десятичное представление для печати - нудная задача. Попробуй печатать hex(2**100500).

const86 ★★★★★
()
Ответ на: комментарий от md5xxx1

>Так как C/C++ были моими первыми языками программирования, и я их знаю в несколько раз лучше чем python/ruby (хотя и не идеально) возьму так и быть C/C++ в оба проекта.

Тебя никто и не уговаривал.

Для бота http://www.mozilla.org/projects/netlib/ и для веб приложения http://www.webtoolkit.eu/wt


http://www.webtoolkit.eu/wt


I lold.

volh ★★
()

Забавно, что пример топикстартера в третьем питоне работает в четыре раза быстрее, чем во втором.

ethercrow
()
Ответ на: комментарий от md5xxx1

> возьму так и быть C/C++ в оба проекта

выбрать правильные инструменты важнее чем выбрать любимое.

VladimirMalyk ★★★★★
()
Ответ на: комментарий от volh

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

volh ★★
()
Ответ на: комментарий от volh

Если заменить печать десятичных на печать hexadecimal (hex(num) для python и num.to_s(16) для ruby) выходит что python их печатает в 20 раз быстрее.

выбрать правильные инструменты важнее чем выбрать любимое.

Я как раз и пытаюсь выбрать правильные. Самое простое для меня было бы написать на PHP, но он не поддерживает threads, что необходимо для бота.

md5xxx1
() автор топика
Ответ на: комментарий от md5xxx1

>Если заменить печать десятичных на печать hexadecimal (hex(num) для python и num.to_s(16) для ruby) выходит что python их печатает в 20 раз быстрее.

Ну ты продвинулся, да. Предлагаю тест еще лучше - получение 1000 http запросов на скорость. У кого время получения меньше - тот и круче. И опять же, напрямую связано с твоими задачами..

volh ★★
()

подсунь своей раби вот такой тест на конкатенацию строк

loop_count = 1000000

def method4():
  return ''.join([`num` for num in xrange(loop_count)])

.

kto_tama ★★★★★
()
Ответ на: комментарий от volh

> если самое простое - на php, чем же тебя не устроил перл с mechanize?

рррр!!! жуткий кошмар этот перл. даже не предлагайте! я лучше на ассемблере напишу. такого корявого языка я ещё не видел. вместо того что дать возможность программисту думать о деталях приложения он предлагает думать в терминах своих корявых конструкций что бы понять которые надо убить не один год. и даже после этого программа на перл это полная мешанина в которой переменные могут изменяться не предсказуемым образом. для примера, $_ передаётся в sub'ы и там может изменяться. вместо того что бы дать возможность программисту просто создать multidimensional array как это сделано в python, ruby, да даже в C++ (vector и т.д.) он разрешает помещать внутрь массива только scalar. хочешь multidimensional array возись с его антилогичными reference. и это только 2 примера идиотизма. кто то скажет щас что я его поленился выучить и что он просто много взял из лиспа что делает трудным для изучения C программистам в отличии от других языков которые похожи на C, а также что он как кто то где то написал «optimized for use rather than for learning». однако это полный бред, хоть как ты его знаешь всё равно вся эта мешанина приводит к нечитаемому коду и трудно предсказуемым результатам. кстати я не раз уже замечал что в модулях взятых из CPAN зачастую баг на баге сидит, есть только несколько которые более менее стабильны.

а ещё меня забанили по IP в irc.freenode.net на канале #perl уже где то с год назад и до сих пор не разбанили. за то что кто то спросил дать ссылку на книжку «Learning Perl» и я дал. а там сидел один из авторов или создателей я хз, randal schwartz (или как то так), и прикиньте забанил))) Нафиг мне нужна его книга в которой больше словесного пустословия чем программирования. И вообще этот пёрл полукоммерческий проект. Хитрые гады, релизят его под GPL только для того что бы им помогали в разработке, как для open source некоммерческого проекта. а сами зарабатывают на продажах этих своих пустословных книжек, потому что прекрасно знают что никто никогда не сможет разобраться до конца в этой мешанине которую они создали. кто начинает писать на этом пёрле подсаживается на него как наркоман и убивает всё больше и больше времени на то что бы учить этот бред. и вся концепция TIMTOWTDI полный отстой потому что она приводит к нечитаемому коду, и заставляет потратить сотни часов на изучение всей этой мешанины.

md5xxx1
() автор топика
Ответ на: комментарий от md5xxx1

слууушай. а может тебе erlang попробовать? что скажешь?

( жду такого же потока незамутненного сознания, попкорн есть )

volh ★★
()
Ответ на: комментарий от mono

> >Раньше для питона был psyco (а-ля JIT), очень сильно оптимизировал математику.

а сейчас разве нет? вроде есть.

Его не заинтегряли в мейнлайн?

suzuki
()
Ответ на: комментарий от md5xxx1

Весь этот несвязный поток сознания умещается в одну простую фразу: «я не пробовал писать на перле, но мне сказали, что он говно». Ни одной реальной проблемы озвучено не было, всё из озвученного бреда либо не соответствует действительности, либо не является проблемой.

возись с его антилогичными reference

О-ло-ло, и оно говорит, что на С писать умеет? 8))) А указатели тебе не «антилогичные», случайно? 8))))

kemm
()
Ответ на: комментарий от VladimirMalyk

>он хотел сказать, что об однострочкини на пёрл можно сломать мозг.

и поэтому мозг надо закалять хаскелем.

volh ★★
()

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

Том Кристъянсен и Рендел Шварц тебе помогут. Если уж перл по-твоему плох для парсера, то [тут я просто не знаю что сказать]

golodranez ★★★★
()
Ответ на: комментарий от VladimirMalyk

А об однострочники на sed'е? awk'е? На то они и однострочники, они не предназначены для повторного использования. Если однострочник записывается в файл, он тут же обязан перестать быть однострочником.

kemm
()
Ответ на: комментарий от kemm

Указатели раз в сто логичней этой фигни в перле. По той простой причине что они предельно просты по своей концепции - выделяешь место в памяти с помощью malloc и вот тебе массив. Однако если создавать выскоуровневый язык программирования нафига так делать. В том же C++ есть возможность надстроить свои классы для удобной работы с такими структурами, и STL с готовыми классами для этого.

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

$_ и дебилизм с массивами не соответствует действительности или не является проблемой?

md5xxx1
() автор топика
Ответ на: комментарий от md5xxx1

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

md5xxx1
() автор топика
Ответ на: комментарий от md5xxx1

я скажу только - ты не прав. ни в первом абзаце, ни во втором

golodranez ★★★★
()
Ответ на: комментарий от golodranez

> сли уж перл по-твоему плох для парсера, то [тут я просто не знаю что сказать]

А чем перл хорош для парсеров? Не, ну правда, чем? pcre?

suzuki
()
Ответ на: комментарий от volh

на кой?
«FBIPHDTWAIBM» мозг всегда отпарсит хуже чем «FBI PHD TWA IBM»

VladimirMalyk ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.