| 1.1, Аноним (1), 00:19, 29/10/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
Но ведь есть же уже numba в виде декоратора? Толку то от этого жита, выше ГИЛа не прыгнешь (в мультипотоке, в однопотоке всё прекрасно).
| | |
| |
| 2.14, erthink (ok), 04:31, 29/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
 И первое и второе не работает для "общего случая", не "из каробки" и т.п.
С одной стороны, они не воюют с мельницами, оставляя обход многих проблем на плечи пользоватля.
С другой стороны, зачем мне такая "коза с баяном" если (при действительной потребности в скорости) критический питоновский код лучше (!?) и несложно (!?) переписать на С/C++
?
| | |
| |
| 3.15, Аноним (1), 04:41, 29/10/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
Cython зато для общего случая и из коробки, хоть и не жит, зато сишная производительность 1 в 1. Проставляешь сишные типы для переменных типа счётчиков, отключаешь гил где только с непитоновыми данными работаешь, остальное оставляешь как есть. Удобненько. На самом деле на си переписать сложнее чем ускорить питон в 10000 раз подобным образом. Точно так же с кудой веселее из питона работать.
| | |
| |
| 4.41, n00by (ok), 16:09, 29/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
 > Cython зато для общего случая и из коробки, хоть и не жит,
> сишная производительность 1 в 1.
What users have to say about Cython:
»SciPy is approximately 50% Python, 25% Fortran, 20% C, 3% Cython and 2% C++ … If Python performance is an issue, then we prefer the use of Cython followed by C, C++ or Fortran (in that order).
Пожалуй, поверю Анониму, а не первому попавшемуся мнению.
| | |
| |
| 5.43, Аноним (1), 16:49, 29/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
Ты вроде и соглашаешься в цитате (заинтересованного лица, надо признать), а потом вроде и соглашаешься в комментарии. Зачем ты это написал?
| | |
| |
| 6.70, n00by (ok), 10:28, 30/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
Сначала я хотел написать, что "сишная производительность" в сравнении с "сишной производительностью" может различаться в 2-3 раза (в зависимости от транслятора и опций сборки), потому заявление насчёт "1 в 1" выглядит несколько наивно. Вот это было бы точно -- незачем.
| | |
| |
| 7.74, Аноним (1), 14:03, 30/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
Я сравнивал ручную cython оптимизацию с аналогичным кодом чисто на си, и cython действительно был быстрее в несколько раз. Но если собрать си с PGO, разница не столь заметна, и в конечном счёте оказалось возможно сделать аналогичную оптимизацию для си (собственно, cython встраивать код на си и позволяет).
| | |
|
|
|
|
|
|
| 1.2, Жорш (?), 00:20, 29/10/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Я всегда говорил что Пистон это все что нам нужно для прогресса.
| | |
| 1.8, Аноним (8), 01:10, 29/10/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– | |
Я очень люблю Python, просто тащусь от этого языка. Но уважаемые, зачем это если есть Go?
В смысле этот Пестон Гвидо пилил когда работая в Dropbox чтобы ускорить им там всё. Ну и в итоге они же на Go всё переписали и счастливы.
Ideas? Thoughts? Corrections?
| | |
| |
| 2.11, Аноним (11), 02:20, 29/10/2020 [^] [^^] [^^^] [ответить]
| +7 +/– |
Солёное со сладким сравниваете. Go - значимо более низкоуровневый. Прикладные задачи и экосистемы разные. Если бы dropbox изначально писали на go, то может и не было бы этого Dropbox. А когда бизнес устоялся, деньги есть, клиенты есть, ботлнеки известны, серваки деньги кушают, то тогда и оптимизацией можно заняться.
| | |
|
| |
| 2.16, sergey (??), 07:25, 29/10/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Маловато. В моей задаче переписывание с Python на C++ ускорило вычисления примерно в 100 раз. Так что 20% ни о чём.
| | |
| |
| 3.19, Lex (??), 09:04, 29/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
Они там, похоже, что-то с джитом перемудрили.
Или питон настолько тяжело компилится( тяжелее жс ).
С жс-подобным джитом ещё нюансы были, что вначале считается количество вызовов каждой конкретной функции с её последнего изменения и, если оно превышает какое-то значение, только после этого она «компилится». Мб ещё и в этом дело.
| | |
| |
| 4.32, ПэЖэ (?), 12:54, 29/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
>Они там, похоже, что-то с джитом перемудрили.
>близкой к производительности традиционных системных языков, таких как C++
вот это и непонятно - хотят ц++, а делают джит
| | |
| |
| 5.51, Lex (??), 22:11, 29/10/2020 [^] [^^] [^^^] [ответить]
| +/– | |
Дооо. То то питонщики последний хрен с солью доедают, но это к слову о финансировании и поддержке, а так же о том, что питон нынче ставится во многие дистрибутивы линухи в отличие от ноды.
Парадокс их «академической оптимальности» в том, что получился тормозной мусор в сравнении с тем же жс. Хотя исходники и хромиума и вебкита открыты и, если своих мозгов настолько не хватает, то можно и дергануть кусок-другой кода.
.. но даже JIT питону даёт лишь 20% ускорения..
Мб это реально далеко не лучший язык даже для скриптовой разработки, если уж отзывчивость даже на столь серьёзные изменения у него околонулевая ?
| | |
| |
| |
| 7.71, Lex (??), 12:48, 30/10/2020 [^] [^^] [^^^] [ответить] | –1 +/– | Финансирование подразумевает разработку чего-то нового Продукты, в которые влож... большой текст свёрнут, показать | | |
|
| 6.65, Vkni (ok), 04:53, 30/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
 > Мб это реально далеко не лучший язык даже для скриптовой разработки, если
> уж отзывчивость даже на столь серьёзные изменения у него околонулевая ?
Для скриптовой он очень неплох, хотя и перемудрён уже (особенно неочевидна семантика изменяемых объектов). Запускается интерпретатор Питона быстро, с такой же скоростью, что и ocaml Toplevel, в несколько раз медленее bash, но это терпимо.
| | |
|
|
|
| 3.64, Vkni (ok), 04:50, 30/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Маловато. В моей задаче переписывание с Python на C++ ускорило вычисления примерно
> в 100 раз. Так что 20% ни о чём.
Ну обычно просто вдумчивое переписывание с Питона на Питон серьёзно ускоряет программу.
| | |
|
|
| 1.18, Аноним (18), 08:13, 29/10/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– | |
> Ценой использования JIT является незначительное увеличение потребления памяти.
И значительное снижение безопасности.
JIT требует отключение защиты памяти процессором и ядром OS, делая вашу систему уязвимой к переполнению буфера.
| | |
| |
| |
| 3.23, Аноним (18), 09:56, 29/10/2020 [^] [^^] [^^^] [ответить]
| +/– | |
JIT -> изменение исполняемой памяти -> возможность эксплуатации уязвимости переполнения буфера.
Нет JIT -> запрет на любое изменение исполняемой памяти -> невозможность эксплуатации переполнения буфера.
| | |
| |
| 4.25, A.Stahl (ok), 10:14, 29/10/2020 [^] [^^] [^^^] [ответить]
| –4 +/– |
 Я всегда работал с обычными компилируемыми языками, поэтому JITом никогда не интересовался, но разве там не просто "скомпилировали в нативный бинарик, бросили в кеш чтобы не компилировать в следующий раз и запустили самый обычный нативный блоб"?
| | |
| 4.31, Gogi (??), 12:04, 29/10/2020 [^] [^^] [^^^] [ответить]
| –2 +/– | |
> JIT -> изменение исполняемой памяти
Чушь собачья! JIT совершенно не подразумевает, что что-то должно изменяться. Почитай-ка лучше теорию, а потом садись за математику - завтра в школу.
| | |
| |
| 5.80, Аноним (80), 15:48, 30/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
JIT - исполнение скомпилированного во время работы программы кода, который надо записать в память (доступ на запись, W), а потом исполнить (исполнение, X, измененного во время работы программы кода).
| | |
|
| 4.33, Аноним84701 (ok), 14:18, 29/10/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > JIT -> изменение исполняемой памяти -> возможность эксплуатации уязвимости переполнения буфера.
простой интерпретатор без JIT -> исполнение высокоуровневого кода в неисполняемой памяти -> эксплуатация уязвимости в обход ASLR.
> Нет JIT -> запрет на любое изменение исполняемой памяти -> невозможность эксплуатации переполнения буфера.
Только в моей реальности, в скриптовых/ЯП c автоматическим управлением памятью, уязвимости переполнения буфера встречаются куда как реже, чем уязвимости с каким нибудь хитрым eval(userinput).
| | |
| |
| 5.79, Аноним (80), 15:43, 30/10/2020 [^] [^^] [^^^] [ответить]
| +/– | |
В твоем дистре ядро разрешает исполнение левых скриптов?
Не спрашиваю уже о ограничениях интерпретаторов средствами DAC.
| | |
|
| 4.38, Аноним (38), 15:24, 29/10/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
 >Нет JIT -> запрет на любое изменение исполняемой памяти -> невозможность эксплуатации переполнения буфера.
Не полная невозможность, а только увеличение сложности эксплуатации. Если правильно подобрать данные, то переполнение буфера прыгнет на инструкцию в системном коде, которая вызовет функцию изменяющую атрибуты памяти в которой расположен shell-код, а затем "вернёт" управление ему. Именно поэтому и существует рендомизация адресного пространства, которая значительно усложняет ориентацию в коде процесса.
| | |
| |
| 5.77, Аноним (80), 15:40, 30/10/2020 [^] [^^] [^^^] [ответить]
| +/– | |
Согласен, что ALSR также необходимо использовать в ядре OS и программах.
Но в этой теме акцент на вредность JIT для защиты памяти OS. Если JIT нет то в OS можно реализовать простую защиту от переполнения буфера. А если JIT есть то защиту просто не реализуешь, будет дыра в OS и угроза переполнения буфера.
| | |
| |
| 6.84, Аноним (38), 16:55, 30/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
Простая защита это именно флаг запрещающий выполнять определённые области памяти, чтобы сделать защиту получше, нужно сломать ядерный ABI, который позволяет снимать запрет. Но в таком случае вполне возможно выполнять JIT-код в контейнере, который не может самостоятельно менять права страниц своего процесса и вообще может только общаться с процессом-мастером.
| | |
| |
| 7.85, Аноним (85), 16:59, 30/10/2020 [^] [^^] [^^^] [ответить]
| +/– | |
> который позволяет снимать запрет.
Все зависит от реализации защиты: строгая или не строгая.
Нормальные ядра OS запрет снимать не разрешают и никакой JIT исполнить тоже не разрешат.
| | |
| |
| |
| 9.87, Аноним (87), 17:31, 30/10/2020 [^] [^^] [^^^] [ответить] | +/– | И нормальная и посикс держит https mirror yandex ru mirrors ftp linux kiev ua... текст свёрнут, показать | | |
|
|
|
|
| 5.88, Аноним (87), 17:33, 30/10/2020 [^] [^^] [^^^] [ответить]
| +/– | |
> то переполнение буфера прыгнет на инструкцию в системном коде, которая вызовет функцию изменяющую атрибуты памяти
Ну прочитаешь, ну прыгнешь, а исполняется память только для чтения. Ядро ловит попытку записи в область помеченную только для чтения и убивает вирусный процес.
| | |
| |
| 6.90, Аноним (38), 17:40, 30/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
>Ну прочитаешь, ну прыгнешь, а исполняется память только для чтения.
>Ядро ловит попытку записи в область помеченную только для чтения и убивает вирусный процес.
Инструкция в системном коде имеет разрешение на выполнение, иногда даже компилятор не в курсе, что сгенерировал инструкцию, которая может прыгнуть в mprotect. Это просто байты так уж сложились. После mprotect вирусный код получает своё "законное" право на выполнение.
| | |
| |
| 7.92, Аноним (92), 18:05, 30/10/2020 [^] [^^] [^^^] [ответить]
| +/– | |
Ты не имеешь права записи в области которые доступны только для чтения. Все исполняемые области, в нормальных ядрах OS, доступны только для чтения.
Плевал я на программиста и его компилятор, контроль за памятью есть у ядра OS и процессора и при попытке записи в область доступны только для чтения ядро нормальной OS убьет процес.
| | |
| |
| 8.93, Аноним (38), 18:11, 30/10/2020 [^] [^^] [^^^] [ответить] | +/– | Да не работает это всё, в том и дело Только полный запрет mprotect может решить... текст свёрнут, показать | | |
| |
| 9.104, Аноним (104), 08:03, 31/10/2020 [^] [^^] [^^^] [ответить] | +1 +/– | У меня на компе все работает, за малым исключением firefox, kwin-wayland, polki... текст свёрнут, показать | | |
|
|
|
|
| 5.89, Аноним (87), 17:35, 30/10/2020 [^] [^^] [^^^] [ответить]
| +/– | |
> то переполнение буфера прыгнет на инструкцию в системном коде, которая вызовет функцию изменяющую атрибуты памяти
Ну просчитаешь, ну прыгнешь, а вся исполняемая память доступна только для чтения. Ядро ловит попытку записи в область помеченную только для чтения и убивает вирусный процес.
| | |
|
|
|
|
| |
| |
| 3.39, Аноним (39), 15:38, 29/10/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
ты сам понимаешь о чем спрашиваешь?
в C# есть tiered JIT и довольно хороший
| | |
| |
| 4.67, банан (?), 07:34, 30/10/2020 [^] [^^] [^^^] [ответить]
| +2 +/– | |
Там всё вот в таком порядке: c# компилируется IL (такой типо ассемблер для VM дотнета), а затем IL уже обрабатывается джитом в момент исполнения. То есть, JIT - это фича CLR, а не C#.
Поэтому комментатор выше вас в чем-то прав, хоть скорее всего сам об этом не догадывается
| | |
|
|
|
| 1.29, Gogi (??), 12:02, 29/10/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –5 +/– |
Пестон можно хоть на гиперкварках запилить, СМЫСЛ? Неужели вы думаете, мы не трогаем это ***овно только из-за скорости?? САМ ЯЗЫК - ушлёпский и "синтаксис на отступах" - самая несусветная чушь, которая могла прийти в голову. Так что пилите, Шура, пилите! Мы всё равно не будем касаться этого неадеквата.
| | |
| |
| 2.48, BrainFucker (ok), 21:17, 29/10/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
 > "синтаксис на отступах" - самая несусветная чушь, которая могла прийти в голову.
Кому очень не хватает скобок, могут писать так:
## {
def method():
pass
## }
редакторы скобки обычно подсвечивают везде.
| | |
| |
| 3.105, Аноним (-), 10:02, 31/10/2020 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Кому очень не хватает скобок, могут писать так:
Не все фанаты юмора монтипайтона, и любая шутка со временем становится невыносимо отталкивающей.
| | |
|
|
| |
| |
| 3.46, Scriptor (ok), 18:00, 29/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
 Pyston: "We’re on a mission to make Python faster".
PyPy: "A fast, compliant alternative implementation of Python".
У первого, получается, (пока что) хуже с fast, но лучше с compliant, как я понял.
| | |
| |
| 4.47, myhand (ok), 19:51, 29/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
 > Pyston: "We’re on a mission to make Python faster".
Ну тогда у тебя Cython - это тоже что Python. Как-то так.
| | |
| |
| 5.120, Scriptor (ok), 00:14, 06/11/2020 [^] [^^] [^^^] [ответить]
| +/– |
>> Pyston: "We’re on a mission to make Python faster".
> Ну тогда у тебя Cython - это тоже что Python. Как-то
> так.
Cython, как я понимаю, еще менее совместим с эталонной реализацией.
| | |
|
| 4.61, Аноним (56), 00:50, 30/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
Оба не реализуют весь язык Python. Понятное дело, что программисты не используют всех возможностей и что-то работать будет.
Но Гвидо назвал питоном то, что назвал. Надо либо всё реализовать, либо не говорить, что это реализация питона. Зачем выдавать желаемое за действительное?
| | |
|
|
|
| 1.49, BrainFucker (ok), 21:21, 29/10/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
А зачем? Причесали бы Cython, дали бы возможность использовать его без зависимости от libpython, упростили бы возможность использования его целиком для написания программ на нём, а не только модули для питона писать, сделали бы возможным разрабатывать на нём кроссплатформенные приложения, чтобы и под Андроид было легко на нём писать и он взлетел бы, даже без совместимости с обычным питоном, с которого все с радостью ушли бы на это. Питон любят только из-за синтаксиса.
| | |
| 1.50, банан (?), 21:28, 29/10/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Расскажите мне, почему питон такой модный? Вроде он и не очень быстрый и не очень типизированный, и многопоточка у него не фонтан, и в сборке мусора ничего особенного, и синтаксис далеко не всем нравится
От чего все кипятком ссyтся?
| | |
| |
| |
| 3.53, Аноним (56), 22:42, 29/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
Питон проще других языков только по одной причине. Во всех гайдах по нему описывается ОДИН И ТОЛЬКО ОДИН правильный способ делать что-то. В других языках программисту нужно больше думать.
| | |
| |
| 4.57, анонимуслинус (?), 23:01, 29/10/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
даже этот один правильный способ ведет к сотням и тысячам вариаций одного и того же. и это неплохо. те же плюсы это жесть , которую учить надо всю жизнь и фиг выучишь, он очень разжирел. но как инструмент он намного превосходит питон, да и раст скорее всего тоже. но его жуткая усложненность всех вводит в гневный ступор.)) в плюсах знать надо неимоверно много.
| | |
| |
| 5.59, Аноним (1), 00:40, 30/10/2020 [^] [^^] [^^^] [ответить]
| –2 +/– |
В прошлый раз, когда я хотел использовать плюсы, мне пришлось вымазаться в бусте с ног до головы. Я всё ещё надеюсь, что они посмотрят на раст и его эксперименты, и утянут себе в срандарт всё стоящее утягивания, и тогда все любые языки помимо плюсов отомрут. Особенно я надеюсь отомрут дотнет с жавой. А из скриптов пусть останется питон, идеальный вариант.
| | |
| |
| 6.66, банан (?), 07:05, 30/10/2020 [^] [^^] [^^^] [ответить]
| +/– | |
> отомрут дотнет с жавой
Не отомрут пока есть windows, android и горы промышленного софта.
В тоже время котлин вполне себе приятный, а c# развивается очень быстро.
| | |
| 6.96, Аноним (56), 18:58, 30/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
Скорее вас таких программистов заменят нейросетью на проце, потребляющим 10 Вт, чем отомрет джава.
| | |
|
| 5.60, Аноним (56), 00:46, 30/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
Программирование на любом языке примерно одинаково. И все они очень похожи, если не считать экзотику и 1С. Знать для эффективного программирования надо очень много. Где-то два высших образования по объему. Быстро это не заходит.
Собственно поэтому от легкости освоения языка программирования мало что меняется. Ну выучил ты синтаксис языка, и что дальше. Программировать все еще предстоит научиться. Структуры данных, алгоритмы, проектирование, куча сопутствующих технологий. В дальнейшем на передний план выходит организация процесса разработки, тестирования, сопровождения кодовой базы.
К старости можно стать более или менее компетентным во всем.
| | |
|
|
|
| 2.54, Аноним (56), 22:46, 29/10/2020 [^] [^^] [^^^] [ответить]
| –3 +/– |
Вне среды восторженных школьников и младших научных сотрудников он не очень-то используется.
Моду на питон ввела компания гугл, внутри которой это до сих пор основной язык, на котором все работает.
| | |
| |
| |
| 4.73, Аноним (-), 13:44, 30/10/2020 [^] [^^] [^^^] [ответить]
| –1 +/– | |
>В гугле "всё работает" на с++
Парсить текст, отличный от латиницы, на C или C++ то еще удовольствие. Там поддержки UTF-8 из коробки нет, и не предвидится.
| | |
| |
| 5.83, all_glory_to_the_hypnotoad (ok), 16:29, 30/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
 Сделать хоть какую-то корректную либу для работы с UTF-8 дело примерно недели или двух, если не нужно заморачиваться с юникодом, то можно уложиться в несколько дней. Несложно догадаться что подобные либы для плюсов давно написаны многими и для разработки внутри организации типа G идут для разработчика в коробке с кучей других либ.
| | |
|
| |
| 5.82, all_glory_to_the_hypnotoad (ok), 16:22, 30/10/2020 [^] [^^] [^^^] [ответить]
| +/– | |
На плюсах пишут весь код, который должен быстро работать или оптимально использовать другие ресурсы (память, например) или корректно работать с ~POSIX API или алгоритмически сложен или если в компоненте ппросто много кода. Второй такой ЯП с чуть худшими характеристиками это Java. На C++ и Java реализуется подавляющая часть технически сложных решений ради которых G высасывает(ал) инженеров со всего мира.
Ниша питона везде, и в G в частности, скриптовщина для автоматизации инфраструктуры и прослойка между нормальнымы сервисами и веб помоями. Где-то между первой кучей и питоном влезает Go. Ну и разумеется G не имеет отношения к моде на питон.
| | |
| |
| 6.95, Аноним (56), 18:56, 30/10/2020 [^] [^^] [^^^] [ответить]
| +/– | |
Так уж вышло, что я из первых рук знаю, что в гугле питон используется отнюдь не только для автоматизации, но и для обработки основных пайплайнов. Го в гугле используется очень мало.
И к моде на питон отношение самое прямое. Один из основных аргументов в форсировании этого языка всегда было, что вот он в гугле используется.
| | |
|
|
|
|
| 2.69, myhand (ok), 09:39, 30/10/2020 [^] [^^] [^^^] [ответить]
| +/– | |
Может еще потому, что есть механизмы устранения косяков языка? PEPs, вот это вот все.
До питона такое было в scheme (в какой-то степени) - но, видимо, скобочки очень сильно пугают.
| | |
| 2.72, Аноним (-), 13:34, 30/10/2020 [^] [^^] [^^^] [ответить] | +/– | Python не проще в освоении, как об этом ниже говорят По сложности он скоро C ... большой текст свёрнут, показать | | |
| |
| 3.75, Аноним (56), 14:42, 30/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
Perl типа компилируется перед запуском. В том числе поэтому он в разы быстрее.
Насчет понятности - большой вопрос. Лапшу на питоне понимать не проще, чем лапшу на перле.
На перле можно очень чисто писать и код будет понятнее, чем на питоне с его отступами и общей кондовостью. Хороший код на питоне написать сложнее, чем хороший код на перле.
| | |
| |
| 4.78, Аноним (-), 15:43, 30/10/2020 [^] [^^] [^^^] [ответить]
| +/– | |
>Perl типа компилируется перед запуском. В том числе поэтому он в разы быстрее.
Я понимаю, что вам нравится Perl, а не Python. Но сказки все-же выдумывать не нужно. Быстрее Perl лишь иногда, и уж точно не в разы (в пределах 20%, насколько я знаю). И вполне возможно написать модуль для Python на C (а их много на C написано). И использовать его. И быстрота Perl -а, о которой вы говорите, останется не при делах.
| | |
| |
| 5.81, Аноним (56), 16:02, 30/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
Если сравнивать производительность самого языка, то в пределах 20%. А если производительность программ, на них написанных, будет уже в разы. С сишными модулями или без (в перле тоже много сишных модулей).
Поверьте на слово - любую прогу на питоне можно переписать на перле и она станет короче в два раза и будет работать намного быстрее.
Как выше писали, многие вещи в питоне просто не работают нормально. А в перле работают. Можно упрямо этого не признавать и продолжать плакать и колоться, а можно сменить инструмент.
Нет, не на перл. Питонистам следовало бы присмотреться к luajit.
| | |
| |
| 6.91, Аноним (-), 17:53, 30/10/2020 [^] [^^] [^^^] [ответить] | +/– | Если и там и там сишные модули, и если допустить, что написаны они грамотно, то ... большой текст свёрнут, показать | | |
| |
| 7.94, Аноним (56), 18:50, 30/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
Вы просто не знаете перл и думаете, что это как питон, только перл :)
Перл - особенный язык. После перла все остальное кондово и уныло, кроме луа, жс и может быть си.
>Сильно короче программа может стать только в том случае, если в ней используются модули
Я имел в виду именно код на языке. Простые скрипты на питоне размером где-то в экран можно иногда в однострочник на перле превратить. Так уж питонисты пишут.
| | |
| |
| 8.98, Аноним (1), 20:44, 30/10/2020 [^] [^^] [^^^] [ответить] | +/– | Так 3 экрана кода на перл тоже можно превратить в однострочник на питоне, так уж... текст свёрнут, показать | | |
|
|
|
|
|
| 3.111, банан (?), 15:44, 31/10/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
> не надо следить за числовыми типами - то есть следить за
> тем, когда int превратится во float, или обратно, или за переполнением
> этого типа и заменой его на более вместительный.
Вот тут не понял. Судя по вашим словам в питоне много неявных числовых приведений, которые, наоборот, нужно всегда учитывать. По мне так это избавляет от одних проблем и пораждает другие
| | |
| |
| 4.116, Аноним (-), 00:09, 01/11/2020 [^] [^^] [^^^] [ответить]
| +/– |
Никаких проблем это не порождает. Типизация строгая. Надо просто понимать, как это работает. А если уж совсем хочется, то есть анотация типов. То есть, чтобы исключить какую-то путаницу в понимании, можно указать типы.
| | |
|
|
| 2.117, Skynin (?), 10:58, 02/11/2020 [^] [^^] [^^^] [ответить]
| +/– | |
Потому что препоадается в школах и колледжах не один год, в дополнение к массовому применению в науке
-- не очень быстрый
если у приложения главный затык - ожидание ответа сторонненого сервиса - то пофик
-- и не очень типизированный,
у динамической типизации есть и достоинства. чем меньше кода, тем ее применение более оправдано чем статической.
а если нужна статическая - то и у Python и у PHP, и у JavaScript есть для этого средства.
Зато у программистов выбор - хочешь/надо - используй, не хочешь, не надо - не используй.
-- и многопоточка у него не фонтан
однопоточный код писать нааамного проще и быстрее.
а уж сопровождать многопоточный код...
и он нужен он не часто.
а там где нужен на проектах с Python, PHP - его выносят на сервисы на Go, да и все.
На Ноде достаточно ее асинхронщины и подъема нескольких инстансов приложения
-- в сборке мусора ничего особенного
а что должно быть такого особенного в сборке мусора :)
Собирает? задержки приемлимы для проекта - значит ОК.
Не приемлимы задержки? берите другое, как недавно дискордовцы переписали один из своих сервисов с Go на Rust
-- синтаксис далеко не всем нравится
да, помню холивары о синтаксисе С и Pascal
когда студентом был :)
к синтаксису привыкаешь быстро.
хоть к питоновскому, хоть к лисповскому.
если не студент - это не проблема.
Религии только не надо делать с инструмента.
Тогда понятно станет что полезного в каждом инструменте, а какова стоимость этой полезности.
| | |
| |
| 3.119, банан (?), 20:14, 05/11/2020 [^] [^^] [^^^] [ответить]
| +/– | |
> однопоточный код писать нааамного проще и быстрее. а уж сопровождать многопоточный код...
Спасибо, капитан!
| | |
|
|
| 1.68, funny.falcon (?), 08:51, 30/10/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Наконец-таки кто-то ещё догадался, что LLVM в качестве JIT подходит только таким математическим применениям, как Julia.
| | |
|
