Да начнется холивар!
Хмм...А что ты скажешь о джаве
Java (как и C#) сначала компилируется в байткод, а потом исполняется с JIT-компиляцией, поэтому несколько быстрее. (Хотя у python есть PyPy, интерпретатор с JIT. Но даже так происходит синтаксический разбор в рантайме). Но Python создавался как язык научных расчетов, а не для энтерпрайза, как джава. А для расчетов у питона есть различные библиотеки, написанные на C, которые быстрее (напр. numpy). А питон - клей между ними.
Ну, уточню еще 1 момент: java, благодаря оптимизаторам, при правильном коде инлайнится в assembler после warming'a
Окееей, а аргументы будут?
Уточним другой момент: холиварчики холиварчики.
Технически, питон можно компилить, или транспайлить+компилить.
У джавы так вообще грядет (или нагрянул?) Грааль с нативной компиляцией.
И С будет _несколько_ быстрее, при условии что в С всё сделано хорошо и правильно.
В общем и целом программировать на С/С++ слишком дорого для большинства применений при негарантированном и несущественном приросте производительности.
Технически, питон можно компилить, или транспайлить+компилить.
У джавы так вообще грядет (или нагрянул?) Грааль с нативной компиляцией.
И С будет _несколько_ быстрее, при условии что в С всё сделано хорошо и правильно.
В общем и целом программировать на С/С++ слишком дорого для большинства применений при негарантированном и несущественном приросте производительности.
Только C# не в байткод а в IL компилится.
Не знаю, как в других языках с JiT, но в C# компиляция идет на ходу и только того, что в данный момент используется. Т.е те методы, который в данный момент вызываются=> разница между уже скомпилированным кодом не заметна. +JiT поделывает доп. оптимизации на целевой платформе. Скажем, видя крутой процессор, компилится с оптимизациями под него.
Во многих задачах всё сводится к кешу и предварительным вычислениям, и язык уже начинает играть второстепенную роль.
Есть, конечно, задачи, где реально нужно на асме делать, потому что нужена реалтайм обработка чего-то на месте, но в таких случаях можно сделать вставку.
Мой любимый пример с нодой. Не хватает скорости JS? Сделал модуль на C++. Не хватает C++? Вставил туда асм. Ну т.е. опримизация только реально нужных мест, а не всего подряд.
Есть, конечно, задачи, где реально нужно на асме делать, потому что нужена реалтайм обработка чего-то на месте, но в таких случаях можно сделать вставку.
Мой любимый пример с нодой. Не хватает скорости JS? Сделал модуль на C++. Не хватает C++? Вставил туда асм. Ну т.е. опримизация только реально нужных мест, а не всего подряд.
Ну бывает можно существенно оптимизировать код через SSE/AVX/AVX2/AVX512 инструкции. Компиляторы пока так вроде не умеют делать. (или я что-то пропустил?)
С/С++ компиляторы векторизовать в ряде умеют. GCC умеет, интеловский умеет еще сильнее. В интеловском можно еще получить отчет об оптимизации на 100500 страниц, где он, в том числе, напишет, какие циклы были векторизованы, а какие нет и почему. Также можно вручную интринскии вставлять. Intel Intrinsics Guide
Он медленный даже среди интерпретируемых. Если какое-то говно едва шевелится и сожрало половину оперативки - почти 100% питон.
Я начинающий, поэтому у меня вопрос
«Все языки быстрые» это значит что один код выполняется за пять минут, а другой за минуту? (типа существенная разница)
Или разница в сотых долях секунды?
И если второй вариант, то кого ебет эти доли секунды?
«Все языки быстрые» это значит что один код выполняется за пять минут, а другой за минуту? (типа существенная разница)
Или разница в сотых долях секунды?
И если второй вариант, то кого ебет эти доли секунды?
В смысле — Какой то язык быстрый, а какой то медленный — разница существенная или какие то сотые секунды (нахуй никому не сдавшиеся)?
Системы реального времени - это другое. Это не про скорость вычислений, чтобы выполнять операции как можно быстрее. Системы реального времени про то, чтобы время реакции системы было предсказуемым и не превышало заданного. Условно, если ваш код 999 раз отрабатывает за 0.01 сек, а один раз за 0.1 сек - это дерьмовый для реалтайм код. Если ваш код ВСЕГДА отрабатывает за 0.05 сек - это хороший реалтайм код.
Джон, в день, продает 8 апельсинов.
Стив, за тот же период, 7 апельсинов.
Апельсины стоят 5$ за штуку.
Выручка за год:
Джон - 14600$
Стив - 12775$
Все зависит от тяжести программы.
К примеру на калькуляторе ты не заметишь разницы между компилируемым и интерпретируемым языками.
А если использовать, что-то потяжелее, например, 3dsmax или серверные нагрузки, то тут уже заметнее.
Стив, за тот же период, 7 апельсинов.
Апельсины стоят 5$ за штуку.
Выручка за год:
Джон - 14600$
Стив - 12775$
Все зависит от тяжести программы.
К примеру на калькуляторе ты не заметишь разницы между компилируемым и интерпретируемым языками.
А если использовать, что-то потяжелее, например, 3dsmax или серверные нагрузки, то тут уже заметнее.
С закладками апельсины чтоли?
На самом деле больший прирост дает алгоритм. Допустим таже сортировка выполненая пузырьком на С++ будет работать в разы медленее чем быстрая сортировка хоть на 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#. 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, когда код и темплейт смешивались как попало.
Я уже давно не видел "чисто" питоновских программ - машинка - дергает плюсовые либы которые считаются на видяхе, сокеты дергают сишные либы, всякая работа с графикой - плюсовые либы, нумпу - сишная или плюсовая либа... Так что не понимаю этих споров о скорости. Это считается что питон работает на скорости плюсов, потому что я пишу в питоне? Или так уже нельзя сравнивать?
Это аргумент уровня "все равно все языки ждут ответа базы данных". Полным-полно чистых задач.
Посмотри на emerge в Gentoo. Эта хрень ухитряется современный сервер подвешивать на полминуты ради обсчета зависимостей какой-то жалкой тысячи пакетов. Сравни Sli3er (Perl) и Cura (Python) - там в десять раз разница по скорости на одних и тех же задачах.
Посмотри на emerge в Gentoo. Эта хрень ухитряется современный сервер подвешивать на полминуты ради обсчета зависимостей какой-то жалкой тысячи пакетов. Сравни Sli3er (Perl) и Cura (Python) - там в десять раз разница по скорости на одних и тех же задачах.
Ага, потому что "делаешь всё правильно" — это когда пишешь прогу на [вставить язык], смотришь какие места вызывают тормоза и выносишь этот код в отдельную либу на C/C++.
Меч брехло, либо не слышал про питон!