В чём проблема питона(я не очень шарю)?
Интерпретируемый язык. Как не крути, будет медленнее.
Хмм...А что ты скажешь о джаве
Java (как и C#) сначала компилируется в байткод, а потом исполняется с JIT-компиляцией, поэтому несколько быстрее. (Хотя у python есть PyPy, интерпретатор с JIT. Но даже так происходит синтаксический разбор в рантайме). Но Python создавался как язык научных расчетов, а не для энтерпрайза, как джава. А для расчетов у питона есть различные библиотеки, написанные на C, которые быстрее (напр. numpy). А питон - клей между ними.
Ну, уточню еще 1 момент: java, благодаря оптимизаторам, при правильном коде инлайнится в assembler после warming'a
Окееей, а аргументы будут?
Уточним другой момент: холиварчики холиварчики.
Технически, питон можно компилить, или транспайлить+компилить.
У джавы так вообще грядет (или нагрянул?) Грааль с нативной компиляцией.
И С будет _несколько_ быстрее, при условии что в С всё сделано хорошо и правильно.
В общем и целом программировать на С/С++ слишком дорого для большинства применений при негарантированном и несущественном приросте производительности.
Технически, питон можно компилить, или транспайлить+компилить.
У джавы так вообще грядет (или нагрянул?) Грааль с нативной компиляцией.
И С будет _несколько_ быстрее, при условии что в С всё сделано хорошо и правильно.
В общем и целом программировать на С/С++ слишком дорого для большинства применений при негарантированном и несущественном приросте производительности.
Только C# не в байткод а в IL компилится.
Суть одна и та же, не?
Не знаю, как в других языках с JiT, но в C# компиляция идет на ходу и только того, что в данный момент используется. Т.е те методы, который в данный момент вызываются=> разница между уже скомпилированным кодом не заметна. +JiT поделывает доп. оптимизации на целевой платформе. Скажем, видя крутой процессор, компилится с оптимизациями под него.
Сравнивал один и тот же код, написанный на PyPy и на С (MSVC). Разница была на порядок не в пользу Пайтона.
Особенно не разбирался, но догадываюсь, что MS-овский компилятор основные циклы оптимизировал с использованием автовекторизации.
Во многих задачах всё сводится к кешу и предварительным вычислениям, и язык уже начинает играть второстепенную роль.
Есть, конечно, задачи, где реально нужно на асме делать, потому что нужена реалтайм обработка чего-то на месте, но в таких случаях можно сделать вставку.
Мой любимый пример с нодой. Не хватает скорости JS? Сделал модуль на C++. Не хватает C++? Вставил туда асм. Ну т.е. опримизация только реально нужных мест, а не всего подряд.
Есть, конечно, задачи, где реально нужно на асме делать, потому что нужена реалтайм обработка чего-то на месте, но в таких случаях можно сделать вставку.
Мой любимый пример с нодой. Не хватает скорости JS? Сделал модуль на C++. Не хватает C++? Вставил туда асм. Ну т.е. опримизация только реально нужных мест, а не всего подряд.
Вставлять асм - невероятно редкий кейс. Современные оптимизирующие компиляторы справляются со своей работой куда лучше. Они умеют, например, перемещать инструкции, чтобы плотнее загрузить конвейер. Вручную это сделать крайне нетривиально.
Ну бывает можно существенно оптимизировать код через SSE/AVX/AVX2/AVX512 инструкции. Компиляторы пока так вроде не умеют делать. (или я что-то пропустил?)
С/С++ компиляторы векторизовать в ряде умеют. GCC умеет, интеловский умеет еще сильнее. В интеловском можно еще получить отчет об оптимизации на 100500 страниц, где он, в том числе, напишет, какие циклы были векторизованы, а какие нет и почему. Также можно вручную интринскии вставлять. Intel Intrinsics Guide
Так о том и речь :-) Но если вдруг надо, то пожалуйста. Но, обычно, не надо. И проблема не в языке :-)
Он медленный даже среди интерпретируемых. Если какое-то говно едва шевелится и сожрало половину оперативки - почти 100% питон.
Просто на нём не надо писать вычисления, а только вызов методов из dll-ок написанных на C/C++, тогда производительность будет точно такая же.
Я начинающий, поэтому у меня вопрос
«Все языки быстрые» это значит что один код выполняется за пять минут, а другой за минуту? (типа существенная разница)
Или разница в сотых долях секунды?
И если второй вариант, то кого ебет эти доли секунды?
«Все языки быстрые» это значит что один код выполняется за пять минут, а другой за минуту? (типа существенная разница)
Или разница в сотых долях секунды?
И если второй вариант, то кого ебет эти доли секунды?
В смысле — Какой то язык быстрый, а какой то медленный — разница существенная или какие то сотые секунды (нахуй никому не сдавшиеся)?
На одной процедуре, допустим, выигрыш сотые доли секунды. Но эта процедура выполняется миллион раз в секунду. Делай выводы, нужны кому-то эти доли секунды или нет.
В посте, как мне кажется пытаются выразить не популярное мнение, что чаще лучше написать так, что бы процедура не выполнялась миллион раз. Скорее всего и код будет лучше и производительность выше
Пример утрирован, но идея, надеюсь понятна. Хотя, например, как ты оптимизируешь выполнение без миллиона раз, когда тебе нужно распарсить миллион файлов?
Это тебе на твоей пеке они не сдались, а в системе управления ядерным реактором они всем сдались, по понятным причинам.
Системы реального времени везде на производстве нужны.
Системы реального времени везде на производстве нужны.
Системы реального времени - это другое. Это не про скорость вычислений, чтобы выполнять операции как можно быстрее. Системы реального времени про то, чтобы время реакции системы было предсказуемым и не превышало заданного. Условно, если ваш код 999 раз отрабатывает за 0.01 сек, а один раз за 0.1 сек - это дерьмовый для реалтайм код. Если ваш код ВСЕГДА отрабатывает за 0.05 сек - это хороший реалтайм код.
Джон, в день, продает 8 апельсинов.
Стив, за тот же период, 7 апельсинов.
Апельсины стоят 5$ за штуку.
Выручка за год:
Джон - 14600$
Стив - 12775$
Все зависит от тяжести программы.
К примеру на калькуляторе ты не заметишь разницы между компилируемым и интерпретируемым языками.
А если использовать, что-то потяжелее, например, 3dsmax или серверные нагрузки, то тут уже заметнее.
Стив, за тот же период, 7 апельсинов.
Апельсины стоят 5$ за штуку.
Выручка за год:
Джон - 14600$
Стив - 12775$
Все зависит от тяжести программы.
К примеру на калькуляторе ты не заметишь разницы между компилируемым и интерпретируемым языками.
А если использовать, что-то потяжелее, например, 3dsmax или серверные нагрузки, то тут уже заметнее.
С закладками апельсины чтоли?
На самом деле больший прирост дает алгоритм. Допустим таже сортировка выполненая пузырьком на С++ будет работать в разы медленее чем быстрая сортировка хоть на JS. Так что ЯП уже кучу лет как подбирают не столько из-за скорости, сколько по области применения, т.к. у каждого свои инструменты по оптимизации кода и его сопровождению.
Давайте уточним, быстрая сортировка на С++ и JS будет работать одинаково быстро, потому что стандартные модули с высокой нагрузкой используют нативный код (читай, JS подключает С-шную библиотеку для сортировки).
Ты про реализацию метода array.sort? Просто я сортировку привел как найболее наглядный пример, и если с нуля писать на выбраном ЯП, то ожидал бы что плюсы справились чуть быстрее (на те самые мс).
Вообще ради хохмы: http://www.cyberforum.ru/csharp-net/thread2387065.html у человека стоит задача просчитать что-то на матрице 64х64. Прототип пишет на 4х4, считает кажется 5 минут, для финальной матрицы задача будет обсчитыватся 100500 лет. Он пытается "ускорится" за счет более правильной конвертации и сравнения, что на выходе даст прирост где-то в один год. XD
Вообще ради хохмы: http://www.cyberforum.ru/csharp-net/thread2387065.html у человека стоит задача просчитать что-то на матрице 64х64. Прототип пишет на 4х4, считает кажется 5 минут, для финальной матрицы задача будет обсчитыватся 100500 лет. Он пытается "ускорится" за счет более правильной конвертации и сравнения, что на выходе даст прирост где-то в один год. XD
Моя понимать. Просто люди воспринимают по разному, и для контекста стоит внести, что в промышленном программировании разницы для самых прожорливых частей логики крайне мало. Основная часть проблем с производительностью это не скорость языка, а откровенные косяки в логике/алгоритмах (как в твоем примере), или неумение языком пользоваться (такое часто бывает в "разгромных" статьях о том какой плохой язык ХХХ, где автор сравнивает его с языком УУУ, в котором он кое-как умеет писать корректно и выводить в консоль буфер, а не посимвольно, скажем)
Когда речь заходит о числодробилках (научные вычисления, графика, нейронные сети и все такое) - они всегда реализуются на компилируемых нативных языках. Например, можно глянуть бенчмарк, где сравнивается куча языков друг с другом. NodeJS всасывает где-то на порядок у С++. Но V8 вроде как с JIT-компиляцией и прочими приседаниями. А питон - просто феерично всасывает.
Не слушай их. Просто повышай мощность машины. Нахуй вообще что либо оптимизировать!?
Тут энтузиасты написали один и тот же код на нескольких ЯП и сравнили их быстродействие:
https://github.com/Mark-Kovalyov/CardRaytracerBenchmark
Разница все же есть, но на мой взгляд, эта разница большой роли не играет. В тех областях, в которых важна каждая миллисекунда, люди выбирают соответствующие ЯП. Во всех остальных случаях адекватного кода вполне достаточно, чтобы пользователь не испытывал дискомфорта.
https://github.com/Mark-Kovalyov/CardRaytracerBenchmark
Разница все же есть, но на мой взгляд, эта разница большой роли не играет. В тех областях, в которых важна каждая миллисекунда, люди выбирают соответствующие ЯП. Во всех остальных случаях адекватного кода вполне достаточно, чтобы пользователь не испытывал дискомфорта.
> но на мой взгляд, эта разница большой роли не играет
C/Raytracer_handofdos2 - 15,028s
C#/Multi-Thread - 37.67
NodeJS v8.10.0 - 121.76 s
C/Raytracer_handofdos2 - 15,028s
C#/Multi-Thread - 37.67
NodeJS v8.10.0 - 121.76 s
Каждый язык программирования разрабатывался для определенного круга задач, и если его активно используют, то он с этими задачами справляется. Никто не пишет драйвера на C#. NodeJS заточен на асинхронное выполнение и неблокирующую синхронизация, из-за чего, скорее всего, он и завалил этот тест. По своему опыту могу сказать, что разрабатывать приложения для Windows удобнее на C#, а не на C++. Я постоянно решаю проблемы с производительностью на своем проекте. В 100% случаях это кривой код. Вложенные циклы; неоптимальные алгоритмы; незнание узких мест своего ЯП; загрузка огромного массива данный, в то время, когда используется лишь его часть; использование неподходящего контейнера; постоянное обновление всего массива данных, вместо интеллектуального подхода; неоптимальные запросы к БД; отсутствие индексов в БД...
В идеальном мире так оно и есть, но в реальном мире эволюция языков программирования плотно завязана на их популярность, которая часто определяется модой, которая часто определяется каким-нибудь одним событием типа создания фреймворка.
Например, LUA - громоздкий и прожорливый язык и уж точно ему не место на микроконтроллерах. Та-дам - встречай NodeMCU.
> Никто не пишет драйвера на C#
C# исполняется в usermode, так что засунуть что-то написанное на C# в ring0 - та еще задачка. Но это ограничение языка, а вовсе не нежелание разработчиков - люди пишут то, что им нужно на том, на чем привыкли, вообще не заморачиваясь проблемами сопоставления языка и задачи.
> разрабатывать приложения для Windows удобнее на C#,
А я по своему опыту скажу, что вообще не понимаю о чем ты. ГУЙ можно делать вообще на чем угодно, разница минимальна. А что именно будет приложение делать кроме гуя - какбэ зависит от задачи.
Перечисленные тобой ошибки тривиальны и присутствуют в той или иной форме во всех языках и областях.
Например, LUA - громоздкий и прожорливый язык и уж точно ему не место на микроконтроллерах. Та-дам - встречай NodeMCU.
> Никто не пишет драйвера на C#
C# исполняется в usermode, так что засунуть что-то написанное на C# в ring0 - та еще задачка. Но это ограничение языка, а вовсе не нежелание разработчиков - люди пишут то, что им нужно на том, на чем привыкли, вообще не заморачиваясь проблемами сопоставления языка и задачи.
> разрабатывать приложения для Windows удобнее на C#,
А я по своему опыту скажу, что вообще не понимаю о чем ты. ГУЙ можно делать вообще на чем угодно, разница минимальна. А что именно будет приложение делать кроме гуя - какбэ зависит от задачи.
Перечисленные тобой ошибки тривиальны и присутствуют в той или иной форме во всех языках и областях.
Проблема того, что люди не хотят переучиваться или изучать новое, когда они отлично знают старое, а руководство не хочет переплачивать за переобучения своих специалистов или найма новых, была всегда. Я это начал осознавать еще тогда, когда познакомился с Delphi в университете. Спрос на это есть, а значит будут предложения. Если люди используют эти технологии, значит в их ситуации плюсы перевесили минусы. Но это все ерунда. Я уверен, что люди, которые идут не по main пути отдают себе отчет в том, что они делают, а если нет, то они просто плохие программисты.
А еще есть такой момент, что новое не обязательно лучше старого. И очень часто новое - это веяние моды. Например, когда-то модным был XML и с его помощью делали вообще все и везде, невзирая не невысокую производительность и чудовищный объем. Из-за этого родилось хтоническое чудовище - коллада, от которого мир до сих пор не избавился (представь, что это такое - парсить 100 мегабайт XML для данных модели с анимацией). И богомерзкий ужас - XSLT, отбросивший разработку снова в эпоху начала PHP, когда код и темплейт смешивались как попало.
Я уже давно не видел "чисто" питоновских программ - машинка - дергает плюсовые либы которые считаются на видяхе, сокеты дергают сишные либы, всякая работа с графикой - плюсовые либы, нумпу - сишная или плюсовая либа... Так что не понимаю этих споров о скорости. Это считается что питон работает на скорости плюсов, потому что я пишу в питоне? Или так уже нельзя сравнивать?
Считается я думаю, в конце концов даже C в хексы компилится в итоге.
Это аргумент уровня "все равно все языки ждут ответа базы данных". Полным-полно чистых задач.
Посмотри на emerge в Gentoo. Эта хрень ухитряется современный сервер подвешивать на полминуты ради обсчета зависимостей какой-то жалкой тысячи пакетов. Сравни Sli3er (Perl) и Cura (Python) - там в десять раз разница по скорости на одних и тех же задачах.
Посмотри на emerge в Gentoo. Эта хрень ухитряется современный сервер подвешивать на полминуты ради обсчета зависимостей какой-то жалкой тысячи пакетов. Сравни Sli3er (Perl) и Cura (Python) - там в десять раз разница по скорости на одних и тех же задачах.
Слайсер на Perl? А господа знают толк в извращениях.
Уже переписали на C++, но начинался он именно на Perl и резал все довольно бодро.
ЗАТКНИСЬ! ЗАТКНИСЬ!
Ага, потому что "делаешь всё правильно" — это когда пишешь прогу на [вставить язык], смотришь какие места вызывают тормоза и выносишь этот код в отдельную либу на C/C++.
Чтобы написать коммент, необходимо залогиниться
Меч брехло, либо не слышал про питон!