Сравнение языков программирования по скорости и не только

    А у вас так?


    Выполняя разные проекты я пользуюсь разными языками и порой намного проще оформить идею в python нежли в лоб решать её на С++. Но любой уважающий себя девелопер думающий хотя бы немного наперёд о том в каких условиях будет работать его приложение, задаст сам себе вопрос "хватит ли мне скорости python или же лучше сразу писать на с++? А может мне скорость не критична, зато важно чтоб легко пис́алось и поддерживалось?". На хабре периодически проскакивают статьи, которые освещают замеры производительности в разных областях development'а, но централизованной информации по языкам не было (если только поиск меня не обманывает). Лично я в таких случаях иду на один очень полезный ресурс находящийся под патронатом Debian сообщества и получаю информативные графики статистики по достаточно большому спектру языков.

    Подробнее


    Проект называется незамысловато: «The Computer Language Benchmarks Game» и под его крышей собраны в основном самые популярные языки программирования. Там можно взять C++ и сравнить его с Python или, к примеру, со Scala. Получить статистику не только на сколько быстр тот или иной язык, но и увидеть потребление памяти программой на стандартных тестах и даже у кого размер кода больше/меньше.

    Например С++ vs Python 3:


    Из графика наглядно можно увидеть, что на некоторых тестах С++ резвее Python до 100 раз, а на некоторых всего раза в 2-3 (сами тесты конечно же предоставляются в виде исходных кодов). Потребление памяти у С++ в 3-6 раз меньше, а вот размер исполняемого кода у Python на выходе местами до 10 раз меньше.

    Создатели этого проекта вполне ясно понимают, что производительность приложения вещь не постоянная и зависит от конкретной программы и задачи. Поэтому для тестов используется добрый десяток разных программок и алгоритмов чтобы статистика покрывала достаточно разные ситуации: там и бинарные деревья, и рекурсии, и прочие радости программистской жизни. Стоит только сказать, что тестов там достаточное количество, а в графиках показываются только основные и наиболее значимые.

    Для особо скрупулёзных людей под графиками идут подробные таблицы с конкретными цифрами.

    В довесок можно изучить влияние на производительность в сборках под 32 и 64 разрядные процессоры (если конечно компиляторы/интерпретаторы работают/генерируют код для соответствующих режимов).

    Ну и конечно же ссылка на проект.

    PS: Вполне возможно, что корифеи от девелопмента знают про этот ресурс, но тех кто не в курсе может быть огромное количество. Например многим менеджерам и руководителям проектов подобный ресурс попросту не известен, но может быть крайне необходим на стадии планирования проекта и позволит объективно принимать решения хватит им PHP или лучше сразу на java делать проект. А может и вовсе на C++.
    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 125

      +6
      Premature optimization — зло. На стадии проектирования важна не скорость работы приложения, а скорость его разработки, ибо время — деньги.

      А за ссылку спасибо, пригодится.
        +13
        Это не предварительная оптимизация. Это грамотный выбор инструмента для решения задачи.
          +9
          Это грамотный выбор лишь при условии, что скорость работы приложения — первостепенная задача.
            –2
            Скорость на самом деле второстепенна только в приложениях типа странички заказа пиццы в Google (которая на PHP).

            Я уже насмотрелся на приложения, в которых вначале упор делался на скорость разработки.
            Страдают от этого пользователи, которые тратят дни (именно дни) своей жизни в ожидании реакции приложения.
            Тут уже действительно время-деньги.
            Оптимизировать потом эти поделки сущий ад.

            Если разработчик уважает своих пользователей, то он изначально задумывается над скоростью работы и выбирает язык в соответствии с задачей.
              +4
              Т.е. я правильно понимаю, что вы предлагаете писать сразу на асме? Пофиг, что несколько лет на разработку уйдет, скорость то важнее.
                +2
                А я так и делаю. Правда, еще не доделал.)))
                  +8
                  Внуки допишут
                    0
                    Наследованный-то асмовский код? =)
                      0
                      Будете смеяться, но я не шучу.

                      Некоторые узкие места своего проекта я решил переписать как расширение для пхп на си с ассемблерными вставками. Основная масса действий происходит как раз в ассемблере.
                  –5
                  Если вы можете писать на Асме, пишите на Асме.
                  Некоторые даже ОС на Асме пишут, получается очень даже хорошо.
                  Но говорить что быстродействие второстепенно может только человек, которому нужно быстрее сдать свой говнокод.
                    +3
                    На месте заказчика вы стали платить исполнителю хотя бы вдвое больше за то, что его код на асме обрабатывает, скажем, 100000 запросов в секунду вместо 1000 на питоне, при том что в ТЗ указано 100 (вами осознанно указано, по самым оптимистическим оценкам)? Причём вторая цифра получена без напряга, а первая как плод наносекундных :) оптимизаций бинарного формата команды «MOV A, B» исполняющейся один раз за запрсо
                      –3
                      Таким образом я бы сэкономил в 100 раз на железе.
                      Математика простая.
                      Если заказчик умеет считать он заплатит такому программисту.

                      Я не говорю о детских программках, я говорю о серьезных проектах.
                        0
                        А если стоимость разработки на питоне больше, чем экономия на железе? ;)
                          +1
                          Прочитайте последнее предложение.

                          Если перенести вопрос в область моей работы, либо мне поставить 100 стоек по 50к баксов каждая и потратить 5000к на железо и скажем 100к на разработку, либо мне поставить одну стойку за 50к и потратить 200к на разработчикам.

                          Первый случай затраты: 5000к
                          Второй случай затраты: 250к

                          При увеличении нагрузки затраты будут увеличиваться в арифметической прогрессии.
                          Я уже молчу кукие будут постоянные затраты на содержание оборудования.
                          В первом случае они будут баснословными.

                          Так что лучше заплатить программисту за качественный и оптимизированный код.
                          Как я и говорил математика простая.
                            0
                            Я прочитал, представьте, что трудоемкость разработки на питоне составляет порядка миллиона человеко-часов (неужто для вас не серьезный проект, требующий года работы команды в 500 человек?), на асме — два миллиона. Если платить хотя бы 5$ в час, то в первом случае затраты 5000к на железо+5000к на разработку= 10 000к, во втором 250к на железо+10 000к на разработку=10 250к, уже экономия, но вряд ли вы захотите вкладывать такие деньги в разработку из расчёта зп меньше средней по России.

                            За качественный никто не спорит (в данном случае), что лучше платить, а вот надо ли доплачивать за оптимизацию — вопрос весьма спорный, хотя бы в уме надо прикинуть, может железо дешевле обойдётся?

                              0
                              Год работы и 500 человек, это либо поисковик масштаба Google, либо отмывание денег.
                              В таких случаях затраты на железо также ростут как на дрожжах и они постоянные, в отличие от расходов на разработчиков в таком объеме.
                              Не стройте иллюзий.

                              Крупные компании не зря постоянно обновляют железо для экономии электричества и повышения мощности на единицу стоимости.
                              Они не снижают затраты на разработчиков, т.к. они в разы меньше чем затраты на покупку и обслуживание железа.
                                0
                                Снижают, снижают ) Тенденция на аутсорсинг все еще есть, как и обилие и многообразие индусского кода.
                              +3
                              Давайте тогда уж посчитаем реальные цифры, пример в моей компании — крупное веб приложение, для разработки использован инструмент python, т.к. под него уже есть много грамотно написанных, общедоступных компонентов которые нужны для разработки. В случае с++, многое пришлось бы писать самому (свои кривые колеса). В итоге длительность разработки увеличилась бы в 5..20 раз (примерно подсчитано).
                              Считаем производительность: быстрее на 10%..20%, потому что главный тормоз — это толстая БД (очень частый случай). можно пойти дальше, написать свой инструмент — сервер БД, который именно для этого проекта будет в 2 раза быстрее( и то сомнительно), но для этого потребуется ещё год выкинуть на разработку.
                              В итоге получается что «говнокода» будет в случае с++ будет гораздо больше, ибо на python мы будем использовать готовые компоненты грамотно нписанные и отлаженные.
                              И в нашем случае получается — неважно сколько будет стоить второй сервер.
                                0
                                промахнулся, ответ для DLag
                                  0
                                  Вы явно не писали таких вещей на C++.
                                  На нем как раз написано в разы больше чем на python.
                                  Многие колеса, особенно по алгоритмам пишутся как раз на python.

                                  Но все решается намного проще, наймите нормального системного архитектора и сис.админа.
                                  У вас сразу отпадет проблема с БД, потому что один подберет самый эффективный вариант, а второй сделает из него конфетку.
                              +1
                              … это если проект УЖЕ серьезный, и у него УЖЕ есть такая нагрузка, и стоимость параллелизации действительно выше стоимости разработки.

                              В приличных книжках про архитектуру именно про это и пишут — premature optimization. Если в ТЗ указано 100 транзакций, ваш код дает 1000 — не надо его вылизывать еще дальше, это бессмысленная трата денег заказчика.

                              А вы почему-то дальше постоянно исходите из «при увеличении нагрузки». А кто сказал, что оно будет? Что оно кого-то интересует?
                                0
                                Серьезные проекты тоже заваливаются из-за невлезания в сроки и в бюджет. А предварительная оптимизация, увеличивающая время разработки, сильно бьет по этому параметру.

                                Правильнее всего локализовать код так, чтобы потом его можно было легко заменить на оптимизированный вариант, и оставить в таком виде. А когда дойдет до существенных нагрузок — вспомнить про такие места, искать среди них самые узкие — и исправлять их. А оптимизировать то, что отрабатывает один раз при старте системы, которая перезапускается раз в год — как правило, не самое лучшее решенеи.
                                0
                                Ваш пример неудачен — уже сейчас компиляторы высокоуровневых языков оптимизируют код лучше человека, особенно когда это касается современных процессоров.
                                  0
                                  В лучше не поверю, намного быстрее и ненамного хуже — легко. Причина простая — человек знает, что он хочет от кода, а компилятор нет.
                                    0
                                    Ох как мало таких людей, которые знают все нюансы современных процессоров… И они пишут компиляторы…
                                    А все остальные зачастую даже не знают чего они хотят от программы…
                                +4
                                Это у вас дедлайнов, видимо, не было никогда. Быстродействие не всегда 1) первостепеннно 2) стоит трат сил и времени.
                                  –6
                                  Почитайте про управление временем.
                                  Научитесь правильно его распределять и делать оценку своих возможностей.
                                  И не будет у вас дедлайнов.
                                    +5
                                    Не всегда сроки ставите вы, ага.
                                      –2
                                      Я уже дорос до того чтобы ставить сроки самому.
                                      Раньше просто не брался за то что не успевал сделать.
                                      Нужно реально оценивать свои возможности.
                                      Ага.
                                        0
                                        Доросли, да не переросли. Никто в компании не будет вас спрашивать, беретесь вы, или нет. У рекламного отдела, положим, есть продажа, с четко установленным сроком. И уложиться вы обязаны.
                                          –1
                                          Посмотрел бы я на своего программера, который мне говорит что я ему обязан. ))
                                          Дорос, уж поверьте.
                                            0
                                            Тот же гипотетический рекламный отдел не ваш программист и не ваш подчиненный.
                                              –1
                                              Рекламный отдел тоже в моем подчинении, как собственно и вся фирма.
                                              Очень плохо когда в компании командует рекламный отдел.
                                              В таких случаях репутация у фирмы падает ниже плинтуса.
                                                0
                                                Я очень рад, что вы добились.
                                                  0
                                                  Директор фирмы не определяет сроки. Он либо соглашается со сроками заказчика, либо может попробовать их подвинуть путем переговоров. Но последнее слово всегда за заказчиком. И если его Ваши сроки не устроят — проект уже не Ваш.
                                            0
                                            «Я уже дорос до того чтобы ставить сроки самому.» — Вы теперь заказчик? )
                                    0
                                    Т.е. я правильно понимаю, что вы предлагаете писать сразу на асме? Пофиг, что несколько лет на разработку уйдет, скорость то важнее.

                                    Можно копнуть глубже. :) Товарищ-радиолюбитель говорит что если что-то нельзя сделать на ассемблере, то приходится паять. :)
                                      0
                                      похоже, что те кто разгоняют коллайдер не умеют ни на асме писать, ни паять… пробуют вселенную видимо разогнать да заоверклокать… :)))))
                                    +4
                                    Язык выбирает не разработчик, а менеджер, учитывая не только инересы пользователей и скорость разработки, но и наличие и цену специалистов на рынке труда.

                                    Иначе все писали бы на Common Lisp, на котором и хорошая скорость первоначальной разработки и можно инкрементально оптимизировать алгоритмы, не перезапуская приложения, и добиваться высокой производительность более низкоуровневой оптимизаций, декларациями типов и т.д.
                                      +4
                                      Инструмент выбирает компетентный человек (кажется, таких называют software architect), причем после того, как будет более-менее прикинут фронт работ. С менеджера станется ляпнуть: «Мы будем писать сервис по поиску простых чисел на пи-эйч-пи, потому что его все знают и писать на нем быстро и легко». Конечно, в стартапах встречаются менеджеры-архитекторы-программисты-дизайнеры-маркетологи, но чем крупнее компания, тем меньше там таких универсалов (в процентном соотношении).
                                      +10
                                      Не далее чем сегодня мне заказчик ответил про одну предложенную оптимизацию: «Эта программа запускается один раз в день. Мне не важно, будет она работать двадцать минут или сорок. Займись лучше другим — благо есть чем.»

                                      Заказчик, к слову сказать, сам бывший программист, ушедший в бизнес.
                                        –11
                                        Видимо потому и ушел в бизнес…
                                        +3
                                        Вот и мне так кажется, когда думают: «мы будем писать на том на чем быстрее,» — (хотя это спорный вопрос), потом появляются страшные монстры типа php-to-cpp(HipHop) транслятор, как у одного очень известного интернет проекта.
                                        Скорость разработки это интересный фактор, некоторые проекты, например игры, на быстрых языках типа python мне кажется вообще нельзя написать, но это не значит что на нем нельзя писать скрипты уровней например. Так что выбор языка по скорости разработки это не самый главный критерий потому что чем сложнее проект тем сложнее оценить скорость разработки. Ну а если кто-то хочет сравнивать языки по возможностям на программах уровня блокнот — его право. Для людей плохо знающих С++ скажу, что почти любую конструкцию языка легко можно в голове представить в асемблерном коде, поэтому до него нужно спускаться крайне редко, в основном это задачи связанные с оптимизацией расчетов, видел как симуляцию ткани на SSE оптимизировали, приросто в 5 раз по сравнению с кодом на С++. Но и тут например можно пойти дальше и перенести вообще все на OpenCL (кстати там то же С подобный язык) и получить оптимизацию в 30 раз минимум по сравнению с 4-х ядерным процессором.
                                        А ещё интересный момент, хочу написать программу под iPhone у меня выбор из Objective C и C++, со вторым будет сложнее, т.к. вся библиотека ориентированна больше на ObjC, или хочу под Android — снова выбор не большой Java и С++, со вторым снова проблемы, придется кучу оберток писать для мапинга библиотеки, если это не игры на OpenGL — то и выбора всегда между Java и Java (я не опечатался). Хочу приложение под linux/win32/MacOSX — ну тут то же не густо, если офисное, встает вопрос какую GUI дибу юзать — если Qt — то и думать нечего, если swing/JavaFX — то же, а под python особо ничего хорошего не знаю. Так что вопрос выбора языка часто упирается в выбор платформы. А оценить дельту скорости разработки прикладного софта с ипользованием Qt или JavaFX я например не в состояние, опыта не хватает, если здесь есть люди которым хватает — я бы с радостью с ними познакомился и поговорил, но боюсь что их время будет настолько дорого, что тратить на меня они его не будут.
                                          0
                                          >например игры, на быстрых языках типа python мне кажется вообще нельзя написать,

                                          Eve Online (правда критические участки серверного кода, афаик, на C++ переписаны)

                                          >Хочу приложение под linux/win32/MacOSX —… а под python особо ничего хорошего не знаю.

                                          PyQt ;)
                                            0
                                            Ну как вариант, но это же не совсем официальный порт, возможно что-то не будет работать, рисковать бы не стал.
                                              0
                                              Disney, Sony,… рискуют, тем более это не порт, а привязка (или обёртка) объектов Python к обычным либами Qt (oдна из сильных сторон питона — легкость интеграции со сторонними либами на любом (в теории) языке, переписать узкое место на C/C++/Asm или даже на Lisp или другой «экзотике» можно абсолютно прозрачно для остального приложения).

                                              Кроме того есть «официальный» (с активным участием Nokia) PySide, но пока статуса релиза не достиг и для продакшена пока не рекомендуется (заявлено что первый релиз будет совместим с PyQt, только заменить везде pyqt на pyside надо будет — вообще возник из-за сложностей с лицензированием PyQT — лицензия либо GPL со всеми вытекающими, либо довольно дорогая коммерческая, PySide же под более свободной LGPL)
                                              0
                                              EVE Online имеет хреновую масштабируемость и как следствие — жуткие лаги при боях >200 тел что уже давно не предел. Локал от 500 приводит к фризам и десинкам, что практически неиграбельно.
                                              Так что пример вы взяли весьма хреновый… В коммьюнити давно уже стоит вой на эту тему…
                                                0
                                                Хреновая масштабированность это, скорее, следствие неудачной (не рассчитанной на такую массовость) архитектуры (ну не рассчитывали они, что на один грид нужно будет несколько нод ставить, да ещё динамически их переключать при «пропрыг все, бля»), а не неудачного языка. Да и говорил я скорее не о серверной части, а о клиенте, что игру с 3D графикой в принципе можно на python написать.
                                                0
                                                wxpython =)
                                                +1
                                                > потом появляются страшные монстры типа php-to-cpp(HipHop) транслятор, как у одного очень известного интернет проекта.

                                                Угу, только почему-то РНР не помешал им стать известным интернет проектом. И HipHop появился у них на достаточно позднем этапе.
                                                +1
                                                А вот и нет. В большинстве случаев производительность упрется в диск. Не забываем, что почти все языки позволяют использовать c-extension, а значит сейчас можно написать не очень быстрый код на python/ruby, а потом уже переписать критичные участки кода на си, однако этим вы уменьшите оверхед по CPU, ну и вероятно памяти. И да это стоит того, чтобы ускорить скорость разработку.
                                            +2
                                            Однако почему-то часто встречаютсв проекты, которые достигнув зрелости и огромной аудитории (я про веб проекты), в которых разработчики садятся и переписывают ядро с нуля на более производительном языке, т.к. «ну кто ж знал что народ попрёт толпами»? :) Девелоперы из твиттера переписали ядро на Scala слезши предварительно с не столь шустрого Ruby on Rails, цитата: «Over time we found that although Rails works great for doing front-end web development, for doing heavy weight back-end processing, Rails had some performance limitations at runtime.» По тем же графикам Scala слегка шустрее той же Java, хотя работают на одной и той же виртуальной машине. Но, полностью согласен, что архитектура и дизайн часто решают судьбу приложения в плане производительности.
                                              +18
                                              Если бы твиттер не зашел аудитории (не стал бы таким популярным), разработчики бы понесли бОльшие затраты, начав сразу писать в рассчете на большую производительность
                                                +16
                                                Заметьте, они переписали лишь бэкэнд. Это раз.
                                                Два: у них уже был продукт. Он работал, приносил деньги, и они могли спокойно и без проблем его переписывать.
                                                  +2
                                                  Это верно. А FaceBook все еще на PHP :) Хоть и с HipHop. Пути оптимизации можно найти различные.
                                                    0
                                                    Не надо про твиттер. Их архитектуру и выборы языков, количество написаных велосипедов и т.п. не критиковал только ленивый
                                                    –11
                                                    Ага, очень круто быстро налепить говнокода и поняв, что работает это все очень-очень-очень медленно начать переделывать. При этом потратить времени в 2 раза больше чем если бы сразу делали с учетом скорости.
                                                    Сами же говорите, время — деньги.

                                                    PS: Зачем вы написали именно «Premature optimization», если можно написать то же самое по-русски? понт?
                                                      +4
                                                      Тут надо включить вероятность того что написанное будет кому то нужно, если пошло тогда имеет смысл переписать. А если нет то не жалко если бы писали на си и оптимизировали по полной.
                                                        +1
                                                        На тему premature optimization — некоторые термины по-английски звучат тупо приятней, короче и лаконичней.
                                                        «Преждевременная оптимизация» — как громоздко.
                                                          +34
                                                          А по-моему, это вполне нормально налепить говнокода, запуститься, и получить хоть какую-то прибыль с проекта и обратную связсь с клиентов. Дальше можно хоть до усрачки переделывать и причёсывать код, но в этом случае уже есть: 1. понимание куда двигаться, 2. можно поесть самому и покормить своих детей.
                                                            +2
                                                            «Все, что заслуживает быть сделанным, заслуживает того, чтобы быть сделанным плохо» © Золотые правила менеджмента
                                                              +2
                                                              На самом деле, лучше ни в какую крайность не впадать — есть какая-то оптимальная золотая серединка.
                                                                0
                                                                Золотые слова. Еще б все им следовали бы.
                                                              +1
                                                              Я так понимаю, вы по себе судите?
                                                              Заметьте, я не призывал писать говнокод. Любое (популярное) приложение рано или поздно придется либо масштабировать, либо оптимизировать.
                                                              Задумайтесь, почему для, например, автомобилей или же электроники создаются сначала прототипы, и уж потом доводятся до нужной кондиции.
                                                                0
                                                                Только эти прототипы не продаются клиентам за деньги, а тестируются внутри компании. При разработке софта тоже есть прототипы, которые никто кроме автора не видел и не увидит. А здесь предлагают слепить на коленке заведомо неподъёмного и кривого монстра и получить за это деньги с пользователя. Выбор языка программирования чётко следует из области применения ПО и проверяется на линейке прототипов узловых алгоритмов. А всё это переписывание целого проекта на другом языке — следствие непродуманности архитектуры и целей приложения в лучшем случае, в худшем — это элементарный обман клиента.
                                                                  0
                                                                  >А здесь предлагают слепить на коленке заведомо неподъёмного и кривого монстра
                                                                  И вы, конечно же, готовы процитировать данное моё предложение?
                                                                    0
                                                                    К вам относится только пассаж про прототипы. Но общий смысл ветки в том, чтобы как можно быстрее слепить дерьмо на коленке, продать его, повесив все свои косяки на клиента, а потом на вырученные деньги (клиента) начать всё переписывать и оптимизировать.
                                                                      0
                                                                      Пути веток неисповедимы, да. Клиенту нужно (по хорошему) делать хорошо, но и в сроки неплохо бы укладываться, ведь мало какому клиенту понравится, ежели вы будете вместо заявленного месяца разрабатывать проект три, в погоне за скоростью работы, не так ли?

                                                                      К слову, как ни странно, приведенный вами сценарий может оказаться клиенту и дешевле. Например: клиенту нужен видеохостинг с рекламой, положим с хитрой ротацией таковой рекламы. На разработку неделя. При этом у клиента уже есть заказы на размещение. Теперь рассмотрим два варианта: 1) вы сидите, и планируете как это лучше сделать, выбираете инструменты, в итоге в неделю не укладываетесь и просите две. Итого: клиент платит за две недели разработки и не получает прибыль от рекламы. 2) Вы пишете с использованием того инструмента, на котором быстрее, укладываетесь в неделю, все хорошо, но при большой нагрузке хитрая ротация не работает. Просите еще неделю на оптимизацию. Итого: клиент так же платит за две недели, но, в течении второй рекламы получает хоть какую-то прибыль от рекламы.

                                                                      Какой из вариантов дешевле клиенту?
                                                                        0
                                                                        Лично я объявляю срок в который заведомо укладываюсь, потому что знаю, что, как и на чём я это буду делать. Перед тем как объявить этот срок я провожу предварительный анализ проекта и в тех местах в которых я сомневаюсь насчёт срока я провожу дополнительные проверки. Если проект небольшой, то я это делаю за свой счёт, если проект серьёзный, то добавляю эти сроки (расходы) к срокам (расходам) заказчика о чём ставлю его в известность. Сразу оговорюсь, я не занимаюсь вэб-программированием, я занимаюсь разработкой алгоритмов и целых фреймворков на их основе. В основном это с/с++, эрланг, хаскель. Если заказчик не согласен, ну что же пусть ищет другого.
                                                                    0
                                                                    >А всё это переписывание целого проекта на другом языке — следствие непродуманности архитектуры и целей приложения в лучшем случае, в худшем — это элементарный обман клиента.

                                                                    В лучшем (для разработчика) случае это может быть ошибкой клиента (или нанятых им аналитиков/маркетологов), если его (клиента) самая оптимистическая оценка нагрузки, например посещаемости ресурса или сценариев его использования, оказалась на деле очень, на порядки, пессимистичной. Сказал клиент рассчитывать на 1000 посетителей онлайн максимум на таком-то железе (десять серверов, например), архитектор завысил эту цифру в 2,5 раза, команда реализовала ещё с двухкратным запасом. Архитектура великолепна, узких мест практически нет, масштабирование практически линейное. Запустили проект, но вместо 1 000. посетителей имеем 500 000. Покупка ещё тысячи серверов вдобавок к имеющимся десяти вряд ли будет является экономически эффективным решением, если, например, есть возможность переписать код на другом языке, увеличив тем самым его скорость раз в десять за стоимость, например, полусотни серверов — экономим 850 серверов :)
                                                                      0
                                                                      Разумеется, если изначальные требования к ПО неверны, то речи об удовлетворительном продукте быть не может. Тут уж, как говорится, заказччик сам себе злобный буратино. И тогда переписывание всего этого дела за деньги заказчика это другой проект с новыми требованиями. Я же говорил о недобросовестности исполнителя, который прикрываясь весьма странными для заказчика аргументами, типа: мне так удобней или бабки нужны, втюхивает клиенту фуфло и просит деньги на оптимизацию.
                                                                        0
                                                                        Ещё требования могут быть неполными, и тут дело разработчика уточнять их сразу (показав свою профессиональность, но, возможно, снижая потенциальный доход, а возможно увеличивая) или подождать пока заказчик сам не поймёт, что хотя формально задача решена, но на практике толку ему от этого мало и, возможно, обратится к нему же для действительного решения. Мошенничеством второй вариант назвать сложно, но и абсолютно этичным тоже как-то язык не поворачивается.
                                                                +3
                                                                Поддерживаю, для меня тоже время разработки первоочередной фактор (но с оглядкой на цель и инструменты),
                                                                если не будет хватать мощности — докупить серверов, и это будет выгоднее чем разрабатывать и поддерживать на «скоростном» инструменте но с медленной разработкой (в большинстве случаев которые я встречал). на крайний случай, ни что не мешает узкие места переписать на «скоростном» инструменте.
                                                                а если сразу писать на медленном инструменте, то проект может просто не дожить до релиза из-за не хватки времени, которого итак мало.
                                                                  +1
                                                                  Не могу не согласиться, Вы практически полностью озвучили мое мнение.
                                                                    0
                                                                    Да это всегда так. Нужно найти оптимальное (с учетом планируемых нагрузок) соотношение производительность/скорость разработки, а не делать упор на одну из этих сторон. Где-то хватит обычного млотока с долотом, где-то нужен перфоратор.
                                                                      +1
                                                                      Не все проблемы можно решить «еще одним сервером в стойке». Масштабируемое приложение точно так же надо написать, как и быстрое.
                                                                      +6
                                                                      Предварительная оптимизация — зло, но причем здесь выбор языка для проекта?
                                                                      На самом деле, мы имеем тут очень интересное расслоение аудитории. Первая половина рассматривает «проект» в классическом понимании — как некий заказ, со своей ценой, сроками и т.п. Вторая половина рассматривает «проект» в более новаторском духе — как свой «стартап», который хочется поскорее запустить, собрать отзывы и далее развивать в ту или иную сторону. И поэтому каждая половина по-своему права.
                                                                      Для второго случая правильнее тогда говорить не «проект», а «прототип». Если вспомнить классиков, то кто-то из них (то ли Брукс, то ли Макконнелл) советовал прототип делать на другом языке, нежели собственно проект. Тогда ты знаешь, что код потом точно выбросишь, и поэтому концентрируешься только на главном, а не на деталях.
                                                                        +2
                                                                        По-моему, расслоение не такое уж явное. «Заказ» тоже хочется побыстрее (раньше срока) сдать (ну или быть готовым к сдаче, если досрочная не желательна), чтобы приступить к другому или просто отдохнуть заслуженно :) Да и «фидбэки» (изменения в ТЗ) могут приходить во время работы над заказом.

                                                                        Да и «прототип» не совсем правильно будет употреблять к «стартапу», «прототип» делается для нескольких человек, максимум показать на «ивенте», его цель проверить идею (и, возможно, получить инвестиции, партнёра и т. п :) ) — многую функциональность на нём реализовывать совсем не желательно. Прототип далеко не то же самое, что даже закрытое альфа-тестирование. Второе подразумевает уже более-менее готовый продукт со всей инфраструктурой и функциональностью, переделывать который с нуля на другом языке/платформе станут, только если выявятся критические ошибки анализа, проектирования или выбора инструмента при проверке на реальных задачах. Например, если подразумевалось, что сервер какой-то конфигурации должен держать 1000 пользователей онлайн, а он с трудом 10 держит и явных узких мест нет. Тут надо всё бросать и переписывать на ассмеблере :)
                                                                        –6
                                                                        > На стадии проектирования важна не скорость работы приложения, а скорость его разработки, ибо время — деньги.

                                                                        Потрясающая глупость. Наверное благодаря такой логике мы имеем кучу глючных и тормозных программ. Зато разработчкам было удобно ее разрабатывать, это же главное. Кого волнует потом сколько ресурсов будет жрать система на облаке ежемесячно или какие требования к комьютерам пользователей она будет предьявлять.
                                                                        • UFO just landed and posted this here
                                                                            +1
                                                                            >Разработчики сейчас вынуждены думать о прибыли, а не об абстрактном качестве программы. Как сделать так, чтобы одно было пропорционально другому, остаётся загадкой.

                                                                            Просто, так же как и в других областях — платите за качество, не покупайте дерьмо ;)
                                                                            • UFO just landed and posted this here
                                                                            +3
                                                                            >Кого волнует потом сколько ресурсов будет жрать система на облаке ежемесячно или какие требования к комьютерам пользователей она будет предьявлять.

                                                                            Если вы заказчик — формируйте требования к быстродействию, ресурсам и т. п. в ТЗ (только приготовьтесь к тому, что платить, если требования жёсткие, придётся больше, за то, что разработчикам неудобно :) ). Если покупатель — голосуйте рублём (долларом, евро) за более разумные, по-вашему, варианты или станьте заказчиком/разработчиком, если таких вариантов нет.
                                                                            • UFO just landed and posted this here
                                                                                0
                                                                                Здесь дело не в требованиях и голосованиях рублем, а в индусском стиле мышления некоторых разработчиков (как у автора первоначального комментария). Срок разработки — это всего лишь один из параметров цены, неправильный выбор инструментов или архитектуры облегчая разработку в итоге делает дороже владение продуктом. В этом можно убедится подсчитав сколько нам приходило проектов написанных индусами на рефакторинг/переделку/итд. Оправдываясь тем что «предварительная оптимизация — это зло» разработчики максируют принципиальную неумение работать с алгоритмами, понимание архитектуры и инструментов. Я не на пустом месте это говорю, мне приходилось собеседовать людей которые не понимают сложности вставки элемента в какой-нибудь контейнер, оправдывая это тем что пока программа у него не тормозит это не важно.
                                                                              0
                                                                              «если ты можешь сделать хорошо — сделай это» по моему это сказал тот же автор…
                                                                                +1
                                                                                Если можешь сделать что-то хорошо — не делай это бесплатно (с) Joker
                                                                                0
                                                                                Вообще-то стадия проектирования это самое правильное место чтобы заботиться о скорости
                                                                                Полная фраза звучит так
                                                                                We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil
                                                                                Иначе — не нужно оптимизировать вещи, которые не нужно оптимизировать =)
                                                                                +20
                                                                                Браво. Мы выяснили, что компилируемые языки быстрее интерпретируемых.
                                                                                  +3
                                                                                  Мы выяснили, насколько именно быстрее. (хотя все эти цифры довольно условны)
                                                                                    +2
                                                                                    Они более чем условны, если тестировать на искусственных задачах.
                                                                                    • UFO just landed and posted this here
                                                                                        +2
                                                                                        Сферовакуумные тесты на сферовакуумных задачах.
                                                                                        +4
                                                                                        На самом деле довольно старый и изместный ресурс, но напомнить никогда не будет лишним.
                                                                                        Хороший материал по теме: блоггер-программист Guillaume Marceau проанализировал языки из clbg в некоторое подобие магического квадрата, выразительность vs. скорость. Очень наглядно.
                                                                                          0
                                                                                          * известный
                                                                                            +2
                                                                                            И гораздо ближе к реальности, чем shootout
                                                                                            +8
                                                                                            Работа, спору нет, проделана большая, и пиписькомер получился знатный.

                                                                                            Вот только есть кое-какие сомнения в подходе. Например, тест regex-dna.
                                                                                            На графике видно, что C++ выполняет его в четыре раза быстрее, чем Python.

                                                                                            При этом в исходниках просто берутся и подключаются библиотеки регеэкспов — для С++ это re2, которая построена на DFA, а для Питона — родная, NFA. А для DFA-регэкспов конструкция выбора (которая используется в дальнейшем) выполняется гораздо быстрее, чем для NFA.

                                                                                            Так что здесь они, извините, сравнивают хуй с трамвайной ручкой.

                                                                                            PS: бенчмарки re2 и PCRE
                                                                                            PPS: про re2 писали на Хабре

                                                                                              0
                                                                                              В контексте самих тестов такие отличия не имеют значения. Это скорее сравнение похожего в близкой к этому похожему среде. Как бы сравнивают слона с китом, не уточняя, что один в воде, а другой на суше, а просто показав скорость в привычной среде (т.е. с использованием или родных библиотек, или наиболее часто использованных, если нет родных).
                                                                                                +3
                                                                                                Какой контекст? Это все равно что сказать, что тест у нас — сортировка массива, написать на одном языке пузырек, а на другом — qsort, да еще и дать им соответственно худший и лучший случай.

                                                                                                К тому же, что менее важно, re2 — новая библиотека, ни в коем разе не является для С++ «родной» или «часто используемой». Пусть там заинклюдят pcre.h, вот тогда тест будет иметь ценность.
                                                                                                0
                                                                                                Ну так перептшите вариант на питоне с использованием другой библиотеки и пошлите им! Это же открытый проект, там выложены бенчмарки программ, которые просто кто то прислал.
                                                                                                Хотя там и говорится, что «Prefer plain vanilla programs — after all we're trying to compare language implementations not programmer effort and skill.» Это не значит, что даже выбирать разные алгоритмы для решения задачи нельзя.
                                                                                                0
                                                                                                Ресурс «The Computer Language Benchmarks Game» совершенно неадекватный. Вы видели какой там сверхоптимизированный код? Такого не бывает в продакшне. Конечно, возможность оптимизации это хорошая черта языка, но она как бы ортогональна общей производительности. Было бы неплохо, если бы там было 2 варинта каждой задачки: оптимизированный и влоб.
                                                                                                  +5
                                                                                                  Мне довелось поучаствовать в проекте на С++, для которого параллельно создавался аналогичный продукт только на Perl. Так скорость работы перлового проекта ничуть не уступала плюсовому. Есть целые классы задач, особенно в прикладном программировании, когда производительность упирается не в скорость вычислений и не в скорость работы с памятью, а в файловую систему, базу данных, локи. А когда на свет появляется монструозное чудо-юдо с кучей плагинов, состоящее из пачки серверов, и эти сервера интенсивно общаются друг с другом, так вообще пиши хоть на bash-е, хуже не будет.
                                                                                                    0
                                                                                                    А скорость разработки на perl и C++ была сравнима?
                                                                                                      0
                                                                                                      Да, сравнима. Насколько я понимаю, чем крупнее проект (а у нас был как раз крупный), тем сложнее писать на dynamic typing языках, а до тестов мы тогда ещё не додумались. Плюс для С++ был хорошо заточеный фреймворк. Вообще, мне кажется, скорость разработки (по крайней мере для веба) сильнее зависит от фреймворка, чем от самого языка. Руби, например, стал известен после появления на свет рельсов, т.е. после того как на нём стало реально удобно делать сайты.
                                                                                                      0
                                                                                                      Оригинальный совет :) Ходит байка что у разработчиков Eva-online как раз большие проблемы с серверами написаными на python, игроки которые жалуются на то что если в системе 50 человек то играть не возможно являются косвенным подтверждением, хотя мне сложно судить может именно в сеть и уперлись и там все равно с++ или perl, правда в том же WoW все хорошо.
                                                                                                        0
                                                                                                        Это не совет, а пример из жизни. Хочу просто сказать, что не всё так однозначно, мол если язык компилируемый, то всё будет очень быстро работать. Это далеко не всегда так.
                                                                                                      0
                                                                                                      Они бы ещё написали, что есть что.
                                                                                                      Например, что такое Java -Xint и Java steady state
                                                                                                        0
                                                                                                        Ага, разобрался. :)
                                                                                                        0
                                                                                                        ппц, целый сайт сварганили с бенчмарками непонятно чего и какой платформы.
                                                                                                        *nix? отлично. Какие именно компиляторы юзаются? какие настройки оптимизации? какие тесты проводятся?

                                                                                                        Особенно порадовало, что все это исключительно в пределах Ubuntu.
                                                                                                        Лично я бы переименовал топик в «Сравнение сред исполнения в Ubuntu»

                                                                                                        ИМХО.
                                                                                                          +1
                                                                                                          Компиляторы и настройки есть на индивидуальных страницах тестов в конце.
                                                                                                          shootout.alioth.debian.org/u32/program.php?test=regexdna&lang=gpp&id=2
                                                                                                            0
                                                                                                            и где там сравнение с другими компиляторами?
                                                                                                            кроме того, сравнивать компилятор одного языка с другим компилятором другого языка — это как сравнивать теплое с мягким.

                                                                                                            имхо ессно. возможно какой то смысл и есть. чисто для субъективной оценки
                                                                                                          +2
                                                                                                          А вы не задумывались, что сравнение «X в k раз быстрее Y» вас не волнует, на самом деле? Вас волнует только то, насколько это быстрее в абсолютных единицах, и как это соотносится с самым медленным куском вашей системы — обычно, обращением к диску или интернет-соединением?

                                                                                                          Нет никакого смысла вылизывать доли миллисекунд на тонком интерфейсе, если все равно основное время ожидания определяется исключительно тем, какой пинг до сервера.
                                                                                                            0
                                                                                                            Ну как бы (Y-медленный_кусок)*k+медленный_кусок даст нам оценку в абсолютных единицах. Да и если время ожидания определяется исключительно пингом до сервера, но при этом использование CPU сервера близко к 100%, а количество свободной памяти близко к нулю — самое время подумать (вернее осталось совсем чуть-чуть времени подумать), а чем оно будет определяться, когда количество запросов увеличится на 10, 100, 1000%?
                                                                                                              +1
                                                                                                              «Ну как бы (Y-медленный_кусок)*k+медленный_кусок даст нам оценку в абсолютных единицах.»
                                                                                                              Только все равно не покажет нам того, насколько в реальности важна потеря производительности на «скорости языка».

                                                                                                              «Да и если время ожидания определяется исключительно пингом до сервера, но при этом использование CPU сервера близко к 100%,»
                                                                                                              А вы не обратили внимания, что я пишу про интерфейс (т.е., клиент), а не сервер?

                                                                                                              В случае с сервером пример традиционно (собственно, это не я их придумывал, это из Эспозитовской книжки про enterprise architecture) другой: нет смысла оптимизировать бизнес-код, если время его выполнения пренебрежимо мало по сравнению со временем выборки нужных ему данных из СУБД.
                                                                                                                0
                                                                                                                >Только все равно не покажет нам того, насколько в реальности важна потеря производительности на «скорости языка».

                                                                                                                Разделить ещё на Y и получим относительную оценку прироста скорости при смене языка. Чем меньше k и больше медленный_кусок тем меньше смысла менять язык, обратное тоже верно.

                                                                                                                >А вы не обратили внимания, что я пишу про интерфейс (т.е., клиент), а не сервер?

                                                                                                                А что, интерфейсы (включая тонкие) у нас привилегия клиентов? O_o Или мы разных интерфейсах говорим? Я о программных, а не пользовательских

                                                                                                                >нет смысла оптимизировать бизнес-код, если время его выполнения пренебрежимо мало по сравнению со временем выборки нужных ему данных из СУБД.

                                                                                                                В том случае, если для нас критично время ответа, согласен. Но критично может быть, например, пиковое количество одновременно обрабатываемых запросов, а не время отклика на один из них (в разумных пределах, а иногда ответ и вообще не нужен, главное запрос не потерять), то есть сколько сервер приложений может сформировать запросов к тому серверу БД. И вот тут выигрыш миллисекунды на «скорости языка» (или масштабировании этого сервера) даёт 1000 дополнительных запросов в секунду, а там пускай хоть полдня их СУБД переваривает. Конечно, это прежде всего относится к запросам на добавление/обновление записей, а не на выборку их.
                                                                                                                  +1
                                                                                                                  «Я о программных, а не пользовательских»
                                                                                                                  Программный интерфейс не бывает тонким. Впрочем, да, надо было уточнить, что речь идет о клиенте.

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

                                                                                                                  В реальности всегда надо искать узкое место, и начинать с него. В современных системах язык таким местом оказывается приблизительно на последнем месте.
                                                                                                            +2
                                                                                                            Странно.

                                                                                                            Очень странно, что на 57 (на момент моего чтения) комментов все комментарии посвящены обсуждению скорости. В то время как бенчмарк — трёхкомпонентный, при этом сравнивает данные на четырёх разных архитектурах, и вряд ли хоть одна из возможностей этого сравнения менее интересна, чем другая.

                                                                                                            Например, на одной из страниц можно сравнить несколько языков визуально на предмет того, какие из них имеют какое соотношение лаконичности и производительности:


                                                                                                            Да-да, получается, что в боевой задаче хвалёный Хаскель не сильно-то лучше Джавы, и при этом проигрывает F#-у. Ну, или что на Ruby код получится компактнее и тормознее всех остальных, впрочем, мы другого ведь и не ждали, да?

                                                                                                            А можно открыть более подробные бенчмарки, с временами, и оценить, какой кровью (с точки зрения кода) и какого ускорения можно добиться при параллелизации алгоритма, или при переходе с 32 бит на 64, или оценить оверхеды по памяти каждого языка… Столько возможностей, а всех интересует банальная производительность.
                                                                                                              0
                                                                                                              Вообще-то, уважающие себя девелоперы на shootout даже не смотрят, потому что там:

                                                                                                              — непонятно, что сравнивается
                                                                                                              — реализация алгоритмов чаще всего длеко не на высоте
                                                                                                              — в 99.9999999% проект упрется в скорость I/O или в базу данных прежде, чем он упрется в ограничения языка

                                                                                                                +3
                                                                                                                «многим менеджерам и руководителям проектов подобный ресурс попросту не известен, но может быть крайне необходим на стадии планирования проекта и позволит объективно принимать решения хватит им PHP или лучше сразу на java делать проект. А может и вовсе на C++. „
                                                                                                                Так вот, менеджерам и руководителям проекта туда смотреть не надо, они все равно ничего не поймут. Зато сделают вывод “такой-то язык — быстрее, надо разрабатывать на нем».

                                                                                                                В то время как исходить надо из совсем других вещей — например, доступности ресурсов или возможностей платформы или совместимости со старым кодом…
                                                                                                                  0
                                                                                                                  а где Groovy?
                                                                                                                    0
                                                                                                                    Странный заголовок, IMHO язык программирования не имеет такой характеристики как скорость, интерпретатор/компилятор/контейнер — да.
                                                                                                                      +1
                                                                                                                      Сложный вопрос. Некоторые языки имеют только одну реализацию интерпретатора/компилятора и фактически язык неотделим от компилятора/интерпретатора, поэтому производительность приложения будет ограниченна фактически языком, т.к. с интерпретатором/компилятором они одно целое… С другой стороны возьмите Scala и Java… Вроде бы обе работают на JVM, но именно конструктивные особенности каждого из языков будут давать изменения в производительности. К примеру, я для себя в последнее время заметил, что интерпретируемые функциональные языки по скорости часто догоняют императивные компилируемые… И моё субъективное имхо — не спроста это. :) Т.е. используемые в императивных языках техники обработки кода в чём-то не эффективны в сравнении результирующим кодом функциональных языках (я не силён в компиляторах, но возможно функциональные языки легче оптимизируются?). Но сразу честно скажу — это только поверхностные наблюдения, т.к. я серьёзно не использовал ни один функциональный язык. :) Возможно я заблуждаюсь :)
                                                                                                                      0
                                                                                                                      Простите, я не до конца понял из текста заметки, Python запускали с psycho?
                                                                                                                        0
                                                                                                                        Простите, но вот, мой крик души по теме Language Shootout

                                                                                                                        Only users with full accounts can post comments. Log in, please.