Comments 221
Неожиданный, но очень приятный результат :)
а что Вы будете делать, если разработчики пхп в версии, скажем, 5.3 поставят упор на скорость? :)
Хм, ничего, так и останусь на Ruby:)
Лично для меня синтаксический сахар(а следовательно более высокая скорость разработки) важнее чем скорость выполнения.
Лично для меня синтаксический сахар(а следовательно более высокая скорость разработки) важнее чем скорость выполнения.
полностью поддерживаю.
а если есть затыки то всегда можно переписать медленный код на си.
а если есть затыки то всегда можно переписать медленный код на си.
Вы оценили скорость работы интерпретированного приложения, в то время как на практике гораздо большее значение имеет скорость собственно интерпритации когда. Скорее всего, при таком испытании, победил бы питон за счёт компиляции в байт-код.
Ruby сравнивать c php грешно, каким бы быстрым не был php. Я не говорю, что php плохой, просто там нет дизайна.
Кстати, в какой блог перенести? Или так и оставить в личном?
Расшифруйте, пожалуйста, что значит: real, user, sys в тестах.
real — общее время
user — время затраченное в user mode
sys — время затраченное в kernel mode
Подробнее можете например тут почитать unixhelp.ed.ac.uk/CGI/man-cgi?time
user — время затраченное в user mode
sys — время затраченное в kernel mode
Подробнее можете например тут почитать unixhelp.ed.ac.uk/CGI/man-cgi?time
PHP, значит, не просто живее всех живых, но еще и быстрее, спасибо за тест!
Конечно, интересно бы посмотреть на работу с БД и мультимедиа, но это уже возможности модулей, а не языков, будет необъективно…
Конечно, интересно бы посмотреть на работу с БД и мультимедиа, но это уже возможности модулей, а не языков, будет необъективно…
Странный тест. Взяли вообщем-то редко используемую задачу в этих языках программирования и на ее основе делаются выводы о скорости всего языка. Например, по вашим данным Python проигрывает PHP, но я специально сравнивал их скорости на конкретной небольшой, но комплексной задаче, результат, как вы понимаете, был абсолютно противоположный.
Не буду спорить, вполне возможно.
Просто этот топик, это ответ на коментарий: habrahabr.ru/blogs/ruby/48928/#comment_1272091
Просто этот топик, это ответ на коментарий: habrahabr.ru/blogs/ruby/48928/#comment_1272091
Тогда мне непонятна эта фраза «Python примерно соизмерим по скорости с Perl. Ruby 1.8 естественно проигрывает. PHP почти быстрее всех...» без контекста естественно. Каков процент таких счетных задач на скриптовых языках программирования, чтобы о быстродействии вычислений факториала, можно было судить о быстродействии всего языка?
Просто откровенно раздражают такие необъективные выводы, только зря народ неопытный баламутите.
Просто откровенно раздражают такие необъективные выводы, только зря народ неопытный баламутите.
Прочитайте, пожалуйста первую строчку внимательней:)
«В коментариях к моей статье были высказанны просьбы протестировать производительность приведенного там примера на других языках. Что я и пытался сделать.»
В ней то как раз и устанавливается контекст.
«В коментариях к моей статье были высказанны просьбы протестировать производительность приведенного там примера на других языках. Что я и пытался сделать.»
В ней то как раз и устанавливается контекст.
Зачем вам пытаться понять фразу без контекста, когда она написана в контексте определённой задачи?
Есть же shootout.alioth.debian.org/
Там хоть и не последняя версия руби, но вы обратите внимание на количество бенчмарков.
Превосходство какого-либо языка в одном синтетическом тесте, говорит только о том, что этот язык быстрее других выполняет этот синтетический тест. Ни о каком сравнении языков не может быть и речи.
Там хоть и не последняя версия руби, но вы обратите внимание на количество бенчмарков.
Превосходство какого-либо языка в одном синтетическом тесте, говорит только о том, что этот язык быстрее других выполняет этот синтетический тест. Ни о каком сравнении языков не может быть и речи.
Тест был бы гораздо лучше, если бы еще сравнивалась память, занимаемая при выполнении скриптов.
+ для таких штук в питоне есть psyco: пишем 2 строчки
import psyco
psyco.bind(Factor.factorization)
после объявления класса, и вуаля — у меня время real с 0.395 упало до 0.046, почти в 10 раз.
+ для таких штук в питоне есть psyco: пишем 2 строчки
import psyco
psyco.bind(Factor.factorization)
после объявления класса, и вуаля — у меня время real с 0.395 упало до 0.046, почти в 10 раз.
Ну естественно что с JIT быстрее будет:) Я для всех языков использовал просто стандартные интерпретаторы.
И опять же повторюсь iv_s.habrahabr.ru/blog/48952/#comment_1272787
И опять же повторюсь iv_s.habrahabr.ru/blog/48952/#comment_1272787
так руби 1.9 потому и быстрее, что в него YARV интегрировали
а насчет того, что psyco не стандартный — это скорее штука идеологическая.
Его настолько просто использовать, что не вижу особой разницы.
установка: sudo easy_install psyco
использование:
import psyco
psyco.bind(function_name)
Питоновский «Explicit is better than implicit.» против «Convention over Configuration» от Руби в действии, кому что нравится)
А про память я заговорил именно поэтому, просто есть подозрение, что с jit-компиляцией ruby 1.9 станет есть больше памяти, примерно как python при использовании psyco. А раз все интегрировано, то бороться с этим станет сложнее. Замеров не проводил, просто мысли по поводу.
а насчет того, что psyco не стандартный — это скорее штука идеологическая.
Его настолько просто использовать, что не вижу особой разницы.
установка: sudo easy_install psyco
использование:
import psyco
psyco.bind(function_name)
Питоновский «Explicit is better than implicit.» против «Convention over Configuration» от Руби в действии, кому что нравится)
А про память я заговорил именно поэтому, просто есть подозрение, что с jit-компиляцией ruby 1.9 станет есть больше памяти, примерно как python при использовании psyco. А раз все интегрировано, то бороться с этим станет сложнее. Замеров не проводил, просто мысли по поводу.
Python, если я не ошибаюсь, тоже в промежуточный байт код компилируется. А насчет памяти в Ruby 1.9, можно тот же shootout посмотреть:
shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=yarv&lang2=psyco
по производительности конечно раза в 3-4 проигрывает(может 1.9.1 уже быстрее будет:)), но по памети все-таки чуть меньше.
>Explicit is better than implicit.
Все таки psycho сторонняя библиотека, не в python core:)
shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=yarv&lang2=psyco
по производительности конечно раза в 3-4 проигрывает(может 1.9.1 уже быстрее будет:)), но по памети все-таки чуть меньше.
>Explicit is better than implicit.
Все таки psycho сторонняя библиотека, не в python core:)
в питоне да, что-то такое есть, но это не компиляция, а скорее препроцессор, просто сокращение текста программы
«A program doesn't run any faster when it is read from a ‘.pyc’ or ‘.pyo’ file than when it is read from a ‘.py’ file; the only thing that's faster about ‘.pyc’ or ‘.pyo’ files is the speed with which they are loaded.»
«A program doesn't run any faster when it is read from a ‘.pyc’ or ‘.pyo’ file than when it is read from a ‘.py’ file; the only thing that's faster about ‘.pyc’ or ‘.pyo’ files is the speed with which they are loaded.»
psyco к тому же еще и год уже как заброшена) но всем как-то по барабану, работает ведь)
А автор psyco занят веселой штукой — пишет интерпретатор питона на питоне, чтобы прикрутить к нему потом JIT и всем было счастье и все работало быстрее, чем питон, написанный на C.
С памятью глянул — да, в руби прогресс заметен по сравнению с тем, что было раньше.
А автор psyco занят веселой штукой — пишет интерпретатор питона на питоне, чтобы прикрутить к нему потом JIT и всем было счастье и все работало быстрее, чем питон, написанный на C.
С памятью глянул — да, в руби прогресс заметен по сравнению с тем, что было раньше.
Питон на питоне — оригинально:)
Меня больше интригует вот это проект www.parrot.org/
Я давно-давно смотрел, там совсем все глухо было.
Сейчас зашел — обещают релиз 1.0 в марте. Думаю посмотреть в ближайшее время.
Меня больше интригует вот это проект www.parrot.org/
Я давно-давно смотрел, там совсем все глухо было.
Сейчас зашел — обещают релиз 1.0 в марте. Думаю посмотреть в ближайшее время.
> Питон на питоне — оригинально:)
Может для питона это и оригинально, но это обычная практика. Компиляторы не пишут на ассемблере, часто их пишут на предыдущих версиях этого же компилятора, а потом уже оптимизируют. Точно также как первый компилятор C++ писался с использованием C.
Может для питона это и оригинально, но это обычная практика. Компиляторы не пишут на ассемблере, часто их пишут на предыдущих версиях этого же компилятора, а потом уже оптимизируют. Точно также как первый компилятор C++ писался с использованием C.
Не, идея кросс-компиллеров понятна. У них свои задачи.
Я просто не очень представляю каким образом можно в данном случае прирост производительности получить, в сравнении с тем же Psycho.
Я просто не очень представляю каким образом можно в данном случае прирост производительности получить, в сравнении с тем же Psycho.
Ну так ведь JIT. А разработка на питоне — чтобы в очередной раз доказать что это быстрее. Выглядит действительно «весело», эх, есть же у него времени на coding for fun.
Думаю там всеже не for fun а гранд какой нибудь:)
Там был гранд от Евросоюза
А размер какой случаем не знаете? Интересно сколько за инновации в программировании дают:)
АФАИР, грант был несколько миллионов евро на полтора года. Но он закончился ещё прошлой весной, тогда как раз выпустили версию 1.0.
Неплохо, совсем неплохо. Но скорей всего это не на человека, а на исследовательскую группу какого-нить университета.
Да, это не на человека, а на всю толпу (десятка полтора людей, вроде бы, может и больше). Толпа вроде как не из одного университета — сборная солянка. Плюс, если я не ошибаюсь, все спринты тоже оплачивались из этих денег. А спринты у них ой какие весёлые были — в духе собраться в домике на горнолыжном курорте на недельку, кататься на лыжах/сноуборде и прогать. Правда, активность разработки во время таких спринтов просто поражает :)
codespeak.net/pypy/dist/pypy/doc/home.html
веселуха по полной программе «bla-bla-bla up to the point of being able to automatically generate Just-in-Time compilers for dynamic languages»
веселуха по полной программе «bla-bla-bla up to the point of being able to automatically generate Just-in-Time compilers for dynamic languages»
Psyco, во время выполнения программы собирает информацию о типах объектов, и затем эта информация используется для генерации высокоэффективного машинного кода, оптимизированного для объектов этого типа. После этого произведенный машинный код заменяет соответствующие участки байт-кода и тем самым увеличивает скорость выполнения программы. © Марк Лутц
Конечно, если используются С++ вставки, то они не будут оптимизированы с помощью Psyco.
Поэтому, думаю, не лишним было бы протестировать чисто-питоновский код данного примера с использованием Psyco.
PS: А никто не пробовал использовать транслятор Shedskin C++, насколько он может дать прирост?
Конечно, если используются С++ вставки, то они не будут оптимизированы с помощью Psyco.
Поэтому, думаю, не лишним было бы протестировать чисто-питоновский код данного примера с использованием Psyco.
PS: А никто не пробовал использовать транслятор Shedskin C++, насколько он может дать прирост?
на моей машине psyco дает ускорение в 8.6 раз, думаю, тут примерно так же будет (вместо 0,537 будет где-то 0,062, т.е. раза в 4 быстрее, чем руби 1.9)
В контексте данного теста Shedskin — это читерство:)
А вообще с их сайта:
For a set of 27 non-trivial test programs (at about 7,000 lines in total; see the ss-progs-0.0.30.tgz download), measurements show a typical speedup of 2-40 times over Psyco, and 2-220 times over CPython.
Но 220 — это какие-то уже совсем нереальные чила, только если частный случай разворачивания динамических вещей типо eval, или кэшерование.
А вообще с их сайта:
For a set of 27 non-trivial test programs (at about 7,000 lines in total; see the ss-progs-0.0.30.tgz download), measurements show a typical speedup of 2-40 times over Psyco, and 2-220 times over CPython.
Но 220 — это какие-то уже совсем нереальные чила, только если частный случай разворачивания динамических вещей типо eval, или кэшерование.
«Convention over Configuration» — девиз рельс. Рельсы — это не руби. Вы задолбали путать.
Прикиньте, кто-нибудь питон с джанго бы начал путать.
Прикиньте, кто-нибудь питон с джанго бы начал путать.
За тест спасибо, хорошее дело.
Это типа как в Perl'е use memoize? Так ничестно — это хак :)
А если серьезно, то конечно, хотелось бы какие-то комплексные тесты посмотреть.
Счетные задачи в вебе — это редкость. Обычно в вебе задачи структурные (работа со сложными структурами данных и обработка текстов).
А если серьезно, то конечно, хотелось бы какие-то комплексные тесты посмотреть.
Счетные задачи в вебе — это редкость. Обычно в вебе задачи структурные (работа со сложными структурами данных и обработка текстов).
Интересные цифры, абстрактные, конечно, но возможно и не зря стал Ruby изучать на замену PHP :)
А Python 3.0 будет как-то отличаться по скорости от 2.*?
ничего php10 переплюнет ruby 2.0 :)
К тому времени уже наверно Ruby 5 будет, так что не страшно:)
А если серьезно — за тест спасибо + прочитав комментарии можно еще раз убедиться — разницы нет на чем вы программируете, скорость можно увеличить правильным подходом, а так же прямотой рук. И всегда читайте, что нам дают новые версии продуктов.
Гораздо важнее для языков их читаемость и скорость разработки, для себя я выбрал Python.
Именно по этому же принципу для себя я выбрал Ruby:) В сравнении с Python синтаксического сахара там больше.
Извините за оффтоп.
Просто спросить не у кого. Расскажите неграмотному поподробнее о возможностях Ruby, для меня пока этот язык — загадка… У меня ситуация такая… вот я владею в какой-то мере PHP, осваивал ASP.NET (это для веб), для десктопных приложений и приложений с БД использую C# (раньше С++Builder). Как с этим у Ruby? Удобно ли использовать для написания десктопных приложений? Для веба я уже ни раз слышал, что рельсы Ryby рулят, а как с хостингом? Достаточно ли они распространены и качественны уже? Заранее спасибо.
Просто спросить не у кого. Расскажите неграмотному поподробнее о возможностях Ruby, для меня пока этот язык — загадка… У меня ситуация такая… вот я владею в какой-то мере PHP, осваивал ASP.NET (это для веб), для десктопных приложений и приложений с БД использую C# (раньше С++Builder). Как с этим у Ruby? Удобно ли использовать для написания десктопных приложений? Для веба я уже ни раз слышал, что рельсы Ryby рулят, а как с хостингом? Достаточно ли они распространены и качественны уже? Заранее спасибо.
Ruby удобен будет тем, что вы на одном языке сможете и Desktop и Web программировать. Desktop-приложения программировать удобно, особенно с Shoes. Для веба проще использовать VPS и не мучатся.
Python уже удобен тем
Да, VPS это здорово, но мне кажется, что это решение актуально для высоконагруженных сайтов. Разве нет? Где важна скорость. Ведь разница в цене 3-4 раза с виртуальным хостингом довольно значительна, особенно для небольших сайтов.
VPS к скорости отношение не имеет. Он больше нужен тем, кто хочет контроль. Я перешёл на VPS ещё, когда писал на PHP — замучало отсутствие нужных расширений или их старая версия. На VPS у вас есть root и вы можете делать с системой всё что угодно.
Понятно. Да это удобно… но все же дороговато.
Посмотрите на 1vds.ru/, попробовать нужно ли оно вам, да и справитесь ли вполне сравнимо по цене со средним php-хостингом
>На VPS у вас есть root и вы можете делать с системой всё что угодно.
И несете за это полную ответственность, прежде всего за безопасность, что на практике, в условиях ограниченного бюджета (профессионалам платить не хочется/не можется), означает еще и освоение професии *nix админа. Конечно, поднять локальный дев-сервер через консоль или по ssh редактировать файлы должен уметь любой веб-разработчик, но вот знать какие процессы на нем крутятся по дефолту, какие можно безболезненно отключить, а какие нет, уметь писать правила для iptable (и уметь делать так, чтобы они сохранялись при ребуте), в конце-концов знать, что в var можно почистить, когда отведенное место заканчивается, а что лучше не трогать — это уже, имхо, на любителя.
А если использовать VDS через какую-нибудь CPanel, то особо ничем от обычного хостинга и не отличается, по-моему.
И несете за это полную ответственность, прежде всего за безопасность, что на практике, в условиях ограниченного бюджета (профессионалам платить не хочется/не можется), означает еще и освоение професии *nix админа. Конечно, поднять локальный дев-сервер через консоль или по ssh редактировать файлы должен уметь любой веб-разработчик, но вот знать какие процессы на нем крутятся по дефолту, какие можно безболезненно отключить, а какие нет, уметь писать правила для iptable (и уметь делать так, чтобы они сохранялись при ребуте), в конце-концов знать, что в var можно почистить, когда отведенное место заканчивается, а что лучше не трогать — это уже, имхо, на любителя.
А если использовать VDS через какую-нибудь CPanel, то особо ничем от обычного хостинга и не отличается, по-моему.
Такая ситуация имеет место, но реально проблема не такая уж и серьёзная. Практически все VDS-хостинг имеют готовые наборы ПО, которые они сами [централизовано] поддерживают. Туда входят и Rails с MySQL. Сильно думать надо, только если у Вас какой-то особый набор ПО.
Согласен, но в контексте нашего треда VDS нужен все-таки именно для тонкой настройки под себя, и начиная «ковырятся» в консоли или конфигах (особенно с правами с правами рута) надо понимать, что после «rm -rf» в корне или еще где в лучшем случае бесплатно тебе восстановят вчерашний бакап системы, и то не сразу, как правило.
P.S. Хоть один человек на хабре принял мои доводы против VDS/DS всерьез и аргументированно ответил :) Респект!
P.S. Хоть один человек на хабре принял мои доводы против VDS/DS всерьез и аргументированно ответил :) Респект!
О мой бог! Присуждаю вашему комменту приз самого полезного (для меня) комментария на Хабрахабре. Я пытался использовать txruby, fxruby, wxruby, но мне они не нравились, прежде всего, своим не-Ruby-Way-подходом. Shoes — это, извините, невъебенно круто. Огромное спасибо за наводку, пойду смотреть Shoes дальше.
И простите за экспрессивность — очень уж понравился синтаксис Shoes. :)
И простите за экспрессивность — очень уж понравился синтаксис Shoes. :)
Шаред хостинг — только появляется(по крайней мере у нас). Как правильно сказали — проще использовать VDS/VPS, к томуже они дешевеют.
Насчет десктопа — обертки есть практически для всех оконных библиотек
RubyGTK, RubyQt, FoxRuby, Tk
Мне лично больше нравиться обертка WxWidgets — WxRuby.
Или тот же Shoes
Насчет десктопа — обертки есть практически для всех оконных библиотек
RubyGTK, RubyQt, FoxRuby, Tk
Мне лично больше нравиться обертка WxWidgets — WxRuby.
Или тот же Shoes
Ясно. Возможно это какие-то мои стереотипы… Но имхо эти «обертки» пока не дотягивают до удобства разработки GUI, что есть в том же VS. Серьезные приложения с большим количеством контролов имхо как-то проблематично. Есть ли какое-то удобное и эффективное решение в плане GUI?
Эдитор интерфейсов? Насколько я знаю — нет. Я еще когда на Java программировал десктопные приложения от этих эдиторов отучился. Чего и вам советую:)
Проблема оберток в том, что они тянут за собой сишный синтаксис. Ну в плане структуры самой библиотеки. С этой точки зрения, как уже говорили, хорошо посмотреть Shoes.
Проблема оберток в том, что они тянут за собой сишный синтаксис. Ну в плане структуры самой библиотеки. С этой точки зрения, как уже говорили, хорошо посмотреть Shoes.
Комменты не читал, выскажусь только по топику:
«Очередная академическая х*%ня» © — так бы сказал один известный автор и был бы прав.
Если уж хотите действительно протестировать, потрате время на придумывание задания, сделайте топик о таком тестировании и попросите пишуших на Perl/PHP/Python реализовать это задание (вы естественно Ruby возьмёте) с учётом актуальных сегодня технологий, подключите базу, может ещё какие-то актуальные операции (скажем файловые) и вот это протестируйте, jMeter'om желательно, с и без opcode кешеров (для питона это прекомпиляция Psycho насколько я знаю, про другие языки ничего не скажу, тёмный лес для меня).
Как условие — не берите фреймворки, всё от руки. Вот тогда это будет сравнение. Прогремите не только на хабре, но и по всем IT порталам в мире, потому что до сих пор никто так не делал, в лучшем случае брали Django, CakePHP, CodeIgniter и умудрялись забыть про opcode cache для PHP, когда для Python использовали Psycho (а потом вспомнили и оказалось, что code igniter способен выжать 600 запросов в секунду, т.е. был 2-м с офигенным отрывом от всего остального после Django с Psycho у которого вышло больше 1000 запросов в секунду — да быстро, но мне и PHP хватает. Покрайней мере я знаю где он слаб и знаю что могу всегда обратиться к Python )
«Очередная академическая х*%ня» © — так бы сказал один известный автор и был бы прав.
Если уж хотите действительно протестировать, потрате время на придумывание задания, сделайте топик о таком тестировании и попросите пишуших на Perl/PHP/Python реализовать это задание (вы естественно Ruby возьмёте) с учётом актуальных сегодня технологий, подключите базу, может ещё какие-то актуальные операции (скажем файловые) и вот это протестируйте, jMeter'om желательно, с и без opcode кешеров (для питона это прекомпиляция Psycho насколько я знаю, про другие языки ничего не скажу, тёмный лес для меня).
Как условие — не берите фреймворки, всё от руки. Вот тогда это будет сравнение. Прогремите не только на хабре, но и по всем IT порталам в мире, потому что до сих пор никто так не делал, в лучшем случае брали Django, CakePHP, CodeIgniter и умудрялись забыть про opcode cache для PHP, когда для Python использовали Psycho (а потом вспомнили и оказалось, что code igniter способен выжать 600 запросов в секунду, т.е. был 2-м с офигенным отрывом от всего остального после Django с Psycho у которого вышло больше 1000 запросов в секунду — да быстро, но мне и PHP хватает. Покрайней мере я знаю где он слаб и знаю что могу всегда обратиться к Python )
Не такая задача ставилась, как вы описали.
Все-таки почитайте коменты:)
Все-таки почитайте коменты:)
Да просто надоело читать эту хрень, как ни напишешь в гугле — таких результатов сотни — хоть бы один нормальный обзор.
Я вот как-то по юности устроил тест выводу на экран с помощью разных методов — с '' и "" — потратил пол дня на разные варианты и доведения до совершенства, в итоге всем было интересно обсудить результаты, а не пофлудить в теме.
Я вот как-то по юности устроил тест выводу на экран с помощью разных методов — с '' и "" — потратил пол дня на разные варианты и доведения до совершенства, в итоге всем было интересно обсудить результаты, а не пофлудить в теме.
Это по поводу хрени: iv_s.habrahabr.ru/blog/48952/#comment_1272787 И апдейт к статье тоже прочитайте.
И вообще, прежде чем заявлять флуд в коментариях или нет, сначало нужно их прочитать.
И вообще, прежде чем заявлять флуд в коментариях или нет, сначало нужно их прочитать.
Я высказал отношение к топику, а не к коментам. Из-за топика комменты мне не интересны. Половина спорит о том, насколько тест реален, остальные холиварят о том, какой язык лучше. За долгое время чтения хабра уже предугадываешь что пишут в комментах с 80% вероятностью. Здесь мало непредвзятого народа, очень мало.
>Я высказал отношение к топику, а не к коментам
По вашим коментам, похоже что вы его неправильно поняли. Хотя возможно я не достаточно понятно его написал.
>За долгое время чтения хабра уже предугадываешь что пишут в комментах с 80% вероятностью.
Завидую, тоже хочу обладать телепатией:)
Ну а вообще, у нас с вами сейчас как раз флуд не по теме и получается. Предлагаю закончить:)
По вашим коментам, похоже что вы его неправильно поняли. Хотя возможно я не достаточно понятно его написал.
>За долгое время чтения хабра уже предугадываешь что пишут в комментах с 80% вероятностью.
Завидую, тоже хочу обладать телепатией:)
Ну а вообще, у нас с вами сейчас как раз флуд не по теме и получается. Предлагаю закончить:)
Кстати, да.
У меня возникла подобная мысль… я хотел бы написать код на perl'е по работе со сложными структурами данных (ссылки, многоуровневые хэши и массивы, копирование структур) и предложить харбаюзерам перевести его на Ruby и Python и сделать бенчмарк. Если кто пожелает присоединиться (в ближайшие пару дней напишу в блоге) — велкам.
Кроме того, у меня есть несколько вопросов по платформе RoR — их я тоже опубликую чуть позже — надеюсь на ответы.
У меня возникла подобная мысль… я хотел бы написать код на perl'е по работе со сложными структурами данных (ссылки, многоуровневые хэши и массивы, копирование структур) и предложить харбаюзерам перевести его на Ruby и Python и сделать бенчмарк. Если кто пожелает присоединиться (в ближайшие пару дней напишу в блоге) — велкам.
Кроме того, у меня есть несколько вопросов по платформе RoR — их я тоже опубликую чуть позже — надеюсь на ответы.
Спасибо, интересные факты. Очень интересно сравнить их с языками компилируемыми, просто для того, чтобы иметь представление о масштабах, если Вас это не слишком затруднит. (Думаю о чистом Си)
В начале указанна ссылка на статью: habrahabr.ru/blogs/ruby/48928/
Посмотрите там результат выполнения factorfast. По скорости — практически идентично чистому С. За минусом времени, нужного для старта интерпретатора.
Посмотрите там результат выполнения factorfast. По скорости — практически идентично чистому С. За минусом времени, нужного для старта интерпретатора.
Всетаки сравнил с С:)
Я вам немного соврал, скорость запуска будет сильно отличаться у Ruby например
А вот скорость выполнения С вставок в Ruby с помощью RubyInline практически такая же:
Я вам немного соврал, скорость запуска будет сильно отличаться у Ruby например
$ time ruby factorfast.rb real 0m0.120s user 0m0.120s sys 0m0.000s $ time ./factor real 0m0.023s user 0m0.016s sys 0m0.000s
А вот скорость выполнения С вставок в Ruby с помощью RubyInline практически такая же:
puts Benchmark.realtime {1000.times { f.factorization 999999, false }} #измененный кусок кода, замер времени выполнения
ruby factorfast.rb
0.0170009136199951
С код тут можно посмотреть: pastie.org/359182в этой конкретной задачи должен рулить Хаскель — у меня он весьма лихо считал факториалы, итоговые цифры которых выводился на экран по 15 минут ;)
Не чесно:) Он функиональный, да еще и компилируемый!:)
Кстати, как он по впечатлениям? А то я решил приобщиться к функциональному миру, но для начала выбрал Erlang.
Кстати, как он по впечатлениям? А то я решил приобщиться к функциональному миру, но для начала выбрал Erlang.
дальше факториала дело не пошло, потому что тоже выбрал эрланг ;)
Я Haskell смотрел исключительно из интереса, на академических задачах, то есть много на нём не работал. Но мне он очень понравился и заинтересовал. Мозг сломать легко, но восхищение от, скажем, quicksort'а в две строчки ни с чем не сравнимо. ;)
Erlang я, впрочем, не видел, сравнить не смогу.
Erlang я, впрочем, не видел, сравнить не смогу.
Ну после императивных языков, функциональным очень легко мозк сломать:)
Кстати, Erlang меня тем же квиксортом поразил, можно посмотреть на википедии:
en.wikipedia.org/wiki/Erlang_(programming_language)
Но у него что больше интересно, так это концепция конкуррентно ориентированного программирования. Лично для меня это стало решающим фактором в решении изучить именно Erlang:)
Кстати, Erlang меня тем же квиксортом поразил, можно посмотреть на википедии:
en.wikipedia.org/wiki/Erlang_(programming_language)
Но у него что больше интересно, так это концепция конкуррентно ориентированного программирования. Лично для меня это стало решающим фактором в решении изучить именно Erlang:)
Очень интересно! Спасибо за наводку.
Если заинтересовались, советую эту книжку:
www.flazx.com/ebook8174.php
Только в первых 5-6 главах про основную фичу — конкурентность — ни слова:) Там описание самого языка(читать «введение в функциональное программирование»:))
Самое интересное нчинается с середины:)
Возможно потом напишу что нибудь про Erlang.
www.flazx.com/ebook8174.php
Только в первых 5-6 главах про основную фичу — конкурентность — ни слова:) Там описание самого языка(читать «введение в функциональное программирование»:))
Самое интересное нчинается с середины:)
Возможно потом напишу что нибудь про Erlang.
Расскажу о своих впечатлениях.
Алгоритмы, не требующие IO (вывод на экран, запись или чтение из файла) или не требующие явной императивности (например, присваивания) пишутся замечательно, и работают тоже неплохо.
Когда нужно, чтобы «внутри» функции были присваивания (из соображений скорости или еще каких), но при этом функция оставалась чистой снаружи, немного жутковато писать (ST монаду в помощь, но таки легче при помощи уникальных типов из Clean — вот этого в Хаскеле нет и не будет).
А, и еще: IO Хаскеля в стандартной библиотеке ужасно медленное (вот из-за этого большинство народу считает, что Хаскель тормозит). Есть библиотеки ByteString и Binary, которые работают быстро, а иногда медленно (связано со space leaks). Альтернативные подходы вроде iteratee-based IO, lightweight monadic regions и functional reactivity еще не доросли до повседневного использования, но они весьма многообещающие.
Алгоритмы, не требующие IO (вывод на экран, запись или чтение из файла) или не требующие явной императивности (например, присваивания) пишутся замечательно, и работают тоже неплохо.
Когда нужно, чтобы «внутри» функции были присваивания (из соображений скорости или еще каких), но при этом функция оставалась чистой снаружи, немного жутковато писать (ST монаду в помощь, но таки легче при помощи уникальных типов из Clean — вот этого в Хаскеле нет и не будет).
А, и еще: IO Хаскеля в стандартной библиотеке ужасно медленное (вот из-за этого большинство народу считает, что Хаскель тормозит). Есть библиотеки ByteString и Binary, которые работают быстро, а иногда медленно (связано со space leaks). Альтернативные подходы вроде iteratee-based IO, lightweight monadic regions и functional reactivity еще не доросли до повседневного использования, но они весьма многообещающие.
Никогда не сталкивался с какими-либо серьезными мат вычислениями в своей работе (php). Интерпритируемые языки вообще для этого никак не предназначены. Все тормоза языка можно легко дотянуть установкой более мощного железа. Это вообще глупые тесты, которые ни к чему не приведут. Куда важней для веба правильно работать с базой и иметь красивый, читаемый код. У меня на работе так однажды выбирали шаблонизатор… посмотрели, кто быстрей работает и выбрали Blitz. В итоге сейчас будет много времени переход на смарти просто потому, что у Blitz не такой большой функционал. Так это я к чему:
В вебе, где нет никакой нужды в сложной мат логике, где язык является тоненькой прослойкой между БД и браузером пользователя победит тот язык, который даст минимальную стоимость поддержки и максимальное удобство для разработки. Тут мы уже можем видеть, как самый быстрый PHP сильно отстает от всех остальных языков. Скорость работы языка — не критерий в вебе!!!
В вебе, где нет никакой нужды в сложной мат логике, где язык является тоненькой прослойкой между БД и браузером пользователя победит тот язык, который даст минимальную стоимость поддержки и максимальное удобство для разработки. Тут мы уже можем видеть, как самый быстрый PHP сильно отстает от всех остальных языков. Скорость работы языка — не критерий в вебе!!!
Знаете ли Вы, что Ruby можно использовать не только для веба? И в этом топике нет ни слова о вебе… Причём здесь вообще вэб?
Да что же сразу Ruby. Любой их этих языков можно использовать не только для веба. Только вот есть ли в этом какой-либо смысл?! Если вы хотите хорошо работать с математикой, то интерпритируемые языки вам вообще не подходят. Тут только C/C++. Для математики необходима грамотная работа с памятью, а это есть только в C/C++.
Ну а веб при том, что больше 90 процентов проектов, написанных на этих языках (а если убрать питон, то еще больше) веб.
Ну а веб при том, что больше 90 процентов проектов, написанных на этих языках (а если убрать питон, то еще больше) веб.
Вы похожи на ребенка, который не знает, откуда берутся дети. Если вы работаете там, где нужно инструменты только использовать, то вы считаете, что оно все берется само по себе.
Или вот как больщинство людей считают, что линукс нинафига никому не нужен, потому что они сами его никогда не видели, и аргументируют неприязнь к линуксу «90% компов стоят с виндой...»
Или вот как больщинство людей считают, что линукс нинафига никому не нужен, потому что они сами его никогда не видели, и аргументируют неприязнь к линуксу «90% компов стоят с виндой...»
Есть смысл. Я пробовал писать гуевые приложения на ruby+qt, ruby+qtk, jruby+swing. Полет отличный. Если нужна будет производительность я себе модуль напишу на сях и все. Да и грамотная работа с памятью не всегда нужна (помню делал 7 лабораторных по численным методам и 5 по методам оптимизации + пара курсачей ни в одной работа с памятью не понадобилась).
>ruby+qt, ruby+qtk, jruby+swing
Попробуйте обертку к WxWidgets — WxRuby. Мне приятнее всех показалась.
Попробуйте обертку к WxWidgets — WxRuby. Мне приятнее всех показалась.
Рекомендую также Shoes :)
>для математики необходима грамотная работа с памятью
Не понял смысла утверждения. У C/C++ работа с памятью вообще никакая, все ложиться на программиста. В том же Ruby уже есть сборщик мусора(впрочем как и у Java, C#, Python и т.д.).
Не понял смысла утверждения. У C/C++ работа с памятью вообще никакая, все ложиться на программиста. В том же Ruby уже есть сборщик мусора(впрочем как и у Java, C#, Python и т.д.).
1. Используйте умные указатели
2. К С++ можно прикрутить сборщик мусора. А смысл? Первый пункт предпочтительней.
2. К С++ можно прикрутить сборщик мусора. А смысл? Первый пункт предпочтительней.
Ну это для C++. Для С то не пройдет.
Конечно не спорю, что от программиста зависит, но мне кажеться что GC все-таки надежнее.
Конечно не спорю, что от программиста зависит, но мне кажеться что GC все-таки надежнее.
Не хочу разводить холивара, но ни одного идеального и полностью надёжного GC я не видел. А так как я предпочту расплачиваться за свои ошибки, чем за ошибки GC, то и нравится мне больше ручное управление памятью, особенно, если его можно автоматизировать как вам угодно.
По поводу С — опыт разработки на С++ у меня гораздо больше, чем на С, поэтому мне свойственно иногда забываться. Так что здесь вы правы — в С ситуация с памятью намного хуже, чем в С++. Но ведь и С стоит выбирать только для определенного класса задач.
По поводу С — опыт разработки на С++ у меня гораздо больше, чем на С, поэтому мне свойственно иногда забываться. Так что здесь вы правы — в С ситуация с памятью намного хуже, чем в С++. Но ведь и С стоит выбирать только для определенного класса задач.
э, сами говорите «даст максимальное удобство разработки», а тут же «хотите хорошо работать с математикой… только C/C++»… может всё же удобнее работать с тем же Fortran'ом ^)
UFO just landed and posted this here
Для математики достаточно numpy/scipy скорость сишная, легкость змеиная
>Все тормоза языка можно легко дотянуть установкой более мощного железа
Креативный способ оптимизации кода:)
Креативный способ оптимизации кода:)
В целом согласен.
Хотя так и проситься какой-нибудь контр пример, типо сложной функции(математической!) расчета рейтинга.:)
Но опять же процитирую сама себя в пятый раз: habrahabr.ru/blogs/ruby/48952/#comment_1272787
И еще раз выводы в апдейте прочитайте.
Хотя так и проситься какой-нибудь контр пример, типо сложной функции(математической!) расчета рейтинга.:)
Но опять же процитирую сама себя в пятый раз: habrahabr.ru/blogs/ruby/48952/#comment_1272787
И еще раз выводы в апдейте прочитайте.
Про Руби 1.9 неожиданно, да.
>> ожидал что настолько хорошо получиться.
Проверочное слово — что сделает?
>> ожидал что настолько хорошо получиться.
Проверочное слово — что сделает?
в питоновском тесте должен быть не range, а xrange
Похоже все забыли про такой известный проект сравнения производительности языков:
shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=php&lang2=yarv
shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=php&lang2=yarv
Тяжело такие данные воспринимать ;)
а эту синюю тонкую хрень легко вспринимать по-твоему, да? )
Хм, чесно говоря не понял что заначит шкала справа и синяя полоска.
Объясните пожалуйста:) И тогда я в топик добавлю, с вашего разрешения конечно.
Объясните пожалуйста:) И тогда я в топик добавлю, с вашего разрешения конечно.
Рекомендация автору добавить в бенчмарк Groovy. Одного поля ягода с Ruby и Python.
А где же Python 3000, PHP 5.2.3? Если сравнивать бету языка, то с бетами.
Прочитайте пост, контекст и комментарии. И вам всё станет понятно.
Тут 114 комментариев, «читать комментарии» — проблематично. Впрочем, автор поста мне уже объяснил причины и по прежнему считаю сравнение некорректным.
Автору виднее, конечно ;), но немаловажной причиной выбора Ruby 1.9 и игнорировании бет остальных языков, как мне кажется, явилось желание посмотреть именно на прогресс Руби в производиельности, за которую его часто критикуют.
>желание посмотреть именно на прогресс Руби в производиельности
Эта цель также преследовалась, как и написанно в выводах в апдейте.
И опять же повторюсь, Ruby 1.9 это не бета, это эксперементальная ветка. Которая используется наравне с 1.8.
Не сллучайно ведь она есть в репозитариях.
Эта цель также преследовалась, как и написанно в выводах в апдейте.
И опять же повторюсь, Ruby 1.9 это не бета, это эксперементальная ветка. Которая используется наравне с 1.8.
Не сллучайно ведь она есть в репозитариях.
Я в топике специально написал, что все ставилось только из оф. репозитария.
>Python 3000, PHP 5.2.3
Этого там не было. И Ruby 1.9 это не бета, это эксперементальная ветка, в отличае от стабильной 1.8.
>Python 3000, PHP 5.2.3
Этого там не было. И Ruby 1.9 это не бета, это эксперементальная ветка, в отличае от стабильной 1.8.
PHP — золотая середина! респектный тест! :)
Вот мне давно интересно.
А в чем заключается большая и главная разница между Ruby и Python? Отчего вообще понадобился и появился первый?
А в чем заключается большая и главная разница между Ruby и Python? Отчего вообще понадобился и появился первый?
//не ради холивара с фанатами Python'a
Ruby — это полностью объектный язык. В нем нет процедурных наследий как в Python.
Python:
Ruby:
Потом Ruby все-таки «слаще», синтаксического сахара в нем больше, один
Но я сильно Python'ом не увлекался. Возможно, если есть перешедшин с Python'a на Ruby, они больше различий покажут.
Ruby — это полностью объектный язык. В нем нет процедурных наследий как в Python.
Python:
len("asdf") — вызов функции с параметром объект класса строка.Ruby:
"asdf".length — вызов метода у объекта класса строка(или отправка сообщения)Потом Ruby все-таки «слаще», синтаксического сахара в нем больше, один
10.times {puts "hi"} чего стоит:)Но я сильно Python'ом не увлекался. Возможно, если есть перешедшин с Python'a на Ruby, они больше различий покажут.
Итак, отличия Раби:
1) Более строгая объектная парадигма;
2) Больше упор на встроенные в язык фишки; меньше — на стандартную библиотеку.
Вопрос вкуса.
Мне скорее интересно, зачем понадобился Раби
1) Более строгая объектная парадигма;
2) Больше упор на встроенные в язык фишки; меньше — на стандартную библиотеку.
Вопрос вкуса.
Мне скорее интересно, зачем понадобился Раби
Он Руби а не Раби:)
>2) Больше упор на встроенные в язык фишки; меньше — на стандартную библиотеку.
Неправельно. Синтаксический сахар — да, на него есть упор. Но это никак не связанно с библиотекой.
Почитайте теже капли(курс статей на хабре был), например работа с массивами.
>2) Больше упор на встроенные в язык фишки; меньше — на стандартную библиотеку.
Неправельно. Синтаксический сахар — да, на него есть упор. Но это никак не связанно с библиотекой.
Почитайте теже капли(курс статей на хабре был), например работа с массивами.
автор руби хотел чтобы язык был как перл (что отражено в названии), но только гораздо лучше и более ОО чем питон.
а вообще вопрос «зачем понадобился» некорректен. на данный момент существует болеее 8000 языков, но реально используются от силы 50. так что есть в нем потребность значит.
а ажиотаж вокруг руби появился из-за РоР. на хабре по крайней мере исключительно из-за этого обсуждают руби.
а вообще вопрос «зачем понадобился» некорректен. на данный момент существует болеее 8000 языков, но реально используются от силы 50. так что есть в нем потребность значит.
а ажиотаж вокруг руби появился из-за РоР. на хабре по крайней мере исключительно из-за этого обсуждают руби.
на сайте разработчиков уже доступна ruby-1.9.1-rc1
Интересно было бы и его включить в тест, потому как на стандартном banchmark.rb, входящем в библиотеку Ruby, 1.9.0 проигрывает 1.8.7
Интересно было бы и его включить в тест, потому как на стандартном banchmark.rb, входящем в библиотеку Ruby, 1.9.0 проигрывает 1.8.7
И ещё реальное гониво: dumpz.org/4762/
А какая версия питона? У меня отставание руби значительно меньше.
$ time ruby1.9 t.rb
real 0m0.336s
user 0m0.324s
sys 0m0.000s
$ time python t.py
real 0m0.214s
user 0m0.212s
sys 0m0.004s
а 1.8 в полтора раза медленнее чем у вас
$ time ruby1.9 t.rb
real 0m0.336s
user 0m0.324s
sys 0m0.000s
$ time python t.py
real 0m0.214s
user 0m0.212s
sys 0m0.004s
а 1.8 в полтора раза медленнее чем у вас
Т.е. всё выполняется порядка полсекунды? Автор, твой тест показывает погоду в унитазе.
Хотя бы потому, что при таком времени сильно влияет время запуска рантайма. А на это, в свою очередь, сильно влияет файловый кэш, расположение файлов на диске и т.п. Оказался у тебя Ruby 1.9 в кэше — и всё, «выигрыш».
Не знаю, вполне возможно Ruby 1.9 вновь окажется впереди, если время работы теста увеличить (ну хотя бы до 10 сек! А лучше до минуты). Но этим цифрам доверять нельзя.
Хотя бы потому, что при таком времени сильно влияет время запуска рантайма. А на это, в свою очередь, сильно влияет файловый кэш, расположение файлов на диске и т.п. Оказался у тебя Ruby 1.9 в кэше — и всё, «выигрыш».
Не знаю, вполне возможно Ruby 1.9 вновь окажется впереди, если время работы теста увеличить (ну хотя бы до 10 сек! А лучше до минуты). Но этим цифрам доверять нельзя.
Именно поэтому я прогонял тесты по нескольку раз, и выбирал средние значения.
В доказательство — результаты для Ruby1.9 и Python на сто тысячь итераций:
$ time ruby1.9 factor.rb
real 0m27.477s
user 0m25.542s
sys 0m0.164s
$ time python factor.py
real 0m51.926s
user 0m50.791s
sys 0m0.164s
Т.е. пропорции те же что и в топике.
В доказательство — результаты для Ruby1.9 и Python на сто тысячь итераций:
$ time ruby1.9 factor.rb
real 0m27.477s
user 0m25.542s
sys 0m0.164s
$ time python factor.py
real 0m51.926s
user 0m50.791s
sys 0m0.164s
Т.е. пропорции те же что и в топике.
Хотел написать об этом же… корректнее наверно замерять время внутренних участков кода, а не запуска скрипта с рантаймом.
Ну при относительно большом промежутке времени разницы практически не будет. Да к томуже старт интерпретатора с парсингом файла — пара десятков миллисекунд, что большой роль не играет.
А это от задачи зависит — запуск какого-нибудь демона или интерактивной проги — эт одно, а вот запуск на веб-сервере в ответ на каждый запрос…
UFO just landed and posted this here
За 1.8 конечно обидно, но результат был ожидаемым:)
Насчет теста. Вот такой JRuby(самый последний с их сайта, в репах старый 1.0):
Немного изменил код, замеряю Benchmark.realtime, а не time, т.к. Java долго стартует:
И сами результаты:
Как видно из теста, ruby1.9 подает большие надежды чем JRuby:)
Хотя возможно это только на данной задаче, и из-за синтетического теста.
В топик добавлять не буду, т.к тест немного изменен, и тогда еще Groovy'цы будут требовать тестов:)
Насчет теста. Вот такой JRuby(самый последний с их сайта, в репах старый 1.0):
$ java -version java version "1.6.0_07" Java(TM) SE Runtime Environment (build 1.6.0_07-b06) Java HotSpot(TM) Client VM (build 10.0-b23, mixed mode, sharing) $ jruby -v jruby 1.1.6 (ruby 1.8.6 patchlevel 114) (2008-12-17 rev 8388) [i386-java]
Немного изменил код, замеряю Benchmark.realtime, а не time, т.к. Java долго стартует:
puts Benchmark.realtime { 1000.times { f.factorization 999999} }И сами результаты:
$ ruby factor.rb 1.06909513473511 $ ruby1.9 factor.rb 0.328825235366821 $ jruby factor.rb 0.6868088245391846
Как видно из теста, ruby1.9 подает большие надежды чем JRuby:)
Хотя возможно это только на данной задаче, и из-за синтетического теста.
В топик добавлять не буду, т.к тест немного изменен, и тогда еще Groovy'цы будут требовать тестов:)
Рассматривать языки отдельно от области их применения — бессмысленно.
Perl можно уже не вспоминать, кроме бородатых сисадминов его уже никто не использует. Python 3 не оправдал ожиданий и с потерей обратной совместимости будет уже не так хорош в плане поддержки библиотек.
JRuby, MacRuby, IronRuby — делают Ruby на данный момент самым привлекательным скриптовым языком. Конечно Perl, Python никуда не уйдут — скорее останутся как наследие.
PHP абсолютный лидер в Web:
* в версии 5.3 будут closures & namespaces
* Zend активно продвигает свой Framework
* готовые продукты(Bitrix, Drupal, MediaWiki, phpBB)
* самая большая база фрилансеров
* дешёвый хостинг
Ruby может конкурировать и здесь, особенно учитывая, что типовые решения превращаются в SaaS или остаются в прошлом.
JavaScript — тёмная лошадка, которая может насолить всем вышеперечисленным языкам, вытестив их из браузера далеко на сервер. Но MS тормозит с Canvas/SVG да и Flex должен вскоре начать поддерживать другие языки, отличные от AS, тот же Ruby. Silverlight уже поддерживает.
Так что в качестве скриптового языка я бы сделал ставку именно на Ruby.
Perl можно уже не вспоминать, кроме бородатых сисадминов его уже никто не использует. Python 3 не оправдал ожиданий и с потерей обратной совместимости будет уже не так хорош в плане поддержки библиотек.
JRuby, MacRuby, IronRuby — делают Ruby на данный момент самым привлекательным скриптовым языком. Конечно Perl, Python никуда не уйдут — скорее останутся как наследие.
PHP абсолютный лидер в Web:
* в версии 5.3 будут closures & namespaces
* Zend активно продвигает свой Framework
* готовые продукты(Bitrix, Drupal, MediaWiki, phpBB)
* самая большая база фрилансеров
* дешёвый хостинг
Ruby может конкурировать и здесь, особенно учитывая, что типовые решения превращаются в SaaS или остаются в прошлом.
JavaScript — тёмная лошадка, которая может насолить всем вышеперечисленным языкам, вытестив их из браузера далеко на сервер. Но MS тормозит с Canvas/SVG да и Flex должен вскоре начать поддерживать другие языки, отличные от AS, тот же Ruby. Silverlight уже поддерживает.
Так что в качестве скриптового языка я бы сделал ставку именно на Ruby.
С PHP понятно, это всемирный заговор:)
Я все таки надеюсь, что Ruby в Web будет успешно с ним конкурировать.
>JavaScript — тёмная лошадка, которая может насолить всем вышеперечисленным языкам, вытестив их из браузера далеко на сервер.
И не только вытеснить далеко на сервер, но и самому придти к серверам как например Jaxer и аналогичные проекты, или самоделки на Rhino/SpiderMonkey/V8.
Кстати, насчет темной лошадки — сдается мне что Erlang отхватит свою долю в серверных решениях. Но естественно уровня повыше чем задачи для Ruby/PHP.
Но это уже немного из другой оперы.
Я все таки надеюсь, что Ruby в Web будет успешно с ним конкурировать.
>JavaScript — тёмная лошадка, которая может насолить всем вышеперечисленным языкам, вытестив их из браузера далеко на сервер.
И не только вытеснить далеко на сервер, но и самому придти к серверам как например Jaxer и аналогичные проекты, или самоделки на Rhino/SpiderMonkey/V8.
Кстати, насчет темной лошадки — сдается мне что Erlang отхватит свою долю в серверных решениях. Но естественно уровня повыше чем задачи для Ruby/PHP.
Но это уже немного из другой оперы.
В виде ECMAScript 4 JS может быть и мог претендовать на сервер, но с тех пор как спеку свернули — вряд ли.
Erlang — по опыту, большинство людей, прогнозирующих его рост имеют мало опыта в задачах, которые он решает, либо не имеют его вообще. Тот же Twitter прекрасно обходиться с помощью Scala.
Erlang — по опыту, большинство людей, прогнозирующих его рост имеют мало опыта в задачах, которые он решает, либо не имеют его вообще. Тот же Twitter прекрасно обходиться с помощью Scala.
Хм, Erlang — не для всего, это больше узкоспециализированное средство для построения высоконагруженных и отказоустойчивых серверов. Чего только их платформа OTP стоит, с мониторингом процессов и сменой кода без остановки системы. Вот как раз в таких задачах он, я думаю, и проявит себя.
Уже появились успешные проекты ejabberd, Yaws, CouchDB. Возможно скоро Erlang и в вебдев придет.
Но опять же, не странички генерировать.
А про Twitter и Scala можно по подробнее? Для чего она там используется?
Уже появились успешные проекты ejabberd, Yaws, CouchDB. Возможно скоро Erlang и в вебдев придет.
Но опять же, не странички генерировать.
А про Twitter и Scala можно по подробнее? Для чего она там используется?
Для построения «высоконагруженных и отказоустойчивых серверов» нужны в первую очередь навыки, а уж в последнюю — технологии, ведь как-то и до сего дня их без Erlang строили, не так ли? Yaws & CouchDB это конечно круто, но кто их использует?
www.gracelessfailures.com/ — блог разработчиков Twitter для чего используется не знаю. В инкубаторе Apache есть проект ESME — это OpenSource реализация Twitter от SAP, которую вроде бы используем Siemens.
www.gracelessfailures.com/ — блог разработчиков Twitter для чего используется не знаю. В инкубаторе Apache есть проект ESME — это OpenSource реализация Twitter от SAP, которую вроде бы используем Siemens.
Я тоже наблюдаю потихоньку за Erlang. Вот например есть такой клон Rails на Erlang: nitrogenproject.com/ Еще есть фреймворк Erlyweb.
Вроде бы ребята идут в нужном направлении, но все равно все упирается в язык и его страшноватый, на мой взгляд, синтаксис.
Вроде бы ребята идут в нужном направлении, но все равно все упирается в язык и его страшноватый, на мой взгляд, синтаксис.
Erlang, Scala, F#, Nemerle — последние года 3 точно на слуху; не говоря уже о LISP & Haskell, которые с нами полвека. Да вот никто на них не спешит переходить, хотя идеи и подходы некоторые перенимают.
Я вот ввёл сейчас все эти языки на американском Job-сайте с 55 тысячами IT-ваксний, выбрав «match any» — набролось всего 36. Из них реальной работы с ФП — пальцев одной руки пересчитать хватит.
ФП безусловно имеет много интересных приёмов и стоит изучения, но я сомневаюсь, что оно станет хоть сколько либо популярным, даже в виде гибридов Scala/F#, которые поддерживают оба(ООП&ФП) подхода.
Я вот ввёл сейчас все эти языки на американском Job-сайте с 55 тысячами IT-ваксний, выбрав «match any» — набролось всего 36. Из них реальной работы с ФП — пальцев одной руки пересчитать хватит.
ФП безусловно имеет много интересных приёмов и стоит изучения, но я сомневаюсь, что оно станет хоть сколько либо популярным, даже в виде гибридов Scala/F#, которые поддерживают оба(ООП&ФП) подхода.
> Python 3 не оправдал ожиданий
Чьих это он ожиданий не оправдал? По-моему вполне себе оправдал.
Чьих это он ожиданий не оправдал? По-моему вполне себе оправдал.
… васюки переименовываются в нью-васюки, а москва в старые васюки, ага.
А нет ли такого теста?
— Пишется спека веб-приложения (гастивуха какая-нибудь).
— Сторонники каждого из языков пишут свою реализацию (можно и не одну).
— Всё это добро гоняется на сервере под разными нагрузками.
По-мне так это самое интересное. Не?
— Пишется спека веб-приложения (гастивуха какая-нибудь).
— Сторонники каждого из языков пишут свою реализацию (можно и не одну).
— Всё это добро гоняется на сервере под разными нагрузками.
По-мне так это самое интересное. Не?
>По-мне так это самое интересное.
Ага, иак конечно интереснее. И уже были похожие предложения:
habrahabr.ru/blogs/ruby/48952/#comment_1274249
Ага, иак конечно интереснее. И уже были похожие предложения:
habrahabr.ru/blogs/ruby/48952/#comment_1274249
Эти тесты очень субъективные. Ведь кроме производительности есть ещё куча факторов, куда более важных порой.
Позвольте, что же субъективного в производительности платформы? Придумайте другое «реальное приложение» если это не нравится.
Если под кучей факторов вы подразумеваете скорость разработки, то можно помер[яи]ть их отдельно. К производительости интерпретаторов и т. п. это отношения не имеет.
Короче, моё предложение имеет хоть какое-то отношение к реальности.
Если под кучей факторов вы подразумеваете скорость разработки, то можно помер[яи]ть их отдельно. К производительости интерпретаторов и т. п. это отношения не имеет.
Короче, моё предложение имеет хоть какое-то отношение к реальности.
а в питоне специально супер медленный while использовался и другие замедляющие работу конструкции?
Прошу обратить внимание всех, что Python код в данном примере не просто не оптимизирвоан, но специально замедлен.
А вообще, оптимизировать можно всё и долго, а потом еще и на С++ переписать.
Я на такие веселья смотрю так: чем бы дитя не тешилось, лишь бы работать мне не мешало, бегая перед моим рабочим местом с криками «Ruby — rulezzz, Python — говно».
Прошу обратить внимание всех, что Python код в данном примере не просто не оптимизирвоан, но специально замедлен.
А вообще, оптимизировать можно всё и долго, а потом еще и на С++ переписать.
Я на такие веселья смотрю так: чем бы дитя не тешилось, лишь бы работать мне не мешало, бегая перед моим рабочим местом с криками «Ruby — rulezzz, Python — говно».
Присоединюсь ко всем что способ тестирования неправильный. Особенности языков надо обязательно учитывать.
Программа на Perl должна выглядеть как минимум вот так:
работает на 40% быстрее, только в стиле Perl-way
Программа на Perl должна выглядеть как минимум вот так:
работает на 40% быстрее, только в стиле Perl-way
http://pastie.org/543879
хабрахабр ссылку съел
Смысл тестировать php без APC, а ruby 1.9 — с jit?
Sign up to leave a comment.
Ruby && Python && Perl && PHP && Ruby1.9