Каждый раз когда я вас слушаю я поражаюсь глубине понимания своих предметов оратора. Не менее удивляет и феноминальная способность обяснять на доступном языке без потери качества информации
Когда изучал Haskell кайфанул в моменте, когда лектор (Денис Москвин) прокомментировал оператор монадического связывания фразой "вот мы и изобрели императивное программирование через оператор точка с запятой"
Очень интересный рассказ - во всяком случае, пока не дошёл до вещей, про которые я хоть что-нибудь знаю. Казалось бы, как Linux может сломаться от изменений в юзерспейсной библиотеке glibc? Разгадка проста: на самом деле история имела место с Flash Player, в котором проприетарная лицензия не позволяла что-то просто взять и подхачить на стороне мейнтейнеров. Линус возмущался на правах пользователя, которому сломали звук в видосиках с котиками, в итоге все долго думали, как бы вызвать memmove вместо memcpy так, чтобы ничего не нарушить, а Дреппер как бы ни винил программистов (в целом закономерно, но что с того пользователям) - в конце концов к glibc всё же приделали версионирование символов, чтобы бажный, но ранее работавший код не ломался от того, что кто-то обновил glibc.
Спасибо! Я таких деталей не знала. Но понятно, что неприятно, когда что-то ломают и тебя это аффектит. Мы тоже были не очень довольны, когда в релизе gcc13 сломали в стандартной библиотеке обратную совместимость.
После скандала с memcpy/memmove я был так потрясён реакцией Linus'а, что сначала некоторое время не мог в это поверить. Особенно меня потрясло это его заявление: "Standards are paper. I use paper to wipe my butt every day. That's how much that paper is worth." Это точная цитата, но она встречается много, где, первоисточник же ищется по ключевым словам bug 638477 bugzilla redhat (читать Comment 129). Ни один разработчик никогда так не падал в моих глазах. На самом деле решение там имеется, и оно -- не от Linus'а,хотя он предложил своё тоже. А именно -- все вызовы memcpy в бинарнике заменяются на memmove с помощью утилиты dd, то есть, бинарный файл patch'ится. Или ещё проще -- модифицируется одно вхождение в динамической таблице символов.
Забавно, что HLSL теперь кроссплатформенный и кроссапишный. Плюс есть всякие битфилды, темплейты и всё такое. И есть компиляция в бекенды SPRIV, GLSL, и даже в Metal. И для Vulkan есть неймспейс чтоб юзать device address какой-нибудь, арифметика для указателей)
Помню свою беспомощность при поиске причины повисания одного SoC от TI. На условном ядре #0 была ошибка доступа по шине, а намертво вешалось при этом ядро #1. И выведать проблему путем отладки софта заняло очень много времени. Кайфово работать верификатором, когда видишь сразу всё состояние чипа во все моменты времени на диаграмме, и ничего от взгляда не скрыто. С подобными проблемами надо идти именно к верификаторам, и если не баг в железе найдут, то хоть баг в софте помогут найти быстрей
Не всегда и у не у всех, к сожалению, есть легкий доступ к верификаторам. Аппаратчики люди занятые. У нас как раз одним из следующих гостей планируются именно верификатор, может затронем и этот вопрос :)
Это точно. Я работал над двумя разными GPU ядрами (ARM Mali T6xx and Broadcom VC5), и было до крайности удобно иметь полную RTL модель GPU - никогда больше у меня не было такой удобной среды для отладки компиляторов.
При кодогенерации (backend), конечно, не следует диагностировать UB, но при разборе (frontend) -- это было бы очень полезно. Кстати, сейчас компиляторы стараются диагностировать, но, в идеале, было бы неплохо, если бы диагностировалось всё. Например, лет 20 назад я писал такой типичный код для переносимого вычитывания двухбайтового числа в little endian'е (скажем, это заголовок протокола был): unsigned f(unsigned char const *&p) { return *p++ + 256u * *p++; } И даже не подозревал, что там -- махровый UB. А сейчас все компиляторы предупреждают об этом, в частности, clang делает это так: source>:11:11: warning: multiple unsequenced modifications to 'p' [-Wunsequenced] 11 | return *p++ + 256u * *p++; Если бы компилятор детектировал все случаи UB, то качество программ, равно, как и грамотность программистов, -- заметно улучшились бы.
@@z140140 Когда-то я тоже так думал. Но вы настолько уверены в своей правоте, что даже недвусмысленное предупреждение компилятора для вас -- не указ. Либо вы просто не понимаете, о чём речь, и поэтому предупреждение компилятора вам ни о чём не говорит. Но, в любом случае, ищите теперь самостоятельно, что здесь не так, я не буду проламывать ваш "железобетон", защищающий вашу "правоту".
Одно небольшое уточнение - в RCU читатели не останавливаются и не блокируются никогда, удаление структуры происходит не когда "они перестают читать на краткое мгновение" а когда все читатели покинут так называемую rcu_read_lock секцию. Покидая эту секцию и входя вновь они получают новую копию. Это порождает еще один тонкий эффект - группа читателей получает разные копии структуры, корректные но разные.
Спасибо за уточнение, конечно, это так :) В подкасте просто объяснения на пальцах, там все детали упомянуть нельзя, ну или иначе эта будет уже подкаст на тему многопоточности и механизмов синхронизации
Забавно, что Константин упомянул статью Дреппера. Я вот как раз надеялся бы услышать в какой-либо форме от него лекцию с обзором этой статьи, с учётом современного состояния железа - всё-таки прошло 16 лет после написания статьи.
Так статья-то до сих пор хороша и актуальна. С тех пор не так уж много чего-то революционно поменялось. А лекции про современное состояние соответствующего железа читает, например, Onur Multu.
Когда я в первый раз попытался распараллелить свой код в универе у меня разумеется всё упало. Путём долгого чтения документации, я смог добиться того, что бы оно зависало. И наверное прошла минимум неделя прежде чем что-то ускорилось.
Если писать код так, чтобы он не падал, то запрет эксепшонов - нормальное поведение ) Кучу библиотек на C не мешает использовать отсутствие в них исключений )
В Си у тебя вместо исключений либо errno ставиться, либо код выхода, либо переменная, которая может означать, например, кол-во записанных байт, и ошибку, если -1. Ну или просто сегу в лицо кидать Писать "чтобы не падало" - сказка. Падать будет и надо рекавериться. Но я и не защищаю исключения. По стандарту не определено вообще как они должны аллоцироваться. Хоп и на куче тебе аллокацию лови)
И легко можно забыть проверить код возврата или errno, что мы и видим. Исключения проигнорировать сложнее. Как минимум рантайм "мягко" намекнёт о необработанном исключении. Про алокацию, да, всё так, но у гцц или у стдлибы есть флажок, чтобы запретить динамическую алокацию.
@@melchugin О, про флаг не знал. Про забыть проверить код, к слову, можно ещё с С23 ставить [[nodiscard]]. Наконец-то стандартизировали)) А так да, надо постоянно проверять что всё это барахло возвращает.
@@gr3yknigh1, да атрибуты это хорошо. Но их нужно не забыть поставить, и это варнинг. А с Werror не все собираются. Ну и самый плюс от исключений: happy-path в них really zero cost! 0 оверхеда в рантайме (только чуть-чуть толще бинарник будет). А все эти if всё же код и он всегда работает. Бранч предиктор, сглаживает эту ситуацию, но всё же.
> Если писать код так, чтобы он не падал, то запрет эксепшонов - нормальное поведение ) Возьмём код: A a; a.method(); Если в конструкторе 'A' выяснится, что сконструировать объект не удалось, то как без поддержки исключений сообщить об этом коду, в котором заводится переменная 'a' и как узнать, что нельзя вызывать метод 'method'? Google совершила в своё время настоящий epic fail, отказавшись использовать исключения ради попытки выиграть в производительности, но теперь уже поздно.
40:42 "компилятор ведёт себя так, как будто UB не существует, как мы можем диагностировать то, чего не существует?" в математике это называется доказательством от противного: "предположим, что в этой программе нет UB", а потом запускаем программу доказательства теорем, которая находит противоречие. Компилятор мог бы быть такой программой, и иногда он даже может найти противоречие, но в-общем случае это невозможно.
Пользователи видят какую-то проблему в C++, и не видят чужих предложений по решению этой проблемы, и начинают изобретать свои улучшения. Если бы был какой-нибудь открытый CEP (по аналогии с PEP), то пользователи бы просто как-нибудь голосовали за чужие предложения и не придумывали бы свои.
С++ это язык, который выбирают плохие программисты, потому что там проще всего писать ужастный код - Линус Торвальдс. Мне кажется ядро Линукса на С++ в ближайшие 30 лет переписывать не будут.
Конечно, если очень интересно и нравится сфера, все возможно, но понятно, что это займет время. Тут не от аккаунта канала нельзя прикреплять ссылки, поэтому просто напишу название. Есть интервью с Алексеем Шипилевым и статья с выжимкой на хабре, которая называется «Чтобы стать хорошим системщиком, нужно 5-10 лет опыта» - интервью с Алексеем Шипилёвым из Java Performance Team. Интервью старое, но хорошее
Ворваться -- реально, но есть обязательное условие: должно быть настолько дико интересно, что за уши не оттащить. Иначе, есть очень большой риск, что через некоторое время наступит разочарование, и придётся вернуться и признать, что врывались зря.
@@eklepilkina К ссылкам на сам youtube это не относится: th-cam.com/video/B1P8RHGtE5I/w-d-xo.html Я добавил ссылку, и мне ничего за это не было, то есть, это сообщение не удалилось, поскольку ссылка -- на youtube.
Register Spill. При аллокации регистров в случае, если не хватает регистров для всех переменных, часть этих переменных перемещается в память. Этот процесс называется spilling.
![1. CS50 на русском: Лекция #1 [Гарвард, Основы программирования, осень 2015 год]](http://i.ytimg.com/vi/SW_UCzFO7X0/mqdefault.jpg)
![[Full Episode] The Restaurant War Thailand ศึกพ่อค้าซ่าแม่ค้าแซ่บ Episode 4 | 13 ต.ค. 67](http://i.ytimg.com/vi/h8N9tY46P-M/mqdefault.jpg)
Каждый раз когда я вас слушаю я поражаюсь глубине понимания своих предметов оратора. Не менее удивляет и феноминальная способность обяснять на доступном языке без потери качества информации
Спасибо, очень рады, что у вас такие впечатления от нашего гостя :)
Ничего не понял, но очень интересно.
Спасибо за гостя ждал выпуска.
Константин в своих спичах как всегда крайне хорош
Когда изучал Haskell кайфанул в моменте, когда лектор (Денис Москвин) прокомментировал оператор монадического связывания фразой "вот мы и изобрели императивное программирование через оператор точка с запятой"
Великолепно. Благодарим!
Очень интересный рассказ - во всяком случае, пока не дошёл до вещей, про которые я хоть что-нибудь знаю. Казалось бы, как Linux может сломаться от изменений в юзерспейсной библиотеке glibc? Разгадка проста: на самом деле история имела место с Flash Player, в котором проприетарная лицензия не позволяла что-то просто взять и подхачить на стороне мейнтейнеров. Линус возмущался на правах пользователя, которому сломали звук в видосиках с котиками, в итоге все долго думали, как бы вызвать memmove вместо memcpy так, чтобы ничего не нарушить, а Дреппер как бы ни винил программистов (в целом закономерно, но что с того пользователям) - в конце концов к glibc всё же приделали версионирование символов, чтобы бажный, но ранее работавший код не ломался от того, что кто-то обновил glibc.
Спасибо! Я таких деталей не знала. Но понятно, что неприятно, когда что-то ломают и тебя это аффектит. Мы тоже были не очень довольны, когда в релизе gcc13 сломали в стандартной библиотеке обратную совместимость.
После скандала с memcpy/memmove я был так потрясён реакцией Linus'а, что сначала некоторое время не мог в это поверить.
Особенно меня потрясло это его заявление: "Standards are paper. I use paper to wipe my butt every day. That's how much that paper is worth."
Это точная цитата, но она встречается много, где, первоисточник же ищется по ключевым словам bug 638477 bugzilla redhat (читать Comment 129).
Ни один разработчик никогда так не падал в моих глазах.
На самом деле решение там имеется, и оно -- не от Linus'а,хотя он предложил своё тоже.
А именно -- все вызовы memcpy в бинарнике заменяются на memmove с помощью утилиты dd, то есть, бинарный файл patch'ится.
Или ещё проще -- модифицируется одно вхождение в динамической таблице символов.
Забавно, что HLSL теперь кроссплатформенный и кроссапишный. Плюс есть всякие битфилды, темплейты и всё такое. И есть компиляция в бекенды SPRIV, GLSL, и даже в Metal. И для Vulkan есть неймспейс чтоб юзать device address какой-нибудь, арифметика для указателей)
Помню свою беспомощность при поиске причины повисания одного SoC от TI. На условном ядре #0 была ошибка доступа по шине, а намертво вешалось при этом ядро #1. И выведать проблему путем отладки софта заняло очень много времени.
Кайфово работать верификатором, когда видишь сразу всё состояние чипа во все моменты времени на диаграмме, и ничего от взгляда не скрыто.
С подобными проблемами надо идти именно к верификаторам, и если не баг в железе найдут, то хоть баг в софте помогут найти быстрей
Не всегда и у не у всех, к сожалению, есть легкий доступ к верификаторам. Аппаратчики люди занятые. У нас как раз одним из следующих гостей планируются именно верификатор, может затронем и этот вопрос :)
Это точно. Я работал над двумя разными GPU ядрами (ARM Mali T6xx and Broadcom VC5), и было до крайности удобно иметь полную RTL модель GPU - никогда больше у меня не было такой удобной среды для отладки компиляторов.
При кодогенерации (backend), конечно, не следует диагностировать UB, но при разборе (frontend) -- это было бы очень полезно.
Кстати, сейчас компиляторы стараются диагностировать, но, в идеале, было бы неплохо, если бы диагностировалось всё.
Например, лет 20 назад я писал такой типичный код для переносимого вычитывания двухбайтового числа в little endian'е (скажем, это заголовок протокола был):
unsigned f(unsigned char const *&p) {
return *p++ + 256u * *p++;
}
И даже не подозревал, что там -- махровый UB.
А сейчас все компиляторы предупреждают об этом, в частности, clang делает это так:
source>:11:11: warning: multiple unsequenced modifications to 'p' [-Wunsequenced]
11 | return *p++ + 256u * *p++;
Если бы компилятор детектировал все случаи UB, то качество программ, равно, как и грамотность программистов, -- заметно улучшились бы.
какое ж это ub? это просто чтение слова в random-endian
@@z140140 Когда-то я тоже так думал.
Но вы настолько уверены в своей правоте, что даже недвусмысленное предупреждение компилятора для вас -- не указ.
Либо вы просто не понимаете, о чём речь, и поэтому предупреждение компилятора вам ни о чём не говорит.
Но, в любом случае, ищите теперь самостоятельно, что здесь не так, я не буду проламывать ваш "железобетон", защищающий вашу "правоту".
давайте теперь в формате stendup следующую встречу
Одно небольшое уточнение - в RCU читатели не останавливаются и не блокируются никогда, удаление структуры происходит не когда "они перестают читать на краткое мгновение" а когда все читатели покинут так называемую rcu_read_lock секцию. Покидая эту секцию и входя вновь они получают новую копию. Это порождает еще один тонкий эффект - группа читателей получает разные копии структуры, корректные но разные.
Спасибо за уточнение, конечно, это так :) В подкасте просто объяснения на пальцах, там все детали упомянуть нельзя, ну или иначе эта будет уже подкаст на тему многопоточности и механизмов синхронизации
Забавно, что Константин упомянул статью Дреппера. Я вот как раз надеялся бы услышать в какой-либо форме от него лекцию с обзором этой статьи, с учётом современного состояния железа - всё-таки прошло 16 лет после написания статьи.
Так статья-то до сих пор хороша и актуальна. С тех пор не так уж много чего-то революционно поменялось. А лекции про современное состояние соответствующего железа читает, например, Onur Multu.
Воо, спасибо-спасибо! Ждал)
Первая параллельная программа работала в 1.5 раза хуже чем однопоточная, а вот на CUDA удалось с первого раза что-то быстрое запилить
Когда я в первый раз попытался распараллелить свой код в универе у меня разумеется всё упало. Путём долгого чтения документации, я смог добиться того, что бы оно зависало. И наверное прошла минимум неделя прежде чем что-то ускорилось.
Если писать код так, чтобы он не падал, то запрет эксепшонов - нормальное поведение )
Кучу библиотек на C не мешает использовать отсутствие в них исключений )
В Си у тебя вместо исключений либо errno ставиться, либо код выхода, либо переменная, которая может означать, например, кол-во записанных байт, и ошибку, если -1. Ну или просто сегу в лицо кидать
Писать "чтобы не падало" - сказка. Падать будет и надо рекавериться.
Но я и не защищаю исключения. По стандарту не определено вообще как они должны аллоцироваться. Хоп и на куче тебе аллокацию лови)
И легко можно забыть проверить код возврата или errno, что мы и видим.
Исключения проигнорировать сложнее. Как минимум рантайм "мягко" намекнёт о необработанном исключении.
Про алокацию, да, всё так, но у гцц или у стдлибы есть флажок, чтобы запретить динамическую алокацию.
@@melchugin О, про флаг не знал.
Про забыть проверить код, к слову, можно ещё с С23 ставить [[nodiscard]]. Наконец-то стандартизировали))
А так да, надо постоянно проверять что всё это барахло возвращает.
@@gr3yknigh1, да атрибуты это хорошо. Но их нужно не забыть поставить, и это варнинг. А с Werror не все собираются.
Ну и самый плюс от исключений: happy-path в них really zero cost! 0 оверхеда в рантайме (только чуть-чуть толще бинарник будет).
А все эти if всё же код и он всегда работает. Бранч предиктор, сглаживает эту ситуацию, но всё же.
> Если писать код так, чтобы он не падал, то запрет эксепшонов - нормальное поведение )
Возьмём код:
A a;
a.method();
Если в конструкторе 'A' выяснится, что сконструировать объект не удалось, то как без поддержки исключений сообщить об этом коду, в котором заводится переменная 'a' и как узнать, что нельзя вызывать метод 'method'?
Google совершила в своё время настоящий epic fail, отказавшись использовать исключения ради попытки выиграть в производительности, но теперь уже поздно.
@49:22 а что за лекция про hazard pointers? не могу найти
Полагаем, что речь про это th-cam.com/video/R1XcV5vHn0I/w-d-xo.html, просто в начале идет описание проблемы
ОпенМП хорошо ускорил с первого раза, + Неон (Кортекс 4хА9), Гцц. Обработка видео кадра.
Здорово! Конечно, если подходить разумно и потратив время на изучение предмета, то и с первого раза можно получить ускорение.
Что такое спил? Я новичок
Register Spill. Когда не хватает регистров под все переменные, компилятор "разливает" лишние по памяти.
@@RenamedChannel Класс, спасибо!
Что такое коалясинг? Я новичок
Coalescing, то есть объединение - вроде речь шла о том, чтобы как-то померджить несколько операций над одной и той же памятью
@@АдамСмит-ы7р Хорошо, спасибо!
Я как то пробовал распараллелить программу
на питоне -_-
40:42 "компилятор ведёт себя так, как будто UB не существует, как мы можем диагностировать то, чего не существует?" в математике это называется доказательством от противного: "предположим, что в этой программе нет UB", а потом запускаем программу доказательства теорем, которая находит противоречие. Компилятор мог бы быть такой программой, и иногда он даже может найти противоречие, но в-общем случае это невозможно.
Очень интересно) Ничего не понятно)
Пользователи видят какую-то проблему в C++, и не видят чужих предложений по решению этой проблемы, и начинают изобретать свои улучшения.
Если бы был какой-нибудь открытый CEP (по аналогии с PEP), то пользователи бы просто как-нибудь голосовали за чужие предложения и не придумывали бы свои.
уххх... как же я рад, что Константин считает прямо как я -- что линукс должен быть переписан на плюсы....
С++ это язык, который выбирают плохие программисты, потому что там проще всего писать ужастный код - Линус Торвальдс.
Мне кажется ядро Линукса на С++ в ближайшие 30 лет переписывать не будут.
Что такое CCА? Я новичок
Single static assignment form, простыми словами - представление, где присваивание в переменную может быть только один раз
сказали же - прочитайте самостоятельно, например в вики
SSA
Реально вообще во все о чем шла беседа ворваться в возрасте 35+ лет с нуля и еще чего-то преуспеть? Или поздняк уже?
Реально
UPD: Всё реально, если уверен в себе
Конечно, если очень интересно и нравится сфера, все возможно, но понятно, что это займет время. Тут не от аккаунта канала нельзя прикреплять ссылки, поэтому просто напишу название. Есть интервью с Алексеем Шипилевым и статья с выжимкой на хабре, которая называется «Чтобы стать хорошим системщиком, нужно 5-10 лет опыта» - интервью с Алексеем Шипилёвым из Java Performance Team. Интервью старое, но хорошее
Ворваться -- реально, но есть обязательное условие: должно быть настолько дико интересно, что за уши не оттащить.
Иначе, есть очень большой риск, что через некоторое время наступит разочарование, и придётся вернуться и признать, что врывались зря.
@@eklepilkina К ссылкам на сам youtube это не относится: th-cam.com/video/B1P8RHGtE5I/w-d-xo.html
Я добавил ссылку, и мне ничего за это не было, то есть, это сообщение не удалилось, поскольку ссылка -- на youtube.
мне 49 я снуля начинаю
CUDA это свой мир, но Nvidia даёт хорошие тулзы и библиотеки. На и C++ там особо не нужен.
PS гость просто эталон токсичности.
Не можем с вами согласиться - нам было очень интересно и комфортно слушать Константина :)
CUDA, на самом деле, простое расширение C++ со своими библиотеками. А тулы у Nvidia vна LLVM
Спилы? Спинлоки что ли?
Register Spill. При аллокации регистров в случае, если не хватает регистров для всех переменных, часть этих переменных перемещается в память. Этот процесс называется spilling.
@@eklepilkina ясно