Опубликовано (https://blog.pyston.org/2017/01/31/pyston-0-6-1-released-and.../) обновление проекта Pyston 0.6.1 (http://www.pyston.org/), в рамках которого компанией Dropbox развивалась высокопроизводительная реализация языка Python, созданная с использованием наработок проекта LLVM и использующая JIT-компиляцию для достижения высокой производительности. Код Pyston написан на языке C++ и распространяется (https://github.com/dropbox/pyston) под лицензией Apache.
Кроме исправления ошибок и устранения несовместимостей в новой версии в представлены значительные оптимизации производительности. При проведении штатных тестов Pyston 0.6.1 работает в среднем на 95% быстрее, чем CPython, в более реалистичных тестах на основе реальных web-приложений Pyston обгоняет CPython на 48%, а на серверах Dropbox - на 10%.К сожалению дальнейшее развитие проекта будет зависеть от интереса к нему независимого сообщества - компания Dropbox приняла решение прекратить разработку своими силами и Pyston 0.6.1 стал последним релизом, подготовленным инженерами Dropbox в своё основное рабочее время. Проанализировав состояние проекта компания пришла к выводу, что на поддержание совместимости с CPython и обеспечение приемлемого потребления памяти требуется значительно больше ресурсов и затрат, чем ожидалось. Но решающим фактором отказа от проекта Pyston стали не оправдавшиеся завышенные надежды на производительность Pyston.
Несмотря на неплохие показатели в синтетических тестах, на реальных серверах Dropbox использование Pyston позволило добиться лишь ускорения кода на 10%, что значительно меньше ожидаемого (планировалось добиться повышения производительности как минимум в два раза). В текущем виде Pyston обеспечивает неплохую совместимость с CPython, достаточную для выполнения серверного кода Dropbox, но всё время при разработке ушло на обеспечение совместимости и снижение потребления памяти, а не на оптимизацию специфичных нагрузок. В итоге, более реалистичным путём оптимизации в Dropbox стала переработка кода, требующего высокой производительности, на других языках, таких как Go.
В ближайшее время занятые в разработке Pyston инженеры будут переключены на работу над другими проектами. Код Pyston останется открытым и доступным для развития сообществом. Рассматриваются возможности продолжения развития отдельных частей проекта или их переноса в CPython.
Напомним, что в отличие от проекта PyPy (https://www.opennet.me/opennews/art.shtml?num=43218), также продвигающего идею применения JIT для ускорения выполнения Python-скриптов, в Pyston используется не трассирующий JIT, базирующийся на компиляции в машинный код часто выполняемых циклов, а применяемый в современных JavaScript-движках JIT на основе трансляции отдельных методов (method-at-a-time), который, по мнению инженеров Dropbox, является более перспективной технологией. Принцип работы Pyston сводится к разбору кода на языке Python и его трансляции в промежуточное представление LLVM (IR, Intermediate Representation). Далее IR-представление проходит обработку в оптимизаторе LLVM и передаётся для исполнения в JIT-движок LLVM, который преобразует IR-представление в машинный код.Для получения информации о типах переменных для программ на динамическом языке Python применяется техника вероятностного предсказания типов объектов с последующим уточнением правильности выбора типа в процессе выполнения. Таким образом Pyston постоянно варьирует выполнение между двумя ветками - быстрой, когда данные о предсказанных типах подтверждаются, и медленной, используемой в случае рассогласования данных о типе. Работа может осуществляться в многопоточном режиме, допускающем параллельное выполнение нескольких нитей кода на языке Python и избавленном от глобальной блокировки интерпретатора (GIL, global interpreter lock).
<
URL: https://blog.pyston.org/2017/01/31/pyston-0-6-1-released-and.../
Новость: http://www.opennet.me/opennews/art.shtml?num=45984
Ускорить один из популярных языков в два раза не так уж и просто, кто бы мог подумать?
в PHP этого добились
Это потому, что они поддержку mysql выкинули. Решительные ребята ведь ; )
Это потому что go вылупился а там еще rust какой-то болтается и прочие node.js. Тут то до всех, включая dropbox-а и дошло что мучаться с попытками привязато ракету к гадюке совершенно не обязательно. Достаточно взять более вменяемо сделанный ЯП. Вот Dropbox и переписал все сначала на go а потом и на rust. Потом наверное на что-нибудь еще перепишут и это будет все-таки проще чем тянуть свой JIT.
В PHP важна производительность. В 99% школьных лаб не нужна. Вот вся разница.
> В PHP важна производительность. В 99% школьных лаб не нужна. Вот вся
> разница.Пых у нас теперь прямо эталон, а пыхпышники, рассуждающие о производительности, производят впечатление знающих и рассудительных людей, а не мартышек в очках и с микроскопами!
Про pypy мартышки уже забыли, да?
https://blog.famzah.net/2016/02/09/cpp-vs-python-vs-perl-vs-.../
> The benchmarks here do not try to be complete, as they are showing the performance
> of the languages in one aspect, and mainly: loops, dynamic arrays with numbers,
> basic math operations.Это первое. Второе - я не рассуждаю о производительности вообще. Я лишь заявил, что для сайтов она имеет вполне определенное значение. Третье - в тесте php7 есть много мест, которые реализованы абсолютно не оптимально. Если требуется производительность, я бы реализовал всё иначе. Используется ли приведенный подход среднестатистически? Я не знаю и сомневаюсь. Ничего в пользу этого довода там не приведено. А значит и заявлять что он медленнее PyPy даже для представленных задач - неверно.
Вот посмотрите сами, на какой код Вы ссылаетесь:
> $j = (int)(($m*$m - 3) / 2);
> $s[$j] = 0;
> while ($j < $half) {
> $s[$j] = 0;
> $j += $m;
> }Ничего не смущает?
Только #$@%^ будет сравнивать ЯП на основе одной числодробилки. Где XS-версия для Perl?! И еще зовет себя программистом... А другие пограммисты ему верят и распространяют эту #$%$^.
> Только #$@%^ будет сравнивать ЯП на основе одной числодробилки. Где XS-версия для
> Perl?! И еще зовет себя программистом... А другие пограммисты ему верят
> и распространяют эту #$%$^.О, как у пыхапистов бомбануло. Кстати, как назвать тех, кто сравнивает вообще без всяких числодробилок?
Вообще, пыхописты, рассуждающие о производительности, смешны. Пых даже в своей нише хорошо так сливает:
https://www.techempower.com/benchmarks/
https://www.techempower.com/benchmarks/#section=code&hw=ph&t...
Сливаете непроверенные источники ради разведения холивара, доверия вам нет.
> Сливаете непроверенные источники ради разведения холивара, доверия вам нет.Зато голословные умствования анонима насчет производительности PHP - отличный и авторитетный источник, ага. Этож анонимЪ! Понимать надожЪ!
И конечно же techempower «непроверенный».
Подумаешь, сорцы, описания и т.д. есть
https://github.com/TechEmpower/FrameworkBenchmarks/
https://www.techempower.com/benchmarks/#section=code
http://frameworkbenchmarks.readthedocs.org/
ведь если пых там не побеждает, значит все враки и холивары. Удобная позиция, спору нет.
Успокойтесь. Я оценил Ваш уровень компетентности по первой Вашей ссылке:
> Про pypy мартышки уже забыли, да?
> https://blog.famzah.net/2016/02/09/cpp-vs-python-vs-perl-vs-.../Мой вердикт - там фигня, а не тесты. Хотите поспорить, давайте приводите свои аргументы, а я приведу свои.
Анализировать другие кучи ссылок, которые Вы наваливаете в каждом комментарии, я не собираюсь.
> Мой вердикт - там фигня, а не тесты. Хотите поспорить, давайте приводите
> свои аргументы, а я приведу свои.Спорить с пыхапистоми о производительности? Зачем? Это все равно что обсуждать музыкальное произведение с теми, кто слышал его только в «напеве Рабиновича».
Динамика в ЯП сама по себе вещь, производительности никак не способствующая, а уж совместно со слабой типизацией – вообще убойное для анализатора и оптимизатора сочетание.
Из-за этого, примитивных типов там, как таковых нет.Есть универсальные конструкты-обертки, способные вместить любой нужный тип плюс информацию о текущем. В похапе это zval:
https://github.com/php/php-src/blob/master/Zend/zend_types.h...
typedef struct _zval_struct zval;typedef union _zend_value {
zend_long lval; /* long value */
double dval; /* double value */
zend_refcounted *counted;
zend_string *str;
zend_array *arr;
zend_object *obj;
zend_resource *res;
zend_reference *ref;
zend_ast_ref *ast;
zval *zv;
void *ptr;
zend_class_entry *ce;
zend_function *func;
struct {
uint32_t w1;
uint32_t w2;
} ww;
} zend_value;struct _zval_struct {
zend_value value; /* value */
union {
struct {
ZEND_ENDIAN_LOHI_4(
zend_uchar type, /* active type */
zend_uchar type_flags,
zend_uchar const_flags,
zend_uchar reserved) /* call info for EX(This) */
} v;
uint32_t type_info;
} u1;
union {
uint32_t next; /* hash collision chain */
uint32_t cache_slot; /* literal cache slot */
uint32_t lineno; /* line number (for ast nodes) */
uint32_t num_args; /* arguments number for EX(This) */
uint32_t fe_pos; /* foreach position */
uint32_t fe_iter_idx; /* foreach iterator index */
uint32_t access_flags; /* class constant access flags */
uint32_t property_guard; /* single property guard */
uint32_t extra; /* not further specified */
} u2;
};
Поэтому, на самом деле, даже просто «добраться до начинки», т.е. самих данных переменной, относительно недешево, потому как сначала нужно прочитать и определить тип.А уж про операции я и объяснять не буду. Пускай пыхпышники и далее считают, что
add REG1, REG2
и
PUSH zval1
PUSH zval2
MOV REG1, [zval1+type_info*magic_val]
CALL [add_op_offset + REG1]
...
здесь еще следует определение типа для второй переменной и ее приведение в случае необходимости.
почти одинаковы по затратам. Ведь они точно знают, что мифические бранчпредикторы давно вышли на уровень ораклов, все кэши отменили за ненадобностью и поэтому ПоХаПе и производительность можно вполне упоминать в одном предложении )
>О, как у пыхапистов бомбануло.Да, бомбануло. Я любитель.
>Кстати, как назвать тех, кто сравнивает вообще без всяких числодробилок?Без понятия. Я что, похож на гида для туристов?
>Вообще, пыхописты, рассуждающие о производительности, смешны.Мужик. Протри глаза! Я говорил про Perl. Perl это не PHP. Ты это понимаешь? [когда вынимаешь].
Настоящий программист это человек, который разбирается в том, как устроен компьютер и как устроен, используемый ЯП. Увы, человек показал лишь, что он лишь начинающий пограммист, который даже школу не закончил. Все его выводы сводятся к ОЧЕВИДНЫМ вещам, что рано или поздно 100500 вызовов функций-оберток затормозят работу программы в 100500 раз.
Какой нормальный программист не знает, что PHP медленней C/C++? Какой нормальный программист не знает, что Python или Perl медленней, чем тот же PHP? Почему (см. выше) так происходит ОЧЕВИДНО любому нормальному программисту.
Нет же. Находится выскочка программист, который НЕ осилил программирование, но именует себя программистом, разработчиком. Он не разобрался как работает компьютер. Он не разобрался во ВСЕХ возможностях выбранного ЯП. И именно поэтому он выдает высеры ВМЕСТО настоящих исследований. А настоящее исследование, в случае его примера с простой как дважды два число-дробилкой, является написание тестов с использованием ВСЕХ возможностей ЯП. А именно: взять и написать XS-версию под Perl. Взять и написать версию сишного модуля для Python, для PHP.
Почему люди, которые написали плагины для работы с MySQL написали их на сишке, а не на чистом PHP? Почему не написали их на чистом Python? Почему не написали их на чистом Perl?
Потому что их писали программисты. А мужик, который выДал свои ничего не значащие тесты просто не в праве себя именовать программистом, а тем более ему должно быть стыдно рассказывать на весь Интернет столь очевидные для детей вещи. Хватит быть идиотами в глазах идиотов, читая их бред.
> Какой нормальный программист
> не знает, что Python или Perl медленней, чем тот же PHP?
> Почему (см. выше) так происходит ОЧЕВИДНО любому нормальному программисту.А можно поподробнее, что там именно и кому должно быть очевидно?
А то мне вот очевидно, что реализовать интерпретатор с JIT компилятором для строго типизированного, пусть и динамического, языка многим проще, чем для такого же, но слабо типизированного. На что, как бы, намекают pypy, cделанный пусть и не на коленке, но в значительной мере студентами и дающий прирост при использовании джанги или твистев в три-четыре раза.
И рhpшный hhvm, пилящийся кучу лет фейспуком, где уже 16% ускорение вызывает бурю восторга.
>А можно поподробнее, что там именно и кому должно быть очевидно?Если тебя это действительно интересует, то ты берешь и открываешь исходники. Ты берешь и читаешь их. Ты берешь и разбираешься в том, в чем якобы ты хочешь быть профи.
Если ты не прочитал книгу, фильм, и т.д., ты имеешь право высказывать свое мнение об этом. Но не имеешь право выдавать это мнение за конструктивную критику/информацию. Твое мнение никого не волнует. Нормальный человек не бросается словами. Профессионал разбирается в деталях и не пустословит, не пишет г#$%^код. И не пытается делать бесмысленные выводы из бесмысленных опытов. Такие опыты, уровня неандертальца, в 21 веке НИКОМУ НЕ НУЖНЫ.
Программист, который пытается высказать критику по поводу какого-либо ЯП обязан досконально знать его особенности. И уметь использовать его слабые и сильные стороны.
Почему-то недопрограммист узнал откуда-то про "-O2". Однако, не узнал про то, что 40% модулей/плагинов для интерпретиерумых ЯП написано на Си. Ради чего? Ну, это сложно, надо разбираться в сишном коде. Лучше пог#$%^кожу. Покажу нубам какие плюсы крутые! Смотрите, я гений! Написал никому ненужный тест и выдаю это за истину (по факту ложь).
>А то мне вот очевидно, что реализовать интерпретатор с JIT компилятором для строго типизированного, пусть и динамического, языка многим проще, чем для такого же, но слабо типизированного.
Окей. Пили. А другие пилят то, что они хотят и могут. Давай ты вместо своих хотелок сделаешь что ты хочешь и докажешь свои домыслы на деле.
>На что, как бы, намекают pypy, cделанный пусть и не на коленке, но в значительной мере студентами и дающий прирост при использовании джанги или твистев в три-четыре раза.
Кто они? Где их доказательства? О ком ты вообще?
>И рhpшный hhvm, пилящийся кучу лет фейспуком, где уже 16% ускорение вызывает бурю восторга.
А это к чему? hhvm решает свой круг задач. Разработчики hhvm четко и ясно объясняют плюсы и минусы. Они не писали hhvm как замену PHP. Они решали свои задачи, делая это как профессионалы.
Восторг лишь у макак, которые НЕ хотят разбираться в деталях. У нормальных программистов взгляд на hhvm точно такой же как на Pyston: есть плюсы, есть минусы, есть круг задач где ЭТО решение катит, и НЕ катит.
>>> не знает, что Python или Perl медленней, чем тот же PHP?
>>> Почему (см. выше) так происходит ОЧЕВИДНО любому нормальному программисту.
>>А можно поподробнее, что там именно и кому должно быть очевидно?
> Если тебя это действительно интересует, то ты берешь и открываешь исходники. Ты
> берешь и читаешь их. Ты берешь и разбираешься в том, в чем якобы ты хочешь быть профи.Берешь, открываешь исходники чего-то (CPython, Jthon, Rakudo?), читаешь. И сразу становится очевидно, что Perl или Питон медленнее. В общем, эпичное деление на ноль. Да еще и с какими-то совсем левыми передергами про «профи».
> Если ты не прочитал книгу, фильм, и т.д., ты имеешь право высказывать
> свое мнение об этом. Но не имеешь право выдавать это мнение
> за конструктивную критику/информацию. Твое мнение никого не волнует. Нормальный человек
> не бросается словами. Профессионал разбирается в деталях и не пустословит, не
> пишет г#$%^код. И не пытается делать бесмысленные выводы из бесмысленных опытов.
> Такие опыты, уровня неандертальца, в 21 веке НИКОМУ НЕ НУЖНЫ.Понятно, пруфов не будет, будет балабольство о професиАнализЪме и какие-то отсылки на что-то там.
>>А то мне вот очевидно, что реализовать интерпретатор с JIT компилятором для строго типизированного, пусть и динамического, языка многим проще, чем для такого же, но слабо типизированного.
> Окей. Пили. А другие пилят то, что они хотят и могут. Давай ты вместо своих хотелок сделаешь что ты хочешь и докажешь свои домыслы на деле.А в огороде бузина! Т.е. ты даже не понял о чем речь, но мнение заимел? Разъясняю на пальцах: перл с питоном имеют строгую типизацию. PHP нет. PyPy - это питоновский JIT компилятор. Причем тут хотелки и домыслы? Мне домысливать особо ничего не надо, я и так в курсе принципов работы как оптимизаторов, так и трассировочных JIT. Любой НОРМАЛЬНЫЙ прорграмист тоже.
>>На что, как бы, намекают pypy, cделанный пусть и не на коленке, но в значительной мере студентами и дающий прирост при использовании джанги или твистев в три-четыре раза.
> Кто они? Где их доказательства? О ком ты вообще?Опять проблемы с пониманием прочитанного?
Да хотя бы пай-пайщики сами:
http://speed.pypy.org/timeline/#/?exe=1,5&base=2+472&ben=django&env=1&revs=200&equid=off
Ну или https://lincolnloop.com/blog/faster-django-sites-pypy/
ну и самостоятельную проверку никто не отменял, благо это не ракетные технологии.
>>И рhpшный hhvm, пилящийся кучу лет фейспуком, где уже 16% ускорение вызывает бурю восторга.
> А это к чему?Это все еще о JITах и быстротах с медленностями в целом и о возможностях оптимизации в частности, о НОРМАЛЬНЫЙ программист.
> hhvm решает свой круг задач. Разработчики hhvm четко
> и ясно объясняют плюсы и минусы. Они не писали hhvm как
> замену PHP. Они решали свои задачи, делая это как профессионалы.
> Они не писали hhvm как замену PHP
> замену PHPсмешались в кучу кони, люди ... рукалицо.жпг
>Разъясняю на пальцах: перл с питоном имеют строгую типизацию.В каком месте? Я даже боюсь узнать правду. Не ужели ты узнал, что оба написаны на Си, который действительно имеет строгую типизацию. Или ты имел ввиду что-то иное?
Давай объясни мне где тут строгая типизация: http://ideone.com/2qNQkm
Дальше даже комментировать не буду. Жду ответа на твой фейл.
>>Разъясняю на пальцах: перл с питоном имеют строгую типизацию.
> В каком месте? Я даже боюсь узнать правду. Не ужели ты узнал,
> что оба написаны на Си,_Реализации_ того же питона есть не только на си, но и на яве или шарпе.
> который действительно имеет строгую типизацию.Cи и строгая типизация? Понятно.
% cat weak.c && gcc -Wall -Wextra -Wpedantic -std=c99 weak.c -o weak && ./weak
#include <stdio.h>
int main(void) {
char x = '0';
struct { int x,y;} mystruct = {0xDEAD0000, 2};
printf("Hello %d %x"+1, x + 2, *(int*) &mystruct + 0xC0DE);
return 0;
}
ello 50 deadc0de> Давай объясни мне где тут строгая типизация: http://ideone.com/2qNQkm
Use strict, Luke. Use warnings, Luke. Use diagnostics, Luke. Не забывай про RTFM
perldoc perlops
> DESCRIPTION
> In Perl, the operator determines what operation is performed, independent
> of the type of the operands. For example "$x + $y" is always a numeric
> addition, and if $x or $y do not contain numbers, an attempt is made to
> convert them to numbers first.perldoc -f ioclt
> if OS returns: then Perl returns:
> -1 undefined value
> 0 string "0 but true"
> The special string "0 but true" is exempt from "Argument "..."
> isn't numeric" warnings on improper numeric conversions.https://github.com/Perl/perl5/blob/v5.25.9/numeric.c#L1014
if (s >= send)
return numtype;
if (len == 10 && _memEQs(pv, "0 but true")) {
и сила битов пребудет с тобой!
% perl -lwe 'print 0 == "0 but tru";'
Argument "0 but tru" isn't numeric in numeric eq (==) at -e line 1
>Cи и строгая типизация? Понятно.Я зафейлился насчет строгой типизации. Как и ты. Но, я любитель, мне можно. Я исправляюсь:
Итак, мне лично пофиг где какая типизация, пусть археологи и историки определяют, что есть что. Однако, по делу:
C: слабая статическая типизация
Perl: слабая динамическая типизация
Python: сильная динамическая типизацияЕсли говорить просто, то в сишке все есть число, поэтому приведение типов (слабость типизации) проявляется в том, что ЛЮБОЙ тип можно превратить число. А число есть адрес в памяти. Что в итоге дает доступ к той или иной переменной.
Говоря про Perl, в нем все есть строка, либо число. В зависимости от _контекста_ Perl выбирает, что взять за основу: число или строку.
>Argument "0 but tru" isn't numeric in numeric eq (==) at -e line 1
Что ты этим хотел доказать? Ты хоть понимаешь что это варнинг генерируется в рантайме? А в Python вообще все зашибись: http://ideone.com/uPfqlK
Т.о. чтобы защитить код от подобной ошибки ты должен явно объяснять Perl, что тебе нужно сравнивать числа:
shell> perl -le 'print 0 == 0 + "0 but true"'
shell> 1 # операция валиднаСтрока 0 + $string <-- классический хинт/хак для пояснения Perl, что надо все воспринимать как числа.
Аналогично, чтобы пояснить Perl, что все есть строка используется хинт конкатенации: $number_or_string . ""; <-- моментально конвертируем $number_or_string в строку, т.к. дальше 100% будем работать в контексте строковых литералов. Использовать eq/ne вместо ==/!= не охватывает все задачи работы со строками:
shell> perl -le 'use strict; use warnings; my $num = 123; print index $num, "a";'
shell> -1Упс, Perl не выпленул варнинг, что работаем не со строкой. Ай-ай, надо срочно накатать плаксивое письмо, чтобы добавили варнинг на этот счет! Мало в Perl идиотских варнингов напихали!
>и сила битов пребудет с тобой!
Да-да, что ты хотел сказать? Я в JIT не бум-бум. Ты в Perl не про. А разговор был про то, что кто-то не умеет писать модули на сишке для Perl, Python, PHP.
> Говоря про Perl, в нем все есть строка, либо число. В зависимости
> от _контекста_ Perl выбирает, что взять за основу: число или строку.Тут уже выше упоминали RTFM:
In Perl, the operator determines what operation is performed, independent
of the type of the operands. For example "$x + $y" is always a numeric
addition, and if $x or $y do not contain numbers, an attempt is made to
convert them to numbers first.This is in contrast to many other dynamic languages, where the operation
is determined by the type of the first argument. It also means that Perl
has two versions of some operators, one for numeric and one for string
comparison. For example "$x == $y" compares two numbers for equality, and
"$x eq $y" compares two strings.Хотя типизация в перловке предмет долголетних споров и про то, что у перла все же сильная типизация, упоминают намного более авторитетные источники, чем анонимы опеннета. Как впрочем и наоборот.
>>Argument "0 but tru" isn't numeric in numeric eq (==) at -e line 1
> Что ты этим хотел доказать? Ты хоть понимаешь что это варнинг генерируется
> в рантайме? А в Python вообще все зашибись: http://ideone.com/uPfqlKИ что? В питоне тоже все генерируется в рантайме. Динамическая типизация, как она есть.
> Т.о. чтобы защитить код от подобной ошибки ты должен явно объяснять Perl,
> что тебе нужно сравнивать числа:
> shell> perl -le 'print 0 == 0 + "0 but true"'
> shell> 1 # операция валиднаОпять же, выше упоминали RTFM вместе со ссылочкой на код. Конкретно "0 but true" грязный хак на уровне интерпретатора, поэтому приводить его в качестве примера не очень удачная мысль.
> Строка 0 + $string <-- классический хинт/хак для пояснения Perl, что надо
> все воспринимать как числа.Это не хинт и не хак. Это особенность грамматики/ЯП. Cм.
> In Perl, the operator determines what operation is performed, independent
> of the type of the operands.===
> shell> perl -le 'use strict; use warnings; my $num = 123; print
> index $num, "a";'
> shell> -1
> Упс, Perl не выпленул варнинг, что работаем не со строкой. Ай-ай, надо
> срочно накатать плаксивое письмо, чтобы добавили варнинг на этот счет! Мало
> в Perl идиотских варнингов напихали!Это, извините, полиморфизм и не говорит ни о чем. Вроде как даже в хаскеле прокатывает.
ЗЫ: кстати, есть определенное подозрение, что анонимов на опеннете значительно > 2
>Тут уже выше упоминали RTFMИ что? К чему ты это сказал? Ты вообще понял фразу: In Perl, the operator determines what operation is performed? Давай вместе, оператор. определяет. какая. операция. будет. исполнена. Ты это понял? Да, в Perl есть два оператора сравнения: один для чисел, другой для строк. Что логично, нужно же в кой-то век вызвать strcmp (и его производные). А может и memcmp. Не суть.
>Хотя типизация в перловке предмет долголетних споров и про то, что у перла все же сильная типизация, упоминают намного более авторитетные источники, чем анонимы опеннета. Как впрочем и наоборот.
Мне лично пофиг кто с кем спорит. Сейчас вот кто-то не может ответить по делу, но как лоровское дитя переходит на личности.
>И что? В питоне тоже все генерируется в рантайме. Динамическая типизация, как она есть.
Пруф. Без пруфа это пустословие. Где такое же сообщение для Python? Может чему выучусь, хотя пистон мне до лампочки.
>Опять же, выше упоминали RTFM вместе со ссылочкой на код. Конкретно "0 but true" грязный хак на уровне интерпретатора, поэтому приводить его в качестве примера не очень удачная мысль.
Пфффф. Мужик просто сделал греп по манам, по исходнику перла, ибо фраза заезженная. Попробуй вместо "0 but true" использовать "дураки на Волге" и эффект не изменится. Пруф выше из RTFM просто фуфло, я оставил это для профи, посмеялись от души, наверное.
>===
Ого. Это оператор? Из PHP? Из Python? Из JavaScript? Да. Ведь, в Perl его нету! Для сравнения строк нужно юзать "eq", чудо.
>Это, извините, полиморфизм и не говорит ни о чем. Вроде как даже в хаскеле прокатывает.Что?! ПОЛИМОРФИЗМ? В сути динамического приведения типов? Ты серьезно, мээн?
Давай, попытка номер два с пруфами из манов или RTFM, лучше из perldoc, конечно, еще раз донесите, пожалуйста, в чем именно я ошибъся. Я вас не понял, сударь.
>>> Говоря про Perl, в нем все есть строка, либо число. В зависимости
>>> от _контекста_ Perl выбирает, что взять за основу: число или строку.
>>Тут уже выше упоминали RTFM
> И что? К чему ты это сказал? Ты вообще понял фразу: In
> Perl, the operator determines what operation is performed? Давай вместе, оператор.
> определяет. какая. операция. будет. исполнена. Ты это понял?Ты не видишь разницу между контекстом и оператором? Оператор не зависит от контекста. Это не хак и не хинт, это так определено в языке. Или ты имел в виду «в контексте оператора»? Тогда причем тут «выбор основы»?
>>Хотя типизация в перловке предмет долголетних споров и про то, что у перла все же сильная типизация, упоминают намного более авторитетные источники, чем анонимы опеннета. Как впрочем и наоборот.
> Мне лично пофиг кто с кем спорит. Сейчас вот кто-то не может
> ответить по делу, но как лоровское дитя переходит на личности.Чудило, я тоже вроде как из под анона пишу. Где ты переход на личности углядел? В том, что тот же Рандал Шварц, возможно, будет поавторитетнее группы анонимов опеннета?
>>И что? В питоне тоже все генерируется в рантайме. Динамическая типизация, как она есть.
> Пруф. Без пруфа это пустословие. Где такое же сообщение для Python? Может
> чему выучусь, хотя пистон мне до лампочки.Пруф чего? Того что int не равен строке?
% python -c 'print 1 == "0"'
False
% python -c 'print 0 == ""'
False
% python -c 'print 0 == "0"'
False
О чем это должно говорить? О слабой типизации питона? Или просто другом подходе?
https://docs.python.org/2/library/stdtypes.html
> Objects of different types, except different numeric types and different string types,
> never compare equal; such objects are ordered consistently but arbitrarily (so that
> sorting a heterogeneous array yields a consistent result).
> Non-identical instances of a class normally compare as non-equal unless the class
> defines the __eq__() method or the __cmp__() method.Или тебе нужны рантайм сообщения?
% python -c 'print 1+"0"'
Traceback (most recent call last):
File "<string>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'int' and 'str
% python -c 'print int.__cmp__(1,"")'
Traceback (most recent call last):
File "<string>", line 1, in <module>
TypeError: int.__cmp__(x,y) requires y to be a 'int', not a 'str'
% python -c 'print str.__eq__("0",2)'
NotImplemented
А теперь фокус:
>>> class X(int):... def __add__(self, o): return X(int.__add__(self, int(o)))
...
...
>>> X(2) + 2 + 37
>>> X(2) + 2 + "3"7
>>> X(2) + 2 + "3d"Traceback (most recent call last):
File "<input>", line 1, in <module>
X(2) + 2 + "3d"
File "<input>", line 2, in __add__
def __add__(self, o): return X(int.__add__(self, int(o)))
ValueError: invalid literal for int() with base 10: '3d'
>>>
оператор внезапно зависит от контекста. Это теперь неявное преобразование?
>>Опять же, выше упоминали RTFM вместе со ссылочкой на код. Конкретно "0 but true" грязный хак на уровне интерпретатора, поэтому приводить его в качестве примера не очень удачная мысль.
> Пфффф. Мужик просто сделал греп по манам, по исходнику перла, ибо фраза
> заезженная. Попробуй вместо "0 but true" использовать "дураки на Волге" и
> эффект не изменится.
% perl -wle 'print 0 == 0 + "дураки на Волге"'
Argument "дураки на Волге" isn't numeric in addition (+) at -e line 1.>>===
> Ого. Это оператор? Из PHP? Из Python? Из JavaScript? Да. Ведь, в
> Perl его нету! Для сравнения строк нужно юзать "eq", чудо.Остынь, чудило. Это разделитель цитатируемых кусков текста. Пустые строки между цитатами движок опеннета проглатывает.
>>Это, извините, полиморфизм и не говорит ни о чем. Вроде как даже в хаскеле прокатывает.
> Что?! ПОЛИМОРФИЗМ? В сути динамического приведения типов? Ты серьезно, мээн?Ты путаешь теплое с мягким. Возможность вызвать фунцию с разными типами аргументов и собственно, реализацию.
http://ideone.com/hiNBFn
#include <iostream>
using namespace std;
int x(int a) {return a + 3;}
int x(double a) {return (int)a;}
int main() {
// your code goes here
std::cout << "Hello, World!\n" << "x(3):" << x(3) << "\nx(3.0):" << x(3.0);
return 0;
}
поэтому и вызов функции в качестве примера ни о чем не говорит.
>Или ты имел в виду «в контексте оператора»? Тогда причем тут «выбор основы»?В контексте оператора естевенно. Ведь, если подумать, кроме операторов ничего нет. Присвоить значение -- используем оператор присваивания. Сравнение -- используем оператор сравнения. Обратиться к n-элементу массива -- используем оператор доступа. И тут есть другой ньюанс смешивание операторов в одной конструкции. Что будет тут тебе известно:
$array[1] = <STDIN>;
А тут, ты знаешь, что будет? Давай без помощи use warnings; Т.к. в других ситуациях он тебя и не спасет:
@array[1] = <STDIN>;
Вот, подумай почему "в контексте опрератора" присваивания получаем разные результаты? Может потому что нет никаких "контекстов операторов"?
А есть контексты списка, скаляра, никакого значения? Увы, ты пропустил момент, что число в перле это тоже адрес чего-либо, а строка она и в Африке строка. Пример 0 == "0 but true" показывает как Perl хитрописан, ведь если ты не прочитаешь исходники, ты не поймешь, почему тут все валидно:
#!/usr/bin/perl
use strict;
use warnings;if (0 == "0 but true") {
print "but true\n";
}Оцениваем: http://ideone.com/iViUX3
А тут, все иначе:
#!/usr/bin/perl
use strict;
use warnings;if (0 == "устал повотрять 100500 раз, что надо читать копипасты") {
print "but true\n";
}Оцениваем (увы, ideone имеет свою патченную версию перл, где варнинга нет, а должен): http://ideone.com/Si7wM2
>О чем это должно говорить? О слабой типизации питона? Или просто другом подходе?
Мне ничего не говорит. Извини, питон меня не интересует, поэтому я не выеживаюсь, а задаю тактично вопросы. А ты вот считаешь себя гуру перла, разве нет?
Кстати, зачем наезжать на меня, когда очевидно, что в одних и тех же конструкция ЯП ведут себя по-разному (что логично):
shell> # перл любит выплевывать пустую строку в случае "False", делаем это за него
shell> perl -le 'print ((1 == "0") ? "true" : "false");'
false
shell> perl -le 'print ((1 == "") ? "true" : "false");'
false
shell> perl -le 'print ((0 == "0") ? "true" : "false");'
true>Или тебе нужны рантайм сообщения?
Ох. Мне нужны были сообщения какие выплевывает перл:
Argument "abc" isn't numeric in numeric eq (==) at abc.pl line 6.
В райнтайме, а не в момент компиляции, ибо для Perl ошибка выше не фатальная: типы он приведет кое-как и код, кое-как, отработает. Ну, ты привел доказательства, меня они устраивают. Ок, спасибо.
>оператор внезапно зависит от контекста. Это теперь неявное преобразование?
Контекста чего? Я в Python не бум-бум, но давай читать вместе:
ValueError: invalid literal for int() with base 10: '3d'
Давай смотреть, что будет и в перле одновременно:
shell> perl -wle 'print int("3a")'
Argument "3a" isn't numeric in int at -e line 1.
3Ну, как видишь, работает все примерно одинаково. Дальше что? Я, как не про по питону, надеялся увидеть сильную типизацию, ну, чтобы на этапе компиляции все валилось, а че-то примеры походу неправильно выбраны, поэтому спор заходит в тупик.
В итоге, википедия дает все ответы:
Python uses duck typing and has typed objects but untyped variable names. Type constraints are not checked at compile time; rather, operations on an object may fail, signifying that the given object is not of a suitable type. Despite being dynamically typed, Python is strongly typed, forbidding operations that are not well-defined (for example, adding a number to a string) rather than silently attempting to make sense of them.
https://en.wikipedia.org/wiki/Python_%28programming_lan...
Чтение https://en.wikipedia.org/wiki/Duck_typing дает все ответы. Да, я зафейлился, не вникся в детали ЯП и оказался не прав: мои надежды насчет строгой типизации не оправдались. И это хорошо. Это еще раз подтвердило правильность моих мыслей, что профессиональный программист ДОСКАНАЛЬНО изучает ЯП, который он хочет критиковать.
Возможно, ты это знал и подловил меня. А, возможно, и сам не знал. Ибо спорим мы на этот счет уже трындец много времени.
>using namespace std;
Я в плюсах не бум-бум. Пиши на сишке, пожалуйста :) А лучше вообще закрыть спор или поспорить о чем-то другом.
>int x(double a) {return (int)a;}
Ты же понимаешь, что это платформозависимая конструкция? Почитай про извлечение квадратного корня в Quake III, будет интересно, а может это боян для тебя.
Основной usecase PHP это: https://www.techempower.com/benchmarks/#section=data-r13&hw=...Как всегда, пограммист не разобрался в вопросе и сдулся. Даже не стану отвечать почему и почему не так. Учись разбираться сам. Начни с изучения английского.
> Основной usecase PHP это: https://www.techempower.com/benchmarks/#section=data-r13&hw=...Вижу дарт, плюсы, го и яву перед пыхом, с хорошим таким отрывом.
> Как всегда, пограммист не разобрался в вопросе и сдулся. Даже не стану
> отвечать почему и почему не так. Учись разбираться сам. Начни с
> изучения английского.Самокритично.
>Вижу дарт, плюсы, го и яву перед пыхом, с хорошим таким отрывом.А чего ты ожидал?
>Самокритично.Нет, давай по делу. Скажи, когда ты в последний раз видел серваки на PHP без использования кэша. Кэш, который раздает nginx? Или все сайты только и делают, что сортируют что-то бесконечно. Всем сайтам нужен полноценный ORM, ну, со всякими там фабриками фабрик, создающих фабрики для фабрик?
И вообще, когда ты последний раз писал сам сайт хотя бы... ммм, на плюсах или яве? Именно такие как ты люди поднимали Кинопоиск 2. Нафиг кэшировать страницы, тпа это же ЯВА! Она в 100500 раз быстрее пыха. Пых для школоты. И что? На чем крутится кинопоиск до сих пор? На пыхе!
>>Вижу дарт, плюсы, го и яву перед пыхом, с хорошим таким отрывом.
> А чего ты ожидал?Лидирующего пыха, конечно же!
> Нет, давай по делу. Скажи, когда ты в последний раз видел серваки
> на PHP без использования кэша. Кэш, который раздает nginx? Или все
> сайты только и делают, что сортируют что-то бесконечно. Всем сайтам нужен
> полноценный ORM, ну, со всякими там фабриками фабрик, создающих фабрики для
> фабрик?Какие-то невнятные отмазки. То в пыхе важна производительность. То, теперь уже не очень, ведь можно кэшить. Будто кто-то запрещает использовать (микро)кэш с другими фреймворками в других ЯП.
> Нет, давай по делу.
> Именно такие как ты люди поднимали КинопоискОпределись уж, кто ты - деловой или Ванга.
> На чем крутится кинопоиск до сих пор? На пыхе!Главная городость пыховцев и вообще, аргУмент!
>Какие-то невнятные отмазки. То в пыхе важна производительность.Отмазки только у тебя. Про производительность я вообще не заикался. Заикался о ней некий недопограммист, который криво написал числодробилку для Perl. И недопрограммисты его поддержали.
>То, теперь уже не очень, ведь можно кэшить. Будто кто-то запрещает использовать (микро)кэш с другими фреймворками в других ЯП.
Ну, наконец-то! До тебя начинает кое-что доходить. Что не все так просто. А?
>Главная городость пыховцев и вообще, аргУмент!
Я любитель. Предпочитаю сишку и перл. На деле задачи решаются с использованием тех технологий, которые ставится решить. И только недопрограммисты будут везде кричать как быстры плюсы. Пофиг. Пиши хоть на ассемблере, твое вшивое мнение никому не интересно. Иди, учись делать отчеты и проводить настоящие исследования, разобравшись сперва что и как устроено. Досконально узнав, что и как устроено.
>> Какие-то невнятные отмазки. То в пыхе важна производительность.
> Отмазки только у тебя. Про производительность я вообще не заикался.http://www.opennet.me/openforum/vsluhforumID3/110365.html#66
> В PHP важна производительность.Перевод стрелок не удался.
>>То, теперь уже не очень, ведь можно кэшить. Будто кто-то запрещает использовать (микро)кэш с другими фреймворками в других ЯП.
> Ну, наконец-то! До тебя начинает кое-что доходить. Что не все так просто.Все таки деловая Ванга, да?
>>Главная городость пыховцев и вообще, аргУмент!
> Я любитель. Предпочитаю сишку и перл. На деле задачи решаются с использованием
> тех технологий, которые ставится решить. И только недопрограммисты будут везде кричать
> как быстры плюсы. Пофиг. Пиши хоть на ассемблере, твое вшивое мнение
> никому не интересно. Иди, учись делать отчеты и проводить настоящие исследования,
> разобравшись сперва что и как устроено. Досконально узнав, что и как
> устроено.Опять уход с темы в сторону, с переходом на личности и вангования о том, кто что знает и умеет? Ничего иного я не ожидал. Пишите еще, шлите открытки в /dev/null и все такое, мы ждем!
Анонимов на опеннет много. Каждый отвечает сам за себя. Я ничего не говорил про производительность, кроме критики в адрес малозначимого теста, упомянутого выше.>Опять уход с темы в сторону
Я никуда не ухожу. Задавай вопрос по делу. Рассказал о себе и это уже переход на личности? Раскритиковал по делу за откровенно слабо выполненное исследование -- уже переход на личности? Да, я тут вообще самый правильный критикун, остальные не могут не то, что скопипастить верный отрывок из пруфа, так они его копипастять, не читая суть отрывка! Я их за это не поливаю грязью, не опускаю потому что их "пруф" вообще не по делу.
>Пишите еще, шлите открытки в /dev/null и все такое, мы ждем!
ЛОР развалился походу. Вообще не с кем поговорить на IT-темы нормально. Лишь бы трындеть не по делу (это значит не давать пруфов и _ссылок_ откуда они взяты). Лишь бы лулзы ловить.
Вот, держи, смешное видео (БАЯН): https://www.youtube.com/watch?v=iIHS4UlSthY
> Анонимов на опеннет много.Но только ты один в белом? Или с чего ты так усердно педалируешь ссылку на 100500й, бессмысленный и беспощадный, микробенч в недобложике очередного студенташкольника?
>> Опять уход с темы в сторону
> Я никуда не ухожу. Задавай вопрос по делу.Еще раз, для тех кто в белом:
>>>>> На чем крутится кинопоиск до сих пор? На пыхе!Извини, но на аргумент это не тянет, о чем тебе, аккуратно процитировав, сообщили:
>>>> Главная городость пыховцев и вообще, аргУмент!А теперь твой ответ:
>>> Я любитель. Предпочитаю сишку и перл. На деле задачи решаются с использованием тех технологий, которые ставится решить.
>>> Пиши хоть на ассемблере, твое вшивое мнение никому не интересно.Если ты не считаешь это уходом с темы, то дальнейшее обсуждение бессмыслено.
>>> Пиши хоть на ассемблере, твое вшивое мнение никому не интересно
> Рассказал о себе и это уже переход на личности? Раскритиковал по делу за откровенно слабо выполненное исследование -- уже переход на личности?
> Да, я тут вообще самый правильный критикунНасчет критикуна не знаю, а вот дартаньян ты вполне неполохой.
>Если ты не считаешь это уходом с темы, то дальнейшее обсуждение бессмыслено.Шах и мат. ЛОЛ. Завернул зачетно, надо в рамку и на стенку. Ржу не могу. АХАХАХА. Я просил же задать конкретные вопросы. Нет, ты за свое: пытаешься меня в чем-то уличить, как-то унизить и т.д. Так что, да, АХАХАХАА, я, это, ухожу. Бессмыслеца. АХАХАХАА..
Смешно читать о производительности в сраном синхроне.
Так речь же идет не о Python а Cython, который и так был создан чтобы ускорить Python.
Некорректно сравнивать PHP и Cython.
Где ты тут Cython увидел? CPython == интерпретатор, который хостится на python.org
Поняли наконец, что идея использования питона в качестве высокопроизводительного языка ущербна изначально. Костыли только отсрочили момент осознания. Быстро, Дешево, Качественно - выбери только 2 критерия.
> Быстро, Дешево, Качественно - выбери только 2 критерия.Выбираю Быстро и Качественно. Что делать?
rust наверно?"быстро" -- я так понимаю имеется ввиду "быстро работает программа"
"дёшево" -- значит "быстро и дёшево написать на коленке программу"
"качественно" -- "на 1 процент кода -- допустить маленькую вероятность в нём ошибки"
"дёшево"+"качественно" это понятное дело ниша для Python
Вы шутите? Rust далеко не быстрый. Да и не слишком качественный с его существенными изменениями в минорных версиях.
В Rust статических оптимизаций доступно больше, чем в с++.
В тестах debian скорость алгоритмов, реализованных на rust была почти что такая же как и у C++.
Ruby? Elixir?
Ruby - это тот же Python: красив, удобен и фичаст, но тормозной и с GIL'ом.
А Elixir - это вообще в другую степь. Лучше уже node.js.
Что значит Elixir - в другую степь? http://www.phoenixframework.org/
> Ruby - это тот же Python: красив, удобен и фичаст, но тормозной
> и с GIL'ом.GIL используется и в CPython. А вот в JRuby его нет.
На счёт тормознутости - https://benchmarksgame.alioth.debian.org/u64q/ruby.htmlВ 0.5-0.7 раза "тормознее" питона, как-то странно говорить. Проще сказать "быстрее".
Избирательность зрения у тебя потрясающая. Сам дал ссылку, в которой ruby быстрее только на 5 тестах из 10 и медленнее на других 5, казалось бы паритет. Но нет, на вторые пять тестов можно просто закрыть глаза и сделать вид, что их нет.
потому что тесты какашные, сравните код тестов и убедитесь в этом сами.
Там вообще-то можно предложить свой вариант кода для любого из тестов на любом из ЯП. Дерзайте.
Уже проходили это, тесты заворачивают с формулировкой что используются оптимизации специфичные для интерпретатора.
Просили ведь, качественно!
Динамика это быстро и дёшево. Quick and dirty.
>> Быстро, Дешево, Качественно - выбери только 2 критерия.
> Выбираю Быстро и Качественно. Что делать?Платить много-много денег для разработки. По-моему, очевидно.
заплатить миллион за python
> Выбираю Быстро и Качественно. Что делать?бери с++
>> Быстро, Дешево, Качественно - выбери только 2 критерия.
>Выбираю Быстро и Качественно. Что делать?Готовить бабки на java+с++ || go+c++ программистов.
> Выбираю Быстро и Качественно. Что делать?c#
ахахаха
> Выбираю Быстро и Качественно. Что делать?Деньги готовить. Ибо не дёшево.
Не дешево, но зато правильно. Полный контроль. При любой проблеме винить кроме собственных программистов будет некого.
c++11 + Qt позволяют писать код не менее быстро, зато на порядок быстрее выполняющийся.
А в результате проект типа KDE забагованный...
Не знаю чего та у KDE, на моё ПО на Qt у пользователей нет жалоб..., разве что за очень редким исключением. Полагаю у них просто бардак в организации.
Если заранее посчитать зп прогеров, надо было ставить нормальное железо (что дешевле, чем нанять штат писателей Крутого Нового Языка и в итоге профукать бабло и не получить роста. А из нормальных языков (те не си) самый крутой известно кто
Неужели хоть до кого-то доходит, что все эти скрипто поделки лишь саппорт, и городить огород типа пипи и прочего тупик и неизбежное фиаско.
> Быстро, Дешево, Качественно
> - выбери только 2 критерия.Ну те же простые программы на Ocaml'е визуально отличаются от питоновских только заменой def на let да убиранием двоеточий. Производительность - половина от C++ной.
здесь не любят OCaml, жди мунусов.
На с++ с учетом последнего стандарта и либ на все случаи жизни (Boost, Qt), код пишется не на много медленнее, где-то на 20%, не больше. Зато дает гарантированную производительность. Видимо у них там совсем всё глубоко запитонено, раз они решились заняться исследованиями в области оптимизации, не дающими никаких гарантий, нежели просто переписать на другой язык.
Мда уж. Вот тебе и "сверхбыстрый питон". Рожденный ползать, как говорится,..
Надо понимать, что питон оказался достаточным для достижения ими того положения, в котором они находятся и которое недостижимо для 99.999% проектов. И теперь пришло время идти дальше. А рядовым проектам питона хватит за глаза, причём без оптимизаций. Ещё Брукс писал, что "первое правило оптимизации - не занимайтесь оптимизацией".
Прямо так и писал - "не занимайтесь"? Врёте нещадно. Не занимайтесь ПРЕЖДЕВРЕМЕННОЙ оптимизацией. Сначала пишем, потом ищем узкие места, узкие места оптимизируем. Писать сразу "оптимизированно" не стоит, потому что как правило получается экономия на спичках в ущерб читабельности кода.
> Писать сразу "оптимизированно" не стоитЭто уже баянoм стало... Каждый год находитя очередной цитирующий ее человек, при полном непонимании смысла. Вне изначального контекста она неверна. Как минимум надо писать так:
> Писать сразу "оптимизированно" в ущерб читаемости, когда недостаток производительности зараннее не очевиден, не стоит.Если есть возможность писaть сразу более оптимальный код без всяких негaтивных пoследствий - ничего плoхого в этом нет. Есть дофига ситуаций, когда на переписывание настроченного гoвнокода уходило куда больше времени, нежели если бы подумали и сразу применили оптимальный по скорости алгоритм, архитектуру. Примeр - мнoгопоточность. Переписать однoпоточное приложение на многoпоточное иногда задача фактически недостижимая.
Не шмогли. "Перспективная технология", да, в то время как у PyPy на синтетике на порядок быстрее здесь всего в два раза. Но надо снять шляпу, синдром Вьетнама не развился.
Вы там не забывайте, что этот ваш пи-пи является подмножеством, а не самим питоном.
Питон тормозной. С этим нужно смириться.
PyPy — это не RPython. RPython — это то, на чём PyPy написан. А реализует PyPy именно полноценный Python.И потом, тормоза — в головах. Когда на Python пишется код, по-настоящему критичный по производительности и памяти (кроме случаев, когда всё критичное упрятано, скажем, в библиотеку на C/C++, а на Python сделана только логика обвязки), это проблема не столько языка, сколько выбора языка. Для фрагментов, которые обещают стать бутылочными горлышками, на Python можно писать макет, самую первую версию и т.п. Но и только.
Рецепт-то прост. У данного языка есть масса ниш, в которых он хорош, но не надо пытаться лезть туда, где — как минимум, при существующих реализациях — он является не лучшим выбором.
Слуште, Филип Филипыч. А зачем обвязки на тормозном языке делать, когда быстрых навалом?
Ниже смотри цитату из блога больших любителей питона.
Потому что быстрее сделать на питоне, а потом узкие места (как всего лишь авторизационную проксю) оптимизировать. Но лично я к таким историям всегда со скепсисом отношусь, так как не раз и не два приходил на новый проект и поднимал производительность питонокода на порядок. Даже не трогая pypy. Такие дела. Хотя никто не запрещает хвататься за go, а не профайлер, это да.
> Потому что быстрее сделать на питоне, а потом узкие места (как всего
> лишь авторизационную проксю) оптимизировать. Но лично я к таким историям всегда
> со скепсисом отношусь, так как не раз и не два приходил
> на новый проект и поднимал производительность питонокода на порядок. Даже не
> трогая pypy. Такие дела. Хотя никто не запрещает хвататься за go,
> а не профайлер, это да.О, ну конечно. Вот вы бы решили проблему, повысив производительность на порядок.
Еще можете говорить, что потребление памяти на порядок снижаете. Питонисты проверять не будут.Питон - это древний убогий бейсик. И место ему там, где требуется, чтобы непрограммисты могли программировать. Это вузы и институты.
Питон превосходит другие языки только в создании образа идеального языка программирования для всего. Во всем остальном он выступает посредственно.
Он тормозной и код выглядит как расплесканный понос.Всего хорошего.
"Он тормозной и код выглядит как..." Отличная метафора, сохраню на память.
Теперь наши свинцовые костыли для бега, благодаря новейшим разработкам в генной инженерии могут быть выкрашены в стойкий, чудесный нежно-изумрудный цвет. Наши костыли - идеальный подарок как для начинающего, так и опытного питониста. Ведь всем известно, что без костылей они не могут ходить.
> И место ему там, где требуется,
> чтобы непрограммисты могли программировать. Это вузы и институты.Только там для этого почему-то предпочитают жабку.
> Питон превосходит другие языки только в создании образа идеального языка программирования
И опять мимо. Классика здесь паскаль. Который заменили (или заменяют, по мере слоупочности) на жабку и уж потом, самыми передовыми, на питон.
О, слышу гулкие раскаты грома. Похоже жабисты прочитали и впечатлились )
Потому что, до появления Go, Python был самым "легко усвояевым" языком общего назначения.
Т.е. из тех языков, на которых можно было писать "почти-всё-что-угодно", он был проще всего в изучении, и имел меньше всего косяков в самом языке и рантайме (чем выгодно отличался от perl и php).Теперь нишу подобного языка всё больше отвоёвывает Go, т.к. он, в добавок к перечисленным достоинствам, ещё и быстрый.
> Потому что, до появления Go, Python был самым "легко усвояевым" языком общего
> назначения.
> Т.е. из тех языков, на которых можно было писать "почти-всё-что-угодно",Совершенно внезапно, "самым-самым" в этом плане был VB. Сперва 5-6, потом уже .NET.
Чуть более элитная школота любила дельфи. Главный аргумент – и там и там, гуи с формочками можно было легко и просто нащелкать мышкой, в отличие от питонов и прочих. Да и привлекательность для типичного «общеназначенца» кучи платных компонентов, как и возможности сразу, «из коробки», не открывать код и деплоить бинарник, недооценивать не следует.
Так было ещё до популярности питона, когда в общем то айти образование везде было ниже плинтуса. А сейчас уровень немного подрос и везде впихивают именно питон без всякой гуйни.
> Когда на Python пишется код, по-настоящему критичный по производительности и памяти (кроме случаев, когда всё критичное упрятано, скажем, в библиотеку на C/C++, а на Python сделана только логика обвязки)В реальности всё происходит несколько иначе. Если уж меня совсем прижало и пришлось какую-то часть функционала переписывать на C/C++, то мне проще всё переписать на C/C++ и некоторые части, требующие частой кастомизации, вынести во встраиваемые в приложение скрипты, причём уже не обязательно на питоне.
А проще переписать т.к. разработка модулей для питона хоть и относительно проста, но всё равно доставляет кучу гемора на поддержку мн-ва ненужных обвязок. И сам язык, по сравнению с теми же плюсами, достаточно неприятен - в нём весь синтаксический сахар не zero cost.
Да и что-то можно вынести в C/C++ модули только когда в приложении имеется конкретное узкое место и оно не размазано равномерно по всему коду. Но такое бывает не всегда, простые узкие места это скорее свойство молодого проекта не знавшего рук грамотных инженеров.
Вот и кадры из Dropbox решили не писать модули, а сразу свалить на более адекватное средство.
https://blog.selectel.ru/oblachnoe-xranilishhe-obnovlenie-api/Слово людям, которым хватило мозгов принять очевидный факт:
Первоначально мы использовали стандартный swift-proxy, затем, когда нагрузка увеличилась, а нашего собственного кода стало больше, — перевели все это на gevent и gunicorn, позже заменили gunicorn на uwsgi ввиду того, что последний лучше работает под большими нагрузками. Все эти решения были не особо эффективны, время ожидания, связанное с прокси, было достаточно большим и приходилось использовать все больше серверов для обработки авторизованного трафика, т.к. Python cам по себе работает очень медленно. В итоге весь этот трафик пришлось обрабатывать на 12 машинах (сейчас весь трафик — и публичный, и приватный, — обрабатывается всего на 3 серверах).
После всех этих паллиативных действий мы переписали прокси-сервер на go.
1 миллион хелловорлдов в секунду на питоне:https://medium.com/@squeaky_pl/million-requests-per-sec...
т.е. они сравнивают prefork-архитектуру (wsgi) с event-driven. для прокси, понятно, по процессу на запрос, будет очень неоптимально. asyncio? не, не слышали.
prefork архитектура, event-driven и wsgi ортогональны друг другу. В частности wsgi это всего лишь програмный интерфейс, prefork способ бутстрапа секелета сервиса и e-d - метод организации асинхронности. Упомянутый uwsgi в статье сочетает сразу все эти технологии и нарвряд ли существует что-то более лучшее для убогого питона.
rtfm. WSGI doesn't work with async. т.е. запустить-то можно, но асинхронным оно быть перестаёт и работает с wsgi только по схеме "один клиент -- один воркер"
ты просто тупoй и совсем не понимаешь что читаешь. Вот для совсем овoщей разжёвано как это всё работаетhttp://uwsgi-docs.readthedocs.io/en/latest/Async.html#runnin...
http://www.tornadoweb.org/en/stable/wsgi.htmlIn WSGI mode asynchronous methods are not supported. This means that it is not possible to use AsyncHTTPClient, or the tornado.auth or tornado.websocket modules.
То что тонадо не может в асинхронный wsgi не значит что и другие не могут. Так то!
я вообще сомневаюсь, что у этих программистов на uwsgi было что-то асинхронное. или объяснить 12 серверов для прокси я никак не могу.
как корабль назовёте - так он вам и поплывёт
Скорее как корабль назовете- так он и по ползет)
А «Корытом» назовете —
Не уйдете от беды:
Эта шхуна и в болоте
Нахлебается воды.
Эта шхуна и в болоте
Нахлебается воды.;-)
> Несмотря на неплохие показатели в синтетических тестах, на реальных серверах Dropbox использование Pyston позволило добиться лишь ускорения кода на 10%, что значительно меньше ожидаемого ... более реалистичным путём ... стала переработка кода ... на других языках, таких как Go.Что-то до людей очень долго и туго доходят очевидные вещи. Действительно, ну кто бы мог подумать, что программы, написанные на во-всех-щелях-динамическом-яп в котором ну просто всё сделано чтобы его невозможно было никак ускорить, будут тормозить с любыми подпорками в виде JITов, особенно если код пишет типичная техническая недоросль.
Всё просто, люди не хотят переучиваться, становятся ярыми фанатиками своей позиции. Мультикомбайность языка позволяет его использовать под всё на свете, но это не значит что это правильно. Как следствие когда-то всё таки возникает понимание данного факта. А тут еще и весь мир рассмешили.
Чему не хочет переучиваться хрюндель который продвигал pyston?
Тут прямо эксперты языков программирования. Один, не сможет усидеть на всех стульях сразу. Не надо так идеализировать мир
Python еще как сидит. С такой сборной фанатиков пересидит и пересмешит всех остальных.
Нельзя ускорить то, что и так работает запредельно быстро.
А зачем в этом проекте какая то там совместимость с другим проектом - CPython? Вот этого я не понял. Это ведь два разных проекта. Кому нужна совместимость между Linux и Andoid или между WebKit и Blink? Да никому, их нет и чем дальше, тем сильнее они разойдутся.
Это же очевидно, чтобы без модификаций выполнять уже существующий код на CPython.
Вот смотрите, на Scala свой код, а на Java свой, они похожи, но они разные и каждый для своего дела и всех это устраивает, тогда в чём проблема здесь?
А причем здесь Scala и Java? Сдается мне, что ты вообще не понимаешь, о чем речь идет. А заодно не понимаешь, каким именно образом код на Scala и Java может сосуществовать в одном проекте и почему в случае Pyston и CPython подобное невозможно.
Потому что хотели "всё быстро заработало", а не "создали свой ни с чем не совместимый язык и переписали всё на нём".
Пришли в итоге к компромису и переписывают всё на уже созданном быстром языке, проверенном и отточенном под их задачи, хотя и не идеальном.
А разработчики CPython ничего из пистона в свой проект не привнесут?
В отличие от ряда аналогов, Dropbox не использует шифрование данных на стороне клиента, что, в частности, сделало возможным инцидент 19 июня 2011 года, когда из-за ошибки в обновлённом программном обеспечении сервера в течение четырёх часов был возможен вход в любой аккаунт с использованием любого пароля.
Это был просто день открытых дверей
Что и следовало ожидать. В нашем проекте идет переезд на Java и возможно Scala
Да всё нормально, это естественное стечение обстоятельств. Люди, просто инструменты надо подбирать по назначению, а не по удобству. Что вы думали, Python заменит все остальные языки? Нет конечно. У него есть своя небольшая ниша, как у матлаба, под которую он заточен. И ожидать от него большего - глупо.
Это должно быть написано везде, вместо рекомендаций использовать питон для всего.
Как тут у всех быстро отношение к питону поменялось. В прошлых новостях были одни восхваления. А как написали что да, действительно, питон не для нагруженных сервисов, так понеслось.
> Как тут у всех быстро отношение к питону поменялось. В прошлых новостях
> были одни восхваления. А как написали что да, действительно, питон не
> для нагруженных сервисов, так понеслось.Потому что те, кто радовались - сейчас напиваются, а те, кто нудел "ну мы же вам говорили" - воспрянули духом и торжествуют.
Помню какой был скандал у Ubuntu, когда они долгие месяцы пытались оптимизировать менеджер приложений, и всё бестолку, продолжал безбожно тормозить. В итоге признали ошибку, и убрали его. Тут видим аналогичную ситуацию. Только с явно большими потерями. Дураки, чё сказать. Надо смотреть на вещи объективно, а не через призму упрямости.
> Помню какой был скандал у Ubuntu, когда они долгие месяцы пытались оптимизировать
> менеджер приложений, и всё бестолку, продолжал безбожно тормозить.Очередной знаток реалий. На опеннете анонимы годами жаловалисть на тормозной питон в убунте в целом и на этот самый менеджер в частности.
> В итоге признали ошибку, и убрали его.
Правильно, кривой код там был совсем ни при чем.
Кучка пейсателей из конторки чье творение замечательно заменяется любым популярным веб-сервером с DAV надоело тратить время на совместимость своих костылей, но плохой именно Python, да.Я не знаю что там такого у Dropbox на Python, но очевидно, что узкое место - это I/O операции. Нужно было не свои монстроузные JIT-костыли выдумывать, а просто взять asyncio.
Вам, конечно, виднее
> Вам, конечно, виднееКонечно, закупиться железом и смаштабироваться в ширь было бы куда умнее и дальновиднее на деньги которые вливали в разработку этого JIT-компилятора, который при наличии PyPy и так не жизнеспособен. Все эти басни наш JIT лучше, чем их JIT - это темы для докладов на конференциях и не более.
Судя по новости, они остро нуждаются в подобных диванных аналитиках. Может вам стоит предложить свою кандидатуру?
> но очевидно, что узкое место - это I/O операцииУверен, Вы замените с десяток их экспертов, которые даже на месте не могут определиться в чём проблема.
>Я не знаю что там такого у Dropbox на Python, но очевидно, что узкое место - это I/O операции.расшифровываю: я не знаю что там происходит, но я все проблемы решаю почесав пятку правой ноги левой ногой.
Ну, как видите, они вот только осознали, что так можно
>просто взять asyncioIO не зависит от ЯП, парадигмы программирования -- все зависит от пряморукости. И уж поверь, проседоны по IO есть константа. И хоть пиши на ассемблере производительность не увеличится.Свой asyncio проверь на 100500 одновременных запросах. Ждем отчета.
P.S. Хотя, нет, не ждем, ты ж никогда отчеты не писал.
Ты просто не в курсе асинхронного программирования, а пытаешься что-то рассуждать. На асинхронщине можно и 100500 и 201000 rps держать. А asyncio это или NodeJS уже и не так важно. Жду от тебя аналога последних на ассемблере.
>Ты просто не в курсе асинхронного программированияЯ как раз в курсе. Каждый твой асинхронный запрос, висячий и ожидающий возможности чтения/записи (ждем когда select сделает select, грубо говоря) отжирает память. Да, можно повесить биллион асинхронных запросов. Одновременно. И что? Это как улучшит ситуацию? Нет.
В ОС, например, в GNU/Linux уже встроенна в ядро своя асинхронная модель IO. Ядро писали умные дяди. Они поняли, что ресурсы не бесконечны. Они сделали все на очереди. Да-да, тупо в очередь складировать все запросы, а далее по классике их раскидывать по процессам/важности. Увы, ты, архитектор прикладной программы этого не знаешь и думаешь, что твой asyncio это верх идеала, совершенства. Копни #$%^ глубже, да разберись что и как. И почему смена парадигмы не влияет на производительность IO. Да, можно ускорить вычисления, да, можно закинуть 100500 fd сокетов в один пул, типа kqueue, select, etc, но это НЕ работает в случае IO. Иди читай маны, там про это рассказано, что FS IO != sockets. У них даже буферизация по-разному работает!
"Быстро, Дешево, Качественно - выбери только 2 критерия." Похоже все три - это NIM (Nimrod). Синтаксис питона, скорость CPP.
Продолжайте, продолжайте фразу. ...маргинальность лиспа.
Как всё в начале маргинально. Потом что-то "выстреливает", что-то нет. Последнее непредсказуемо.
> "Быстро, Дешево, Качественно - выбери только 2 критерия." Похоже все три -
> это NIM (Nimrod). Синтаксис питона, скорость CPP.Вопрос - почему не писать сразу на Си?
Си- устаревший синтаксис (нет выделения блоков отступами), нет модульности, нет сборки мусора, нет контроля выхода за границы массива. Всё это есть в Nim. Синтаксический сахар питона. При том компиляция в нативный код, это не интерпретатор. Поскольку использует вылизанный gcc, мала вероятность глюков и нет нужды переписывать под разные процессоры, это gcc делает.
Расскажи какой gcc хороший бсд-шникам. Как они там выпиливали его, ибо неясно, что есть "стандартная библиотека", "стандартные вызовы". По факту, выхлоп от gcc должен быть открыт под GPL, как сам gcc. Дядя Столлман просто водит всех занос.
>устаревший синтаксис (нет выделения блоков отступами)Уууууууу.
>> "Быстро, Дешево, Качественно - выбери только 2 критерия." Похоже все три -
>> это NIM (Nimrod). Синтаксис питона, скорость CPP.
> Вопрос - почему не писать сразу на Си?Пиши! Разрешаю!
Заодно уговори авторов ranger переписать его на сишке и помоги vifmщикам, а то их детище, хоть и на сишечке, позорно^W нехорошо сливает, при включенных превиюшках, по скорости этому самому рейнджеру.Еще, можешь обратить свой взор на mps-youtube. Тоже питон. Не труЪ, нужно переписать. Не знаю правда, что это даст в плане экономии ресурсов, но возможно, если запускать и искать пару сотен альбомов одновременно, что-то можно будет и заметить невооруженным глазом!
arandr - питонообертка вокруг xrandr. xpra, прокся для иксов ни питоне.
Увы, тут вся надежда только на тебя!
>[оверквотинг удален]
> Пиши! Разрешаю!
> Заодно уговори авторов ranger переписать его на сишке и помоги vifmщикам, а
> то их детище, хоть и на сишечке, позорно^W нехорошо сливает, при
> включенных превиюшках, по скорости этому самому рейнджеру.
> Еще, можешь обратить свой взор на mps-youtube. Тоже питон. Не труЪ, нужно
> переписать. Не знаю правда, что это даст в плане экономии ресурсов,
> но возможно, если запускать и искать пару сотен альбомов одновременно, что-то
> можно будет и заметить невооруженным глазом!
> arandr - питонообертка вокруг xrandr. xpra, прокся для иксов ни питоне.
> Увы, тут вся надежда только на тебя!Мне питон не уперся, как бы perl + xs.
> Мне питон не уперся, как бы perl + xs.Очень интересно, даже не смотря на то, что новость о питоне, да и ветка обсуждения тоже.
Держи нас в курсе!
Правда, постарайся в следующий раз все же прочитать, на что отвечаешь.