Я беру паузу в моём обсуждении asyncio в Python, чтобы поговорить о скорости Python. Позвольте представиться, я — ярый поклонник Python, и использую его везде, где только удаётся. Одна из причин, почему люди выступают против этого языка, — то, что он медленный. Некоторые отказываются даже попробовать на нём поработать лишь из-за того, что «X быстрее». Вот мои мысли на этот счёт.
Производительность более не важна
Раньше программы выполнялись очень долго. Ресурсы процессора и памяти были дорогими, и время работы было важным показателем. А уж сколько платили за электричество! Однако, те времена давно прошли, потому что главное правило гласит:
Оптимизируйте использование своих самых дорогих ресурсов.Исторически самым дорогим было процессорное время. Именно к этому подводят при изучению информатики, фокусируясь на эффективности различных алгоритмов. Увы, это уже не так — железо сейчас дёшево как никогда, а вслед за ним и время выполнения становится всё дешевле. Самым дорогим же становится время сотрудника, то есть вас. Гораздо важнее решить задачу, нежели ускорить выполнение программы. Повторюсь для тех, кто просто пролистывает статью:
Гораздо важнее решить задачу, нежели ускорить выполнение программы.
Вы можете возразить: «В моей компании заботятся о скорости. Я создаю веб-приложение, в котором все ответы приходят меньше, чем за x миллисекунд» или «от нас уходили клиенты, потому что считали наше приложение слишком медленным». Я не говорю, что скорость работы не важна совсем, я хочу лишь сказать, что она перестала быть самой важной; это уже не самый дорогой ваш ресурс.
Скорость — единственная вещь, которая имеет значение.
Когда вы употребляете слово «скорость» в контексте программирования, скорей всего вы подразумеваете производительность CPU. Но когда ваш CEO употребляет его применительно к программированию, то он подразумевает скорость бизнеса. Самая главная метрика — время выхода на рынок. В конечном счёте неважно насколько быстро работают ваши продукты, не важно на каком языке программирования они написаны или сколько требуется ресурсов для их работы. Единственная вещь, которая заставит вашу компанию выжить или умереть, — это время выхода на рынок. Я говорю больше не о том, насколько быстро идея начнёт приносить доход, а о том, как быстро вы сможете выпустить первую версию продукта. Единственный способ выжить в бизнесе — развиваться быстрее, чем конкуренты. Неважно, сколько у вас идей, если конкуренты реализуют их быстрее. Вы должны быть первыми на рынке, ну или как минимум не отставать. Чуть затормозитесь — и погибните.
Единственный способ выжить в бизнесе — развиваться быстрее, чем конкуренты.
Поговорим о микросервисах
Крупные компании, такие как Amazon, Google или Netflix, понимают важность быстрого развития. Они специально строят свой бизнес так, чтобы быстро вводить инновации. Микросервисы помогают им в этом. Эта статья не имеет никакого отношения к тому, следует ли вам строить на них свою архитектуру, но, по крайней мере, согласитесь с тем, что Amazon и Google должны их использовать. Микросервисы медленны по своей сути. Сама их концепция заключается в том, чтобы использовать сетевые вызовы. Иными словами, вместо вызова функции вы отправляетесь гулять по сети. Что может быть хуже с точки зрения производительности?! Сетевые вызовы очень медленны по сравнению с тактами процессора. Однако, большие компании по-прежнему предпочитают строить архитектуру на основе микросервисов. Я действительно не знаю, что может быть медленнее. Самый большой минус такого подхода — производительность, в то время как плюсом будет время выхода на рынок. Создавая команды вокруг небольших проектов и кодовых баз, компания может проводить итерации и вводить инновации намного быстрее. Мы видим, что даже очень крупные компании заботятся о времени выхода на рынок, а не только стартапы.Процессор не является вашим узким местом
Если вы пишете сетевое приложение, такое как веб-сервер, скорее всего, процессор не является узким местом вашего приложения. В процессе обработки запроса будет сделано несколько сетевых обращений, например, к базе данных или кешу. Эти сервера могут быть сколь угодно быстрыми, но всё упрётся в скорость передачи данных по сети. Вот действительно классная статья, в которой сравнивается время выполнения каждой операции. В ней автор считает за один такт процессора одну секунду. В таком случае запрос из Калифорнии в Нью-Йорк растянется на 4 года. Вот такая вот сеть медленная. Для примерных расчётов предположим, что передача данных по сети внутри датацентра занимает около 3 мс, что эквивалентно 3 месяцам по нашей шкале отсчёта. Теперь возьмём программу, которая нагружает CPU. Допустим, ей надо 100 000 циклов, чтобы обработать один вызов, это будет эквивалентно 1 дню. Предположим, что мы пишем на языке, который в 5 раз медленнее — это займёт 5 дней. Для тех, кто готов ждать 3 месяца, разница в 4 дня уже не так важна.
В конечном счёте то, что python медленный, уже не имеет значения. Скорость языка (или процессорного времени) почти никогда не является проблемой. Google описал это в своём исследовании. А там, между прочим, говорится о разработке высокопроизводительной системы. В заключении приходят к следующему выводу:
Решение использовать интерпретируемый язык программирования в высокопроизводительных приложениях может быть парадоксальным, но мы столкнулись с тем, что CPU редко когда является сдерживающим фактором; выразительность языка означает, что большинство программ невелики и большую часть времени тратят на ввод-вывод, а не на собственный код. Более того, гибкость интерпретируемой реализации была полезной, как в простоте экспериментов на лингвистическом уровне, так и в предоставлении нам возможности исследовать способы распределения вычислений на многих машинах.
Другими словами:
CPU редко когда является сдерживающим фактором.
Что, если мы всё-таки упираемся в CPU?
Что насчёт таких аргументов: «Всё это прекрасно, но что, если CPU становится узким местом и это начинает сказываться на производительности?» или «Язык x менее требователен к железу, нежели y»? Они тоже имеют место быть, однако вы можете масштабировать приложение горизонтально бесконечно. Просто добавьте серверов, и сервис будет работать быстрее :) Без сомнения, Python более требователен к железу, чем тот же C, но стоимость нового сервера гораздо меньше стоимости вашего времени. То есть дешевле будет докупить ресурсов, а не бросаться каждый раз что-то оптимизировать.
Так что, Python быстрый?
На протяжении всей статьи я твердил, что самое важное — время разработчика. Таким образом, остается открытым вопрос: быстрее ли Python языка X во время разработки? Смешно, но я, Google и кое-кто ещё, могут подтвердить насколько продуктивен Python. Он скрывает так много вещей от вас, помогая сосредоточиться на основной вашей задаче и не отвлекаясь на всякие мелочи. Давайте рассмотрим некоторые примеры из жизни.
По большей части все споры вокруг производительности Python скатываются к сравнению динамической и статической типизации. Думаю, все согласятся, что статически типизированные языки менее продуктивны, но на всякий случай вот хорошая статья, объясняющая почему. Что касается непосредственно Python, то есть хороший отчёт об исследовании, в котором рассматривается, сколько времени потребовалось, чтобы написать код для обработки строк на разных языках.
В представленном выше исследовании Python более чем в 2 раза продуктивнее Java. Многие другие также языки программирования дают похожий результат. Rosetta Code провёл довольно обширное исследование различий изучения языков программирования. В статье они сравнивают python с другими интерпретируемыми языками и заявляют:
Python, в целом, наиболее краток, даже в сравнении с функциональными языками (в среднем в 1,2-1,6 раза короче).
По-видимому, в реализации на Python будет как правило меньше строк кода, чем на каком-либо другом языке. Это может показаться ужасной метрикой, однако несколько исследований, в том числе и упомянутых выше, показывают, что время, затраченное на каждую строку кода, примерно одинаково на каждом языке. Таким образом, чем меньше строк кода, тем больше продуктивность. Даже сам codinghorror (программист на C#) написал статью о том, что Python более продуктивен.
Я думаю, будет справедливо сказать, что Python более продуктивен, чем многие другие языки программирования. В основном это связано с тем, что он поставляется «с батарейками», а также имеет множество сторонних библиотек на все случаи жизни. Вот небольшая статья, сравнивающая Python и X. Если вы мне не верите, можете сами убедиться насколько этот язык программирования прост и удобен. Вот ваша первая программа:
import __hello__Но что, если скорость действительно важна?
Мои рассуждения выше могли сложить мнение, что оптимизация и скорость выполнения программы вообще не имеют значения. Во многих случаях это не так. Например, у вас есть веб-приложение и некоторый endpoint, который уж очень тормозит. У вас могут быть даже определённые требования на этот счёт. Наш пример строится на некоторых предположениях:
- есть некоторый endpoint, который выполняется медленно
- есть некоторые метрики, определяющие насколько медленными может быть обработка запросов
Мы не будем заниматься микро-оптимизацией всего приложения. Всё должно быть «достаточно быстро». Ваши пользователи могут заметить, если обработка запроса занимает секунды, но они никогда не заметят разницу между 35 мс и 25 мс. Вам нужно лишь сделать приложение «достаточно хорошим».
Чтобы понять как оптимизировать, мы должны сначала понять что именно надо оптимизировать. В конце концов:
Любые улучшения, сделанные где-либо помимо узкого места, являются иллюзией. — Джин Ким.
Если оптимизация не устраняет узкого места приложения, то вы просто потратите впустую своё время и не решите реальную проблему. Вы не должны продолжать разработку, пока не исправите тормоза. Если вы пытаетесь оптимизировать нечто, не зная конкретно что, то вряд ли результат вас удовлетворит. Это и называется «преждевременной оптимизацией» — улучшение производительности без каких-либо метрик. Д. Кнуту часто приписывают следующую цитату, хотя он утверждает, что она не его:
Преждевременная оптимизация — корень всех зол.Если быть точным, то более полная цитата:
Мы должны забыть об эффективности, скажем, на 97% времени: преждевременная оптимизация — корень всех зол. Однако мы не должны упускать наши возможности в этих критических 3%.
Другими словами, здесь говорится, что большую часть времени вам не нужно думать об оптимизации. Код и так хорош :) А в случае, когда это не так, нужно переписать не более 3% Вас никто не похвалит, если вы сделаете обработку запроса на несколько наносекунд быстрее. Оптимизируйте то, что поддаётся измерению.
Преждевременная оптимизация, как правило, заключается в вызове более быстрых методов <прим пер. видимо, подразумеваются ассемблерные вставки> или использовании специфичных структур данных из-за их внутренней реализации. В университете нас учили, что если два алгоритма имеют одну асимптотику Big-O, то они эквивалентны. Даже если один из них в 2 раза медленнее. Компьютеры сейчас настолько быстры, что вычислительную сложность пора измерять на большом количестве данных. То есть, если у вас есть две функции O(log n), но одна в два раза медленнее другой, то это не имеет большого значения. По мере увеличения размера данных они обе начинают показывать примерно одно и то же время выполнения. Вот почему преждевременная оптимизация — это корень всего зла; Это тратит наше время и практически никогда не помогает нашей общей производительности.
В терминах Big-O все языки программирования имеют сложность O(n), где n — кол-во строк кода или инструкций. Не имеет значения, насколько медленным будет язык или его виртуальная машина — все они имеют общую асимптоту. <прим. пер. автор имеет ввиду, что даже если сейчас язык X в два раза медленнее Y, то в будущем после оптимизаций они будут примерно равны по скорости> В соответствии с этим рассуждением можно сказать, что «быстрый» язык программирования всего лишь преждевременно оптимизированный, причём непонятно по каким метрикам.
Оптимизируя Python
Что мне нравится в Python, так это то, что он позволяет оптимизировать небольшой участок кода за раз. Допустим, у вас есть метод на Python, который вы считаете своим узким местом. Вы оптимизировали его несколько раз, возможно, следуя советам отсюда и отсюда, и теперь пришли к выводу, что уже сам Python является узким местом. Но он имеет возможность вызова кода на C, а это означает, что вы можете переписать этот метод на C, чтобы уменьшить проблему с производительностью. Вы без проблем можете использовать этот метод вместе с остальным кодом.
Это позволяет писать хорошо оптимизированные методы узких мест на любом языке, который компилируется в ассемблерный код, то есть вы продолжаете писать на Python большую часть времени и переходите к низкоуровневому программированию лишь вам это действительно нужно.
Существует также язык Cython, который является надмножеством Python. Он представляет из себя смесь с типизированным C. Любой код Python является также валидным кодом и на Cython, который транслируется в C. Вы можете смешивать типы C и утиную типизацию. Используя Cython, вы получаете прирост производительности только в узком месте, не переписывая весь остальной код. Так делает, например, EVE Online. Эта MMoRPG использует только Python и Cython для всего стека, проводя оптимизацию только там, где это требуется. Кроме того, есть и другие способы. Например, PyPy — реализация JIT Python, которая может дать вам значительное ускорение во время выполнения долгоживущих приложений (например, веб-сервера), просто путем замены CPython (реализация по умолчанию) на PyPy.
Итак, основные моменты:
- оптимизируйте использование самого дорогого ресурса — то есть вас, а не компьютера;
- выбирайте язык/фреймворк/архитектуру, которая позволяет вам разрабатывать продукты как можно быстрее. Не стоит выбирать язык программирования лишь потому, что программы на нём работают быстро;
- если у вас проблемы с производительностью — определите, где именно;
- и, скорее всего, это не ресурсы процессора или Python;
- если это всё же Python (и вы уже оптимизировали алгоритм), реализуйте проблемное место на Cython/C;
- и побыстрее возвращайтесь к основной работе.
Спасибо за внимание!
Комментарии (211)
Dimash2
02.06.2017 09:18+6Подправьте меня пожалуйста. Что если аренда сервера стоит 250$, и мы добавляем второй, вместо оптимизации, то это 500$. 6000$ каждый год, Программиста можно уволить или перевести на другой проект, а расходы останутся, а кто эти два сервера будет администрировать? Админу теперь вместо 1, надо администрировтать 2 сервера.
А что буде тесли 1 сервер упадет? (Риторический вопрос)
Это все сказки, что железо дешевое работы программиста, программисты разные и железо разное, если мы считаем VPS по 10-50 долларов в месяц и Senior с окладом 4000$ в месяц, то да, но если сервер стоит хотябы 250$, то тут другая история.
— Более того, я не согласен про скорость, понятие скорости очень размыто и зависит от прокладки. Такое ощущение, что каждая новая работа — это чистый лист. Потратил на 4000$ больше, зато экономишь каждый год 3000$, а это 15000$ за 5 лет
TyVik
02.06.2017 09:31+1Уверен, что в компании, которая нуждается в серверах m4.2xlarge (а это 32Gb RAM и стоят они всего $2000/год), зарплаты программистов гораздо больше $4000/mo. К тому же я б разбил такой сервис на кучу маленьких серверов и засунул в autoscale группу — удобнее будет и спокойнее по ночам. Ну и ещё раз повторюсь — оптимизации никто не отменял, но это работа с высокими рисками по времени (может занять день, а может и неделю), так что лучше её проводить в спокойное время.
Dimash2
02.06.2017 09:37Уверен — не аргумент, вы так уверенно считаете чужие деньги ) Проекты очень разные, даже там где есть деньги, есть автоматические скрипты, которые не требуют суппорта годами. А есть проекты, где денег мало, клиентов мало, но данных очень много.
А что делать, если данные ждут сначала жесткий или SSD, а потом приходится еще и проц ждать )
JekaMas
02.06.2017 09:47+2Про зарплаты — это не так. Достаточно вспомнить те же зарплаты в яндексе, которые несколько ниже рыночного уровня.
В больших компаниях спокойного времени часто не бывает вовсе: всегда есть горящая кампания, выход на новый рынок, развитие нового направления, мега-важная бизнес задача. По сути просто выше планка минимального приемлимого уровня по производительности.
С aws и большими компаниями тоже неоднозначно. Не дешевое оно удовольствие в highload: когда счета переваливают за тысячи в день, и когда понимаешь, что отсутствие возможности лично решать проблемы со связью — это задержки в недели и месяцы в важных задачах, а если вот прямо сейчас идут сотни и тысячи заказов в секунду… Все приходят к своим дц в итоге. И своей поддержке. И мы возвращаемся к вопросу оптимизации издержек на железо и поддержку.
worldmind
02.06.2017 21:55> Программиста можно уволить или перевести на другой проект
это только в сказочном мире так бывает, обычно программистов нужно всё больше если проект живёт, а если не живёт, то и сервера будут не нужны
> Админу теперь вместо 1, надо администрировтать 2 сервера.
для нормального админа разницы нет, сервера то типовые, хоть 50
Dimash2
02.06.2017 09:32+1Замерил я производительность для своей задачи.
1 млн объектов в массива + легкая арифметика заняли около 30 секунд на Python и 11 секунд на php7, NodeJS и C = 9 секунд.
Убедительная прозьба не лошить на замеры, замеры сделаны аматорки, был написал 1 алгоритм на всех языках и запускались из под консоли не для точных замеров, а для быстро решения в чем массив обрабатывать.
Так вот, 20 секунд разницы против тоже простого, но более уродливого языка.
на 100 000 000 — это уже 2000 секунд, что есть 30 минут. Откуда берутся 100 млн циклы? Это когда у вас вложеные циклы. Вложеные циклы плохо? Ну а что делать, если задача брать 1 обхект из массива, у которого например 20 полей, проверять каждое поле по определенным патеррнам и тд (безумловно много чего было придумано для уменьшенитя этих итераций, но суть остается)Dimash2
02.06.2017 09:45-2Чтобы убрать эти 30 минут, мне надо докупить еще 1 сервер за 500$, именно столько стоит текущий, мне этого делать не хочется, а я не корпоративная компания монстр с огроными бюджетами, а задача такая есть. И я не вижу разницы в скорости разработки между Python, NodeJS, php, можете объяснить где же это узкое место.
На конференциях везде проталкивают Джанго, как джина с батарейками, где все есть и ничего делать не нужно.rodgar
02.06.2017 09:49+5Бизнес-логику писать на python, а критичные числодробилки переписывать на C. Об этом и статья. Из личного опыта, за 5 лет пришлось написать два экстеншена на чистом C. И что, из-за двух мест писать весь продукт, например, на Java? И потерять на этом пару десятков человеко-лет?
Если эта числодробилка и есть весь ваш проект, то безусловно, выбираем язык под потребности. Но, мне кажется, есть много всего вокруг этого алгоритма: пользовательские интерфейсы, API и т.д. Их тоже обязательно писать на супер-быстром языке, жертвуя своей производительностью? Python как раз дает такую гибкость.
Поводом выбрать Java может быть наличие статических анализиторов кода, широкое сообщество, кол-во доступных разработчиков на рынке, особенности продукта. Но точно не скорость работы языка как такового.
JekaMas
02.06.2017 09:52Узкое место есть, просто оно дальше. В большинстве же небольших проектов оно в язык вряд ли упрется, разве что в вопрос, на каком языке лучше и шуствее код писать и поддерживать, то есть в первую очередь, читать, в том числе и новичками.
seleznev_nvkz
02.06.2017 11:50+1Подобные числодробилки и пишутся на Cython, о чем говорится в статье (и о чем говорил Гвидо).
Для примера вот вычисление чисел Фибоначчи на Python и Cython:
Pythondef fib(n): a, b = 1, 1 for i in range(n): a, b = a + b, a return a %timeit fib(1000) 10000 loops, best of 3: 104 µs per loopsbagan
02.06.2017 18:24Справедливости ради стоит отметить, что целые числа в python — с абсолютной точностью(не ограничены по размеру), а значит сравнивать сложение их со сложением double совсем не корректно(потому что чем больше числа тем сложнее их складывать) подкорректировал чтоб считать модуль по большому простому числу каждый раз:
PythonIn [11]: def fib(n): ....: p = 10**9 + 7 ....: a, b = 1, 1 ....: for i in range(n): ....: a, b = (a+b)%p, a ....: return a In [12]: %timeit fib(1000) 10000 loops, best of 3: 58.5 µs per loopNepherhotep
04.06.2017 10:55+1Ваш пример станет работать в 2..3 раза быстрее, если отключить zero division error специальным декоратором:
import cython @cython.cdivision(True) def cfib(int n): cdef int p=10**9 + 7 cdef int i cdef int a=1, b=1 for i in range(n): a, b = (a+b)%p, a return a
До отключения
После отключения
danforth
03.06.2017 08:11Почему в Cython 1000000 loops а в Python 10000 loops, при этом n что там что там 1000?
splav_asv
03.06.2017 09:30Для уменьшения погрешности. %timeit автоматически выбирает количество итераций чтобы суммарное время исполнения было выше некоторого порога. n это номер числа. Он влияет на количество итераций только косвенно, через время одной итерации.
arvitaly
02.06.2017 09:52Зачем сравнивать C и Python, сравнивайте современные развивающиеся языки, которые намного быстрее, а во многом и удобнее питона.
И разница в серверах (а значит и всей инфраструктуре) может быть на порядки, если задача выполняется не в 2 раза медленнее, а в 100.rodgar
02.06.2017 10:04+3Топ языков по исследованию SO: JavaScript, SQL, Java, C#, Python, PHP, C++, C. Все они стартовали в прошлом тысячелетии. И все они современные и развивающиеся, ИМХО.
tmnhy
02.06.2017 10:06+1ачем сравнивать C и Python, сравнивайте современные развивающиеся языки
Вы, даже если не сравнили, то хотя бы перечислили какие именно и для чего предлагагаете сравнивать.
PetrPetrowitch
02.06.2017 11:01В точку! автор прав, но это справедливо только для некоторой части рынка.
Но к сожелению это не относится к одной из самых крупных индустрий — игровой. Там проблемы с оптимизацией, которые последнее время стали бичем ААА проектов, равносилен провалу и убыткам.
bak
02.06.2017 20:51Для геймдева это точно так же справедливо, и питон там вполне успешно используется, в том числе и в AAA проектах.
AlexKbit
02.06.2017 11:01+2ИМХО статья несколько найвна, всё зависит от задачи.
Архитектура приложения и технологии выбираются исходя из постановки задачи и требований.
Если вам нужно приложение в короткие сроки ваш заказчик должен понимать чем он рискует и какие возможности буду ущемлены.
Другое дело если заказчик ставит изначально целью высоконагруженную систему которой точно будут пользоваться милионы пользователей. Для таких случаев систему требуется проектировать по другому и использовать другие технологии для возможностей горизонтального и вертикального маштабирования.
А Python отлично занимает свою нишу среди других ЯП и справляется со своими задачами в сферах big data & machine learning. Сравнивать его с другими ЯП как сравнивать молоток и ножницы.
bogolt
03.06.2017 14:13+1> найвна
Как вы это произносите?
Добавлю в коллекцию к андройду, гиперболойду, Тайланду, таблойду, гуманойду…DistortNeo
03.06.2017 15:28Тайланд, кстати, в этом списке лишний, потому что, в отличие от остальных слов, произносится именно с краткой и, как, например, в "не делай". До кучи, слова "тайцы", "тайский" пишут именно с "й".
Gorthauer87
02.06.2017 11:04+3Расскажите эти сказки производителям батареек. Они очень порадуются и расскажут как увеличить их емкость в сто раз.
isisTance
02.06.2017 11:31Да, питон медленный, но иногда(давненько на хабре видел) питоп побыстрее плюсов. Но это редкость)
Dark_Daiver
03.06.2017 11:34А можно ссылку? Прям даже интересно
evocatus
03.06.2017 13:38+1Питон относительно медленно работает с простыми объектами типа чисел, но относительно быстро со сложными — хэш-таблицы и т.д. А множество встроенных функций для их обработки (всякие сортировки, поиски, слияния и пр.) написаны на C людьми, которые в этом разбираются гораздо лучше среднего C/C++ программиста, чья кастомная реализация наверняка будет медленнее. Что не отменяет того факта, что для C/C++ уже полно библиотек, которые делают то же самое.
evocatus
03.06.2017 13:58А ещё Python уже давно двигается в сторону ленивых вычислений везде, где это оправдано. Это один из поводов переходить на Py3.
Dark_Daiver
03.06.2017 17:01+1Но ведь это не совсем «но иногда(давненько на хабре видел) питоп побыстрее плюсов».
evocatus
03.06.2017 23:52Я помню такую статью. Насколько я помню автор написал два файла на Си. В одном объявлялась функция для сложения двух чисел int, а во втором вызывалась. И аналогичный код на Python. И засчёт того, что компилятор Си анализирует файлы только по отдельности, питоновская версия получалась быстрее. Но точно не помню.
Dark_Daiver
03.06.2017 23:54Ага, я кажется видел что-то подобное но связанное с PyPy (возможно даже в их блоге).
Но это ведь спекуляция, по сути? Если дать компилятору заинлайнить ф-ию, то сишная версия будет как минимум так же быстра.
DistortNeo
03.06.2017 17:31Да, такое бывает в случае, когда Python используется просто как обёртка над вылизанной и оптимизированной нативной библиотекой, то есть скорость выполнения зависит не от скорости интерпретации Python, а от производительности библиотеки.
Если для выполнения одной и той же операции C++ программист будет использовать более медленную библиотеку, то в данном случае код на Python будет более быстрым.
Пример: библиотеки для работы с регулярными выражениями. Стандартная библиотека C++ в этом отношении очень медленная, поэтому её обходят все, кому не лень.
AoD314
02.06.2017 11:43Разработка на python действительно достаточная быстрая. Недостаток в производительности компенсирую за счет pyopencl(заодно можно запускаться на GPU).
bigfatbrowncat
02.06.2017 11:54Время на решение задачи на C меньше, чем на Java (и C++)?
Это что за задача такая? Задачу в студию! Хочу ознакомиться и лично сравнить.GarryC
02.06.2017 12:41Вопрос не в задаче, я думаю, вопрос в решении.
Если Вы вместо строки на С типа
if (A>B) do_something(); else do_other();
начнете создавать класс для A и делать у него перегруженный метод сравнения, одним из вариантов будет выше приведенное выражение, то да, время на подобные экзерсисы уйдет больше.
Недавно был диспут на подобную тему в ответ на заявление «Ну тут нужна фабрика ....».
oYASo
03.06.2017 02:05Это все хрень, которую зачем-то проталкивают вот такие авторы статей. У любого уважающего себя программиста на любом языке программирования есть инструментарий, с помощью которого он может быстро решить типичный набор задач. Никто не будет писать свой класс строки на плюсах, несмотря даже на то, что в стандартной либе поддержка так себе.
Мне кажется, отлично все эти споры разруливает Геннадий Короткевич под ником tourist, почти что ежегодный победитель соревнований Яндекс.Алгоритм, Google Code Jam и многих других. А фишка в том, что они пишет везде, где возможно, на Pascal. Хотя казалось бы.
Dsvolkov
07.06.2017 19:17Ну как бы задача решения олимпиадных задач и задача промышленного программирования — это очень разные вещи. В олимпиадных задачах обычно не так много кода, довольно много работы с числами и жесткий лимит времени выполнения кода при выходе за который задача не засчитывается. А заниматься переписыванием узких мест на компилируемый язык просто нет времени, потому что решить надо всё как можно быстрее. Это не очень похоже на то, с чем обычно приходится сталкиваться в реальной жизни
fly_style
07.06.2017 23:11Начнем с того, что в проде надо писать читаемый и поддерживаемый код. На олипмиаде быренько набросал алгоритм и заслал. Зашло — супер, не зашло — фиксим и сдаем.
Но согласитесь, навыки прокаченого пресловутого problem solving skill помогает в продакшене.Dsvolkov
07.06.2017 23:17Навыки помогают, кто ж спорит, но речь-то о другом — о выборе языка. Я про то, что пример Туриста и его языков для олимпиады мало показателен для прода
intsurfer
02.06.2017 12:15Вопрос в решаемой задаче. Если внешнее устройство типа онлайн-кассы отвечает с задержкой в секунду, то нет никакого смысла бороться за доли секунды. Питона+GTK3 хватает за глаза.
saluev
02.06.2017 15:24У онлайн-кассы есть другая проблема — надёжность. Я бы не стал использовать Python, когда нужны какие-то реальные гарантии.
saw_tooth
02.06.2017 15:40То есть питон, менее надежен чем любой другой язык?
nolled
02.06.2017 15:44+7Динамическая типизация это + N багов отлавливаемых только во время выполнения.
saw_tooth
02.06.2017 16:10-4То есть в установке неверного типа, виноват язык а не программист, который позволил неверному типу в то или иное место программы?
Второй момент, типизация хоть и динамическая но сильная, и поэтому все баги с типами которые Вы описываете, целиком и полностью вина программистов… у нас тут массивы с числами не складывают.DistortNeo
03.06.2017 01:20+5Виноват программист, но в языках со статической типизацией ошибка вылезет в худшем случае на этапе компиляции, а вообще IDE сама подскажет, что с кодом что-то не так.
bogolt
03.06.2017 14:26Нужно решить задачу, а не разобраться на кого возложить вину. В типизированных языках на этапе компиляции можно отсеять кучу явных багов.
saluev
02.06.2017 16:52+1Я не могу сказать про любой. Я про C/C++. На этих языках вы, приложив некоторые усилия, можете написать ПО, предъявляющее какие-то гарантии времени выполнения (в пределах, допустимых операционной системой и железом). На питоне заниматься системным программированием тоже можно, но подводных камней и ограничений слишком много.
saw_tooth
02.06.2017 17:13Если под надежностью Вы подразумеваете время отклика онлайн кассы, в пределах опять таки железа, то тут ни Си ни любой другой язык не сможет этого обеспечить, из за присутствия сети между терминалами.
Второй момент, с которым я солидарен с автором, что критический участок можно переписать на Си/ASM и прочее, но зачем простите писать на Си бизнес логику? Или например UI? При умеренных количествах Python может реализовать отличный UI, при очень скромных затратах на разработку.
В целом, думаю данный разговор можно свести к утверждению «на каждую задачу — свой инструмент», но мне кажется, утверждать без контекста что питон — ненадежен, это реально преувеличенно и совершенно неверно.saluev
02.06.2017 17:39+1Я не про время отклика. В питоне довольно трудно писать адекватные обработчики сигналов, особенно когда начинается мультитрединг/мультипроцессинг и всё в таком духе. В стандартной библиотеке все модули работают на глобальных локах, так что элементарное логирование может повесить программу и убить логику завершения транзакции, например.
dbagaev
07.06.2017 00:50А почему бы не запускать UI в одном-двух потоках, а все остальное написать на С/С++ и пусть себе работает в многих потоках, посылая сообщения в UI? Я никогда не писал на питоне UI больше пары полей ввода, но вдруг стало интересно, насколько возможно в нем создать сложный асинхронный интерфейс к многопоточному приложению.
DistortNeo
07.06.2017 01:17+1Мне кажется, что Python для UI — не лучший выбор. Если речь идёт исключительно об UI, то почему бы не использовать для этого более удобные средства, да хоть те же WinForms?
Antervis
07.06.2017 05:38потому что это win forms
DistortNeo
07.06.2017 14:15Ну на Java можно написать, если религия того просит.
А если речь об энтерпрайзе, то там ОС — всего лишь инструмент.
saluev
07.06.2017 10:58Ну как раз-таки UI я бы предпочёл писать на Питоне. Другое дело, что годных библиотек для этого как-то не видно на горизонте, но если бы они были, уверен, Питон бы отлично справился.
DistortNeo
07.06.2017 14:17А почему, если не секрет? Никаких причин, кроме как незнания другого языка/технологий, я здесь не вижу.
saluev
07.06.2017 14:51Ну, высокоуровневый язык, как минимум удобно обработчики событий писать.
DistortNeo
07.06.2017 15:50Верно, но ровно то тех пор, пока не придётся бодаться с многопоточностью и асинхронностью.
splav_asv
07.06.2017 21:34Если всё, кроме ui живёт в отдельных потока с отпущенным GIL, то почему нет (с тем же PyQt например). Отлично всё работает, даже довольно шустро, сам пользовался.
dbagaev
06.06.2017 22:38+2Мой опыт пока что показывает, что предоставление гарантий в одном месте приводят к их исчезновению в другом. Да, в питоне можно намудрить с типами, но в результате обработать исключение и восстановить процесс выполнения. В С можно намудрить с памятью-указателями, разыменовать null и получить необрабатываемый Access Violation. Умные указатели помогают, но всегда находится другой метод намудрить, источник багов воистину неиссякаем.
Хотя в том, что Pytjon не самый подходящий язык для системных задач — я полностью согласен. Но мы вроде бы и не про них сейчас.
vics001
02.06.2017 12:34Графики, конечно, это да. Наверное, брался срез среди каких-то ученых, которым писать на Perl, Python быстрее чем на Java/.Net. Все соревнования показывают, что практически код одинаково пишется на всех языках С++, Java, Pascal (если умеешь писать конечно). По себе могу сказать, что пишу код быстрее, чем на python и чем другие пишут на питоне, правда, они вообще очень медленно пишут на Java. Знаю людей, которые еще быстрее пишут на С++.
Вброс про производительность против продуктивности не засчитан. Выучи язык и пиши на нем, если человек выучил только питон, то это его трудности.drafterleo
02.06.2017 13:08А если человек выучил и Питон, и C++? :)
TargetSan
02.06.2017 19:38+6Вы не поверите, на питоне я буду писать скрипты не более 500 строк (примерно естественно). После этого объёма я возьму компилятор, бьющий по рукам хоть немного. Потому что в динамике любой мало-мальски объёмный рефакторинг — боль.
drafterleo
03.06.2017 14:24Отчего же, охотно верю. Но это отражает удобный Вам подход к разработке. Я, например, прежде чем кодить собственно проект, пишу много маленьких эскизов-черновичков, в которых решаются-проверяются-тестируются частные задачи-идеи-библиотеки, предположительно необходимые для реализации проекта. А потом вспоминаю паттерны проектирования и пишу большое полотно с учётом общей картины (видение которой как раз формируется на эскизном этапе). Причём подобным образом работаю и на С++ и на Питоне (надо ли говорить, что на Питоне в таком стиле работать удобней). Кстати, в последнее время стал замечать, что «большое полотно» всё чаще оказывается не таким уж большим, если правильно подобрать «фреймворк».
Что касается ошибок, отлавливаемых во время компиляции — ну вот честное слово, не припомню, чтобы на Питоне меня долго мучил какой-то неуловимо-критичный баг, связанный именно с перепутыванием типов (да, бывает, конечно же, но отлавливается очень быстро — активное использование аннотаций типов служит хорошую службу).
Про порог в полтысячи строк не совсем ясный принцип — это на весь проект или на один модуль (класс, компонент)?TargetSan
03.06.2017 15:13Дело вкуса и подхода. Я скорее пишу первичный каркас, на который навешиваю дополнительные плюшки и рефакторю по мере необходимости. Вот в процессе такой "перестройки" система типов помогает очень сильно.
Я сталкивался с подобным. Конечно подобные баги "мучили" меня не неделю и не день, а часа 2-3. Но осадочек остался. По поводу аннотаций — я работал с 2.7, и скрипт был подсобный, для прогона своего рода интеграционных тестов. Собственно, я столкнулся с неприятностями на немного извратном сравнении двух JSON документов.
Порог на один файл, и конечно очень условно. За счёт того, что питон таки умеет инкапсулцию на уровне файлов. Читаемым и легко поддерживаемым может быть и 1000-строчный скрипт.
amarao
02.06.2017 12:40+13Удачи в использовании браузера, в написании которого программисты руководствовались идеей «производительность не важна».
Она не важна ровно до тех пор, пока не становится важна.
navion
02.06.2017 22:45+3Мы живём в эпоху тормозных неотзывчивых интерфейсов.
Браузер тут скорее в качестве исключения, как пример штучного оптимизированного приложения. Вся электроника ужасно тормозит — давно вы видели быстрый интерфейс в банкомате, информационное табло, которое сразу реагируюет на нажатия или телевизор без секундной задержки на любое действие?
varnav
02.06.2017 13:46+1В веб-разработке важен только один показатель скорости — как быстро веб-приложение работает с точки зрения пользователя. Вот это и надо оптимизировать.
Akon32
02.06.2017 14:01+1У меня впечатление, что я слышал эту мантру 10 лет назад.
Есть конечно задачи, которые отлично масштабируются горизонтально; есть задачи, где СУБД в любом случае узкое место. Но есть и задачи, в которых в зависимости от качества (говно)кода пользователь будет ждать или секунду, или минуту.
Правда, в таких случаях больше на скорость влияют эффективные алгоритмы, а не языки. И, кроме оптимизации (преждевременной или нет) этих алгоритмов, мало что может помочь.
VEG
02.06.2017 14:13+7Вот сравниваю я Skype и Telegram на своём смартфоне. И становится понятно, разработчики которого из IM руководствовались принципом «зато быстро накодили и оно даже работает». Мобильным Skype невозможно пользоваться без боли.
FoxCanFly
02.06.2017 16:12+6Так вам же сказали, вам просто мощнее смартфон надо купить, это дешевле времени разработчика
evocatus
03.06.2017 13:53+1Кстати, да, вся эта демагогия про «время разработчика дороже» имеет право на существование до тех пор, пока затраты на отсутствие оптимизации не перекладываются на пользователей. ВСЕХ пользователей. Таким образом принцип — «лучше сэкономить на разработке» работает только с бэкендом онлайн приложений. А фронтенд уже работает в браузере и его извольте оптимизировать. Не только под последний Chrome. Не только под последний макбук разработчика. А для десктопных приложений, мобильных приложений производительность имеет большое значение. При прочих равных люди будут выбирать Telegram вместо FB Messenger, The Old Reader вместо Feedly, Google Keep вместо Microsoft OneNote и т.д.
mickvav
02.06.2017 15:07+1Тема сравнения с perl не раскрыта. Зачем в вашей метрике продуктивности нужен питон, когда есть перл?
worldmind
02.06.2017 22:01+4Питон аккуратно спроектирован, прямо вылизывается создателями, они всё стараются делать логично, выразительно, прямо радуешься когда читаешь как оно в питоне, а перл это перл, это альтернативное видение и синтаксиса и концепции ЯП — сигилы, глобальные переменные, контексты и так далее.
mickvav
03.06.2017 12:26Эм, вас перл заставляет использовать глобальные переменные? use strict, my/our вот это всё. В перле есть довольно много разумных неявных умолчаний, удобных для его класса задач — сколько там строчек в питоне займёт аналог while(<>) { s/--MYVAR--/$ENV{MYVAR}/; print ;}? Другое дело, что если вам нужен не однострочник «прям щас», а нужен код, который прочитают и будут поддерживать другие люди, на перле надо писать как на питоне или на java. Но он не заставляет вас так делать (а питон да, пытается).
worldmind
03.06.2017 15:20В приведённом вами коде используются как минимум две глобальные переменные.
TargetSan
03.06.2017 15:26Ваш пример годится только для однострочника, накиданного в командной строке по месту. Как только вы захотите переиспользовать этот код — упрётесь в чтение этой клинописи. Почему-то многие при сравнении "одноразовых" языков и "многоразовых" не учитывают, что сам автор может и не прочитать своё творение через недельку — из-за того, что писал в клинописном стиле.
По поводу use strict/my/our — у меня есть перед глазами замечательный пример в виде основного инструмента, С++. Языка, на 50-60% состоящего из легаси. Можно писать хорошо и красиво — но для этого придётся написать свою мини-обвязку, а также следовать правилам, в порверке которых компилятор вам просто так не поможет. Короткий вывод — есть языки, на которых легко писать криво и неправильно — и есть языки, на которых если писать криво и неправильно, придётся постоянно ублажать компилятор "обходными манёврами".
mickvav
03.06.2017 17:04Ну тут уже вопрос вкусовщины/личного комфорта/корпоративных стандартов/сложности поддержки в долгую. Основной поинт автора статьи был в том, что интерпретируемые языки с динамической типизацией и компактным синтаксисом в лице питона экономят время программиста, которое — ключевой ресурс. При этом ровно в метрике времени на решение разовой задачи перл не хуже питона, как минимум. Другое дело, что да, питон строже и наваять на нём странный стрёмный нечитаемый код — сложнее. Но не невозможно. И да, если писать на перле с нужной обвязкой (какой-нибудь perlcritic на pre-commit навесить, например) — должно получаться неплохо. Но свобода этого не делать — остается.
TargetSan
03.06.2017 18:05+1Как по мне, вырисовывается вполне себе зависимость, где объём свободно поддерживаемого кода обратно пропорционален условной сложности компилятора
- На перле или APL/K (из-за эзотеричности их синтаксиса) легко писать короткострочники, но код средних размеров уже может стать нечитаем. Уточню, что и Перл может быть читаем в среднем объёме, если не использовать "клинопись".
- Питон, человеческий перл, яваскрипт и т.п. динамика читаемы и поддерживаемы в рамках среднего объёма (мои наблюдения — в среднем 500, до 1000 значащих строк). И в этом объёме в среднем более продуктивны чем языки со статической типизацией. Так как содежимое модуля и связи внутри вполне можно удержать в голове.
- Всё что выше — требует статической типизации, т.к. кол-во связей и общий объём уже таков, что прилетевший из ниоткуда инт вместо строки в рантайме приводит к боли при отладке. А транслятор в этом помогать не желает. И рефакторинг превращается в охоту за тараканами.
mickvav
03.06.2017 18:29Биллинг на ~400 000 значащих строк на перле, строгие конвенции на проверку и передачу параметров (т.е. эмуляция статической типизации на уровне взаимодействия компонент), объектная модель, клинопись выпилена, юнит-тесты местами (увы), ~70% функций влезают в экран — полёт нормальный. Да, есть вещи, которые «пора бы отрефакторить», время от времени это делается. Может быть, если это вот всё делать сейчас и с нуля — покурить про язык можно было бы с большим выбором, но особого смысла переписывать столько с нуля сейчас нет и не предвидится — сложность поддержки вполне разумная.
mickvav
03.06.2017 18:33Про прилетевший вместо строки инт для перла (в отличие от питона, кстати) так вообще не корректно — там строка и инт — одно и то же. Больнее будет, если вам в рантайме прилетит вместо скаляра ссылка на массив.
mickvav
03.06.2017 18:40И да, сложность компилятора у ассемблера — минимальна. А вот поддерживать на нём даже 1000 строк — кошмар на улице вязов, имхо. Или это будут вставки по 10 строчек в C/C++.
nolled
02.06.2017 15:36Через лет 10 автор поймет, что язык Х не важен на начальном этапе разработки, архитектура, дизайн и high level оптимизация должна предшествовать низкоуровневой.
Psijic
02.06.2017 16:03+10Думаю, все согласятся, что статически типизированные языки менее продуктивны
Классный аргумент. Я не согласен. Зря так думал.
Вот, например, недавно вышедшая книга «Kotlin in Action» повествует:
Following are some of the benefits of static typing:
Performance — Calling methods is faster because there’s no need to figure out at runtime
which method needs to be called.
Reliability — The compiler verifies the correctness of the program, so there are fewer
chances for crashes at runtime.
Maintainability — Working with unfamiliar code is easier because you can see what kind
of objects the code is working with.
Tool support — Static typing enables reliable refactorings, precise code completion, and
other IDE features.
evocatus
03.06.2017 14:03+1Хорошие статически типизированные языки избавляют от множества ошибок сразу, ещё до компиляции, на уровне автоподсказок IDE. И до этапа тестирования. Подсказки IDE в них более качественные, потому что тип известен точно в подавляющем большинстве случаев. А когда он не известен, или нужно обеспечить большую гибкость, то можно использовать, например интерфейсы (в Go), вместо лямбд, которые возвращают чёрт-знает-что.
В итоге обеспечивается fearless refactoring — одна из заповедей TDD.
Так что давайте смотреть на продуктивность шире, чем количество строк.fly_style
07.06.2017 23:14Как по мне, назначение системы типов в языках программирования со статической типизацией — вынесение как можно большего количества ошибок времени исполнения в ошибки компиляции. Думаю, что это еще один весомый плюс к статической типизации.
Comdiv
02.06.2017 17:28+4Меня не радует то, что так много кода в мире, от которого всё больше зависит наша жизнь, создаётся программистами, у которых плохо с логикой. Автор этой статьи не исключение, поскольку начав с того, что одной из причин, по которой люди отказываются от Python — это его медленная скорость, продолжает доказывать, что нет причин этого делать потому что: 1) скорость не важна 2) Python быстрый.
И как-то выпадает из этого доказательства то, что скорость Python — это далеко не единственный и, возможно, не главный недостаток. Главным недостатком, на мой взгляд, является слабая ошибкоустойчивость Python, которая всё с возврастающей нелинейной силой начинает проявляться по мере роста размера и сложности проекта. Для чего-то простого Python вполне приемлем, для чего-то сложного или ответственного — нет.
Ах да, скорость языка тоже важна для целей корректности программы, так как позволяет использовать более простые, а потому и более надёжные решения там, где для медленных языков придётся изгаляться.tmnhy
02.06.2017 17:43является слабая ошибкоустойчивость Python, которая всё с возврастающей нелинейной силой начинает проявляться по мере роста размера и сложности проекта
Обоснуете, или оценочное заявление?Comdiv
02.06.2017 18:17+3Это стандартная особенность скриптовых языков — то, что хорошо для экономии строчек, плохо в отношении ошибкоустойчивости. Та же статическая типизация не только способствует скорости, но и позволяет вылавливать ошибки раньше. Чем больше программа — тем сложней её связи и тем больше в ней ошибок и вероятность их проявления и последствия от них. Тем критичней возможность отлавливать ошибки как можно раньше.
shockable
02.06.2017 23:10В последних версиях Python появилась возможность указать тип.
Comdiv
03.06.2017 01:48+1Это не делает его статически типизированным, если тип может изменяться по ходу дела.
def static_typing(i: int) -> int: return "bla bla bla" print(static_typing(11))shockable
03.06.2017 02:28+1Вы правы, не делает. Но ошибки отлавливать стало проще с использованием MyPy https://www.google.com/amp/s/ericjmritz.wordpress.com/2015/10/08/static-type-checking-in-python-using-mypy/amp/.
В дополнение к этому, например, PyCharm подсвечивает потенциальные ошибки прямо в редакторе.
PsyHaSTe
06.06.2017 17:59+2Зачем иметь сторонние тулзы если проверки типов можно встроить в сам язык? Мне сторонники динамических языков напоминают диких велосипедостроителей: сначала объявляем статическую типизацию злом, а потом начинаем впиливать собственную костыльную реализацию с помощью комментариев/атрибутов/специальных тулчейнов… Меня не оставляет вопрос — зачем, если можно довериться профессиональным решениям?..
batment
03.06.2017 20:46Были у меня большие программы на питоне. Не помню ни разу, чтобы сложная проблема была последствием использования динамической типизации. Вот всякие race conditions, логические недоработки или просто ошибки в рассчетах — этого навалом, но что-то я не слышал, чтобы статически типизированные языки от подобного были защищены.
Mausglov
02.06.2017 17:28+1100 000 циклов CPU — на мой взгляд, это слишком абстрактно. Взял более близкое мне понятие: считается, что 0.1 с на генерацию веб-страницы — это достаточно быстро. По шкале из статьи, на которую ссылается автор, это 10 лет. Практически эквивалентно сетевым задержкам (туда 4 года и обратно 4 года).
И тут уже выбор языка, который медленнее в 5 раз, смотрится совсем по-другому
Tiendil
02.06.2017 17:45+2Скорость была не важна года 3 назад. А нынче спираль пошла на новый круг и производительность снова готовится сесть на коня.
Comdiv
02.06.2017 18:22+3Да всегда была и будет важна скорость, просто есть задачи, для которых она не важна и есть стремление некоторых излишне обобщать.
Psijic
02.06.2017 18:19+1железо сейчас дёшево как никогда
а кто его покупать пользователям подобных поделок будет — компания? Или если имеется в виду только серверное оборудование и узкий круг веб-разработки — то так и надо писать.
slonoslon
02.06.2017 18:23Во-первых, автор обходит стороной вопрос о памяти (точнее, пишет, что раньше ресурсы процессора и памяти были дорогими, и дальше пишет только про CPU). Постепенно память становится все более узким местом — она дешевеет гораздо медленнее (в последний год в некоторых сегментах вообще подорожала), а упереться в нехватку памяти — это сразу либо резкое замедление работы (если swap есть), либо падение приложения.
Во-вторых, он сравнивает 'median hours to solve problem', и это неправильно. В реальных проектах важно среднее, а не медиана — потому что среднее учитывает те 10-20% затянувшихся задач, которые в итоге и тормозят весь проект, а медиана — нет.
nightvich
02.06.2017 19:31Все сводится к задачам. Например, если вы занимаетесь скрапингом, то в 99% скорость вообще не имеет значения, т.к. все равно вы будете выставлять тайм-аут для избежания бана и т.д. Однако, можно с лёгкостью привести пример, когда производительность крайне важна. Хотя я согласен с мнением автора.
slonopotamus
02.06.2017 20:21+6В ограниченном микросервисами и вебом мирке автора питон возможно действительно fast enough (хотя с этим тоже можно спорить). Но микросервисами разнообразие ПО не ограничивается.
Ядро ОС на питоне? СУБД на питоне? Может быть 3D? Ну хотя бы шифрование? Прошивка маршрутизатора на питоне?
Пользователю у которого тормозит софт на телефоне тоже предлагается кластер на пару десятков серверов в кармане носить?
corr256
02.06.2017 21:10Пользователю у которого тормозит софт на телефоне тоже предлагается кластер на пару десятков серверов в кармане носить?
Раз на этом кто-то заработает, то это тоже полезно для бизнеса.
worldmind
02.06.2017 22:04Да, автор должен был оговорится, что речь о прикладном программировании, а не о системном.
TargetSan
03.06.2017 15:31+1Просчёт топологии меша из нескольких десятков тысяч треугольников тоже далеко не "суперсистемная" задача. Автору стоило оговориться, что питон достаточно быстр для типичного сценария вебсайта со сравнительно небольшой БД.
QtRoS
02.06.2017 22:01+3В Питоне плохо без типизации. Для микросервисов ок, но когда проект подрастает — уже хочется больше проверок на этапе компиляции. Для прототипов и автоматизации действительно круто, потому что можно написать
import redmine # redis, pymongo, etc. # Do something
Питон хорош, но не идеален, поэтому везде пихать не надо, как и любой другой язык…
nikitasius
02.06.2017 22:01чтобы написать код для обработки строк на разных языках
Ну, как бы на java можно написать и медленный код через стринги и быстрый через стрингбилдер, байты и прочие прибамбасы.
KvanTTT
02.06.2017 23:22+1Не знаю что насчет общих задач, но, например, для парсинга скорость играет большое значение. Приведу пример из практики: ANTLR парсер кода PHP на Python работает примерно в 30 раз медленнее C#, вот issue на GitHub: Extremely Poor Performance Parsing PHP. Соответственно если в C# парсинг будет практически незаметен, то в Python придется ждать секунд 15. И в этом случае я пожалуй другой язык выберу.
Более того, динамическая система типов в Python будет адом при обработки древовидных структур. И в том же ANTLR я уже фиксил баг в рантайме, которого не было в статических языках из-за проверок на этапе компиляции.
splav_asv
03.06.2017 00:21IMHO в данном случае было бы хорошо иметь возможность генерировать исходник на C, собрав который можно получить библиотеку Python. К сожалению с реализациями кроме CPython есть сложности, но для них обычно тоже возможны варианты.
Terras
03.06.2017 00:31+1Нужно исходить из бизнес-целей
1) Делается изначально веб-проект, где подразумевается много изменений и сдвигов = php/python/ruby
2) Проект вырос и начались траблы в каких-то местах? Перепиши ряд ключевых библиотек на C
3) Проект вырос и дает стабильное бабло? Перепиши проект на Java/C#
Вот такой алгоритм работы, который работает достаточно хорошо. И решает бизнес цели.
И хочется сказать сразу, что большая часть проектов остаются на 1 этапе. Некоторые переползают на 2 этап и буквально единицы на 3.lega
04.06.2017 02:223) Проект вырос и дает стабильное бабло? Перепиши проект на Java/C#
Зачем если все хорошо?
Если и переписыать, то только если это даст положительный экономический эффект.Antervis
04.06.2017 08:19если проект не растет, значит он скоро начнет сбавлять обороты (пользователям наскучит). А если растет, то рано или поздно дорастет до кондиции, когда сервера не будут справляться. Разве что и Java, и C# — плохой выбор языка для серверного приложения
Terras
07.06.2017 01:07А что будет работать лучше?
Antervis
07.06.2017 05:38C# может и неплохо работает, но он же только для win. Где-то читал (может и неправда, а может неактуально уже месяца четыре как) что java не выдерживает долгий аптайм. Я бы предложил c++/rust/go попросту как более производительные альтернативы.
DistortNeo
07.06.2017 14:30C# может и неплохо работает, но он же только для win.
Уже лет пять как нет.
alexeyknyshev
03.06.2017 11:36+2Многие технологии в том числе и языки — вкусовщина. Кто-то может писать быстрый и надёжный код на Go или Java (Scala, Kotlin) продуктивней чем на Python. А в итоге получит ещё и прирост производительности. К чему это я?
Да — каждый инструмент под задачу, да — кто-то знает лучше технологию А чем B, но имхо, в современном мире энтропия технологий достигла такого уровня, что всегда есть некоторый пулл из них, в котором они приблизительно равны по требованиям к уровню инженера и скорости разработки, но среди них есть набор таких, что они просто работают лучше / быстрее / надёжнее архитектурно.
mclander
03.06.2017 14:41Ну просто человек хорошо знает питон. Если мне надо быдл бы очень-очень быстро нафигачить простой бэк-енд, то я месяц назад ещё взял бы питон или перл (поскольку скилы набиты).
Сейчас поигрался с expressJS и если бэкенд REST — буду писать на JS. Просто JS нравится больше Py, а разница в инструменте для меня минимальная — и так можно и так.
Acuna
06.06.2017 22:58Очень-очень быстро (прям вот если очень-очень быстро) — это Вам на PHP надо писать, синтаксис просто песня. В прямом смысле. Плюс для веба заточен.
mclander
08.06.2017 11:30Ну можно взять PHP, но для меня на питоне быстрее. Хотя бы потому, что больше библиотек и функций помню. И в маны буду лазать меньше.
Если по условиям задачки есть только PHP, тогда другое дело. Из того, что провайдеры предлагают за копейку из коробки — пхп абсолютный лидер.
Так что сарказм не очень уместен. Если инструмент подходит к задаче и он есть в наличии, то надо брать ржавую лопату и копать, а не мечтать о сияющем экскаваторе. Особенно там, где копать -то пару часов)
mclander
03.06.2017 14:31Суть статьи в полутора предложениях
… и теперь пришли к выводу, что уже сам Python является узким местом. Но он имеет возможность вызова кода на C…
Для питона очень легко пишутся расширения на C/C++. Кроме того есть уже библитеки для выноса операций в C-код, например numPy даёт сразу оптимизацию в полпорядка при работе с массивами.
Есть две вещи, за которые я не фанат питона:
— артефактный к другим языкам код (сложно переключаться)
— obj['key'] — вызывающий эксепшен (вот бесит меня писать obj.get('key')
kmmbvnr
04.06.2017 05:20На самом деле, если посмотреть на время расцвета Java в начале 200x, скорость Java на тех железяках была еще меньше. Однако это не помешало Java занять свое место под солнцем.
Многие реальные практические задачи, с тех пор не изменились по нагрузке.
stranger777
04.06.2017 15:01но они никогда не заметят разницу между 35 мс и 25 мс
Посмотрите на этот онлайн секундомер:
http://sekundomer.net/
— и убейте меня. Я замечаю.
Да, сама по себе статья хорошая. Но не этот кусок. Тут автор оригинала ляпнул не проверив.Dsvolkov
07.06.2017 19:47В смысле, как вы это замечаете на этом сайте? Я пробел-то не успеваю нажать быстрее 100 мс, о чем речь вообще?
stranger777
07.06.2017 22:08Не в прямом смысле, конечно: частота мерцания монитора — 60 герц, а это 18 тысячных секунды на одно обновление экрана и всяко разно оно что-нибудь «съест» из этой секунды, поделённой на тысячные доли.
Но при должной концентрации можно начать выделять эти моргания, то есть — они не сливаются в сознании, а идут урывками.
Скорость нажатия клавиши пальцем упирается в вашу скорость реакции и нервного импульса, а также в скорость вставания клавиши пробела в то положение, из которого его можно было бы нажать заново.
А скорость восприятия времени зрительно упирается только в скорость мысленного сравнения двух изображений, которая может быть много быстрее.
Возьмите игру на скоростное сравнение — поймёте, о чём речь. В этом плане мозг может быть очень быстрым.Dsvolkov
07.06.2017 23:08Ну слушайте, вы уж совсем за уши притягиваете. При чём тут моргания, которые при должной концентрации можно рассмотреть? Речь идет о скорости обработки запроса пользователя, и его восприятии этого. Что 25, что 35 мс — это воспринимается как мгновенно, реальный пользователь реальной системы разницы абсолютно не заметит. Об этом и идет речь, а не о разрешающей способности глаза/мозга при предельной концентрации
DistortNeo
07.06.2017 23:14Если вы пишете игровой сервер для экнш-шутера, то такая разница будет уже вполне заметна.
ALexhha
04.06.2017 19:42+1Это все сказки, что железо дешевое работы программиста, программисты разные и железо разное, если мы считаем VPS по 10-50 долларов в месяц и Senior с окладом 4000$ в месяц, то да, но если сервер стоит хотябы 250$, то тут другая история
по словам знакомого, который работал в яндексе, у них так часто и делали — если тормозит сервер, то им проще было добавить N гигабайт памяти, перевести на SSD, заменить на более производительный процессор, чем тратить N часов разработчиков/администраторов на поиск этих тормозов и попытку их устранить. Кстати не факт что она в итоге окажется успешной. Как минимум для dev окружения, насчет прода не помню
werevolff
05.06.2017 16:07+3Интересно, что сегодня Python неофициально популярен в рамках идеологии «используй меньше Python в своих решениях».
К примеру, в WEB-разработке мы сталкиваемся с несколькими проблемами скорости Python:
1. Получение данных из хранилища и их обработка
2. Обработка данных из Request
3. Рендеринг шаблона.
Все три проблемы концептуально решаются минимизацией Python операций.
1. Большинство операций в популярных Python ORM — лишь обёртки для родных функций БД. Оптимизируя код обращения к БД, программист должен свести к минимуму обработку данных в Python.
2. Обработка данных в Request, в большинстве случаев, выносится на REST Endpoints с асинхронными обращениями. В результате, часть асинхронного программирования берёт на себя JS, который контролирует асинхронные запросы, частоту обращения к серверу и т.д. Но, если уж совсем сложная операция, на серверной стороне задействуются свои механизмы создания потоков или процессов. В любом случае, за получение результата будет отвечать JS код.
3. Аналогично дела обстоят с шаблонизаторами: мы либо используем готовые механизмы кеширования шаблонов, либо (что сегодня более популярно) делаем статику и шаблоны независимыми от Python. Благо есть ангуляры, реакты и т.д.
Полагаю, что в других отраслях существуют такие же способы обхода скорости Python, которые позволяют использовать этот язык для решения сложных задач, путём минимизации операций в интерпретаторе Python. И тут сам Python можно использовать как скриптовой язык. Вспомним тот же Ansible: Python в нём является лишь обёрткой для выполнения различных команд в среде операционной системы. Фактически, разработчики берут менее сахарный синтаксис того же bash'а и пишут скрипты на python для объединения объёмного bash кода в простые python команды.
Но вот что Python реально не может добиться, так это собственной производительности. Ему очень часто нужен чужой API для решения задачи. Однако, если осознать упомянутую концепцию «используй меньше Python в Python приложении», начинаешь учить другие языки… чтобы, как ни странно, обернуть их в Python код.lega
06.06.2017 13:13Таким образом Python занимает позицию менеджера (управленца) над другими языками оторые умеют хорошо «крутить гайки».
dbagaev
06.06.2017 22:45+1Да, абсолютно согласен. В Питон удобно заворачивать бизнес-логику, которая обычно выполняется один раз на запрос и все равно плохо оптимизируется. Но как только дело доходит до непосредственно вычислений, итераций и всего, что упирается именно в аппаратную скорость вычислений, в бой сразу вступают сторонние библиотеки, написанные на С/C++/Cuda/etc и имеющие Python API.
Acuna
06.06.2017 22:56Хотел бы спросить, пользуясь случаем, почему бы просто не использовать PHP, который лишен этих недостатков (а уж рендеринг шаблонов и вовсе занимает на нем не более доли секунды)? Зачем использовать язык для этого, тем более когда существует ЯП, заточенный конкретно для этого?
dbagaev
07.06.2017 00:46+1Потому что кроме Web, у Python есть множество других приложений, где он работает на порядок лучше, чем PHP. Я на питоне прототипирую алгоритмы и расчеты. Использовать для этого PHP мне и в страшном сне в голову не пришло бы.
werevolff
07.06.2017 00:46Затем, что Python идеален для сетевых решений. Как ни странно, он пользуется огромной популярностью именно для распределения нагрузки при огромном объёме подключений. Серверная часть самой масштабной сетевой игры — Eve Online — была написана на python. Тому есть много причин. Но, если вкратце, то всё сводится к возможности python эффективно и сахарно задействовать решения на других языках. Это позволяет построить изящную архитектуру. PHP на это не способен. У него гораздо меньше готовых решений и обёрток. Ну а в случае с Web, мы имеем сахарный Python против усложнённого PHP. В большинстве случаев мы избавляемся от той же Jinja2 и задействуем Angular.js или React.js со сборщиком на gulp, bower или webpack. И нам требуется создать эффективный роутер запросов. Эффектичность здесь будет оцениваться колличеством файлов с кодом, их объёмом и возможностю повторного использования. На второй стадии нам потребуется ORM с такими же пожеланиями. Если у нас небольшой сайт, ORM должна давать нам возможность описать структуру и получить данные за минимальное число строк кода, с использованием самой минимальной логики. В случае с большими проектами, нам потребуется то же самое, только в больших объёмах. А значит, мы должны получать огромное число запросов, для каждого запроса создавать отдельный поток, а обработку записывать, по возможности, декларативно — в виде набора данных и команд, которые выполнятся в самой БД. И вот PHP так не может. Его роутер — это либо куча отдельных файлов в ФС, либо многотонный монстр, который с трудом повторяет функционал, хотя бы, Flask. ORM? Ну есть решения, в которых придётся написать фигову тучу строк кода и каждый запрос по отдельности. А ещё можно сказать об инвалидной модульности с непонятными пространствами имён, в которой потребуется убить время на закрытие доступа к отдельным файлам.
P.S. конечно, можно сказать, что на PHP хорошая шаблонизация… только вот беда, PHP, по сути и является шаблонизатором. При том, кривым. Вместо того, чтобы учить его работать с чистыми шаблонами, авторы стали нагружать эти шаблоны ненужной логикой. В итоге, конечно, появились достойные шаблонизаторы на пыхе… но они все просто убогие. С одной стороны, им нужно время, чтобы нарастить функционал, исправить ошибки… сдругой, нет у них времени. Сейчас идёт тенденция к отделению шаблонов в пространство Frontend со своими сборщиками и JS обработчиками. Так что, даже в условиях CMS разумнее будет выбрать python только за счёт потенциального масштабирования проекта с выносом фронта в JS фрэймворк и подключением REST API.
werevolff
07.06.2017 09:12-1Немного дополню себя: мне довелось поработать с Silex. И это довольно хорошее решение. Однако, существуют уже описанные выше ограничения PHP, и несколько других, к слову сказать. Например, кривой composer. Необходимость защищать пакеты с классами при помощи .htaccess (или я чего-то не знаю о других методах ограничения исполнения) и т.д. Но тут важно знать, что фреймворки на PHP, как-правило, уже не так шустро рендерят шаблоны. А вот готовых решений для различных операций у них гораздо меньше.
Acuna
08.06.2017 00:25Огого! Спасибо за содержательный ответ, прочитал с большим интересом! Действительно, все дело в том, что за его синтаксисом я забываю о том, что у меня у самого куча обверток для всего — для разных БД, свой шаблонизатор, несколько мегов функций на все случаи жизни, и так далее, поэтому процесс создания чего-либо на нем ничем не омрачается, без этого никуда, тут я не спорю, да и под нагрузку, он, мягко скажем, не предназначен, это да, но в его защиту хотел бы сказать, что так как он сам является, по сути, фреймворком для С, то и позволяет из коробки очень много всего того, что другие языки могут только с кучей костылей. Вот я сейчас пишу приложение для андройда на Яве как раз, это мой первый опыт действительно углубленного написания чего-либо серьезного на другом языке, но я, честно скажу, бы сильно удивлен, ибо я считал, что уж если PHP умеет очень много по дефолту, то уж типа «серьезные» языки — и подавно, однако для меня оказалось большим открытием то, что любые действия, будь то банальный trim (), массивы? запись и чтение, и тому подобное, потребует кучи костылей. Мой проект разрастается, и параллельно растет с ним и очередной мой фреймворк, только уже для явы, но только в отличии от PHP, на котором он расширял этот функционал — тут он его просто добавляет, и то хорошо :/ И Вы знаете, у меня смешанные чувства, вроде бы типа бОльшая гибкость, мобильность и все такое, другое дело, когда я «благодаря» этой абстрактной гибкости вынужден ежедневно перелопачивать весь Stackoverflow в поисках решения какой-либо относительно простой задачи, и даже если я его и нахожу — возникают вполне оправданные сомнения в оптимальности ее решения, там 90% индусов, им платят за количество кода, да, делятся своими наработками, помогают другим, похвально, но что как все это себя поведет в жизни — не известно, поэтому лично я сторонник максимального числа встроенных методов, ибо я всяко больше доверяю в этих вопросах компетенции создателей данного языка, а не непонятно кому, да и себе в том числе, у меня 10 лет опыта программирования, и то я даже себе не доверяю в таких вопросах)) Да, PHP реально те же индусы, однако всяко это лучше сторонних поделок школьников на коленке, взятых с какого-нибудь ЛОРа. Кстати, как в питоне с этим дела обстоят? И как к синтаксису, привыкли? Как-то никак не перестроится после PHP, уж там он просто для людей!
P. S. Вы, между прочем, зря .htaccess ругаете, сама эта задумка настолько удобна, что ради него даже специально ставят тяжеловесный и монструозный апач, отдавая ему статику (чтобы он хоть что-то делал, от большего серваки просто загнутся), ибо все настройки производятся по сути в одном файле, лежащем в корне сайта, для их применения не нужна даже перезагрузка (!), еще это удобно в плане удаленной настройки, вместо того, чтобы часами объяснять что и где нужно прописать и что и куда положить, достаточно прописать все настройки в одном файле и кинуть его человеку, чтобы он положил его в корень своего сайта, а уж где он находится — знает даже домохозяйка. И в этом файле будет все — и непосредственно сами настройки сервера, и формирование ссылок, и запреты на исполнение каких либо файлов, их отдачи, и т. д. На том же энджинксе нужно править не один файл, причем часто вписывать аналогичные строки одновременно в несколько файлов, причем часто с отсутствием какой-либо логики. Для меня загадка, почему ни один сервер еще такое не поддерживает. Имеются, конечно, некоторые решения, например, парсить его регулярками и перловыми скриптами чуть ли не по крону эти настройки применять, но это уже костыли, разумеется…
P. P. S. Минус не мой)werevolff
08.06.2017 03:45Переходил на Python с PHP. Проблем не испытывал. Гораздо сложнее было перейти с синтаксиса Joomla/Drupal к нормальному PHP коду с пространствами имён и тестами (имеется ввиду построение архитектуры с возможностью тестирования). Сейчас активно работаю с JS. В сравнении с пакетами npm, менеджер пакетов python радует. Можно подобрать очень и очень много готовых решений. Pypi — огромный репозиторий. И качество решений, зачастую, радует. Дело в том, что PHP в принципе не имеет единого стандарта оформления кода и Unit-тестов. Т.е. в случае популярных Python пакетов мы получаем код, отвечающий большинству пунктов соглашения PEP8, этот код будет содержать набор тестов для unittest, а если повезёт, то и докстринги по формату PEP257.
Насколько я помню, в PHP тоже есть различные соглашения об оформлении кода и всего пара нормальных решений для тестов. Но, скажем так, соглашения эти долгое время игнорировали, а своего нормального уровня пакеты для тестов достигли лишь несколько лет назад. Понятно, что старые решения было уже труднее переделывать под популяризованные стандарты разработки.
По Java ничего конкретного сказать не могу, поскольку не работаю с ним. По отзывам коллег могу представить, что там ситуация промежуточная: лучше чем в npm, но хуже, чем в Pypi.
Аналогично, JS — слабосахарный язык. По-умолчанию он не имеет даже команды форматирования даты/времени. Но, на него много готовых решений, которые берутся в npm. Но они, по большей части, собраны на коленке, либо это промышленные решения, но их гибкость оставляет желать лучшего (приходится под них подстраиваться, либо отказываться от них). Стандартов оформления JS кода — несколько. Тестирование вообще не популярно, хотя я пишу тесты на фронтэнд. И если уж говорить о синтаксисе, то мне и синтаксис JS нравится, и синтаксис Python. Синтаксис Ruby не совсем понятен. Но я его действительно не умею готовить. Вообще, вопрос синтаксиса и оформления кода уходит в холивар только тогда, когда человек банально не хочет изучать язык.
P.S. .htaccess не нужен! Это рудимент, как и Apache. Нормальный роутинг, так или иначе, реализуется на программном уровне, а в CGI мы вынуждены дополнять его .htaccess для корректной работы. Ну а в случае связки PHP и Java/Python/Ruby, мы вообще получаем дохлый апач с его CGI и родное решение от «святой троицы web-языков», которое охотней работает на Nginx и предлагает более гибкую и простую настройку.
P.P.S. Минус не принципиален. Интересно, конечно, узнать мнение его автора. Могу предположить, что ему не понравилось высказывание о скорости шаблонизации в отдельных PHP шаблонизаторах. Справедливости ради, стоит сказать, что эта скорость выше, чем у конкурентов. Ну или человек просто самозабвенно любит PHP.michael_vostrikov
09.06.2017 22:06А зачем защищать пакеты с классами при помощи .htaccess? Они обычно не находятся в веб-доступной директории. Подозреваю, что из-за этого и был минус.
werevolff
10.06.2017 01:40Ну потому я и написал, что возможно, чего-то не знаю о других методах защиты. И, при этом, на практике не встречал сайтов, в которых был бы один файл index.php, а классы были бы написаны в другой директории. Может, хотя бы вы подскажете каким образом директория, находящаяся в Site Root, исключается из веб-доступных?
michael_vostrikov
10.06.2017 06:41Папка '/var/www/project', в ней все файлы и папки проекта, среди них есть папки 'public' и 'vendor', в 'vendor' пакеты composer, в 'public' файл 'index.php', и сюда же смотрит веб-сервер. Практически во всех фреймворках так.
werevolff
10.06.2017 06:46При чём тут vendor? Речь шла о файлах, которые создаёт программист. Например, я создаю какую-то модель. Она у меня является классом, который лежит в отдельном модуле. Сама модель использует ORM, но представление, которое возвращает данные из БД, вынуждено импортировать этот класс. Разумеется, если я не ландух, который пишет весь код в index.php или пользуется прямым инклюдом PHP файлов. Правда, даже в случае инклюда, подключаемые файлы защищаются в .htaccess. Иначе их можно тупо скачать и посмотреть из чего состоит сайт.
michael_vostrikov
10.06.2017 07:48В папке 'project' хранится весь код приложения. Модели например могут храниться в 'app/models'. В index.php подключается автозагрузчик через include '../vendor/autoload.php' и все, дальше используются только названия классов с пространством имен. В представлении или где-то еще пишем 'use app/models/MyModel;' и при первом обращении к классу MyModel файл подключится через composer. Отсчет естественно идет от корня проекта, а не от public. Сами представления тоже необязательно в папке public хранить, они подключаются механизмом рендеринга фреймворка.
werevolff
10.06.2017 07:52Ну, в этом есть доля истины. Только всё как-то усложнено. Получается, что проект формально разделён на libraries в одном корне и файл запуска — в другом (public). Возможно, я не прав. Но тогда нужно посмотреть либо на уже существующие рекомендации по такому разделению, либо на авторитетные образцы. Есть такое?
michael_vostrikov
10.06.2017 08:24+1Ну я бы не сказал, что разделен, просто объединяется уровнем выше.
/var/www/project: app config resources public index.php vendor
Хотя да, папку public можно вынести куда нужно, только пути в index.php поправить.
Рекомендации по автозагрузке кажется описаны в PSR. Образцы это проекты на фреймворках типа Yii, Laravel, Symfony.werevolff
10.06.2017 09:26Ну это, конечно, оптимальный подход. В любом случае, я не php-программер, и если сталкивался с решением задач на PHP, как-правило, хостинг был не настраиваемый, и я имел доступ только к public. Вообще, на PHP много забавных архитектурных решений. Но фреймворки, к счастью, по большей части, предлагают относительно верные варианты.
Acuna
11.06.2017 00:32Извиняюсь, в своих делах просто забыл ответить…
Да, но в JS эта проблема практически полностью решается благодаря плагинам к jQuery (если речь идет о свистелках). Понятно, что тоже задействуется сторонний код, поэтому я, как правило, опять же, перелопачиваю код известных плагинов и пишу на их основе свои, при аналогичном функционале позволяет сократить исходный код почти в два раза, ибо часто логика произрастает неизвестно из какого места.
Хорошо, но все-таки, для Вас при переходе с PHP на Python принципиальны тесты, стандартизация и менеджеры пакетов? Просто первые нужны исключительно в промышленных масштабах, последнее решается непосредственно средствами языка и своими/сторонними фреймворками (если я правильно понял, как в случае Pypi, к которому тоже необходимо прибегать). Или может быть всему виной сложившиеся вокруг PHP известные предрассудки и оправданно его очерненная репутация школьниками, клепающими на нем сайтики для своих игровых кланов? Пока ответа на этот вопрос я не нашел, но мне интересно, честно признаюсь…
JekaMas
Скорость это не только скорость, но и максимальная нагрузка на сервис. 30 rps или 6000rps с ноды. А значит меньше серверов, меньше поддержки, меньше трат и немаловажная фича, которую бизнес хорошо понимает: возможность расширяться в N раз, не сталкиваясь с поблемами со стороны сервисов.
TyVik
Да, автор на это тоже обращает внимание и приходит к выводу, что дешевле будет доставить ещё один сервер, чем тратить время программиста. Ну, по крайней мере там :) Я не думаю, что это можно и нужно делать бесконечно, но гораздо проще будет провести оптимизацию комплексно в спокойное время.
Dimash2
Все зависит от нагрузки, 1 сервер + 1 сервер может и не пробелма, а вот если количество растет, типа 10 серверов вместо 5, или когда объемы доходят до сотен. 50 серверов или 100 серверов, есть ведь разница.
А скорость разработки — это не язык, а года существования компании или года практики разработчика, у которых все уже готово и остаются только " частные случаи". Сегодня back-end совсем упростился, в компаниях на 5 front-end 1 back end, потому поднять базу данных и API для CRM — нужен 1 день, ну еще парочка на частные случае или если есть какие-то особенные вычесления, а вот на Front-end постоянно уходит огромное количество времени.
corr256
Чем больше серверов, тем больше нужно админов, тем выше капитализация компании. Так работает бизнес, так работает экономика… Глядишь и унылый говно-чат уже проходит многомиллиардное IPO :D
Именно поэтому бизнес так любит python.
Antervis
сомневаюсь что бизнес любит капитализацию в ущерб прибыли
corr256
посмотри на твиттер
Singaporian
Он прав. Мне как-то объяснили этот момент тоже (речь идет о компании NetCracker). Я приходил каждый раз с рационализаторскими предложениями. Каждый раз мне объясняли, что на это нет времени. Это конечно же неправда — эти люди умеют считать деньги.
А правду мне объяснили потом в курилке: все рационализаторские предложения приводят к сокращению штата. А сокращение штата приводит к проигрышу тендеров у крупных корпораций, для которых маленькая компания == компания однодневка.
Другими словами, сокращение штата — потеря денег, если принять во внимание не только технические, а все особенности бизнеса.
NetCracker до сихпор собирает Java-код руками (даже есть целый отдел «релиз-инженеров»). Результат превзошел все ожидания. Сегодня это крупнейшая в своем рынке компания…
evseev
Еще ведь и от задачи зависит. Скажем на сервере крутится вычислительное ядро, которое реализует сверх сложную с алгоритмической точки зрения задачу. И запросто может так сложиться, что добавление любого количества серверов не даст результата.
JekaMas
Сказать «дешевле поставить еще один сервер» можно только тогда, когда мы сравним траты в обоих случаях, то есть данное утверждение надо подкрепить цифрами и показать, масштабируется ли оно, то есть справедливо ли по прежнему будет сказать «дешевле поставить еще 3000 серверов, чем иметь 200 и научить программистов один раз и навсегда писать более качественный и шустрый код». Мне не кажется, что ответ так однозначен, как преподносится в статье. Особенно с точки зрения бизнеса.
Как говорится «скорость — это тоже фича».
TyVik
Да, кстати, цены можно обсудить. m3.medium (1xCPU, 4Gb) стоит $350 за год, то есть ~20 000 руб. Насколько я знаю, это месяц работы джуниора (вряд ли ему кто-то доверит такую задачу) или 4 дня мидла. А у него задачи могут быть расписаны на недели вперёд.
Смотрите на это как на технический долг — да, мы сейчас ставим более дорогое железо, но в будущем эту ситуацию обязательно исправим.
JekaMas
А когда речь про 1000 серверов и не medium? Я про то, что обобщать по меньшей мере странно. Что может быть верно для небьльшого или среднего проекта, то оказывается фантастическими убытками на больших нагрузках, когда число тех же серверов давно идет на сотни и тысячи. Дешевле несколько заняться бизнес-процессами и устроить обучение в расках компании, заодно с нагрузочным приемочным тестированием. Как итог иметь разовые вложения в программистов против регулярных плат за впустую используемые мощности.
aram_pakhchanian
Вложения в программистов не бывают разовыми — любой код приходится сопровождать и развивать, чтобы он не умер. Если код меньше, его дешевле поддерживать. Оптимизированный код очень часто сложнее для понимания. Времена нынче таковы, что все быстро меняется и время жизни кода стало существенно меньше, чем раньше. Пока вы доведете до ума хорошо оптимизированный код, его, возможно, уже надо будет переделывать.
JekaMas
Исправление этой сетуации, если оно упрется вдруг в язык, на котором написана система, может похоронить. Долг долгу рознь. Если у нас спокойный сублинейный рост по мощности серверов, то можно такой долг и запланировать, когда и как его возвращать. А если рост в разы как минимум? Смогут ли программисты решить проблему такого «долга», когда требования растут от месяца к месяцу?
Я вновь возвращаюсь к вопросу, что обозначенное выше утверждение справедливо только в определенных рамках касательно размера бизнеса и размера нагрузки.
dmxrand
Еще момент про который часто забывают. Ваш сервис не застыл. Его надо развивать. Постоянно вносить изменения…
Singaporian
Люто бешенно плюсую.
Мало того, что нужно учесть цифры в разных перспективах (за год, за 5 лет, за 10), так я заметил и еще одну особенность — люди иногда пересказывают догму «программист дороже железа» без привязки к реальности.
Они не учитывают, что догма эта родилась в западных странах, где цены на железо такие же, как в России + куча скидок и отсроченных платежей, а зарплаты в 10 раз выше. Для России, где разработчики получают $1-2k нужно еще много раз пересчитать и убедиться, что догма не обратная. И опять же: с ростом экономики России нужно снова и снова ее пересчитывать.
Antervis
возникает вопрос: что дешевле — платить квалифицированному по части оптимизаций специалисту или покупать новый сервер?
Regis
Автор как-то упускает/замалчивает тот момент, что для самой возможности "доставить ещё один сервер" приложение должно быть горизонально масштабиремо. А для этого, нередко, нужно чтобы разработчики достаточно сильно "вложились" в обеспечение такой возможности.
Бывают ситуации, когда быстрее и дешевле сделать решение на более производительном языке, и которое не будет (изначально) масштабироваться, но будет обрабатывать нагрузку с достаточной производительностью, чем делать мастабируемое решение на более удобном языке и тратить существенные усилия на обеспечение масштабируемости.
worldmind
Думаю все уже знают и понимают, что если у вас проблемы с производительностью, то решение только в горизонтальном масштабировании т.к. ресурсы одного сервера имеют вполне конкретные ограничения и скорее всего всё равно придётся масштабировать горизонтально т.е. нет смысла тратить деньги на оптимизацию работы на одной железке, лучше сразу заниматься горизонтальным масштабированием.
Помимо этого горизонтальное масштабирование ещё и добавляет отказоустойчивости т.е. его всё равно придётся делать в том или ином виде.
schetilin
Вот бы с автора подобных заявлений, с зарплаты вычесть все затраты (дешевле будет) всех пользователей приложения.
rodgar
Представим что у вас 10 000 000 ежемесячных посетителей. То есть ваш сайт входит в US топ150 по посещаемости и находится рядом с такими ребятами как airbnb.com и steamcommunity.com Пусть каждый посетитель просматривает 10 страниц. Таким образом у вас 10000000*10/30/24/60/60 = 38 rps. Стоило оптимизировать сервис до уровня 6к?
Nerten
Ах, если бы 1 страница это был 1 запрос.
JekaMas
Эх… Солидарен. Если бы одна страница == один запрос…
Dimash2
Легко, если данные важные, можно отдавать кеш 1 раз 5 секунд из файла, а если данные не очень важные то в любое назначенное время.
Сайты которые мы сдаем на Wordpress, вообще не используют Wordpress для вывода страниц, сразу отрубается WP и кешированные странциы достаются 1 запросом прямо из index.php, получается безумно быстро
JekaMas
А есть еще миир realtime и highload…
Нельзя там кэшировать страницу целиком в файл. Максимум отдельные куски.
Dimash2
realtime можно кешировать на 2,1 и 0.5 секунд если мы говорим про страницу, а не про какой-то интерактив
Представьте если за пол секунды заходит 20 человек, это 1 сборка вместо 20
Но суть с отдельными частями такая же, кешируйте все, что можно, а realtime оставьте
JekaMas
А если заходят тысячи покупателей и цены меняются очень часто и склады, опять-таки, а операционные издержки по отмене нескольких тысяч заказов, сделанных в момент, когда остатков на складах уже нет, будут весьма велики. Не считая ущерба для репутации.
И если у нас сотни серверов, тысячи, то мы приходим к задаче инвалидации кэша, которая, как известно, сложна.
Dimash2
Можно обновлять кеш по факту изменения цены, все просто. Контролировать кеш не только по времени, но по факту изменений, тогда изменения применяться моментально.
PS. Контролировать кеш при большом количестве серверов извне сложно, но можно делать 1 запрос на проверку изменений, а изменения хранить как отдельное поле, тогда будет 1 запрос, но не такой критичный.
JekaMas
Это инвалидация кэша. И это сложная задача. Цену могут обносвлять разные сервисы: массовый импорт, просто редактирование продукта, изменение не самой цены, но скидки на нее, которая может считаться несколькими сервисами с совершенно различной бизнес-логикой, стоимость доставки и скидка на стоимость доставки для этого клиента. И кто и где должен сбрасывать кэш? Это не тауой простой вопрос и тут немало копий сломано, чтобы добиться качественной инвалидации.
Dimash2
Придумать что-то можно, тут уже как с лекарствами «принимайте, если риск от болезни выше, чем риск от лекарства» )
JekaMas
Придумать можно и оно зовется инвалидация кэша. Это сложная задача, но поверьте, она не сводится к тому, чтобы выставить время кэша страницы в 0.5 секунды.
michael_vostrikov
Это если у вас в отдельных частях ничего не зависит от user_id и от фильтров, которые он вводит.
rodgar
Мои цифры не претендуют на точность и учет всех параметров для проектов разной тематики. Они о том что ОЧЕНЬ МНОГО пользователей не значит что каждый элемент вашей системы нужно тестировать на абстрактные 6k rps. Нужно максиально быстро запускаться, выявлять под реальной нагрузкой узкие места и тюнить их.
JekaMas
Соглашусь, если под «максимально быстро запускаться» имеется в виду «мы заранее подумали и обозначили миинимальные требования к системе, в том числе и по производительности и масштабированию, и быстро запускаемся, выполняя их».)
JekaMas
Представим, что столько за приходит за час или меньше.
batment
Почему-то все считают, что их проект обязательно доберется до той точки, где ему понадобятся сотни и тысячи серверов и при этом будет использоваться тот же код, что и в начале. Таких больших проектов реально единицы и обычно они начинают с дешевого говнокода от фрилансеров, который все равно потом приходится переписывать.
JekaMas
Верно и обратное: почему-то люди считают, что их проект никогда не столкнется с теми задачами, которые появляются при резком росте.
В сущности я весь разговор подвожу к тому, что оба суждения не верны, если обобщать. Нельзя утверждать, что проблемы решаются любым языком программирования + пара лишних серверов; равно для сервисов с нагрузкой в несколько тысяч в день или час не нужно кидаться оптимизировать для сокращения времени ответа с миллисекунд до микросекунд.
На мой взгляд статья неверна именно в своих основах: обобщение неправомерно и в чем-то непрофессионально — в стиле «надо быстро фигачить код, а плохую скорость компенсируем, это, мол, всегда работает». Нет, не всегда. Можно оказаться один на один с громадным техническим долгом и успешным проектом, который быстро растет по нагрузке, а времени уже не хватит, чтобы сделать хорошо. Должен быть заранее определенный порог, ниже которого не опускаемся по производительности и способности масштабироваться под нагрузку. И порог этот должен учитывать различные бизнес-сценарии, как негативный, так и позитивный.
batment
Не согласен с вами. Поведение под нагрузкой предсказать всегда сложно, и оно может упираться не в RPS, или не в тот RPS, который вы задумали. Уже было очень много случаев, когда делали оптимизированный сервер на Java/C++/Go/etc. и в большинстве случаев все равно все заканчивалось тем, что под взрывом нагрузки сервис несколько дней лежал, так как упор был не в процессор, а например в базу. Почитайте для примеров истории разных io-игр или погуглите на хабре словосочетание «не выдержал хабраэффекта».
Еще мне кажется, что автор не имел в виду, что надо всегда оставаться на питоне в любой ситуации. Вы можете наговнокодить за неделю прототип на Django и размножить его на 100 серверов при необходимости, а убедившись что 100 серверов действительно нужны, нанять в это время высокооплачиваемую Java-команду, которая за три месяца перепишет проект и уместит все в один мощный сервер.
И тогда цена проекта получится полностью оправданной — и 100 серверов, и профессионалы покупаются только если они действительно нужны. А если сервис понадобится только 1.5 пользователям, все что вы потеряете — это деньги на микроинстанс и неделю времени.
JekaMas
Вот про последнее, про команду java: у вас был такой опыт и подобные задачи решались за квартал java командой или нет?
Про «не выдержал нагрузки» — где мне доводилось работать с приемочным нагрузочным тестированием с таким не сталкивались. Такое происходит, когда методология тестирования нарушена. Если есть обратные примеры, где и нагрузочное приемочное было и методология тестирования доступна для проверки, но все равно уперлись в неожиданное нечто, что тестирование не предсказывало, то буду рад примерам. Иначе несколько голословно звучит.
batment
Про 3 месяца я загнул конечно, но если изначально был проект сделанный за неделю, то за 3 месяца уже могут что-нибудь да выкатить на прод. По опыту знакомых джавистов-аутсорсеров, где-то так все и происходит: приходят люди и просят переделать говнокод на питоне или еще чем-то во что-то приличное.
Тут мы и приходим к тому, что чтобы проект выдерживал нагрузки сразу, разработчик должен быть опытным (дорогим) и чтобы просто проверить идею (которая скорее всего не взлетит по статистике), придется потратить много денег и скорее всего времнеи. Естественно я не говорю о проектах, где большая нагрузка точно будет.
JekaMas
Тогда наши мнения вполне совпадают.
Однако же изначальное утверждение статьи «Производительность более не важна» все также выглядит сомнительно.
immaculate
Даже если проект добирается до такой точки, камнем преткновения, по-моему, становится не язык, а задачи и алгоритмы. В тех проектах, где работал я, сложности появлялись не из-за того, что Python «медленный» а из-за того, что какие-то задачи в принципе в лоб быстро сделать невозможно. И кэширование применить невозможно (потому что каждый вызов кода должен был возвращать уникальные данные). Приходилось придумывать какие-то алгоритмы и структуры данных, чтобы можно было максимально быстро генерировать требуемую информацию. И напиши это место хоть на C, ничего не изменилось бы, так как требовалось достать сотни тысяч строк из базы данных, и произвести над ними какие-то действия.
Кстати, Reddit, если не ошибаюсь, на Python написан, а это очень высоконагруженный сайт.
JekaMas
Бывает, что и в язык. Никто в здравом уме и трезвой памяти не будет делать жадные до данных алгоритмы на php, опыт был. Один и тот же алгоритм выявления спама на php съедал 32+ оперативки и прогноз работы был в день. Лоб в лоб переписанный на java без знания java алгоритм отработал в пределах 5и минут. Это времена php 5.6.
immaculate
В PHP нет сборщика мусора, во всяком случае, раньше не было. Так что неудивительно, надо было все-таки сравнивать хотя бы с минимально полноценным языком.
JekaMas
Только что вы говорили, что язык не имеет значения и уже перешли к тому, что PHP — неполноценный? Вы противоречите своему утверждению «Даже если проект добирается до такой точки, камнем преткновения, по-моему, становится не язык, а задачи и алгоритмы».
Кстати, python на той задаче бинарной кластеризации показал не лучший результат.
JekaMas
И кстати http://php.net/manual/ru/features.gc.php
Antervis
погодите. Сборщик мусора не увеличивает быстродействие (за исключением редких случаев, когда вм за сотни циклов понимает, что можно перевести пару выделения/освобождения памяти с кучи на стек).
Понятно, что оптимизировать питон в питон вряд ли есть резон, но если исходить из принципа достаточной эффективности, то далеко не всегда есть резон переписывать в си то, что достаточно быстро отработает на джаве. А иначе и выбора-то нет.