t.me/devworden - наш телеграм-чат, где можно задать вопросы discord.gg/7B4prKBxkZ - Discord-сервер с каналами по разным языкам программирования Мой микрофон: ya.cc/aAXRs Моя камера: ya.cc/WEPvP Мой рабочий компьютер: ya.cc/WEQGr Ссылки партнерские, я могу получить вознаграждение, если вы купите что-то, перейдя по этим ссылкам.
@_.tron.__1337
3 жыл бұрын
Я считаю все дело в употребление памяти.
@IiIKarnajIiI
3 жыл бұрын
Но интерпритаторы много где используются, например JAVA,C#,C++. При разработке кросплатформеных игр и приложений P.S Эти языки переводят свой код в байт код и проигрываются на виртуалке (и да я знаю что можно это обойти, но я говорю про конкретные примеры выше)
@nssononev2016
3 жыл бұрын
сначала научитесь ставить правильные флаги у компилятора а потом снимаете видео если поставить нужные оптимизации то код на Си выполняется менее чем за 1ms и рядо м с js не стояло!
@nssononev2016
3 жыл бұрын
компилятор си в в принципе в состоянии увидеть что выполнение этого кода не имеет смысла и просто удалит его
@TheCximus
3 жыл бұрын
тут короче такое дело афтор, но си это не твое) u_int как бы 40000000000 не может быть. И по факту на джсе ответ 40000000000, а в си коде 1345294336. И это печально, а почему так? Тут надо уже обратиться к АСМ коду, который получается после получения программы способом компиляции. Почему стек не берет больше чем 2 в степени 32. Это ж элементарно!
@maksimsivyy5684
3 жыл бұрын
Извините, вы ошиблись!) Продвигаю грамотный С/С++ в массы. 1. Делаем inline функцию g() 2. Делаем константным указатель (*const fun_ptr) 3. Навешиваем перед g() и указателем volatile, чтобы избежать компайл-тайм подсчета Получаем 13 строчек ассемблерного выхлопа c -O3 вместо 26 из вашего примера Время выполнения на моем пк(Windows 10, Ryzen 3600x, 16GB RAM) снижается с 45 секунд до 10(без инлайна будет 10.5) Поясняю: константность указателя дает компилятору уверенность в том, что нет смысла разыменовывать указатель, можно делать вызов напрямую, а тут у нас еще и инлайн - можно вообще вставить все в main( так и происходит) Получаем обход разыменования и call инструкции, за счет чего выигрываем в 5 раз Считаю эти апгрейды абсолютно легальными - ведь JS делает все оптимизации за разработчика, а в Си нужно дружить с компилятором P.S если будете проверять мои слова - компилируйте как C++, потому что gcc выносит все в компайл тайм и просто возвращает посчитанное число,а с g++ у меня как-раз вышло 13 строчек как-то так(когда вставляю ссылку в комментарий - он удаляется): volatile inline unsigned int g(void) { return 1; } volatile unsigned int (*const fun_ptr )(void) = &g; int main(void) { unsigned long long i, j, ret = 0; for (i = 0; i < 40U; i++) for (j = 0; j < 1'000'000'000U; j++) ret += (*fun_ptr)(); return ret; }
@bdick8136
2 жыл бұрын
Хм. У меня Visual Studio. Стандартное консольное приложение и процессор Ryzen 7 3800X. Код без каких либо модификаций в release_x64 сборке 5.3 миллисекунды. Твое решение примерно такое же по скорости. Если первое решение плавает вокруг цифр 5.2 - 5.5, то твое решение выдает 5.5 - 7.2 миллисекунд соотвественно. В любом случае в этом примитивном тесте C++ раскатывает в блин js по скорости. Кто то тут просто врет и хайпит жс.
@alexanderchesnokov7346
3 жыл бұрын
Кликбейт-зголовок снаружи, максимально бессмысленное синтетическое "сравнение языков" внутри. Даже со всеми сделанными оговорками получилось недоразумение, сорри.
@VitalySazanovich
3 жыл бұрын
11 минут, как-никак.
@volodymyrodaysky2182
3 жыл бұрын
Но всем все равно
@andreyandreev3598
3 жыл бұрын
Я сказал проще)
@McGewen
3 жыл бұрын
Все ради просмотров, и ничего болие
@skpavlenko
3 жыл бұрын
Это просто пример. В сети полно более подробных сравнений, и так же далеко не всегда С в плюсе (каламбур).
@dark.lizzard
3 жыл бұрын
Алексей. Попробуйте компрессор на звук наложить во время монтажа. Например в Adobe Audition. Это не очень сложно - звук очень прыгает по громкости. Перегрузка по частотам присутствует.
@aocore
3 жыл бұрын
Спасибо. Посмотрю повнимательнее, или закажу следующее видео профессиональным монтажерам.
@dark.lizzard
3 жыл бұрын
@@aocore если есть желание можно мне скинуть видео и я попробую сделать бесплатно, у меня есть опыт в данном направлении
@rad9587
3 жыл бұрын
@@dark.lizzard заставили меня улыбнуться
@dark.lizzard
3 жыл бұрын
@@rad9587 главное чтобы без насилия
@AntiBandera
3 жыл бұрын
Нужна просто нормализация звука !
@neurowave9076
3 жыл бұрын
Подача стала динамичнее, спасибо за видео
@XStape1
3 жыл бұрын
Просто видео небось в 1.5х
@demimurych1
2 жыл бұрын
8:06 *Пример кода да и вообще* Это видео, прекрасный пример того, что бывает, когда человек который не понимает что он делает считает о себе иначе. А ситуация, которая привела к нужному ему результату не имеет ничего общего с тем, о чем он рассказывает. Ну знаете, это как тесты на IQ, когда человек который оказывается умнее того, который составил тест, получит в этом тесте наименьшую оценку в силу того, что его ответы неверны с позиции автора теста. То есть вопрос тут не в том, что С код может быть лучше или быстрее или наоборот, а в том, что автор измеряет что угодно, но только не то о чем пытается рассказать. И делает это потому, что в принципе не представляет как сейчас работает TurboFan (оптимизирующий компилятор в JS) *Сначала о JS коде автора* Никакого Inline кода JS функции в примере автора нет. Он бы это и сам увидел если бы умел пользоваться такими конструкциями как allow-native-syntax print-code print-bytecode print-opt-code и так далее. Если бы автор видео знал о том, что даже в Google Chrome он мог бы воспользоваться этими конструкциями и получить как байткод так и машинный код генерируемый рантаймом то знал бы, что инлайн его функции произошел бы в лучшем случае на третий вызов родительского цикла. Вне зависимости от того как много итераций он в него влепил. Современный JIT не может оптимизировать тот цикл который сейчас выполняется и это понятно почему. Что же тогда произошло? А все просто. Автор создал стрелочную функцию, которая уже не этапе компиляции в байт код, была помечена как функция без сайд эффектов задача которой возвращать одно и тоже значение. В результате чего никакого вызова функции вообще не было, а единица была сразу подставлена вместо вызова функции. Подчеркиваю - не инлайн кода функции, а просто константа. Этот факт, безусловно показывает то, насколько хорошо могут справляться современные JIT с кодом "обезьян" или людей которые не понимают что они делают. Как автор видео. Совершенно естественно, что между просто вызовом функции, даже в случае машинного call это будет много медленее чем подстановка вместо него константы 1. Но и это еще не все. Если бы автор знал что он делает, то он бы понял, что его JS код мог бы быть почти в 100 раз быстрее. Если бы его циклы были в пределах макисмального знакового числа помещающегося в 31 бит (именно 31 а не 32). Тогда бы автор вообще бы получил космическую скосрость выполнения JS кода, которая бы возможно заставила бы его задуматься - а не ошибся ли я. Но он этого не сделал и получил ситуацию, когда его код в процессе выполнения был вынужден изменяться. Когда в начале рантейм пытался применять самую простую арифметику с цифрами которые поещались в регистры процессора (я ихсожу из того что код выполнялся на 64 битной ситеме) после переполнения же, код был вынужден перейти к работе с числами с плавающей запятой, несмотря на то, что числа все равно были целыми. Я не помню как сейчас обстоят дела в C, но раньше, C вел себя оптимальнее в этом случае. То есть не переходил на работу с математикой в стандарте IEEE-754. *Вместо ИГОГО* Автор видео, тестировал что угодно но только не то о чем пытался рассказать. Произошло это потому, что автор видео понятия не имеет о том, как в дейтвительности сейчас работает код в JavaScript в случае работы оптимизирующего компилятора. Добавьте к этому еще и то, что автор видео не дал себе труда разобраться хотя бы поверхностно в теме то есть научиться получать от V8 байт код и машинный для случаев его оптимизации или нет. Да черт с ним код. В V8 он мог получить подробный лог сообщений, как когда и при каких условиях оптимизировался конкретно его код строка за строкой. И, что самое главное, деоптимизировался. Потому что в современном V8, самая страшная проблема производительности не то, что код остался не оптимизированным, а то, что код все время то оптимизируется то деоптимизируется. И по хорошему - автору должно быть стыдно как программисту. С другой стороны может он деньги зарабатывает. *Может ли быть код на JS быстрее кода на C* Правильный ответ - да может и часто может быть быстрее во много раз. Почему? Потому что производтельность кода на C зависит только от квалификации программиста (за вычетом ошибок компилятора), но производетльность кода на JS зависит от оптимизирующего компилятора который умеет делать фантастические вещи, и от задачи с которой он компилятор умеет справляться. Как итог, в сухом остатке типичный программист на С сейчас с легкостью. напишет код который будет медленнее аналогичного кода на JS. Особенно в случаях многократных повторений. И хорошим примером тому может быть эволюция того как писался SpiderMokey. Но при этом, если мы возьмем профессионала, который до сих пор активно занимается оптимизациями кода, возможности языка С как языка низкого уровня, ограничены лишь архитектурой под которую пишется код и знаниями программиста. Возможности же профессионала под JS ограничены возможностями оптимизирующего компилятора. Который априори, не может сравнится с человеком в качестве, но может значительно его превзойти по обьемах. *Как шуточный пример* Если задать задачу плохому программисту на C и отвратительному программисту на JS найти все числа которые является четными, как первый так и второй может предложить решение где четность определяется остатком от деления на 2. При этом оптимизирующий компилятор JS этот код сразу приведет к состоянию test al,1 а вот код на C может получить много вариаций. Потому что страшна не граната, а обезьяна с гранатой, которая не знает как ей пользоваться.
@georgespringbach2062
2 жыл бұрын
Уложил Лёшу на лопатки. Спасибо за print-code print-opt-code print-bytecode 👍🏻🍻
@Eustrop
3 жыл бұрын
Очень понравились виды Амстердама. Спасибо! Делайте так ещё ;)
@user-rp4xs2jy1t
3 жыл бұрын
Обыкновенные помойные виды, ничего особенного. Вот из-за таких, Москву убили.
@Igor_user
3 жыл бұрын
Амстердам выглядит как большая деревня. Особенно, когда примелькается.
@lolphdundgren4328
3 жыл бұрын
"Объектный" код, подаваемый на выполнение процессору, режет ухо. По традиции этот код называется "машинным". А "объектным", опять же по традиции, называется код, выдаваемый классическим компилятором после компиляции отдельного файла (те самые .OBJ-файлы).
@aocore
3 жыл бұрын
Точно, машинный код.
@СергейМоскалёв-с3ь
3 жыл бұрын
Объектный и машинный код - в конечном итоге одно и то же. И объектные модули здесь не при чём.
@lolphdundgren4328
3 жыл бұрын
@@СергейМоскалёв-с3ь Если б это было так, объектные модули были бы не нужны, и линковка тоже. По своему содержимому код в объектных модулях и в исполняемой программе различен. В качестве одного примера приведу команду ассемблера CALL foo. В объектном коде на месте адреса foo будут нули, а в программе после линковки там будет лежать offset к подлинкованной функции foo. Так что если подсунуть процессору объектный код, то в большинстве случаев выполнение завершится ошибкой. В конечном итоге... в конечном итоге все мы и перегной - одно и то же.
@СергейМоскалёв-с3ь
3 жыл бұрын
@@lolphdundgren4328 Объектный модуль - объектный код, - логика понятна. Есть источники, которые дают такое определение объектного кода. В общем, то, что содержится в объектном модуле, гораздо ближе к объектному (машинному) коду, чем текст исходника, однако большая часть источников говорит, что объектный и машинный код - одно и то же. Вы можете в этом убедиться с помощью любой поисковой системы.
@lolphdundgren4328
3 жыл бұрын
@@СергейМоскалёв-с3ь > однако большая часть источников говорит миллиарды мух не могут ошибаться
@4308
3 жыл бұрын
О, доброе утро 😃
@aleksandrshevchenko5948
3 жыл бұрын
Если тестировать программы автора, то скорость примерно одинакова по 45 сек на i7-8700K. Но если в вызывать саму функцию g(), то при флагах оптимизации o2 и о3 компилятор считает результат вызова g() на этапе компиляции и такая программа работает мгновенно. Но при флаге o1 программа начинает вызывать функцию g() в рантайме. и тогда сишная программа работает всего 8-9 сек, т.е.примерно в 5-5.5 раз быстрее. Т.ч. автор ролика не прав утверждая, что даже в простых вещах js быстрее C.
@aaronwest55
3 жыл бұрын
Это был простой пример для ролика. Не истина в последней инстанции. Разве это не понятно? Человек просто привел пример для видео
@Mustitz
3 жыл бұрын
Во флагах оптимизации нету смысла, потому что для глобальных переменных действует типа неявный volatile (ISO C99, 5.1.2.3p2): потому как указатель на функцию доступен из любой точки, то у компилятора не остаётся другого выбора, кроме как каждый раз вычитывать адрес функции (а вдруг другой поток её изменил) и далее вызов функции. Сам код написан в ключе, запрещающем компилятору любую оптимизацию. А если брать JS, то там стоят любезные подсказки const, какие возможности оптимизатору они дают я не знаю, и читать ECMA мне лень, но выглядит как подсказка. Вообще, если добавить этот const в сишный код, то получаем мгновенный результат ``` -unsigned int (*fun_ptr)(void) = &g; +unsigned int (*const fun_ptr)(void) = &g; ```
@AlexFour
3 жыл бұрын
Все что может быть написано на JavaSript - будет написано на JavaScript (c)
@denisn6408
3 жыл бұрын
Зачем подменять понятия? В JS переменная не является указателем на функцию, в JS нет указателей, JS исполняется в песочнице и не имеет прямого доступа к памяти, конкретно данный компилятор C не смог определить на этапе компиляции, что за функцию вы ему подсунете по указателю, компилятор JS уже видит что за функцию вы присвоили в переменную, сравнение совершенно некорректно.
@aocore
3 жыл бұрын
Угу. Именно про это и видео. AOT компилятор не смог увидеть что-то, что увидел JIT
@denisn6408
3 жыл бұрын
@@aocore Не факт что не увидел, на вашей машине время выполнения одинаковое. И справедливости ради, нужно было сделать хотя бы с десяток независимых расчетов с чистого листа, посчитать среднее и отклонение, если отклонения пересекаются, то разницы в результате просто нет, собственно ее и нет.
@denisn6408
3 жыл бұрын
@@aocore И это сравнение конкретной реализации компиляторов в нативный код для конкретного очень вырожденного случая, точнее намеренная попытка взять на понт один из компиляторов, сделав неэквивалентный исходный алгоритм, а не сравнение языков программирования.
@victormakovchik249
3 жыл бұрын
Прикольно!) Можно ещё припаять время разработки, тогда JavaScript будет быстрее в гораздо большем количестве случаев)
@petryellow
3 жыл бұрын
Зачем?
@nikolaecolog1438
3 жыл бұрын
Если конечно думать о разработчике, а не о пользователях)
@vladcoolish5390
3 жыл бұрын
Притягування за вуха... :)
@ДякуйГалимов-л1з
3 жыл бұрын
Вообще-то, в JS есть fragment. Это и есть та самая "виртуализация", браузер не будет ничего делать с DOM, пока фрагмент остается фрагментом.
@Александр-ь3т9й
3 жыл бұрын
После прослушивания на 34-35 закрыл видео. Никогда язык высокого уровня не будет быстрее языка низкого уровня, как бы вы не старались. Точнее, можно искусственно создать такие условия. И да, JS действительно быстр, в силу его бедности но не настолько быстр в сравнении с "С". Когда я услышал что термины компиляция кода и интерпретация это вызвало ещё больше разочарование, ведь интерпретация включает в себя пред компиляцию и пост компиляцию. К примеру оперируя массиом в JS нельзя заранее угадать какой тип данных примет элемент массива, и компиляция происходит на момент поступления входных данных в программу, что делает её значительно медленнее. Если уж вы начали заглядывать под капот. Постарайтесь провести более детальный анализ.
@СерёгаСокольский
3 жыл бұрын
Тем не менее, Python и JS по бенчмаркам в реальных задачах и бенчмаркам TechEmpower находятcя в заднице мира. Их как раз с огромнейшим разрывом опережают языки линейки C.
@ДякуйГалимов-л1з
3 жыл бұрын
Так это очевидно. Выяснили уже же, что иное может быть только для очень частных случаев. Самое быстрое - это Ассемблер, а потом С.
@MasterofLupanars
3 жыл бұрын
Можно примеры сравнений?
@СерёгаСокольский
3 жыл бұрын
@@ДякуйГалимов-л1з таких частных случаев один на миллион. По сути, такие случаи в реальной жизни не происходят почти НИКОГДА.
@ДякуйГалимов-л1з
3 жыл бұрын
@@СерёгаСокольский И чтобы такие случаи использовать, это надо знать не только сам JS, но и его особенности, как он написан, т.е. что "под капотом".
@СерёгаСокольский
3 жыл бұрын
@@ДякуйГалимов-л1з а под капотом движок, написанный на C++. Ирония, не иначе.
@PTolkachev
3 жыл бұрын
Так я не понял, какая у C "позорная тайна", вынесенная на превью? Ой, простите, забыл, что "кликбейт" - наше всё.
@0xYura-nov
3 жыл бұрын
Я использую Visual Studio, потестил код на С на двух доступных там компиляторах. На Clang - 50.14 c. На MSVC не поверите - 0. Как я понимаю, MSVC посмотрел, что от ввода ничего не зависит(потому что его нет) и посчитал всё заранее. Но почему тогда он не компилил программу минуту?
@МаксимМатвеев-с2л
3 жыл бұрын
Классный формат подачи материала!!) Очень интересно)
@denisluke7191
3 жыл бұрын
Благославляю подсказки ютуба за открытие мне этого канала. Я в восторге от видео на вашем канале
@Sander38rus
3 жыл бұрын
Имхо, не стоит вырезать все паузы: резкий переход сбивает с мысли, и обдумывание добавляет живости видео
@petryellow
3 жыл бұрын
А я смотрю без пауз на 2х и мне норм.
@jevudi6746
3 жыл бұрын
JavaScript Быстрее чем C? Да, но всем всё равно
@freeshooter3163
3 жыл бұрын
Да я в уме быстрее считаю :)
@septemberseptember4893
3 жыл бұрын
Нихрена себе Леша. Это Алескей!
@denisn6408
3 жыл бұрын
С самого начала не понял, что такое объектный код? Процессор выполняет исполнимый машинный код, процессор не понимает никаких объектов, он понимает исключительно свои инструкции и программа в нативном машинном коде уже ничего общего не имеет с человеческими языками программирования, там уже нет никаких объектов, там набор инструкций для процессора. Файлы бинарные все, текст программы написанный на C или JS тоже бинарный файл, состоящий из нулей и единиц, просто посредством декодирования с помощью одной из текстовых кодировок, например UTF-8, он превращается в отображаемый на экране текст.
@dmitrygroker5138
3 жыл бұрын
"максимализм, категоричность и холивар - признак начинающих программистов" так что ж видео с максимализмом, категоричностью и с названием для холивара(( 0 смысла в видео
@georgewashington2216
3 жыл бұрын
Интересное сравнение. Я тоже люблю таким страдать) Особенно на M1. Кстати, что за страна, где столько велосипедов, это Нидерланды?
@aocore
3 жыл бұрын
Да, Нидерланды
@vladimir0rus
3 жыл бұрын
Вообще в примере оба компилятора показали себя плохо, потому что ответ можно вычислить сразу и он константен. И если в Си версии заменить на прямой вызов функции, то компилятор догадывается в чем дело и сразу подставляет правильный ответ.
@sergeimaslovskiy
3 жыл бұрын
Отличное видео, спасибо за выпуск!
@artemnovichenko
3 жыл бұрын
уверен, можно найти еще кучу извращенных примеров где С будет гораздо медленнее))) а вообще чтобы такого небыло как раз и существует вот та самая прокладка между клавиатурой и креслом.
@igoryurchenko1378
3 жыл бұрын
Алексей, над какими задачами (программами) нужно поработать начинающему фронтенд-программисту или что можно написать на чистом JavaScript, чтобы получить навыки, которые пригодятся ему на реальном проекте?
@benzed1618
2 жыл бұрын
вы ошиблись!)!!! вы ошиблись!)!!!!! вы ошиблись!)!!!!!!!!!! Продвигаю грамотный С/С++ в массы. 1. Делаем inline функцию g() 2. Делаем константным указатель (*const fun_ptr) 3. Навешиваем перед g() и указателем volatile, чтобы избежать компайл-тайм подсчета Получаем 13 строчек ассемблерного выхлопа c -O3 вместо 26 из вашего примера Время выполнения на моем пк(Windows 10, Ryzen 3600x, 16GB RAM) снижается с 45 секунд до 10(без инлайна будет 10.5) Поясняю: константность указателя дает компилятору уверенность в том, что нет смысла разыменовывать указатель, можно делать вызов напрямую, а тут у нас еще и инлайн - можно вообще вставить все в main( так и происходит) Получаем обход разыменования и call инструкции, за счет чего выигрываем в 5 раз Считаю эти апгрейды абсолютно легальными - ведь JS делает все оптимизации за разработчика, а в Си нужно дружить с компилятором P.S если будете проверять мои слова - компилируйте как C++, потому что gcc выносит все в компайл тайм и просто возвращает посчитанное число,а с g++ у меня как-раз вышло 13 строчек как-то так(когда вставляю ссылку в комментарий - он удаляется): volatile inline unsigned int g(void) { return 1; } volatile unsigned int (*const fun_ptr )(void) = &g; int main(void) { unsigned long long i, j, ret = 0; for (i = 0; i < 40U; i++) for (j = 0; j < 1'000'000'000U; j++) ret += (*fun_ptr)(); return ret; }
@gobpblueex
3 жыл бұрын
И, кстати, могу порекомендовать совершенно обалденную игрушку Human Resource Machine. По сути это геймификация программирования на ассемблере с минималистичной системой команд, понятная даже ребенку. А выполняя встроенные челленджи можно разобраться как на низком уровне выполняется оптимизация по скорости или объему занимаемой программой памяти.
@КириллЧе-я5ы
3 жыл бұрын
А если попробовать в циклах, дабы не создавать новые объекты использовать ++i etc?..
@КириллЧе-я5ы
3 жыл бұрын
Спасибо большое поэкспериментируем!
@atom735.ag47
3 жыл бұрын
А как же IR? Большинство компиляторов сначала код компилируют в IR, оптимизируют его и уже потом в ассемблер или любой другой бек Энд и оптимизируют его...
@kot_v_chelindre2125
3 жыл бұрын
Подскажите пожалуйста. Недавно я ответил себе на вопрос, на кого я хочу пойти учится, на програмиста. Но вместе с одним ответом последовало три других вопроса. Так вот вопрос №1: Стоит ли подтягивать какие-то школьные предметы? Или стоит уделить больше внимания каким-та другим вещям? Вопрос №2 Куда идти после 9 класса? Или же что делать после 9 класса? Вопрос №3 После обучения где мне искать роботу? Или мне обяснят по мере обучения?
@assetkussainov
3 жыл бұрын
Понимаю, нужен рост аудитории канала. Но качество материала упало. Скоро до Немчинского докатитесь, осторожнее
@Dmytro-Tsymbaliuk
3 жыл бұрын
как видно из видео, это уже произошло
@nvv1305
3 жыл бұрын
я подумал, что речь пойдет про WebAssembly
@sidless3862
3 жыл бұрын
JavaScript быстрее C, но всем все равно)
@nomad_wizard6865
2 жыл бұрын
Блин, разница в скорости меньше секунды... конечно (по хорошему)"удивился", что они предельно равны в скорости выполнении, но сравнивать тут действительно было нечего.) Хотя все равно спасибо. 😉
@valeriipimenov4894
3 жыл бұрын
SOER теперь не одинок ) Еще один топчик в RU IT ) Спасибо
@vpetrunichkin
3 жыл бұрын
Даже на скорости 0.75 смотрится тяжело... Лёша, куда спешите?)))
@izualno_oname7234
3 жыл бұрын
А мне понравилось, так и должен работать мозг и язык у программиста, быстро как Pshichedelic Trance.
@vpetrunichkin
3 жыл бұрын
@@izualno_oname7234 паузы между предложениями придумали лентяи?)))
Данный пример наглядно показывает, что на С то, что ты напишешь, то и будет выполнено. Поэтому, если ты недалёкого ума и пишешь подобный код не оптимизируя, то значит так он и будет выполняться. А node.js таких индивидумов прощает, оптимизируя код за них.
@dmitrijtjapkin5103
3 жыл бұрын
Здравствуйте Алексей, меня зовут Дмитрий! Регулярно смотрю ваши ролики, в одном из последних выпусков, вы упоминали о том , что иногда вам также приходится заниматься архитектурой и т.д. Алексей можно ли с вами пообщаться персонально , через mail, Skype, whatsApp и т.п ?
@aocore
3 жыл бұрын
В телеграме мой ник @alexkorep
@antonrrtyq
3 жыл бұрын
раз в год и палка стреляет как говорится
@Николай-м1ч6х
3 жыл бұрын
Что я понял из видео: ВСЕМ ВСЕ РАВНО =)
@it1shka
3 жыл бұрын
Js очень мощный язык. Конечно же он медленнее чем С в повседневной жизни) Но! Он очень быстрый для интерпретатора. Js это впринципе самый пластичный и динамический язык который я знаю, и то что он по времени выполнения где то только в 3 раза медленнее чем C/C++ это просто вау. Можно зайти на benchmarkgames и посмотреть замеры языков программирования по задачам, и вы увидите, что js всегда идет либо среди компилируемых языков, либо сразу после них по скорости, иногда даже обгоняя какие нибудь Swift, Dart и Go. Python и Ruby работают в десятки раз медленнее чем js. Вообщем, v8 от гугла это действительно впечатляющая работа, которая лично для меня граничит с магией)
@hurricane-rus
2 жыл бұрын
Понятно, что и на ассемблере можно код так криво написать, что он со всеми флагами оптимизации будет работать в 10 раз медленнее JS или какого-то еще аналогичного языка. Только в чем смысл такого действия? Возможность поставить хайповое название у видео - понятно, но есть что-то кроме этого?
@vanyserezhkin
3 жыл бұрын
процессор не имеет доступа к диску, темболее не знает что такое файлы.
@_.tron.__1337
3 жыл бұрын
Так, то есть С может быть быстрее чем ассемблер?
@Al.Sy.
3 жыл бұрын
В общем случае - нет. При высокой квалификации программиста код на ассемблере будет короче, чем "выхлоп" Си-компилятора сходного алгоритма. Программы на ассемблере труднее переносить, модифицировать, понимать из-за его атомарности. Поэтому его удел - критичные по скорости места.
@redneck_prm5429
3 жыл бұрын
Тут зависит от того, кто пишет на ассемблере. Одно дело штучный спец по оптимизации с зарплатой 300к/нсек, и совсем другое - миддл Вася, услышавший, что ассемблер это круто и быстро, и решивший попробовать.
@РомочкаГефнер
3 жыл бұрын
Кек, вспоминается пример со stackoverflow Челик написал на ассемблере программу для вычисления тригонометрических функций, а потом удивлялся, почему она в ряде случаев медленнее встроенной в С. Оказалось, что встроенные сишные функции писались то ли прошареннным математиком, то ли (что вероятнее) после консультации с таковым. Встроенная сначала вычисляла сам способ вычисления синуса, выгодный для данного аргумента, потом его применяла. Любительская всегда считала синус по одному и тому же алгоритму и поэтому часто оказывалась медленнее, даром что написана на ассемблере.
@petryellow
3 жыл бұрын
@@РомочкаГефнер тем ее менее при всех равных код на асме будет быстрее
@ИмяФамилия-э4ф7в
3 жыл бұрын
@@petryellow Код Си компилятором преобразуется в набор инструкций процессора, что эквивалентно ассемблеру. Т.е., грубо говоря, компилятор Си превращает код на Си в код на ассемблере. Что быстрее, ассемблер или ассемблер? И по скорости и размеру решать будет только то, кто лучше оптимизирует конкретные алгоритмы: компилятор Си или программист на ассемблере.
@АлексейВениченко-ш2в
3 жыл бұрын
Когда Java и С не смогли определить победителя в честном бою - было принято решение создать во грехе некую сущность обладающую их общими преимуществами. Из роддома вынесли Шарпы.
@arnav236
3 жыл бұрын
Please consider adding english subtitles
@ibrag2012
3 жыл бұрын
Від процесора залежить: в х86 процесор зберігає функцію в кеші, а в ARM тягає із пам'яті, перевага віртуальних машин тільки якщо вони вміють розподіляти інструкції між ядрами.
@alexw6751
3 жыл бұрын
Существует ли программа, более быстрая в Питоне, чем в ассемблере?
@deniskhakimov
3 жыл бұрын
Это скорее зависит от используемых алгоритмов, чем от выбранного языка.
@sovulken
3 жыл бұрын
LLVM умеет в JIT
@tilld9488
3 жыл бұрын
Переписал код на golang, результат 23.5135529s на i3-6100U c 8гб ОЗУ
@mikalai_root
3 жыл бұрын
Но всем всё равно:)
@Mr.SmartEagle
3 жыл бұрын
Познавательно!
@freeshooter3163
3 жыл бұрын
Тебя сейчас чепухой накормили, смотри язву мозга не получи
@gobpblueex
3 жыл бұрын
Рад, что пригодилась тема ;) Спасибо за разбор и объективные выводы.
@sergeistarodubov2534
3 жыл бұрын
С работает быстрее жс не потому что у него компилятор лучше или хуже, а потому что сишники пишут более оптимизированный код чем жсники
@sashas.3323
3 жыл бұрын
Ну прям поголовно все c-ники хорошие и js-ки плохие
@sergeistarodubov2534
3 жыл бұрын
@@sashas.3323 только сидхи все возводят в абсолют
@Zwery225
3 жыл бұрын
Кто шарит в программировании ответьте пж, какой язык перспективнее учить с нуля C++ или JavaScript? P.S. можете посоветовать какой нибудь другой язык(необязательно)
@antonstoll
3 жыл бұрын
JavaScript конечно. Или Java, или C#, но точно не C/C++
@Dmytro-Tsymbaliuk
3 жыл бұрын
С++ перспективно учить, много чего на нем пишут
@deniskhakimov
3 жыл бұрын
Если хочешь быстренько стартануть, то Python, либо JS. Если же цель - научиться программировать, то Java + учебник Роберта Седжвика.
@Dmytro-Tsymbaliuk
3 жыл бұрын
@@deniskhakimov научиться программировать на языке без указателей сомнительное дело
@pozvoni_babushke
3 жыл бұрын
*но всем всё равно*
@MsFullluck
3 жыл бұрын
Думаю, при должном желании, подобное можно придумать для любой пары популярных языков (хоть в современные языки и пытаются встроить защиту от дурака).
@freeshooter3163
3 жыл бұрын
Походу это тот самый случай-когда сравнивается поверхностный результат, не углубляясь в машинный код. Мужик выставил себя дураком.
@free_person777
3 жыл бұрын
Защиту от изворотливого дурака ещё не придумали. :)
@smolin35
3 жыл бұрын
Спасибо большое за ролик, очень позновательно! Но вас тяжело слушать, если можно, делайте паузы между преложениями.
@22altair22
3 жыл бұрын
Всё, пацантрэ)) пишем драйверы под Linux на javascript))) Оптимизируем производительность
@thecatwrites9731
3 жыл бұрын
доброе утро)
@atom735.ag47
3 жыл бұрын
К тому же засекать время для синтетических тестов на резонно, необходимо считать сколько реальных тиков затратил процессор на исполнение одного потока, а так же сравнивать количество промахов Кеша и переключения контекста. Ибо это самые дорогостоящие операции по времени
@emelerrr
3 жыл бұрын
хорошая воспитательная отсылка про максимализм и холивары.
@maxmolf1599
3 жыл бұрын
ни х.. не понятно но очень интересно )
@АнатолийТолмачевский
3 жыл бұрын
Я вообще не программист, но е мае. Сравнивать си и джава скрипт - это эпик эпиков))) Это как есть клюшка для гольфа и клюшка для хоккея)
@smith-dev
3 жыл бұрын
хорошо, что ты не программист
@aocore
3 жыл бұрын
Да, я согласен, это разные инструменты
@АнатолийТолмачевский
3 жыл бұрын
@@smith-dev почему?
@freeshooter3163
3 жыл бұрын
@@АнатолийТолмачевский Он JS учит, теперь он программист, а все вокруг сам знаешь кто :)
@andya4418
3 жыл бұрын
Режет слух, когда исходный текст называют "кодом".
@boberbobrov5412
6 ай бұрын
из видео я понял, что js быстрее c, когда программист с тупой
@vadimZ1000
3 жыл бұрын
В обеих случаях 😄
@Rest-and-Rest
3 жыл бұрын
JavaScript для работы,Perl для удоволтствия!
@anton5442
3 жыл бұрын
Ты бы еще Hello World на JS с вычислением pi на C сравнил. Дизлайк (ламер)
@h.f.s4774
3 жыл бұрын
Нихуя не понял но очень интересно (шучу)
@yanzlobin
3 жыл бұрын
Жульничество. Одной строчкой можно многократно ускорить программу на сях.
@freeshooter3163
3 жыл бұрын
Указатель в СИ - это всегда указатель на память, а в JS он может и на регистр указывать. Разбирать надо на уровне машинного кода, а не гладить ежа через одеяло .
@denisshashunkin4705
3 жыл бұрын
так разберись сначала, "адрес регистра')))) ахххаа, умник
@МаксимАлексеев-ч4й
3 жыл бұрын
Тут в тему будет курс по performance engineering от MIT: kzitem.info/door/PLUl4u3cNGP63VIBQVWguXxZZi0566y7Wf
@МаксимАлексеев-ч4й
3 жыл бұрын
Посмотрите первую лекцию 😌
@socksito
3 жыл бұрын
🤘
@СлаваМорозов-м3й
3 жыл бұрын
Я пишу комментарий, но всем всё равно :)))
@CirclesOfMotion
3 жыл бұрын
Леша, купи поп фильтр или хотя бы ветрозащиту на микрофон. Стоят копейки.
@ДавидВартанян-й8ч
3 жыл бұрын
Голосую за Rust ! :)
@pawlap
3 жыл бұрын
нууу M1 тотакое
@hartya1749
2 жыл бұрын
6:13
@izergaer
2 жыл бұрын
Всем всё равно
@petryellow
3 жыл бұрын
Надо было ролик назвать виды оптимизации для ускорения.
@YanOlimov
3 жыл бұрын
Js лучший яп
@TheYozka
3 жыл бұрын
Тут мы посмотрели лекцию для колхозников
@k12370rty
3 жыл бұрын
Илон Маск потратил когда-то 100млн на новое железо..ибо оптимизировать ПО было возможно но долго.. а сроки поджимали.. ибо всем всё равно))) главное результат
@antonstoll
3 жыл бұрын
Читабельный код важнее быстрого. Работа программиста стоит дороже чем новое железо, поэтому скорость разработки важнее чем скорость выполнения программы. Да, исключения есть, какие-нибудь драйвера, но по факту даже там уже давно всем все равно.
@Dmytro-Tsymbaliuk
3 жыл бұрын
@@antonstoll а в каком месте читабельность кода корелируется с быстротой?
@antonstoll
3 жыл бұрын
@@Dmytro-Tsymbaliuk Вы как поклонник C++ и сами должны знать, что читабельный код не всегда самый эффективный, а самый эффективный - не совсем читабельный.
@Dmytro-Tsymbaliuk
3 жыл бұрын
@@antonstoll можно написать эффективно, при этом читабельно, а то некоторые любят ребусы из скобок выстраивать, когда это же можно в несколько операций разбить и итог тот же будет
@medio_cre
3 жыл бұрын
JS всегда был лучше С во всем. А теперь полыхайте сишные попки 😄😄
@Dmytro-Tsymbaliuk
3 жыл бұрын
Где вы полыхающие попки нашли то? Если автор видео не компетентен в вопросе вообще
@medio_cre
3 жыл бұрын
@@Dmytro-Tsymbaliuk Уже слышно запах! 😂😂😂
@aaronwest55
3 жыл бұрын
@@Dmytro-Tsymbaliuk Ну да. Ты наверняка более компитентный. Лучше скажи на основе чего ты компитентность опрелелил? На основе одного ролика цель которого просто поделиться информацией? Тогда я на основе одного твоего комментария определяю что ты делетант который еще как то пытается судить людей из сферы которые что-то понимаю в отличии от тебя
@Rh-iw1ls
3 жыл бұрын
Написать кривой код на си и и говорить что джава скрипт быстрее...
@freeshooter3163
3 жыл бұрын
Вы еще зарекнитесь, что ассемблер медленнее C# :D
@0xsadcat92
3 жыл бұрын
С++ точно медленней! Лови пример int main() { volatile float *f1 = new float(5); volatile float *res = new float(0); for (int i = 0; i < INT_MAX; ++i) { *res += *f1; } cout
@apristen
3 жыл бұрын
Лёша много раз употребил золотую фразу: "но всем пофиг" :-) Скорость исполнения не самый важный параметр прог. Заказчик платит за фичи же...
@voznovpetr
3 жыл бұрын
@@0xsadcat92 а можешь показать, как volatile переменную сделать в JavaScript? :)
@DmitriyMerkushov
3 жыл бұрын
"Давайте я напишу страшно неоптимальную программу на Си и сравню с более-менее приличной на JS. Ого! На Си работает медленнее! Ура! Мы постарались обдурить компилятор, и у нас получилось" Вообще задача разработчика обычно - помочь компилятору работать хорошо, а не заставить его работать плохо на граничных случаях.
@ЯсенПень-ф9л
3 жыл бұрын
Я когда проект на stl перетаскивал оказалось что в моем коде std::sort в 50 раз быстрее работает чем стандартный сишный qsort из stdlib.h, ибо шаблоны и все это самое, но кого это волнует, кроме пользователей.
@vladimirkochanov6933
3 жыл бұрын
std::sort это не только quicksort
@andreyandreev3598
3 жыл бұрын
Во, и еще адекватные люди тут есть) хотя как вы вообще на "это" наткнулись то? Потому что создатель ролика платит за накрутку?
@deniskhakimov
3 жыл бұрын
@@andreyandreev3598 создатель ролика просто окучивает начинающих, коих всегда много )
@PTolkachev
3 жыл бұрын
Ну так можно сказать, что JS быстрее ассемблера (Debian под VMWare, виртуалка, конечно, накладывает свой отпечаток на результаты, но несколько прогонов показали примерно те же значения). js: 0m39.285 s c: 0m57.602 s asm: 0m57.570 s - показатели на уровне С, разницу в 0.1 можно считать погрешностью, что и не удивительно, ведь машинный код, по сути, получается тот же (смотрел дизассемблером). Только такие синтетические тесты к реальности ни какого отношения не имеют, а нужны только для кликбейтных заголовков. p.s. Я, конечно, не спец в asm'е (скорее, даже джун), но задача была не оптимизировать, а приблизить решение к предоставленному коду на С. Дизассемблирование исполняемого С файла показало, что, практически, это удалось. ==================== global _start section .text g: mov eax, 1 ret _start: xor ebx, ebx mov edi, g mov ecx, 40 .lp1: mov edx, 1000000000 .lp2: call edi add ebx, eax dec edx jne .lp2 dec ecx jne .lp1 mov eax, 1 int 80h ====================
@Алексей-п9л6н
3 жыл бұрын
Полезное видео, но ....всем все равно)))
@ЕвгенийСоколов-т5л
3 жыл бұрын
...но, всем все равно😄👍
@ac130kz
3 жыл бұрын
мне кажется js в данном случае использует константный референс на эту функцию, тогда можно легко сделать тоже самое в C и получить время исполнения 0.002 секунды)
@AlexandrZverev
3 жыл бұрын
Большого грязного не типизированного слона javascript мы вспоминать не будем. Пусть продолжает анимировать. А Си продолжит менять реальный мир.
Пікірлер: 362