Да начнется холивар! / it-юмор :: holywar :: geek (Прикольные гаджеты. Научный, инженерный и айтишный юмор)

it-юмор geek holywar 

Да начнется холивар!

МОИ ГЛАЗА НЕ ОБМАНЫВАЮТ
МЕНЯ?ЭТО ДЕЙСТВИТЕЛЬНО ВЕЛИКИЙ МЕН ПРАВДЫ?
ВСЕ ЯЗЫКИ БЫСТРЫЕ, ЕСЛИ ТЫ РЕЛАЕШЬ ПРАВИЛЬНО, А НЕ ТОЛЬКО
С/С**,it-юмор,geek,Прикольные гаджеты. Научный, инженерный и  айтишный юмор,holywar
Подробнее
МОИ ГЛАЗА НЕ ОБМАНЫВАЮТ МЕНЯ?ЭТО ДЕЙСТВИТЕЛЬНО ВЕЛИКИЙ МЕН ПРАВДЫ? ВСЕ ЯЗЫКИ БЫСТРЫЕ, ЕСЛИ ТЫ РЕЛАЕШЬ ПРАВИЛЬНО, А НЕ ТОЛЬКО С/С**
it-юмор,geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор,holywar
Еще на тему
Развернуть
Присоединюсь, пожалуй:
Меч брехло, либо не слышал про питон!
cooleran cooleran 20.01.201916:49 ответить ссылка 1.1
В чём проблема питона(я не очень шарю)?
Vitzan Vitzan 20.01.201917:05 ответить ссылка 3.0
Интерпретируемый язык. Как не крути, будет медленнее.
Хмм...А что ты скажешь о джаве
Java (как и C#) сначала компилируется в байткод, а потом исполняется с JIT-компиляцией, поэтому несколько быстрее. (Хотя у python есть PyPy, интерпретатор с JIT. Но даже так происходит синтаксический разбор в рантайме). Но Python создавался как язык научных расчетов, а не для энтерпрайза, как джава. А для расчетов у питона есть различные библиотеки, написанные на C, которые быстрее (напр. numpy). А питон - клей между ними.
Ну, уточню еще 1 момент: java, благодаря оптимизаторам, при правильном коде инлайнится в assembler после warming'a
Окееей, а аргументы будут?
Уточним другой момент: холиварчики холиварчики.

Технически, питон можно компилить, или транспайлить+компилить.
У джавы так вообще грядет (или нагрянул?) Грааль с нативной компиляцией.

И С будет _несколько_ быстрее, при условии что в С всё сделано хорошо и правильно.

В общем и целом программировать на С/С++ слишком дорого для большинства применений при негарантированном и несущественном приросте производительности.
Я холивар даже не пытался начать. И тут же его закончу.
Никогда раньше холивар не начинал, но в этот раз точно на тему питона разожгу. Язык от народа!
Только C# не в байткод а в IL компилится.
Суть одна и та же, не?
Не знаю, как в других языках с JiT, но в C# компиляция идет на ходу и только того, что в данный момент используется. Т.е те методы, который в данный момент вызываются=> разница между уже скомпилированным кодом не заметна. +JiT поделывает доп. оптимизации на целевой платформе. Скажем, видя крутой процессор, компилится с оптимизациями под него.
Сравнивал один и тот же код, написанный на PyPy и на С (MSVC). Разница была на порядок не в пользу Пайтона.
Особенно не разбирался, но догадываюсь, что MS-овский компилятор основные циклы оптимизировал с использованием автовекторизации.
Энивей, в плане устойчивости к случайным ошибкам в исходном коде что Пайтон, что Си не айс. В итоге на отладке какого-нибудь присваивания методу константного значения теряешь больше, чем выигрываешь от времени исполнения.
Щас на С (не С++) писать - большое извращение. Даже если ограничения жесткие, ну так можно не юзать динамический полиморфизм, RTTI, эксепшены и прочую муть, но иметь преимущества плюсов.
Но примеры на StackOverflow-то все с мутью.
Одна из проблем embedded в том, что далеко не для всех чипов производители заморачиваются достойными компиляторами. В результате в крайних случаях даже С не по стандарту и с говеннейшей оптимизацией, не говоря уже о поддержке С++, тем более кроме 98.
okjeee okjeee 21.01.201909:14 ответить ссылка 0.0
Во многих задачах всё сводится к кешу и предварительным вычислениям, и язык уже начинает играть второстепенную роль.
Есть, конечно, задачи, где реально нужно на асме делать, потому что нужена реалтайм обработка чего-то на месте, но в таких случаях можно сделать вставку.
Мой любимый пример с нодой. Не хватает скорости JS? Сделал модуль на C++. Не хватает C++? Вставил туда асм. Ну т.е. опримизация только реально нужных мест, а не всего подряд.
Zav39 Zav39 20.01.201919:04 ответить ссылка 1.2
Вставлять асм - невероятно редкий кейс. Современные оптимизирующие компиляторы справляются со своей работой куда лучше. Они умеют, например, перемещать инструкции, чтобы плотнее загрузить конвейер. Вручную это сделать крайне нетривиально.
Ну бывает можно существенно оптимизировать код через SSE/AVX/AVX2/AVX512 инструкции. Компиляторы пока так вроде не умеют делать. (или я что-то пропустил?)
С/С++ компиляторы векторизовать в ряде умеют. GCC умеет, интеловский умеет еще сильнее. В интеловском можно еще получить отчет об оптимизации на 100500 страниц, где он, в том числе, напишет, какие циклы были векторизованы, а какие нет и почему. Также можно вручную интринскии вставлять. Intel Intrinsics Guide
*в ряде случаев.
Какие флаги в gcc юзать для того, чтобы компилятор оптимизировал код векторизированными инструкциями?
В общем случае - O3. Подробности: https://www.gnu.org/software/gcc/projects/tree-ssa/vectorization.html
Так о том и речь :-) Но если вдруг надо, то пожалуйста. Но, обычно, не надо. И проблема не в языке :-)
Zav39 Zav39 21.01.201917:14 ответить ссылка 0.0
Он медленный даже среди интерпретируемых. Если какое-то говно едва шевелится и сожрало половину оперативки - почти 100% питон.
Hellsy Hellsy 21.01.201902:03 ответить ссылка 0.6
Просто на нём не надо писать вычисления, а только вызов методов из dll-ок написанных на C/C++, тогда производительность будет точно такая же.
DrXak DrXak 21.01.201911:15 ответить ссылка 0.0
Я начинающий, поэтому у меня вопрос
«Все языки быстрые» это значит что один код выполняется за пять минут, а другой за минуту? (типа существенная разница)
Или разница в сотых долях секунды?
И если второй вариант, то кого ебет эти доли секунды?
В смысле — Какой то язык быстрый, а какой то медленный — разница существенная или какие то сотые секунды (нахуй никому не сдавшиеся)?
На одной процедуре, допустим, выигрыш сотые доли секунды. Но эта процедура выполняется миллион раз в секунду. Делай выводы, нужны кому-то эти доли секунды или нет.
dstwo dstwo 20.01.201918:26 ответить ссылка 2.1
В посте, как мне кажется пытаются выразить не популярное мнение, что чаще лучше написать так, что бы процедура не выполнялась миллион раз. Скорее всего и код будет лучше и производительность выше
Rowan Rowan 20.01.201918:32 ответить ссылка 0.9
Пример утрирован, но идея, надеюсь понятна. Хотя, например, как ты оптимизируешь выполнение без миллиона раз, когда тебе нужно распарсить миллион файлов?
dstwo dstwo 20.01.201922:51 ответить ссылка 0.5
Это тебе на твоей пеке они не сдались, а в системе управления ядерным реактором они всем сдались, по понятным причинам.
Системы реального времени везде на производстве нужны.
Системы реального времени - это другое. Это не про скорость вычислений, чтобы выполнять операции как можно быстрее. Системы реального времени про то, чтобы время реакции системы было предсказуемым и не превышало заданного. Условно, если ваш код 999 раз отрабатывает за 0.01 сек, а один раз за 0.1 сек - это дерьмовый для реалтайм код. Если ваш код ВСЕГДА отрабатывает за 0.05 сек - это хороший реалтайм код.
Джон, в день, продает 8 апельсинов.
Стив, за тот же период, 7 апельсинов.
Апельсины стоят 5$ за штуку.
Выручка за год:
Джон - 14600$
Стив - 12775$
Все зависит от тяжести программы.
К примеру на калькуляторе ты не заметишь разницы между компилируемым и интерпретируемым языками.
А если использовать, что-то потяжелее, например, 3dsmax или серверные нагрузки, то тут уже заметнее.
Jezzy Jezzy 20.01.201918:28 ответить ссылка 3.1
С закладками апельсины чтоли?
На самом деле больший прирост дает алгоритм. Допустим таже сортировка выполненая пузырьком на С++ будет работать в разы медленее чем быстрая сортировка хоть на JS. Так что ЯП уже кучу лет как подбирают не столько из-за скорости, сколько по области применения, т.к. у каждого свои инструменты по оптимизации кода и его сопровождению.
Wolfdp Wolfdp 20.01.201919:47 ответить ссылка 0.5
Давайте уточним, быстрая сортировка на С++ и JS будет работать одинаково быстро, потому что стандартные модули с высокой нагрузкой используют нативный код (читай, JS подключает С-шную библиотеку для сортировки).
Ты про реализацию метода array.sort? Просто я сортировку привел как найболее наглядный пример, и если с нуля писать на выбраном ЯП, то ожидал бы что плюсы справились чуть быстрее (на те самые мс).

Вообще ради хохмы: http://www.cyberforum.ru/csharp-net/thread2387065.html у человека стоит задача просчитать что-то на матрице 64х64. Прототип пишет на 4х4, считает кажется 5 минут, для финальной матрицы задача будет обсчитыватся 100500 лет. Он пытается "ускорится" за счет более правильной конвертации и сравнения, что на выходе даст прирост где-то в один год. XD
Wolfdp Wolfdp 20.01.201921:42 ответить ссылка 0.2
Моя понимать. Просто люди воспринимают по разному, и для контекста стоит внести, что в промышленном программировании разницы для самых прожорливых частей логики крайне мало. Основная часть проблем с производительностью это не скорость языка, а откровенные косяки в логике/алгоритмах (как в твоем примере), или неумение языком пользоваться (такое часто бывает в "разгромных" статьях о том какой плохой язык ХХХ, где автор сравнивает его с языком УУУ, в котором он кое-как умеет писать корректно и выводить в консоль буфер, а не посимвольно, скажем)
Когда речь заходит о числодробилках (научные вычисления, графика, нейронные сети и все такое) - они всегда реализуются на компилируемых нативных языках. Например, можно глянуть бенчмарк, где сравнивается куча языков друг с другом. NodeJS всасывает где-то на порядок у С++. Но V8 вроде как с JIT-компиляцией и прочими приседаниями. А питон - просто феерично всасывает.
Не слушай их. Просто повышай мощность машины. Нахуй вообще что либо оптимизировать!?
Тут энтузиасты написали один и тот же код на нескольких ЯП и сравнили их быстродействие:
https://github.com/Mark-Kovalyov/CardRaytracerBenchmark
Разница все же есть, но на мой взгляд, эта разница большой роли не играет. В тех областях, в которых важна каждая миллисекунда, люди выбирают соответствующие ЯП. Во всех остальных случаях адекватного кода вполне достаточно, чтобы пользователь не испытывал дискомфорта.
g0liath g0liath 20.01.201918:40 ответить ссылка 0.8
> но на мой взгляд, эта разница большой роли не играет

C/Raytracer_handofdos2 - 15,028s
C#/Multi-Thread - 37.67
NodeJS v8.10.0 - 121.76 s
Hellsy Hellsy 21.01.201902:07 ответить ссылка 1.1
Каждый язык программирования разрабатывался для определенного круга задач, и если его активно используют, то он с этими задачами справляется. Никто не пишет драйвера на C#. NodeJS заточен на асинхронное выполнение и неблокирующую синхронизация, из-за чего, скорее всего, он и завалил этот тест. По своему опыту могу сказать, что разрабатывать приложения для Windows удобнее на C#, а не на C++. Я постоянно решаю проблемы с производительностью на своем проекте. В 100% случаях это кривой код. Вложенные циклы; неоптимальные алгоритмы; незнание узких мест своего ЯП; загрузка огромного массива данный, в то время, когда используется лишь его часть; использование неподходящего контейнера; постоянное обновление всего массива данных, вместо интеллектуального подхода; неоптимальные запросы к БД; отсутствие индексов в БД...
g0liath g0liath 21.01.201914:08 ответить ссылка -0.1
В идеальном мире так оно и есть, но в реальном мире эволюция языков программирования плотно завязана на их популярность, которая часто определяется модой, которая часто определяется каким-нибудь одним событием типа создания фреймворка.

Например, LUA - громоздкий и прожорливый язык и уж точно ему не место на микроконтроллерах. Та-дам - встречай NodeMCU.

> Никто не пишет драйвера на C#

C# исполняется в usermode, так что засунуть что-то написанное на C# в ring0 - та еще задачка. Но это ограничение языка, а вовсе не нежелание разработчиков - люди пишут то, что им нужно на том, на чем привыкли, вообще не заморачиваясь проблемами сопоставления языка и задачи.

> разрабатывать приложения для Windows удобнее на C#,

А я по своему опыту скажу, что вообще не понимаю о чем ты. ГУЙ можно делать вообще на чем угодно, разница минимальна. А что именно будет приложение делать кроме гуя - какбэ зависит от задачи.

Перечисленные тобой ошибки тривиальны и присутствуют в той или иной форме во всех языках и областях.
Hellsy Hellsy 22.01.201900:47 ответить ссылка 0.1
Проблема того, что люди не хотят переучиваться или изучать новое, когда они отлично знают старое, а руководство не хочет переплачивать за переобучения своих специалистов или найма новых, была всегда. Я это начал осознавать еще тогда, когда познакомился с Delphi в университете. Спрос на это есть, а значит будут предложения. Если люди используют эти технологии, значит в их ситуации плюсы перевесили минусы. Но это все ерунда. Я уверен, что люди, которые идут не по main пути отдают себе отчет в том, что они делают, а если нет, то они просто плохие программисты.
g0liath g0liath 22.01.201901:11 ответить ссылка -0.1
А еще есть такой момент, что новое не обязательно лучше старого. И очень часто новое - это веяние моды. Например, когда-то модным был XML и с его помощью делали вообще все и везде, невзирая не невысокую производительность и чудовищный объем. Из-за этого родилось хтоническое чудовище - коллада, от которого мир до сих пор не избавился (представь, что это такое - парсить 100 мегабайт XML для данных модели с анимацией). И богомерзкий ужас - XSLT, отбросивший разработку снова в эпоху начала PHP, когда код и темплейт смешивались как попало.
Hellsy Hellsy 22.01.201901:36 ответить ссылка 0.1
Я уже давно не видел "чисто" питоновских программ - машинка - дергает плюсовые либы которые считаются на видяхе, сокеты дергают сишные либы, всякая работа с графикой - плюсовые либы, нумпу - сишная или плюсовая либа... Так что не понимаю этих споров о скорости. Это считается что питон работает на скорости плюсов, потому что я пишу в питоне? Или так уже нельзя сравнивать?
sokos sokos 20.01.201918:42 ответить ссылка 1.9
Считается я думаю, в конце концов даже C в хексы компилится в итоге.
Это аргумент уровня "все равно все языки ждут ответа базы данных". Полным-полно чистых задач.

Посмотри на emerge в Gentoo. Эта хрень ухитряется современный сервер подвешивать на полминуты ради обсчета зависимостей какой-то жалкой тысячи пакетов. Сравни Sli3er (Perl) и Cura (Python) - там в десять раз разница по скорости на одних и тех же задачах.
Hellsy Hellsy 21.01.201902:10 ответить ссылка 0.1
Слайсер на Perl? А господа знают толк в извращениях.
Уже переписали на C++, но начинался он именно на Perl и резал все довольно бодро.
Hellsy Hellsy 21.01.201902:40 ответить ссылка 0.0
ЗАТКНИСЬ! ЗАТКНИСЬ!
Ага, потому что "делаешь всё правильно" — это когда пишешь прогу на [вставить язык], смотришь какие места вызывают тормоза и выносишь этот код в отдельную либу на C/C++.
Только зарегистрированные и активированные пользователи могут добавлять комментарии.
Похожие темы

Похожие посты
One morning you wake up find out you have access to God’s developer console. What’s the first thing you do with this power? Discussion ♦ 154 + W 479 & Share ^ BEST COMMENTS ▼ I like forks • 5h hehe3301 • 7h sudo rm -rf oceans/*/contents/ *.plástic sudo rm -rf people/*/*.cáncer sudo rm -rf v
подробнее»

it-юмор geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор без перевода it humor geek it юмор

One morning you wake up find out you have access to God’s developer console. What’s the first thing you do with this power? Discussion ♦ 154 + W 479 & Share ^ BEST COMMENTS ▼ I like forks • 5h hehe3301 • 7h sudo rm -rf oceans/*/contents/ *.plástic sudo rm -rf people/*/*.cáncer sudo rm -rf v
¿i OR IS IT TESTING ME? ЙКОХАЙ-ТЯН УСТРАИВАЕТ ХОЛИВАР 46