06:00 - ошибки при проведение замеров: 1) не прогрел кэши путем вызова функци до замеров, 2) измерение провел одним наблюдением (необходимо проводить множественные наблюдения и выполнять статистическую обработку, 3) перед измерением необходимо подготовить рабочий стенд (хотябы выключить все фоновые программы, а лучше еще и зафиксировать настройки аппаратной платформы - иначе рискуете получать лучшие результаты на бусте процессора и худшие на его базовой частоте и получить неверный результат). Это все придирки, если вы наносекунды выдрачиваете (что эквивалентно единицам, десяткам и сотням тактов процессора), а не миллисекунды (что уже миллионы и миллиарды тактов процессора).
@@rtgiyrefbgowigi3406 Вот мне и интересно где к этому так стремятся) Я бэкендер и нам не платят за производительность, нам платят за фичи) Производительность берется во внимание только в случае критической ситуации
04:00 - автор дает неверное понимание (вывод) обсуждаемой им скорости операции сложения двух целых чисел: именно скорость сложения (как код на языке ассемблера, выполняющий сложение двух целых) не отличается. Отличается здесь количество инструкций, предшествующий операции сложения и контекст выполнения. Для C-программы это попадание в точку входа программы, загрузка операндов, выполнением операции и выход из программы. Для Python же между точкой входа программы (а она обязательно есть) и загрузкой операндов происходит исполнение части программы, интерпретирующей язык. Т.е. в скорости сложения отличий-то нет, есть отличия скорости работы программы в целом, т.к. С-программа уже собрана для выполнения на процессоре одной операции, а Python-программа runtime интерпретируется из исходного текста программы, доходит до операции и выполняет ее. Неверно утверждение для питона про "сотни инструкций чтобы сложить a+b". Верно будет "сотни инструкций, чтобы добраться до сложения a+b"
@@kooorpatovnikooolay8340да, типо того, интерпретатор - та же программа написанная на Си, банально её выполнение и инициализация ядра (если угодно) гораздо дольше, чем короткая программа сложения двух чисел, но когда интерпретатор инициализируется, в дело вступает уже интерпретация байт кода (читай выполнение сложения двух чисел), но всё равно, интерпретация будет происходить дольше, чем выполнение чистых инструкций, если нужно оптимизировать такие места, то пишут модули для питона на Си
@@kooorpatovnikooolay8340 операция сложения на уровне процессора выполняется одинаково для любой программы. Будь она написана на си или на питоне. Главное помнить про трансляцию в байт код некоторыми языками (питон один из них), а так же связанную JIT компиляцию. В целом, мой первый курс был довольно хорошим, раз я помню это до сих пор
"команда выполняется за один герц" -- чувак, ну это непростительно. Кто-то из зрителей так и запомнит теперь. После этого дальше смотреть как-то не хочется, если на уровне школьной программы такие траблы, как верить всему остальному
Автор видео никак не мог так оговориться. Это специально было сделано, что бы была движуха в комментах) И это можно понять, ведь ютуб продвигать будет именно такие комменто-активные видео
ага и именно потому что запрос в базу выполняется секунду, у тебя логает поле в вода, при вводе текста больше n символов. Ох, уж эти адепты все упрется в базу, потому пофиг и не парьтесь, пишите парсер текста как угодно, похрен что он может ast построить за 20мс против 5 секунд, запрос в базу то целую секунду длится....
Для справки, инструкция обрабатывается не за герц, а за такт, точнее за n-ое количество тактов. Такт - вибрация на кристалле процессора. Тактовая частота процессора показывает количество этих самых вибраций в одну секунду, а герц - это всего-лишь единица измерения тактовой частоты.
то есть если у меня моя программа например занимает 1000 тактов, а проц на частоте 3.2 ГГц, то проц выполнит ее за 1*1000/(3.2*10^9)=312 наносекунд, это так работает?
Удивляет количество критики в комментах. Спасибо большое, автор, смотрится интересно и с удовольствием! Предлагаемые в видео подходы - не только и не столько погоня за мелкими и преждевременными оптимизациями. Пусть они мелкие и преждевременные, но программисты, которые не обращают внимания на перформанс на этом этапе, в дальнейшем начинают городить тяжёлую архитектуру, слать последовательные, а не параллельные запросы в сеть, писать тяжеловесные event-bus'ы вместо простого вызова методов и т. д. Суть в том, чтобы воспитывать в разработчиках дисциплину компактного и производительного кода, а благодаря этому он станет и более читаемым, и более поддерживаемым, и более прибыльным. Неоднократно видел удручающе тяжеловесный код, написанный моими коллегами, где вместо 500 строк можно было написать 100. И после рефакторинга всем становилось легче и приложение начинало работать быстрее. Эта проблема действительно существует, и любое освещение темы очень ценно.
Я искренне надеюсь, что люди после этого видео не начнут вводить такого рода оптимизацию с сложением чисел с помощью 128б регистров в свои программы. В 99% случаев для конечного потребителя ( клиента или бизнеса, без разницы) никакой пользы для этого не будет, а нам, потом этот код поддерживать. Пример с гуглом и 1% производительности == лярд долларов -- не состоятельный. Потому как если бы люди запаривались над этим 1 процетом, то написали бы меньше кода, соответсвенно компания бы запустила меньше продуктов, и получила меньше прибыли. В остальном тема действительно интересная только в каких-нибудь аспектах где это действительно может потребоваться, там где используются большие массивы данных. Например при обучении или использовании нейронок. Вот действительно хороший пример, который показывает насколько важна оптимизация. А вообще осуждение за название видеоролика, очевидный кликбейт.
Можно запустить 100 продуктов за день и в каждом стараться писать меньше кода, в этом же идея... Но почему-то "меньше кода" стало "меньше продуктов" и "меньше прибыли".
@@Денис-о5с9ш герц - не единица измерения времени, а единица измерения частоты - равная 1/сек. Такт не может обрабатываться за один или сколько-то ещё герц.
@@genzonlinew а почему тогда говорят "тактовая частота"? Частота измеряется в герцах. Так если процессор 100 герц, то он делает 100 тактов в секунду. Можно ли в этом случаи сказать, что команда выполняемая за один такт выполняется за один герц? Конечно нет, потому что герц всегда 100.
Спасибо за классный разбор. Напомнило разборки за Clear code, проповедующий читаемые исходики любым дядей с улицы - как итог сравнения "СС" и человеческого в производительности СС уступает в 30раз. 30, блин. И люди продвигают эту идею чистого кода, но не продвигают идею чистого разума( Действительно, прогресс принес крутые железки для програмеров, но и тут палка о двух частях, с одной крутое железо, а с другой человеческая лень))) Вот и получаем патчи оптимизации скорости и плавности работы исправляющие косяки, по какой-то причине в процессе разработки и тестирования не замеченные.
В анрил энжоне в ниагаре для частиц выбираются разные алгоритмы, если алгоритм не динамичный то он сделает сам все кэши. Например если было указано что эммитер живет 5 сек и он создает 20 частиц каждую секунду, а частица живет 0.2 сек то система сама посчитает сколько одновременно частиц будет максимально и выделит ровно столько памяти. В компиляторах надо такую же штуку сделать, указываешь что у тебя цикл будет от столько до стольки максимум например.
В энтэрпрайс программировании скорость выполнения не имеет значения, важна только надёжность. Если использованы правильные алгоритмы конечно. С текущими микросервисными ландшафтами большую часть времени комп будет ждать передачи данных в любом случае. Кстати, преждевременная оптимизация - корень зла. Такие дела, калики. Дееем дальш.
Бомбануло от того, что программисты трудятся, чтобы программы станрвились быстрее )) Это в какой реальности так? Наоборот, все становится тяжелее и медленнее. Деньги платятся за новые фичи, и крайне редко - заулучшение старого или за быстродействие. Ну и общая проблема медленного, тяжелого кода в потребительском софте - не в том, что программисты не умеют или не знают за оптимизацию. Проблема в том, что код в принципе совершает бесполезные действия - открываешь простую на вид веб-страницу, там текст с картинками. А твой ноут начинает все вентиляторы раскручивать, будто взлетать собрался! В джаваскрипте в бесконечном цикле запросы на какой то сервер летают, а сбоку в дырку для рекламного банннера приехало видое весом 0,5 Гб. Программирование сломано на более высоком уровне. Здесь никакие simd и jit проблемы производительности не решат.
Программисты могут и зачастую даже хотят сделать программы эффективнее, просто бизнесу не до этого, ему нужно увеличивать количество зарабатываемых денег, что в принципе понять можно.
Лол, так ты попробуй найти время на оптимизацию, когда тебе компания выделяет 10 минут на написание программы запуска ракеты на марс. Программисты может и не против оптимизировать, но на это просто не выделяют финансирования
Срасибо за ссылки, за инфу +-. Не удаляй пожалуйста комментарии (я видел, что ты сказал не будешь удалять, но все же) В комментах адская жара, сюда похоже залетели все супер щарящие типы (о длинных поправках в адрес видео) Супер интересно, удачи всем
0:43 Нет, инструкция не обрабатывается за 1 Герц (1 Раз в секунду) при тактовой частоте процессора 3 Гигагерца (3000000000 раз в секунду). И тем более 1 Герц (1 раз в секунду) не может быть быстрее 200 Герц (200 раз в секунду). По сути, автор сказал, что более сложная операция выполнялась бы 200 раз за время простой операции. 1 секунда не быстрее 0.005 секунды. Такой вот trouble 😅.
Вообще-то оптимизация - стезя инженеров, а не программистов. Обычные программисты дальше компилятора ничего не видят. Поэтому, чтобы писать быстрый код, нужно быть еще и инженером; понимать, какой код нужен, какой не нужен.
Дожили, вот и быдлокодеры. Для успешного кода надо понимать 3 вещи. Архитектуру железа,чёткое знание языка программирования и понимать структуру исполнения. Где на базе всех трёх описанных выше вещей будет плнимание узких мест в исполнении! Быдлокодеры...
6:20 только забыл упомянуть, в реальном коде никогда так делать не надо, это не имеет никакого смысла, у тебя есть компилятор и это его работа оптимизировать твой код, и по факту если посмотреть на все 3 варианта в том же godbolt, то по факту вывод в ассебмлере будет одинаковый, так как компилятор сделал оптимизацию и выбрал самый эффективный вариант, а тот который ты написал стал менее понятным
@@Tezla0 я закинул пример в godbolt, уже при использовании -O1 компилятор вычислял результат во время компиляции и при вызове функции просто возвращал его, можете пожалуйста дать пример кода, который компилятор не смог так оптимизировать
Говорить, что производительность - одна из главных проблем, на этапе развития индустрии, когда эта проблема стоит исторически наименее остро (и по сути в принципе проблемой практически ни в каких отраслях не является) - это просто ультракек, конечно. Я понимаю, что ты только вылез из криокапсулы, но сейчас 2024, не 1970.
@@ramazangit нигде , про эту профессию все говорят, но что она из себя будет представлять никто не знает. Главное трубить , что это будущее ребята камон и все бегут сразу
@@VeneraMilosskaya-w9v Мне кажется там проблема с возвратом, где-то слышал как чувак пытался вернуть курсы, тк. он понял, что уже это знает, а его послали. PS: Но хотелось бы все же реально узнать в чем проблема, мало ли
Гораздо масштабнее проблемы на верхнем уровне: архитектура кода, эффективное распараллеливание, асинхронность, распределение нагрузки, масштабирование с поддержкой консистентности данных, latency сетей и тд и тп. Оптимизацией циклов на 1% CPU пусть занимаются Intel и разработчики конкретного ЯП и его кора.
Божечки, какие же тут супер спецы собрались. И про "зачем sse, когда avx512 есть", и про оптимизацию через -о2 (почему-то про -о3 не говорят), и про "компилятор всё сам умеет"... Я всем хочу привести простой пример. Мы перепесали Java-бэкенд, котрый крутился на VDS, на плюсы. И знаете что? Бэкенд не просто стал быстрее, он стал плавнее и меньше потреблять ресурсов на 60% (примерно). Хотя всё до этого говорило, что такое не осуществимо и не особо перспективно. Но в итоге, клиент за облако стал платить в несколько раз меньше (уменьшилось количество VDS, нагрузки и т.п.). И таки да, мы использовали тпкие вот "преждеврепенные оптимизации".
Бро, я хочу отлично разбираться в программировании, но какое бы обучающее видео я не открыл, я всегда вижу то, как рассказчик показывают путь, но не говорят о направлении этого пути: они объясняют что к чему но не объясняют зачем, более того, даже в обучающих видео, если я не ошибаюсь, берут айтишные термины будто бы из ниоткуда (может всем людям которые смотрят айтишные видео объясняют всю самую базу слов которую мне не выдали...). Есть ли у тебя какие нибудь материалы, которые бы помогли с этими проблемами?
зач те это изучать ваще если цели нет(что создать хочеш назнешь) ??? 🤦🤦😆😅😅 сначала сам подумай без говорящих голов че делать хочешь потом тока гайды смотри ПО ТЕМЕ 👍👍👍 + проги начинай клепать
Чекни шортс с названием "The Best Way To Learn Programming" от ThePrimeTime. Там на английском, но очень интересная мысль выражена. И да, желательно знать английский, чтобы прогу учить, куча годных материалов на нём
Ох... Программистам хрома бы начать так делать. А ещё, тем, кто пишет сайты вконтакта, мыльной почты и ДНС. Их сайты тяжёлые, что капец! И жрут тонны оперативы!
Опять ты продвигаешь эту глупость с оптимизацией там, где не надо. На выходе сразу код становится не расширяем, тяжело поддерживаемым. И для чего это всё? Для какой галочки? Зачем разработчики компиляторов вводили уровни оптимизаций, если их игнорируют и вручную хотят сделать код, который будет делать компилятор при разных уровнях оптимизаций, только код будет поддерживаемым? Ты так давно свернул не туда. И самое интересное, что оно бесполезно. Заниматься оптимизацией когда всё и так быстро работает (да, да, та самая преждевременная оптимизация), когда самые медленные части это Ввод/Вывод, а не ЦПУ/ГПУ - зачем? И при чём здесь метапрограммирование, которое должен делать компилятор, до сравнения C++/Python? Я не ухватил суть. Не увидел в болтовне Кейси топовости. Не знаю почему ты его таковым считаешь.
@@sls1475 Верно, работаю в компании с самой крупной экосистемой для бизнеса, большинству пользователей нет разницы на время выполнение запроса (+100 мс или +200 мс). Так что хоть тройные вложенные циклы и постоянное копирование массивов делай, в конечном счете все равно никто ничего не заметит. А сидеть бэнчить это все по часу, когда все в итоге упирается в скорость интернета пользователей и поход в БД ради 3 мс, которые окупятся минимум после 2М запросов на каждого пользователя - смело !
Ты в последнем пассаже оспорил мнение типа, которого взяли в RAD. Ты мету программирования интерпретировал как метапрограммирование. Я, после этого, все что ты написал - по определению уже не воспринимаю. Не удаляю твой спич, просто потому что мне похуй. Пусть парни фанятся.
@@wndtn Чел привел аргументы, затрагивающие вопросы целесообразности подобных решений - ты решил от них отвернуться, сославшись на авторитет и ошибку интерпретации. Как 14-летний дединсайдик ЧЕЛТЫкнул и попытался вывезти на крутизне И над чьим спичем парни ещё фаниться должны?
В реальном мире 99.9% проблем с производительностью лежат на совершенно другом уровне; микрооптимизации валидны только в том случае, если ты досконально знаешь целевую платформу и уверен ,что компилятор этого не умеет. Те же векторные инструкции иногда с лихвой нивелируются планировщиком проца. неудачный loop unrolling может сломать спекулятивное исполнение и снизить перформанс. Современные процы на столько сложные, "умные" и разные, что нет какого то общего рецепта на микрооптимизации. Возможно один из самых универсальных советов - попытаться поместить данный в L1 кэш, и работать с ними эффективными алгоритмами. остальные трюки - это больше баловство.
8:35 мне интересно где ты на 64-битном процессоре нашел 128 битный регистр, да есть инструкции, которые используют пару регистров, но это совсем не одном и то же
Я тебе больше скажу, на 64 битном проце есть 256 битные инструкции. И это работает по принципу, что они берут эту инструкцию и разбивают ее на 64 битные
@@mxkv67 да есть, но оперции с ними занимают больше времени, так как в отличии от регистров общего назначения ты не можешь просто взять и положить константу туда, тебе придётся класть значение в память, что будет в несколько раз медленнее, чем взаимодействие с регистрами напрямую
@@Satoshic_ Ну да, при работе со скалярами от них толка никакого. Зато при обработке массивов, когда все операции конверизуются и долгая загрузка перестает играть роль, можно получать по четыре результата за такт.
Все логично. Отличный подход. Потом прилетает обновление винды 100500 гигабайт которое сносит старый но нужный софт. Может они не знают, что так можно...
Ну, я конечно далеко не гений перфоманс ревью, но мне кажется, что нет смысла заниматься оптимизацией cpu bound нагрузкой ОТНОСИТЕЛЬНО io bound. Исключениями могут стать лишь всякие мегагиганские корпорации по типу гугла , меты и прочего, где даже десятые доли оптимизации сэкономят сотни ты сяч долларов. Зачем пытаться оптимизировать условные 30 мс в 24, когда чтение из базы/файлика/сетки занимает 300 мс?
На самом деле, самое большое влияние на производительность, оказывает не то что в ролике сказано, а асимптотика основных алгоритмов программы - если вы сортируете пузырьком с квадратичной асимптотикой (вместо n log n) или для поиска используете массив вместо двоичного дерева или хэш таблицы, - вам не поможет никакой SIMD и ппрочие оптимизации. Правильные алгоритмы на "медлленном" языке, всегда будут лучше, чем неправильные но с описанным в ролике. Да, если все алгоритмы в порядке - никто не спорит что низкоуровневые языки и описанные оптимизации могут дать очень много. Но таких задач, в реальной жизни, кот наплакал. Большая часть кодеров занята перекладыванием джейсонов из одного места, в другое
НАКОНЕЦ-ТО!!!! Как же меня бесило то, что мою программу для самопрограммирования, весившую до 50Кб антивирус распознавал как вирус и приходилось раздувать её вес картинкой.
Экономить надо не на инструкциях и циклах, а на глазном давлении читающего код с открывающимися скобками на отдельной строке. Мракобесие индусское копируют друг у друга как черти.
8:54 Если в первой функции заменить sum на массив, то получится такая же векторизация, но без непереносимой магии. 10:27 Это плохой пример, потому что корень квадратный вычисляется за 4 такта и никакое кеширование ты быстрее не сделаешь..
да пофиг всем на производительность как на проблему, скорость это чисто мерялка между языками программирования, типа как хз там когда богатые меряются у кого больше ухо сломано потому что ну щас модно так
Вывод: нахер питон. Представить страшно что происходить у питона внутри когда обучаются нейросети. Ещё из кул стори... а вот представте питон на 8-битном камне))))
всегда можно использовать компилируемый Cython, например. Там разница скорости уже не такая большая, но да, это всё-таки компилятор, причём не такой оптимизированный, как сппшный.
Не, скорее нужны чуваки которые делают продукт и делают его на питоне и чуваки которые просто пишут код и оптимизируют переписывают и вот это все на С++. Тогда у нас скорость разработки не упадет (а она не должна падать) и производительность появится
Библиотеки машинного обучения для Python, под капотом пишутся на C++ и Rust. Например Pytorch, Numpy, sklearn... А создавать сложные нейронные модели в натив С++, это головная боль, даже на Python коды они очень сложные. Так-что по любому, ваш код переводится на оптимальный при сохранения нейронной сети, а дальше, можете вызывать эту модель, через Java, Go и вообще, на чем хотите.
06:00 - ошибки при проведение замеров: 1) не прогрел кэши путем вызова функци до замеров, 2) измерение провел одним наблюдением (необходимо проводить множественные наблюдения и выполнять статистическую обработку, 3) перед измерением необходимо подготовить рабочий стенд (хотябы выключить все фоновые программы, а лучше еще и зафиксировать настройки аппаратной платформы - иначе рискуете получать лучшие результаты на бусте процессора и худшие на его базовой частоте и получить неверный результат). Это все придирки, если вы наносекунды выдрачиваете (что эквивалентно единицам, десяткам и сотням тактов процессора), а не миллисекунды (что уже миллионы и миллиарды тактов процессора).
возможно надо просто для начала не замерять debug 😊
Я так понимаю ты по опыту всё это заметил. В какой области его обрёл? Интересно где такие дикие замеры делают
@@Sylvadorr такие замеры корректно делать в любом месте, где стремятся выжать из железа максимум
@@Qrlik а еще не использовать для замеров системные счетчики, а только процессорные
@@rtgiyrefbgowigi3406 Вот мне и интересно где к этому так стремятся)
Я бэкендер и нам не платят за производительность, нам платят за фичи)
Производительность берется во внимание только в случае критической ситуации
04:00 - автор дает неверное понимание (вывод) обсуждаемой им скорости операции сложения двух целых чисел: именно скорость сложения (как код на языке ассемблера, выполняющий сложение двух целых) не отличается. Отличается здесь количество инструкций, предшествующий операции сложения и контекст выполнения. Для C-программы это попадание в точку входа программы, загрузка операндов, выполнением операции и выход из программы. Для Python же между точкой входа программы (а она обязательно есть) и загрузкой операндов происходит исполнение части программы, интерпретирующей язык. Т.е. в скорости сложения отличий-то нет, есть отличия скорости работы программы в целом, т.к. С-программа уже собрана для выполнения на процессоре одной операции, а Python-программа runtime интерпретируется из исходного текста программы, доходит до операции и выполняет ее. Неверно утверждение для питона про "сотни инструкций чтобы сложить a+b". Верно будет "сотни инструкций, чтобы добраться до сложения a+b"
Думаю автор это и имел в виду, лично я так и понял
Тоесть если прога доберется до 1 сложения, то второе сложение будет +- как в c?
@@kooorpatovnikooolay8340да, типо того, интерпретатор - та же программа написанная на Си, банально её выполнение и инициализация ядра (если угодно) гораздо дольше, чем короткая программа сложения двух чисел, но когда интерпретатор инициализируется, в дело вступает уже интерпретация байт кода (читай выполнение сложения двух чисел), но всё равно, интерпретация будет происходить дольше, чем выполнение чистых инструкций, если нужно оптимизировать такие места, то пишут модули для питона на Си
@@kooorpatovnikooolay8340 операция сложения на уровне процессора выполняется одинаково для любой программы. Будь она написана на си или на питоне. Главное помнить про трансляцию в байт код некоторыми языками (питон один из них), а так же связанную JIT компиляцию.
В целом, мой первый курс был довольно хорошим, раз я помню это до сих пор
Автор прям так и сказал) Да и любой кто кликнул на это видео и так бы понял это)
"команда выполняется за один герц" -- чувак, ну это непростительно. Кто-то из зрителей так и запомнит теперь. После этого дальше смотреть как-то не хочется, если на уровне школьной программы такие траблы, как верить всему остальному
Согласен, физику в школе прогулял, теперь рассказывает то, о чём не знает.
Да ладно, понятно, что за такт.
Автор видео никак не мог так оговориться. Это специально было сделано, что бы была движуха в комментах) И это можно понять, ведь ютуб продвигать будет именно такие комменто-активные видео
@@pav28amur, ой, да ладно всё в конспирологию превращаеть! )
Автор не оговорился, а искренне так понимает физические процессы в CPU.
За один Герц - это за время жизни Генриха Герца - примерно 36 лет и 10 месяцев )))
Ускорил циклы на 10%, сэкономив 30 мс, а потом оказалось, что запрос в базу выполняется секунду(
Можно использовать асинхронность, чтобы процессор не простаивал
@@goginot_YTТы правя, но все в итоге свелется а тому, что задержка сети станет наибольшим узким горлышком, и ие не оптимизиркешь
@@goginot_YT Использовал асинхронность, а потом оказалось, что один запрос в базу зависит от запросов в другую базу(((
ага и именно потому что запрос в базу выполняется секунду, у тебя логает поле в вода, при вводе текста больше n символов. Ох, уж эти адепты все упрется в базу, потому пофиг и не парьтесь, пишите парсер текста как угодно, похрен что он может ast построить за 20мс против 5 секунд, запрос в базу то целую секунду длится....
А чё вы так тупо упёрлись в запрос к базе?
А ещё прикиньте бывают базы разные... С блюмфильтрами на wyhash работали? Всё очень быстро!
Не несите чушь!
Для справки, инструкция обрабатывается не за герц, а за такт, точнее за n-ое количество тактов. Такт - вибрация на кристалле процессора. Тактовая частота процессора показывает количество этих самых вибраций в одну секунду, а герц - это всего-лишь единица измерения тактовой частоты.
то есть если у меня моя программа например занимает 1000 тактов, а проц на частоте 3.2 ГГц, то проц выполнит ее за 1*1000/(3.2*10^9)=312 наносекунд, это так работает?
@@sphardegod5451 Да, именно. Иными словами она выполнится очень быстро.
@@sphardegod5451ну почти, там еще время на запросы к памяти, если ты с ней работаешь
Позитивные вибрации... Ещё один.
Сказал бы уж Импульс. Тактовый импульс, который переводит процессор в следующее состояние.
За один такт на любом современном OoO процессоре завершается более одной инструкции. Не путать throughput и latency.
я думал это видео про rust, ведь он имеет ⚡blazingly✨fast 🦀performance🔥
А ещё у него есть супер ⭐система 💻сборки 🗑cargo 💼
А где 10 часов C++???
Удивляет количество критики в комментах. Спасибо большое, автор, смотрится интересно и с удовольствием!
Предлагаемые в видео подходы - не только и не столько погоня за мелкими и преждевременными оптимизациями. Пусть они мелкие и преждевременные, но программисты, которые не обращают внимания на перформанс на этом этапе, в дальнейшем начинают городить тяжёлую архитектуру, слать последовательные, а не параллельные запросы в сеть, писать тяжеловесные event-bus'ы вместо простого вызова методов и т. д. Суть в том, чтобы воспитывать в разработчиках дисциплину компактного и производительного кода, а благодаря этому он станет и более читаемым, и более поддерживаемым, и более прибыльным.
Неоднократно видел удручающе тяжеловесный код, написанный моими коллегами, где вместо 500 строк можно было написать 100. И после рефакторинга всем становилось легче и приложение начинало работать быстрее. Эта проблема действительно существует, и любое освещение темы очень ценно.
Вот это уже очень интересно.
Need for Speed: Undercode
"я на винде", дальше не стал смотреть
Я искренне надеюсь, что люди после этого видео не начнут вводить такого рода оптимизацию с сложением чисел с помощью 128б регистров в свои программы. В 99% случаев для конечного потребителя ( клиента или бизнеса, без разницы) никакой пользы для этого не будет, а нам, потом этот код поддерживать.
Пример с гуглом и 1% производительности == лярд долларов -- не состоятельный. Потому как если бы люди запаривались над этим 1 процетом, то написали бы меньше кода, соответсвенно компания бы запустила меньше продуктов, и получила меньше прибыли.
В остальном тема действительно интересная только в каких-нибудь аспектах где это действительно может потребоваться, там где используются большие массивы данных. Например при обучении или использовании нейронок. Вот действительно хороший пример, который показывает насколько важна оптимизация.
А вообще осуждение за название видеоролика, очевидный кликбейт.
Если да кабы
Ты просто оправдываешь лень и не желание разбираться .-.
Можно запустить 100 продуктов за день и в каждом стараться писать меньше кода, в этом же идея... Но почему-то "меньше кода" стало "меньше продуктов" и "меньше прибыли".
@@Turqure_rombus В том числе)
9:10 На канале Casey Muratori всего 19 видео, по каким его работам учился?
1 герц чтобы быть обработанной 0:50. Не герц, а такт
такт,который обрабатывается за один герц,если тебе угодно
@@Денис-о5с9ш только скорость выполнения инструкций все-таки прописывается в мануалах в тактах, а не в герцах
@@Денис-о5с9ш герц - не единица измерения времени, а единица измерения частоты - равная 1/сек. Такт не может обрабатываться за один или сколько-то ещё герц.
@@genzonlinew а почему тогда говорят "тактовая частота"? Частота измеряется в герцах. Так если процессор 100 герц, то он делает 100 тактов в секунду. Можно ли в этом случаи сказать, что команда выполняемая за один такт выполняется за один герц? Конечно нет, потому что герц всегда 100.
@@Денис-о5с9штакт выполняется за 1/частота
Спасибо за классный разбор. Напомнило разборки за Clear code, проповедующий читаемые исходики любым дядей с улицы - как итог сравнения "СС" и человеческого в производительности СС уступает в 30раз. 30, блин. И люди продвигают эту идею чистого кода, но не продвигают идею чистого разума( Действительно, прогресс принес крутые железки для програмеров, но и тут палка о двух частях, с одной крутое железо, а с другой человеческая лень))) Вот и получаем патчи оптимизации скорости и плавности работы исправляющие косяки, по какой-то причине в процессе разработки и тестирования не замеченные.
12:08 вообще-то обороты скорее сбавляются. Это в 80-х выжимали из железа максимум.
В анрил энжоне в ниагаре для частиц выбираются разные алгоритмы, если алгоритм не динамичный то он сделает сам все кэши.
Например если было указано что эммитер живет 5 сек и он создает 20 частиц каждую секунду, а частица живет 0.2 сек то система сама посчитает сколько одновременно частиц будет максимально и выделит ровно столько памяти.
В компиляторах надо такую же штуку сделать, указываешь что у тебя цикл будет от столько до стольки максимум например.
Даёшь вторую часть!
В энтэрпрайс программировании скорость выполнения не имеет значения, важна только надёжность. Если использованы правильные алгоритмы конечно. С текущими микросервисными ландшафтами большую часть времени комп будет ждать передачи данных в любом случае. Кстати, преждевременная оптимизация - корень зла. Такие дела, калики. Дееем дальш.
Бомбануло от того, что программисты трудятся, чтобы программы станрвились быстрее ))
Это в какой реальности так? Наоборот, все становится тяжелее и медленнее. Деньги платятся за новые фичи, и крайне редко - заулучшение старого или за быстродействие.
Ну и общая проблема медленного, тяжелого кода в потребительском софте - не в том, что программисты не умеют или не знают за оптимизацию. Проблема в том, что код в принципе совершает бесполезные действия - открываешь простую на вид веб-страницу, там текст с картинками. А твой ноут начинает все вентиляторы раскручивать, будто взлетать собрался! В джаваскрипте в бесконечном цикле запросы на какой то сервер летают, а сбоку в дырку для рекламного банннера приехало видое весом 0,5 Гб. Программирование сломано на более высоком уровне. Здесь никакие simd и jit проблемы производительности не решат.
Программисты могут и зачастую даже хотят сделать программы эффективнее, просто бизнесу не до этого, ему нужно увеличивать количество зарабатываемых денег, что в принципе понять можно.
Ну так в том то и мем, теперь модно не фичи выпускать, а оптимизировать
Всегда писал с расчётом на оптимизацию и всегда не понимал тех, кто дрочит на пыху или пуптон
Это всë NVDIA! Компания рептилоидов, которая заставляет разработчиков писать на пайтоне или скретче и кажду секунду расчитывать синус. Это всë они!
Лол, так ты попробуй найти время на оптимизацию, когда тебе компания выделяет 10 минут на написание программы запуска ракеты на марс.
Программисты может и не против оптимизировать, но на это просто не выделяют финансирования
Срасибо за ссылки, за инфу +-.
Не удаляй пожалуйста комментарии (я видел, что ты сказал не будешь удалять, но все же)
В комментах адская жара, сюда похоже залетели все супер щарящие типы (о длинных поправках в адрес видео)
Супер интересно, удачи всем
0:43 Нет, инструкция не обрабатывается за 1 Герц (1 Раз в секунду) при тактовой частоте процессора 3 Гигагерца (3000000000 раз в секунду). И тем более 1 Герц (1 раз в секунду) не может быть быстрее 200 Герц (200 раз в секунду). По сути, автор сказал, что более сложная операция выполнялась бы 200 раз за время простой операции. 1 секунда не быстрее 0.005 секунды. Такой вот trouble 😅.
Вообще-то оптимизация - стезя инженеров, а не программистов. Обычные программисты дальше компилятора ничего не видят. Поэтому, чтобы писать быстрый код, нужно быть еще и инженером; понимать, какой код нужен, какой не нужен.
Дожили, вот и быдлокодеры.
Для успешного кода надо понимать 3 вещи.
Архитектуру железа,чёткое знание языка программирования и понимать структуру исполнения. Где на базе всех трёх описанных выше вещей будет плнимание узких мест в исполнении!
Быдлокодеры...
Круть! Обожаю эти видео)) Спасибо!
4:32 - а где кэширование и распараллеливание?
кэширование там есть. Распараллеливание - не такая уж и простая оптимизация
6:20 только забыл упомянуть, в реальном коде никогда так делать не надо, это не имеет никакого смысла, у тебя есть компилятор и это его работа оптимизировать твой код, и по факту если посмотреть на все 3 варианта в том же godbolt, то по факту вывод в ассебмлере будет одинаковый, так как компилятор сделал оптимизацию и выбрал самый эффективный вариант, а тот который ты написал стал менее понятным
И эту работу компилятор выполняет крайне плохое, поэтому так делать надо
@@Tezla0 я закинул пример в godbolt, уже при использовании -O1 компилятор вычислял результат во время компиляции и при вызове функции просто возвращал его, можете пожалуйста дать пример кода, который компилятор не смог так оптимизировать
9:15 как его полностью зовут?
Говорить, что производительность - одна из главных проблем, на этапе развития индустрии, когда эта проблема стоит исторически наименее остро (и по сути в принципе проблемой практически ни в каких отраслях не является) - это просто ультракек, конечно. Я понимаю, что ты только вылез из криокапсулы, но сейчас 2024, не 1970.
Не рассказаны как оптимизировать основные длительные операции, которые встречаются в вебе, хотя о нем было затронуто
5:36 Поясните, кто нибудь, как и за счёт чего это работает - unrolled2 и unrolled4 обрабатывают 2 и 4 элементов массива или миллион?
3:05
что за менюшка, как её вызвать?
Промпт-инжиниринг - вот настоящая новая мета программирования!
Если ты программист да)
Потом добавят в промпты ветвления, циклы, переменные, функции, классы и модули и наконец настоящая мета программирования будет достигнута!
А где учить
@@ramazangit нигде , про эту профессию все говорят, но что она из себя будет представлять никто не знает. Главное трубить , что это будущее ребята камон и все бегут сразу
Тот самый, который сам уже заменен ИИ))))
А ООП замедляет?
оптимизируешь, зп получаешь, потом раз и обновление микрокода прилетает и херачит перфоманс на 10 - 15%
поэтому надо переходить на VLIW. Никакой микрокод оптимизации не сломает, только компилятор)
Сильно оптимизировать под x64 смысла нет, когда приложение идет под работу на куче процессоров разных микроархитектур.
А где алгоритмы и структуры данных? Как раз засчет них ускорение происходит не на 10-20% а буквально в десятки раз
хотел поставить лайк, но потом началась реклама скилфектори
А чем не нравится эта школа? У них хорошие курсы, я после них работу быстро нашла, причём по их же наводке)
@@VeneraMilosskaya-w9v Мне кажется там проблема с возвратом, где-то слышал как чувак пытался вернуть курсы, тк. он понял, что уже это знает, а его послали.
PS: Но хотелось бы все же реально узнать в чем проблема, мало ли
Гораздо масштабнее проблемы на верхнем уровне: архитектура кода, эффективное распараллеливание, асинхронность, распределение нагрузки, масштабирование с поддержкой консистентности данных, latency сетей и тд и тп. Оптимизацией циклов на 1% CPU пусть занимаются Intel и разработчики конкретного ЯП и его кора.
Божечки, какие же тут супер спецы собрались. И про "зачем sse, когда avx512 есть", и про оптимизацию через -о2 (почему-то про -о3 не говорят), и про "компилятор всё сам умеет"...
Я всем хочу привести простой пример. Мы перепесали Java-бэкенд, котрый крутился на VDS, на плюсы. И знаете что? Бэкенд не просто стал быстрее, он стал плавнее и меньше потреблять ресурсов на 60% (примерно). Хотя всё до этого говорило, что такое не осуществимо и не особо перспективно. Но в итоге, клиент за облако стал платить в несколько раз меньше (уменьшилось количество VDS, нагрузки и т.п.).
И таки да, мы использовали тпкие вот "преждеврепенные оптимизации".
хотелось бы увидеть видео про углубление в comp scie
У него целый плейлист есть на эту тему
5:16 тут, видимо, опечатка, в правом примере забыл убрать, собственно, цикл.
Наконец-то видос про оптимизацию
Товарищи требуем 10 часов C++.
Бро, я хочу отлично разбираться в программировании, но какое бы обучающее видео я не открыл, я всегда вижу то, как рассказчик показывают путь, но не говорят о направлении этого пути: они объясняют что к чему но не объясняют зачем, более того, даже в обучающих видео, если я не ошибаюсь, берут айтишные термины будто бы из ниоткуда (может всем людям которые смотрят айтишные видео объясняют всю самую базу слов которую мне не выдали...). Есть ли у тебя какие нибудь материалы, которые бы помогли с этими проблемами?
Найди себе (+/-) опытного чувака, и пуляй вопросами.
Специально для таких как ты существует chatGPT. Или он тебя в ЧС добавил?
Я не хочу показаться токсиком, но в 2024 уже стыдно такие вопросы задавать
@@diam0nddangel336 ничего не стыдно. Всё нормально.
зач те это изучать ваще если цели нет(что создать хочеш назнешь) ??? 🤦🤦😆😅😅 сначала сам подумай без говорящих голов че делать хочешь потом тока гайды смотри ПО ТЕМЕ 👍👍👍 + проги начинай клепать
Чекни шортс с названием "The Best Way To Learn Programming" от ThePrimeTime. Там на английском, но очень интересная мысль выражена. И да, желательно знать английский, чтобы прогу учить, куча годных материалов на нём
Ох... Программистам хрома бы начать так делать. А ещё, тем, кто пишет сайты вконтакта, мыльной почты и ДНС. Их сайты тяжёлые, что капец! И жрут тонны оперативы!
где ты монтируешь видео ?
kdenlive
Опять ты продвигаешь эту глупость с оптимизацией там, где не надо.
На выходе сразу код становится не расширяем, тяжело поддерживаемым. И для чего это всё? Для какой галочки? Зачем разработчики компиляторов вводили уровни оптимизаций, если их игнорируют и вручную хотят сделать код, который будет делать компилятор при разных уровнях оптимизаций, только код будет поддерживаемым?
Ты так давно свернул не туда.
И самое интересное, что оно бесполезно. Заниматься оптимизацией когда всё и так быстро работает (да, да, та самая преждевременная оптимизация), когда самые медленные части это Ввод/Вывод, а не ЦПУ/ГПУ - зачем?
И при чём здесь метапрограммирование, которое должен делать компилятор, до сравнения C++/Python? Я не ухватил суть.
Не увидел в болтовне Кейси топовости. Не знаю почему ты его таковым считаешь.
База
@@sls1475 Верно, работаю в компании с самой крупной экосистемой для бизнеса, большинству пользователей нет разницы на время выполнение запроса (+100 мс или +200 мс). Так что хоть тройные вложенные циклы и постоянное копирование массивов делай, в конечном счете все равно никто ничего не заметит. А сидеть бэнчить это все по часу, когда все в итоге упирается в скорость интернета пользователей и поход в БД ради 3 мс, которые окупятся минимум после 2М запросов на каждого пользователя - смело !
Тут прикол в том, что он не имел ввиду метапрограммирование, а мету программирования
Ты в последнем пассаже оспорил мнение типа, которого взяли в RAD.
Ты мету программирования интерпретировал как метапрограммирование.
Я, после этого, все что ты написал - по определению уже не воспринимаю.
Не удаляю твой спич, просто потому что мне похуй.
Пусть парни фанятся.
@@wndtn
Чел привел аргументы, затрагивающие вопросы целесообразности подобных решений - ты решил от них отвернуться, сославшись на авторитет и ошибку интерпретации.
Как 14-летний дединсайдик ЧЕЛТЫкнул и попытался вывезти на крутизне
И над чьим спичем парни ещё фаниться должны?
Я чет не понял, где 10 часов с++!???
Computer Enhance! Course from muratori, basically said the same thing
Спасибо за ссылки
В реальном мире 99.9% проблем с производительностью лежат на совершенно другом уровне; микрооптимизации валидны только в том случае, если ты досконально знаешь целевую платформу и уверен ,что компилятор этого не умеет. Те же векторные инструкции иногда с лихвой нивелируются планировщиком проца. неудачный loop unrolling может сломать спекулятивное исполнение и снизить перформанс. Современные процы на столько сложные, "умные" и разные, что нет какого то общего рецепта на микрооптимизации. Возможно один из самых универсальных советов - попытаться поместить данный в L1 кэш, и работать с ними эффективными алгоритмами. остальные трюки - это больше баловство.
Это ладно,где 10 часов С++
8:35 мне интересно где ты на 64-битном процессоре нашел 128 битный регистр, да есть инструкции, которые используют пару регистров, но это совсем не одном и то же
Не поверишь, они еще на 32-битном проце появились, назывались xmm0-xmm7, на 64-битном их стало 16: xmm0-xmm15.
Я тебе больше скажу, на 64 битном проце есть 256 битные инструкции. И это работает по принципу, что они берут эту инструкцию и разбивают ее на 64 битные
@@vincentvince2136 я как раз таки это и писал, что разбить можно, но это не один регистр
@@mxkv67 да есть, но оперции с ними занимают больше времени, так как в отличии от регистров общего назначения ты не можешь просто взять и положить константу туда, тебе придётся класть значение в память, что будет в несколько раз медленнее, чем взаимодействие с регистрами напрямую
@@Satoshic_ Ну да, при работе со скалярами от них толка никакого. Зато при обработке массивов, когда все операции конверизуются и долгая загрузка перестает играть роль, можно получать по четыре результата за такт.
добрый вечер джентельмены
Я-то думал, видео про метапрограммирование...
10:36 кэширование для флотов)))
хех
Расскажи про DOTS стек в юнити
Расскажи ещё про RISC-V
обрати внимание на доклады сотрудников
Yadro
@@rtgiyrefbgowigi3406 я сотрудничаю с ядром. Хочу просто услышать мнение Виндертона
Все логично. Отличный подход.
Потом прилетает обновление винды 100500 гигабайт которое сносит старый но нужный софт. Может они не знают, что так можно...
что за потрясающий арт на 4:20
Ну, я конечно далеко не гений перфоманс ревью, но мне кажется, что нет смысла заниматься оптимизацией cpu bound нагрузкой ОТНОСИТЕЛЬНО io bound. Исключениями могут стать лишь всякие мегагиганские корпорации по типу гугла , меты и прочего, где даже десятые доли оптимизации сэкономят сотни ты сяч долларов. Зачем пытаться оптимизировать условные 30 мс в 24, когда чтение из базы/файлика/сетки занимает 300 мс?
2:17 Чел про годболт не слышал
зач ему это нужно когда есть ЛОКАЛЬНЫЙ дизасм?? с удобным ui 🤣🤣🤦 saass 👉💩💩
Чел не слышал про -о2 оптимизации, когда эти 2 числа просто на компайл тайме посчитаются
@@vulduk3679 может ты еще в уме все считать предложиш а в проге тока writeln оставить??? 🤣🤣🤣🤦🤦
Продолжай в том же духе
Hi Ya & best wishes. Thanks for work. Be Happy. Sevastopol/Crimea.
nglsh much.
навали братва 10-20к лайков
Хочу некст видос по этой теме =)
Коммент в поддержку продвижения
The name is Primeagen?
Ждем выпуск в красной рубашке в белый цветочек.
Это не новая мета, а старая база…
ждем вторую часть
10:53 это как b = 10?
Оптимизация. Вот про что ролик.
норм, а то я думал будет про ускорение через обкладывание себя нейросетями)
Герц это одна операция в секунду. Школьная физика с размерносиями величин прошла мимо тебя. Процессор делает такты или операции.
Герц - мера частоты. Т е количество операций за ед. времени.
да. пятница
Я нихуа непонимаю аааааааааааааааааааааа
Одиссею на 100%
вовремя ты
На самом деле, самое большое влияние на производительность, оказывает не то что в ролике сказано, а асимптотика основных алгоритмов программы - если вы сортируете пузырьком с квадратичной асимптотикой (вместо n log n) или для поиска используете массив вместо двоичного дерева или хэш таблицы, - вам не поможет никакой SIMD и ппрочие оптимизации. Правильные алгоритмы на "медлленном" языке, всегда будут лучше, чем неправильные но с описанным в ролике. Да, если все алгоритмы в порядке - никто не спорит что низкоуровневые языки и описанные оптимизации могут дать очень много. Но таких задач, в реальной жизни, кот наплакал. Большая часть кодеров занята перекладыванием джейсонов из одного места, в другое
хорошее видео
Огромное спасибо за видео, очень рад, что ты приобщаешь к великой базе новых людей.
е прирост в несколько процентов ради ничего. ура. А пример про гугл настолько актуален, что каждый смотрящий работает в гугле. (нет)
@@КириллКириллович спасибо, ценная информация, без тебя этого никто не знал, ты же один подключен к интернету во всем мире
НАКОНЕЦ-ТО!!!! Как же меня бесило то, что мою программу для самопрограммирования, весившую до 50Кб антивирус распознавал как вирус и приходилось раздувать её вес картинкой.
Больше половины самых залайканных комментов о том, что автор в чём-то неправ. Как маслёнок, я внемлю мнению толпы и перестаю смотреть.
😴 валидно для компаний с мировым охватом, и даже там не на всех направлениях. Дороги с курсами белых хакеров от лохфактори туда нет.
Экономить надо не на инструкциях и циклах, а на глазном давлении читающего код с открывающимися скобками на отдельной строке. Мракобесие индусское копируют друг у друга как черти.
Shalom
Преждевременная оптимизация - корень всех зол...
Да вроде видос не про это
ок
👋🤜🤛🤝👏💥
8:54 Если в первой функции заменить sum на массив, то получится такая же векторизация, но без непереносимой магии.
10:27 Это плохой пример, потому что корень квадратный вычисляется за 4 такта и никакое кеширование ты быстрее не сделаешь..
Не получится так же.
Вся суть в использовании SIMD регистров процессора.
@@DiIov Компилятор тоже знает про SIMD регистры.
меньше 1ккк просмотров за 10 минут, скатился
После этого видео я понял, что код необязательно должен быть понятным. В первую очередь он должен быть быстрым
потому что все хотят быстро писать а не чтобы это быстро работало. asm это класс конечно но тебя не поймут люди которые не знают как жили с 16М ОЗУ
да пофиг всем на производительность как на проблему, скорость это чисто мерялка между языками программирования, типа как хз там когда богатые меряются у кого больше ухо сломано потому что ну щас модно так
Первое слово на украинском прочитал
Вывод: нахер питон.
Представить страшно что происходить у питона внутри когда обучаются нейросети.
Ещё из кул стори... а вот представте питон на 8-битном камне))))
всегда можно использовать компилируемый Cython, например. Там разница скорости уже не такая большая, но да, это всё-таки компилятор, причём не такой оптимизированный, как сппшный.
Не, скорее нужны чуваки которые делают продукт и делают его на питоне и чуваки которые просто пишут код и оптимизируют переписывают и вот это все на С++. Тогда у нас скорость разработки не упадет (а она не должна падать) и производительность появится
@@pavelkillechannel наконец-то с++ прогеры получат заслуженный unskilled job 👍👍
Библиотеки машинного обучения для Python, под капотом пишутся на C++ и Rust. Например Pytorch, Numpy, sklearn... А создавать сложные нейронные модели в натив С++, это головная боль, даже на Python коды они очень сложные. Так-что по любому, ваш код переводится на оптимальный при сохранения нейронной сети, а дальше, можете вызывать эту модель, через Java, Go и вообще, на чем хотите.
Пятый 🎉