Ruby && Python && Perl && PHP && Ruby1.9

    В коментариях к моей статье были высказанны просьбы протестировать производительность приведенного там примера на других языках. Что я и пытался сделать.
    Как видно из заголовка, в тесте участвовали практически все популярные сегодня динамические языки, а также новая версия Ruby.
    Давайте взглянем на результаты.

    Пару слов о тесте. Для тестирования была использованна функция факторизации числа. Алгоритм самый примитивный — перебор делителей. В каждом языке был создан класс(кроме Perl'a) с одним методом.
    Затем он 1000 раз вызывался в цикле, с аргументом равным 999999.
    Система на которой производилось испытание — Debian Lenny. Все интерпретаоры установленны пакетами из официального репозитария. Процессор — Pentium D 2.8.
    В тесте также участвовал интерпретатор Ruby из эксперементальной ветки 1.9(так же поставленный из репозитария).
    Еще замечание, возможно некоторые скрипты я реализовал неоптимально, учитывая возможности языков. Я старался реализовать алгоритм идентично во всех языках. Если есть замечания и дополнения — пожалуйста в коментарии.
    Для теста был написан такой скрипт:
        #!/bin/bash
        uname -a #информация о системе
        cat /proc/cpuinfo | grep "model name" #информация о процессоре
        #сами тесты, с предворительным выводом версии интерпретатора
        ruby -v
        time ruby factor.rb
        ruby1.9 -v
        time ruby1.9 factor.rb
        php -v
        time php factor.php
        python -V
        time python factor.py
        perl -v
        time perl factor.pl
    

    Теперь посмотрим на результат выполнения этого скрипта:
        Linux debian 2.6.26-1-686 #1 SMP Mon Dec 15 18:15:07 UTC 2008 i686 GNU/Linux
        model name	: Intel(R) Pentium(R) D CPU 2.80GHz
        model name	: Intel(R) Pentium(R) D CPU 2.80GHz
        ruby 1.8.7 (2008-08-11 patchlevel 72) [i486-linux]
    
        real	0m1.099s
        user	0m1.076s
        sys	0m0.000s
        ruby 1.9.0 (2008-06-20 revision 17482) [i486-linux]
    
        real	0m0.287s
        user	0m0.252s
        sys	0m0.008s
        PHP 5.2.6-0.1~lenny1 with Suhosin-Patch 0.9.6.2 (cli) (built: Nov 29 2008 21:35:12) 
        Copyright (c) 1997-2008 The PHP Group
        Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
    
        real	0m0.348s
        user	0m0.324s
        sys	0m0.008s
        Python 2.5.2
    
        real	0m0.537s
        user	0m0.536s
        sys	0m0.000s
    
        This is perl, v5.10.0 built for i486-linux-gnu-thread-multi
    
        Copyright 1987-2007, Larry Wall
    
        Perl may be copied only under the terms of either the Artistic License or the
        GNU General Public License, which may be found in the Perl 5 source kit.
    
        Complete documentation for Perl, including FAQ lists, should be found on
        this system using "man perl" or "perldoc perl".  If you have access to the
        Internet, point your browser at http://www.perl.org/, the Perl Home Page.
    
    
        real	0m0.569s
        user	0m0.552s
        sys	0m0.004s
    


    Подведем итог. Python примерно соизмерим по скорости с Perl. Ruby 1.8 естественно проигрывает. PHP почти быстрее всех.
    И тут такая неожиданность, эксперементальная ветка Ruby 1.9 оказывается быстрее всех. Я не случайно включил в тестирование Ruby 1.9. При его разработке упор ставился на скорость. Но я, чесно говоря, очень удивлен, не ожидал что настолько хорошо получится.
    Так что поклонники Ruby, нам есть куда стремиться. Ждем Ruby 2.0!:)

    Скрипты использованные в тесте:
    factor.rb, factor.py, factor.pl, factor.php

    Upd: В коментариях разгорелся спор об объективности результатов. Да, я не спорю, тест синтетический, к тому же провести комплексный анализ производительности цели не было.
    Результатами можно считать следующее:
    1. Скорость выполнения на этих языках соизмерима(по крайней мере очень значительных скачков на этой задаче нет).
    2. Ruby(этот бенчмарк по мотивам статьи о Ruby) успешно развивается в плане производительности.
    Upd2: Хабраюзер deerua для наглядности сделал диаграму, на которой отображены результаты тестов:
    benchmark
    Upd3: Хабраюзер AlDev не остался в стороне, и сделал другую версию диаграмы:
    bencmark
    Поделиться публикацией
    Реклама помогает поддерживать и развивать наши сервисы

    Подробнее
    Реклама
    Комментарии 221
    • +5
      Неожиданный, но очень приятный результат :)
      • –2
        На питоне код красивше :)
    • 0
      а что Вы будете делать, если разработчики пхп в версии, скажем, 5.3 поставят упор на скорость? :)
      • +5
        Хм, ничего, так и останусь на Ruby:)
        Лично для меня синтаксический сахар(а следовательно более высокая скорость разработки) важнее чем скорость выполнения.
        • +1
          полностью поддерживаю.
          а если есть затыки то всегда можно переписать медленный код на си.
          • 0
            Вы оценили скорость работы интерпретированного приложения, в то время как на практике гораздо большее значение имеет скорость собственно интерпритации когда. Скорее всего, при таком испытании, победил бы питон за счёт компиляции в байт-код.
          • +7
            Ruby сравнивать c php грешно, каким бы быстрым не был php. Я не говорю, что php плохой, просто там нет дизайна.
            • +1
              Хоть я и php-программист, но позволю с вами согласиться. Отрадно, что ситуацию частично исправляют фреймфорки.
          • 0
            Кстати, в какой блог перенести? Или так и оставить в личном?
            • +4
              Перенесу все-таки в Ruby, т.к. он быстрее оказался:)
            • +1
              Расшифруйте, пожалуйста, что значит: real, user, sys в тестах.
              • +2
                real — общее время
                user — время затраченное в user mode
                sys — время затраченное в kernel mode
                Подробнее можете например тут почитать unixhelp.ed.ac.uk/CGI/man-cgi?time
            • +1
              PHP, значит, не просто живее всех живых, но еще и быстрее, спасибо за тест!
              Конечно, интересно бы посмотреть на работу с БД и мультимедиа, но это уже возможности модулей, а не языков, будет необъективно…
              • +3
                >БД и мультимедиа
                Да, это практически всегда С/C++, так что тут сравнивать смысла нет.
                • 0
                  Скорее всего, везде будет более-менее одинаково при условии использования одних и тех же нативных библиотек.
              • +2
                Странный тест. Взяли вообщем-то редко используемую задачу в этих языках программирования и на ее основе делаются выводы о скорости всего языка. Например, по вашим данным Python проигрывает PHP, но я специально сравнивал их скорости на конкретной небольшой, но комплексной задаче, результат, как вы понимаете, был абсолютно противоположный.
                • +2
                  Не буду спорить, вполне возможно.
                  Просто этот топик, это ответ на коментарий: habrahabr.ru/blogs/ruby/48928/#comment_1272091
                  • +1
                    Тогда мне непонятна эта фраза «Python примерно соизмерим по скорости с Perl. Ruby 1.8 естественно проигрывает. PHP почти быстрее всех...» без контекста естественно. Каков процент таких счетных задач на скриптовых языках программирования, чтобы о быстродействии вычислений факториала, можно было судить о быстродействии всего языка?
                    Просто откровенно раздражают такие необъективные выводы, только зря народ неопытный баламутите.
                    • 0
                      Прочитайте, пожалуйста первую строчку внимательней:)
                      «В коментариях к моей статье были высказанны просьбы протестировать производительность приведенного там примера на других языках. Что я и пытался сделать.»
                      В ней то как раз и устанавливается контекст.
                      • +5
                        Зачем вам пытаться понять фразу без контекста, когда она написана в контексте определённой задачи?
                  • +3
                    Есть же shootout.alioth.debian.org/
                    Там хоть и не последняя версия руби, но вы обратите внимание на количество бенчмарков.
                    Превосходство какого-либо языка в одном синтетическом тесте, говорит только о том, что этот язык быстрее других выполняет этот синтетический тест. Ни о каком сравнении языков не может быть и речи.
                  • +9
                    Тест был бы гораздо лучше, если бы еще сравнивалась память, занимаемая при выполнении скриптов.

                    + для таких штук в питоне есть psyco: пишем 2 строчки

                    import psyco
                    psyco.bind(Factor.factorization)

                    после объявления класса, и вуаля — у меня время real с 0.395 упало до 0.046, почти в 10 раз.
                    • 0
                      Ну естественно что с JIT быстрее будет:) Я для всех языков использовал просто стандартные интерпретаторы.
                      И опять же повторюсь iv_s.habrahabr.ru/blog/48952/#comment_1272787
                      • +2
                        так руби 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. А раз все интегрировано, то бороться с этим станет сложнее. Замеров не проводил, просто мысли по поводу.

                        • 0
                          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:)
                          • 0
                            в питоне да, что-то такое есть, но это не компиляция, а скорее препроцессор, просто сокращение текста программы

                            «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.»
                            • 0
                              Понятно, спасибо. А я сдуру искал как в этот самый .pyc скомпилировать:)
                            • 0
                              psyco к тому же еще и год уже как заброшена) но всем как-то по барабану, работает ведь)
                              А автор psyco занят веселой штукой — пишет интерпретатор питона на питоне, чтобы прикрутить к нему потом JIT и всем было счастье и все работало быстрее, чем питон, написанный на C.
                              С памятью глянул — да, в руби прогресс заметен по сравнению с тем, что было раньше.
                              • 0
                                Питон на питоне — оригинально:)
                                Меня больше интригует вот это проект www.parrot.org/
                                Я давно-давно смотрел, там совсем все глухо было.
                                Сейчас зашел — обещают релиз 1.0 в марте. Думаю посмотреть в ближайшее время.
                                • 0
                                  > Питон на питоне — оригинально:)
                                  Может для питона это и оригинально, но это обычная практика. Компиляторы не пишут на ассемблере, часто их пишут на предыдущих версиях этого же компилятора, а потом уже оптимизируют. Точно также как первый компилятор C++ писался с использованием C.
                                  • +2
                                    Не, идея кросс-компиллеров понятна. У них свои задачи.
                                    Я просто не очень представляю каким образом можно в данном случае прирост производительности получить, в сравнении с тем же Psycho.
                                    • 0
                                      Ну так ведь JIT. А разработка на питоне — чтобы в очередной раз доказать что это быстрее. Выглядит действительно «весело», эх, есть же у него времени на coding for fun.
                                      • 0
                                        Думаю там всеже не for fun а гранд какой нибудь:)
                                        • 0
                                          Там был гранд от Евросоюза
                                          • 0
                                            А размер какой случаем не знаете? Интересно сколько за инновации в программировании дают:)
                                            • 0
                                              АФАИР, грант был несколько миллионов евро на полтора года. Но он закончился ещё прошлой весной, тогда как раз выпустили версию 1.0.
                                              • 0
                                                Неплохо, совсем неплохо. Но скорей всего это не на человека, а на исследовательскую группу какого-нить университета.
                                                • 0
                                                  Да, это не на человека, а на всю толпу (десятка полтора людей, вроде бы, может и больше). Толпа вроде как не из одного университета — сборная солянка. Плюс, если я не ошибаюсь, все спринты тоже оплачивались из этих денег. А спринты у них ой какие весёлые были — в духе собраться в домике на горнолыжном курорте на недельку, кататься на лыжах/сноуборде и прогать. Правда, активность разработки во время таких спринтов просто поражает :)
                                      • 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»
                                        • +1
                                          Проекции Футамуры в действии?:)
                                          • 0
                                            и правда похоже)
                                • 0
                                  Psyco, во время выполнения программы собирает информацию о типах объектов, и затем эта информация используется для генерации высокоэффективного машинного кода, оптимизированного для объектов этого типа. После этого произведенный машинный код заменяет соответствующие участки байт-кода и тем самым увеличивает скорость выполнения программы. © Марк Лутц

                                  Конечно, если используются С++ вставки, то они не будут оптимизированы с помощью Psyco.
                                  Поэтому, думаю, не лишним было бы протестировать чисто-питоновский код данного примера с использованием Psyco.

                                  PS: А никто не пробовал использовать транслятор Shedskin C++, насколько он может дать прирост?
                                  • 0
                                    на моей машине psyco дает ускорение в 8.6 раз, думаю, тут примерно так же будет (вместо 0,537 будет где-то 0,062, т.е. раза в 4 быстрее, чем руби 1.9)
                                    • 0
                                      В контексте данного теста 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, или кэшерование.
                                  • +5
                                    «Convention over Configuration» — девиз рельс. Рельсы — это не руби. Вы задолбали путать.

                                    Прикиньте, кто-нибудь питон с джанго бы начал путать.
                                  • 0
                                    За тест спасибо, хорошее дело.
                                  • 0
                                    Это типа как в Perl'е use memoize? Так ничестно — это хак :)

                                    А если серьезно, то конечно, хотелось бы какие-то комплексные тесты посмотреть.
                                    Счетные задачи в вебе — это редкость. Обычно в вебе задачи структурные (работа со сложными структурами данных и обработка текстов).
                                    • 0
                                      нет, это не как use memoize.
                                      use memoize — кеширование результатов
                                      а psyco — это компиляция кода во время выполнения, т.е. функция на самом деле все считает тыщу раз, только делает это быстрее
                                    • +6
                                      %username%, помни — Хабрахабр не только для веб-разработчиков :-)
                                      • 0
                                        А что, многие не веб-разработчики используют интерпретируемые языки для счетных задач?
                                        • 0
                                          Питон очень широко используется. Посмотрите на те же numpy и scipy.
                                          • 0
                                            Для счётных я тоже пока сомневаюсь. именно для очень крупных, а не для счёта факториалов. Но пока что тесты отложены на февраль.
                                    • +2
                                      Интересные цифры, абстрактные, конечно, но возможно и не зря стал Ruby изучать на замену PHP :)
                                      • 0
                                        А Python 3.0 будет как-то отличаться по скорости от 2.*?
                                        • +1
                                          да, в худшую сторону из-за повсеместного перехода на юникод и бОльших возможностей
                                          • 0
                                            пока процентов на 10-20 проигрывает в производительности. думаю будут оптимизировать в следующих релизах
                                          • 0
                                            ничего php10 переплюнет ruby 2.0 :)
                                            • +1
                                              К тому времени уже наверно Ruby 5 будет, так что не страшно:)
                                              • +15
                                                К тому времени процессоры будут выполнять бесконечный цикл за 3 секунды.
                                              • +1
                                                А если серьезно — за тест спасибо + прочитав комментарии можно еще раз убедиться — разницы нет на чем вы программируете, скорость можно увеличить правильным подходом, а так же прямотой рук. И всегда читайте, что нам дают новые версии продуктов.
                                                • +2
                                                  >разницы нет на чем вы программируете
                                                  Вот именно из этих соображений я назвал статью
                                                  «Ruby && Python && Perl && PHP && Ruby1.9»
                                                  а не как обычно в таких случаях
                                                  «Ruby vs Python vs Perl vs PHP vs Ruby1.9» :)
                                                  • +1
                                                    статья — тру, только если все языки — тру
                                                    по замерам выходит, что так
                                                    значит статья — тру
                                                    • 0
                                                      Честно говоря о такой интерпретации не подумал, а ведь и вправду тру!:)
                                                    • 0
                                                      В комментариях начались споры по производительности, показали, как на разных языках ускорить, собственно это дополнение к статье.
                                                • +3
                                                  Гораздо важнее для языков их читаемость и скорость разработки, для себя я выбрал Python.
                                                  • +2
                                                    Именно по этому же принципу для себя я выбрал Ruby:) В сравнении с Python синтаксического сахара там больше.
                                                    • 0
                                                      Извините за оффтоп.
                                                      Просто спросить не у кого. Расскажите неграмотному поподробнее о возможностях Ruby, для меня пока этот язык — загадка… У меня ситуация такая… вот я владею в какой-то мере PHP, осваивал ASP.NET (это для веб), для десктопных приложений и приложений с БД использую C# (раньше С++Builder). Как с этим у Ruby? Удобно ли использовать для написания десктопных приложений? Для веба я уже ни раз слышал, что рельсы Ryby рулят, а как с хостингом? Достаточно ли они распространены и качественны уже? Заранее спасибо.
                                                      • 0
                                                        Ruby удобен будет тем, что вы на одном языке сможете и Desktop и Web программировать. Desktop-приложения программировать удобно, особенно с Shoes. Для веба проще использовать VPS и не мучатся.
                                                        • +1
                                                          Python уже удобен тем
                                                          • 0
                                                            Да, VPS это здорово, но мне кажется, что это решение актуально для высоконагруженных сайтов. Разве нет? Где важна скорость. Ведь разница в цене 3-4 раза с виртуальным хостингом довольно значительна, особенно для небольших сайтов.
                                                            • 0
                                                              VPS к скорости отношение не имеет. Он больше нужен тем, кто хочет контроль. Я перешёл на VPS ещё, когда писал на PHP — замучало отсутствие нужных расширений или их старая версия. На VPS у вас есть root и вы можете делать с системой всё что угодно.
                                                              • 0
                                                                Понятно. Да это удобно… но все же дороговато.
                                                                • 0
                                                                  Посмотрите на 1vds.ru/, попробовать нужно ли оно вам, да и справитесь ли вполне сравнимо по цене со средним php-хостингом
                                                                  • 0
                                                                    И что, нормальный ВДС за такие деньги?
                                                                • +1
                                                                  >На VPS у вас есть root и вы можете делать с системой всё что угодно.

                                                                  И несете за это полную ответственность, прежде всего за безопасность, что на практике, в условиях ограниченного бюджета (профессионалам платить не хочется/не можется), означает еще и освоение професии *nix админа. Конечно, поднять локальный дев-сервер через консоль или по ssh редактировать файлы должен уметь любой веб-разработчик, но вот знать какие процессы на нем крутятся по дефолту, какие можно безболезненно отключить, а какие нет, уметь писать правила для iptable (и уметь делать так, чтобы они сохранялись при ребуте), в конце-концов знать, что в var можно почистить, когда отведенное место заканчивается, а что лучше не трогать — это уже, имхо, на любителя.

                                                                  А если использовать VDS через какую-нибудь CPanel, то особо ничем от обычного хостинга и не отличается, по-моему.
                                                                  • +1
                                                                    Такая ситуация имеет место, но реально проблема не такая уж и серьёзная. Практически все VDS-хостинг имеют готовые наборы ПО, которые они сами [централизовано] поддерживают. Туда входят и Rails с MySQL. Сильно думать надо, только если у Вас какой-то особый набор ПО.
                                                                    • 0
                                                                      Согласен, но в контексте нашего треда VDS нужен все-таки именно для тонкой настройки под себя, и начиная «ковырятся» в консоли или конфигах (особенно с правами с правами рута) надо понимать, что после «rm -rf» в корне или еще где в лучшем случае бесплатно тебе восстановят вчерашний бакап системы, и то не сразу, как правило.

                                                                      P.S. Хоть один человек на хабре принял мои доводы против VDS/DS всерьез и аргументированно ответил :) Респект!
                                                              • 0
                                                                О мой бог! Присуждаю вашему комменту приз самого полезного (для меня) комментария на Хабрахабре. Я пытался использовать txruby, fxruby, wxruby, но мне они не нравились, прежде всего, своим не-Ruby-Way-подходом. Shoes — это, извините, невъебенно круто. Огромное спасибо за наводку, пойду смотреть Shoes дальше.
                                                                И простите за экспрессивность — очень уж понравился синтаксис Shoes. :)
                                                              • 0
                                                                Шаред хостинг — только появляется(по крайней мере у нас). Как правильно сказали — проще использовать VDS/VPS, к томуже они дешевеют.
                                                                Насчет десктопа — обертки есть практически для всех оконных библиотек
                                                                RubyGTK, RubyQt, FoxRuby, Tk
                                                                Мне лично больше нравиться обертка WxWidgets — WxRuby.
                                                                Или тот же Shoes
                                                                • –1
                                                                  Ясно. Возможно это какие-то мои стереотипы… Но имхо эти «обертки» пока не дотягивают до удобства разработки GUI, что есть в том же VS. Серьезные приложения с большим количеством контролов имхо как-то проблематично. Есть ли какое-то удобное и эффективное решение в плане GUI?
                                                                  • 0
                                                                    Эдитор интерфейсов? Насколько я знаю — нет. Я еще когда на Java программировал десктопные приложения от этих эдиторов отучился. Чего и вам советую:)
                                                                    Проблема оберток в том, что они тянут за собой сишный синтаксис. Ну в плане структуры самой библиотеки. С этой точки зрения, как уже говорили, хорошо посмотреть Shoes.
                                                                    • 0
                                                                      Хорошо, Shoes так shoes. Вижу там один человек уже в восторге, значит оно того стоит :)
                                                                      Спасибо. Хоть что-то уже прояснилось.
                                                                      • 0
                                                                        Йойо, привет :)

                                                                        Напиши в джаббер: rudenkoco@gmail.com

                                                                        И насчет эдитора: Interface Builder + MacRuby :)
                                                            • +2
                                                              Комменты не читал, выскажусь только по топику:

                                                              «Очередная академическая х*%ня» © — так бы сказал один известный автор и был бы прав.

                                                              Если уж хотите действительно протестировать, потрате время на придумывание задания, сделайте топик о таком тестировании и попросите пишуших на 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 )
                                                              • 0
                                                                Не такая задача ставилась, как вы описали.
                                                                Все-таки почитайте коменты:)
                                                                • +1
                                                                  Да просто надоело читать эту хрень, как ни напишешь в гугле — таких результатов сотни — хоть бы один нормальный обзор.
                                                                  Я вот как-то по юности устроил тест выводу на экран с помощью разных методов — с '' и "" — потратил пол дня на разные варианты и доведения до совершенства, в итоге всем было интересно обсудить результаты, а не пофлудить в теме.
                                                                  • 0
                                                                    Это по поводу хрени: iv_s.habrahabr.ru/blog/48952/#comment_1272787 И апдейт к статье тоже прочитайте.
                                                                    И вообще, прежде чем заявлять флуд в коментариях или нет, сначало нужно их прочитать.
                                                                    • –1
                                                                      Я высказал отношение к топику, а не к коментам. Из-за топика комменты мне не интересны. Половина спорит о том, насколько тест реален, остальные холиварят о том, какой язык лучше. За долгое время чтения хабра уже предугадываешь что пишут в комментах с 80% вероятностью. Здесь мало непредвзятого народа, очень мало.
                                                                      • 0
                                                                        >Я высказал отношение к топику, а не к коментам
                                                                        По вашим коментам, похоже что вы его неправильно поняли. Хотя возможно я не достаточно понятно его написал.
                                                                        >За долгое время чтения хабра уже предугадываешь что пишут в комментах с 80% вероятностью.
                                                                        Завидую, тоже хочу обладать телепатией:)
                                                                        Ну а вообще, у нас с вами сейчас как раз флуд не по теме и получается. Предлагаю закончить:)
                                                                • 0
                                                                  Кстати, да.
                                                                  У меня возникла подобная мысль… я хотел бы написать код на perl'е по работе со сложными структурами данных (ссылки, многоуровневые хэши и массивы, копирование структур) и предложить харбаюзерам перевести его на Ruby и Python и сделать бенчмарк. Если кто пожелает присоединиться (в ближайшие пару дней напишу в блоге) — велкам.

                                                                  Кроме того, у меня есть несколько вопросов по платформе RoR — их я тоже опубликую чуть позже — надеюсь на ответы.
                                                                  • 0
                                                                    Жизненые тесты — это интересно. Потому как тотже shootout — такиеже синтетические тесты.
                                                                    • 0
                                                                      Жизненными они все равно будут с большой натяжкой… Работа со структурами — тоже синтетика, но направленная на другой аспект. Но хоть какие-то явно прикладные моменты хотелось бы выделить.
                                                                • 0
                                                                  Спасибо, интересные факты. Очень интересно сравнить их с языками компилируемыми, просто для того, чтобы иметь представление о масштабах, если Вас это не слишком затруднит. (Думаю о чистом Си)
                                                                  • 0
                                                                    В начале указанна ссылка на статью: habrahabr.ru/blogs/ruby/48928/
                                                                    Посмотрите там результат выполнения factorfast. По скорости — практически идентично чистому С. За минусом времени, нужного для старта интерпретатора.
                                                                    • 0
                                                                      Всетаки сравнил с С:)
                                                                      Я вам немного соврал, скорость запуска будет сильно отличаться у 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
                                                                      • –1
                                                                        С Ruby 1.9 разница уже просто несущественна! И это при том, что си — фактически тот же асм, личь чуточку «повыше».
                                                                        • +3
                                                                          >фактически тот же асм
                                                                          На асме бенчмарки гонять не буду, даже не просите:)
                                                                          • НЛО прилетело и опубликовало эту надпись здесь
                                                                      • +1
                                                                        в этой конкретной задачи должен рулить Хаскель — у меня он весьма лихо считал факториалы, итоговые цифры которых выводился на экран по 15 минут ;)
                                                                        • 0
                                                                          Не чесно:) Он функиональный, да еще и компилируемый!:)
                                                                          Кстати, как он по впечатлениям? А то я решил приобщиться к функциональному миру, но для начала выбрал Erlang.
                                                                          • 0
                                                                            дальше факториала дело не пошло, потому что тоже выбрал эрланг ;)
                                                                            • 0
                                                                              Я Haskell смотрел исключительно из интереса, на академических задачах, то есть много на нём не работал. Но мне он очень понравился и заинтересовал. Мозг сломать легко, но восхищение от, скажем, quicksort'а в две строчки ни с чем не сравнимо. ;)
                                                                              Erlang я, впрочем, не видел, сравнить не смогу.
                                                                              • 0
                                                                                Ну после императивных языков, функциональным очень легко мозк сломать:)
                                                                                Кстати, Erlang меня тем же квиксортом поразил, можно посмотреть на википедии:
                                                                                en.wikipedia.org/wiki/Erlang_(programming_language)
                                                                                Но у него что больше интересно, так это концепция конкуррентно ориентированного программирования. Лично для меня это стало решающим фактором в решении изучить именно Erlang:)
                                                                                • 0
                                                                                  Очень интересно! Спасибо за наводку.
                                                                                  • 0
                                                                                    Если заинтересовались, советую эту книжку:
                                                                                    www.flazx.com/ebook8174.php
                                                                                    Только в первых 5-6 главах про основную фичу — конкурентность — ни слова:) Там описание самого языка(читать «введение в функциональное программирование»:))
                                                                                    Самое интересное нчинается с середины:)
                                                                                    Возможно потом напишу что нибудь про Erlang.
                                                                              • 0
                                                                                Расскажу о своих впечатлениях.

                                                                                Алгоритмы, не требующие IO (вывод на экран, запись или чтение из файла) или не требующие явной императивности (например, присваивания) пишутся замечательно, и работают тоже неплохо.

                                                                                Когда нужно, чтобы «внутри» функции были присваивания (из соображений скорости или еще каких), но при этом функция оставалась чистой снаружи, немного жутковато писать (ST монаду в помощь, но таки легче при помощи уникальных типов из Clean — вот этого в Хаскеле нет и не будет).

                                                                                А, и еще: IO Хаскеля в стандартной библиотеке ужасно медленное (вот из-за этого большинство народу считает, что Хаскель тормозит). Есть библиотеки ByteString и Binary, которые работают быстро, а иногда медленно (связано со space leaks). Альтернативные подходы вроде iteratee-based IO, lightweight monadic regions и functional reactivity еще не доросли до повседневного использования, но они весьма многообещающие.
                                                                            • +1
                                                                              Никогда не сталкивался с какими-либо серьезными мат вычислениями в своей работе (php). Интерпритируемые языки вообще для этого никак не предназначены. Все тормоза языка можно легко дотянуть установкой более мощного железа. Это вообще глупые тесты, которые ни к чему не приведут. Куда важней для веба правильно работать с базой и иметь красивый, читаемый код. У меня на работе так однажды выбирали шаблонизатор… посмотрели, кто быстрей работает и выбрали Blitz. В итоге сейчас будет много времени переход на смарти просто потому, что у Blitz не такой большой функционал. Так это я к чему:

                                                                              В вебе, где нет никакой нужды в сложной мат логике, где язык является тоненькой прослойкой между БД и браузером пользователя победит тот язык, который даст минимальную стоимость поддержки и максимальное удобство для разработки. Тут мы уже можем видеть, как самый быстрый PHP сильно отстает от всех остальных языков. Скорость работы языка — не критерий в вебе!!!
                                                                              • +2
                                                                                Знаете ли Вы, что Ruby можно использовать не только для веба? И в этом топике нет ни слова о вебе… Причём здесь вообще вэб?
                                                                                • –5
                                                                                  Да что же сразу Ruby. Любой их этих языков можно использовать не только для веба. Только вот есть ли в этом какой-либо смысл?! Если вы хотите хорошо работать с математикой, то интерпритируемые языки вам вообще не подходят. Тут только C/C++. Для математики необходима грамотная работа с памятью, а это есть только в C/C++.
                                                                                  Ну а веб при том, что больше 90 процентов проектов, написанных на этих языках (а если убрать питон, то еще больше) веб.
                                                                                  • +1
                                                                                    Вы похожи на ребенка, который не знает, откуда берутся дети. Если вы работаете там, где нужно инструменты только использовать, то вы считаете, что оно все берется само по себе.
                                                                                    Или вот как больщинство людей считают, что линукс нинафига никому не нужен, потому что они сами его никогда не видели, и аргументируют неприязнь к линуксу «90% компов стоят с виндой...»
                                                                                    • 0
                                                                                      >линукс нинафига никому не нужен, потому что они сами его никогда не видели
                                                                                      Незнание порождает заблуждения:)
                                                                                    • 0
                                                                                      Есть смысл. Я пробовал писать гуевые приложения на ruby+qt, ruby+qtk, jruby+swing. Полет отличный. Если нужна будет производительность я себе модуль напишу на сях и все. Да и грамотная работа с памятью не всегда нужна (помню делал 7 лабораторных по численным методам и 5 по методам оптимизации + пара курсачей ни в одной работа с памятью не понадобилась).
                                                                                      • 0
                                                                                        >ruby+qt, ruby+qtk, jruby+swing
                                                                                        Попробуйте обертку к WxWidgets — WxRuby. Мне приятнее всех показалась.
                                                                                        • 0
                                                                                          Рекомендую также Shoes :)
                                                                                        • 0
                                                                                          >для математики необходима грамотная работа с памятью
                                                                                          Не понял смысла утверждения. У C/C++ работа с памятью вообще никакая, все ложиться на программиста. В том же Ruby уже есть сборщик мусора(впрочем как и у Java, C#, Python и т.д.).
                                                                                          • 0
                                                                                            1. Используйте умные указатели
                                                                                            2. К С++ можно прикрутить сборщик мусора. А смысл? Первый пункт предпочтительней.
                                                                                            • 0
                                                                                              Ну это для C++. Для С то не пройдет.
                                                                                              Конечно не спорю, что от программиста зависит, но мне кажеться что GC все-таки надежнее.
                                                                                              • +1
                                                                                                Не хочу разводить холивара, но ни одного идеального и полностью надёжного GC я не видел. А так как я предпочту расплачиваться за свои ошибки, чем за ошибки GC, то и нравится мне больше ручное управление памятью, особенно, если его можно автоматизировать как вам угодно.
                                                                                                По поводу С — опыт разработки на С++ у меня гораздо больше, чем на С, поэтому мне свойственно иногда забываться. Так что здесь вы правы — в С ситуация с памятью намного хуже, чем в С++. Но ведь и С стоит выбирать только для определенного класса задач.
                                                                                                • 0
                                                                                                  А у меня наоборот, с С++ опыта совсем мало. Да к томуже я поклонник динамических языков.
                                                                                                  Так что, про GC — это субъективно. Согласен, не будем холиварить:)
                                                                                          • 0
                                                                                            э, сами говорите «даст максимальное удобство разработки», а тут же «хотите хорошо работать с математикой… только C/C++»… может всё же удобнее работать с тем же Fortran'ом ^)
                                                                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                                                              • 0
                                                                                                Для математики достаточно numpy/scipy скорость сишная, легкость змеиная
                                                                                            • 0
                                                                                              >Все тормоза языка можно легко дотянуть установкой более мощного железа
                                                                                              Креативный способ оптимизации кода:)
                                                                                              • 0
                                                                                                Ну а чо. Именно так наш препод и говорид по функциональному и логическому программированию.
                                                                                                • 0
                                                                                                  Это в случае когда сам алгоритм оптимальнее реализовать нельзя. Обычно это подразумевает что мы уже имеем самую оптимальную реализацию.
                                                                                                  • 0
                                                                                                    К сожалению многие преподаватели вообще ложили на оптимизацию ..))))
                                                                                                    • 0
                                                                                                      Ну у них задача — научить. И так не все это понимают, а если еще и оптимизацию в процессе обучения прикручивать...:)
                                                                                                      • 0
                                                                                                        Не про нашего… за лишную операцию сразу срезал баллы за лабы
                                                                                                • 0
                                                                                                  В целом согласен.
                                                                                                  Хотя так и проситься какой-нибудь контр пример, типо сложной функции(математической!) расчета рейтинга.:)
                                                                                                  Но опять же процитирую сама себя в пятый раз: habrahabr.ru/blogs/ruby/48952/#comment_1272787
                                                                                                  И еще раз выводы в апдейте прочитайте.
                                                                                                • +1
                                                                                                  Про Руби 1.9 неожиданно, да.

                                                                                                  >> ожидал что настолько хорошо получиться.

                                                                                                  Проверочное слово — что сделает?
                                                                                                  • 0
                                                                                                    Исправил, спасибо.
                                                                                                  • 0
                                                                                                    в питоновском тесте должен быть не range, а xrange
                                                                                                    • 0
                                                                                                      Спасибо за дополнение.
                                                                                                      Результаты:
                                                                                                      time python factorx.py #c range
                                                                                                      
                                                                                                      real	0m0.565s
                                                                                                      user	0m0.556s
                                                                                                      sys	0m0.000s
                                                                                                      
                                                                                                      time python factorx.py #с xrange
                                                                                                      
                                                                                                      real	0m0.553s
                                                                                                      user	0m0.540s
                                                                                                      sys	0m0.016s
                                                                                                      
                                                                                                    • 0
                                                                                                      Похоже все забыли про такой известный проект сравнения производительности языков:
                                                                                                      shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=php&lang2=yarv
                                                                                                      • –1
                                                                                                        Тяжело такие данные воспринимать ;)
                                                                                                        • +4
                                                                                                          а эту синюю тонкую хрень легко вспринимать по-твоему, да? )
                                                                                                          • –1
                                                                                                            без подписей конечно тяжело, но если вставить в контент думаю можно понять.
                                                                                                            • 0
                                                                                                              да, всё понятно, после долгого вчитывания и сравнения с контентом, но разве это цель диаграммы?..
                                                                                                          • +1
                                                                                                            Хм, чесно говоря не понял что заначит шкала справа и синяя полоска.
                                                                                                            Объясните пожалуйста:) И тогда я в топик добавлю, с вашего разрешения конечно.
                                                                                                            • 0
                                                                                                              Слева — real (пример 0m0.537s)
                                                                                                              Справа — sys (пример 0m0.000s)
                                                                                                              • 0
                                                                                                                Ах вот оно что. sys(и user) смысла нет добавлять. Они учтены в real. В тесте они только из-за того, что это стандартный вывод утилиты time.
                                                                                                                Можете это убрать? И тогда, если позволите, размещу в топике.
                                                                                                                • +1


                                                                                                                  Что то типа этого?
                                                                                                                  • +1
                                                                                                                    Супер! Ставлю в топик?
                                                                                                                    • +1
                                                                                                                      Да пожалуйста ;)
                                                                                                                      ФриПабликЛиценз :D
                                                                                                                      • +1
                                                                                                                        Готово, спасибо за диаграму:)