Константин, спасибо за очередную шикарную лекцию. У меня книжка Юрова, 2-е издание всё ещё лежит, я ещё в универе её приобрёл )) Как сокровище лежит. Она прям такая красивая, как игрушка была в магазине :D
Хотелось бы еще один семинар с номером 6.6.6. В котором будет рассказано: как написать свой собственный компилятор. А в качестве домашки - сам компилятор)))
По парсерам должен был быть допсеминар после 5.3 до 6.1 увы мы его пропустили. Может дозапишу отдельно. Про кодогенератор есть лекция в конце второго курса с разбором как использовать для этого LLVM.
Большое спасибо за лекцию! Узнал новые вещи и получил пищу для размышлений. Интересный вопрос, почему в x86 нет некоторых более экзотических сторов/лоадов. Из того что я читал, современные процессоры ARM тоже, как и x86, используют микрокод для более сложных своих инструкций. Поэтому на первый взгляд, вроде бы особых отличий между ними в этом плане нет - могу предположить, обе архитектуры разбивают обращения в память со сложной адресацией на несколько более простых инструкций. Мне лично кажется (я вполне могу ошибаться), они могли их добавить для упрощения фронт-энда (и возможно для упрощения блока, отвечающего за адресную арифметику команд работы с памятью?). х86 нужно быстро работать с любыми х86 программами, при этом таких ограничений на энергопотребление как у АРМ у них обычно нет. При этом систему команд менять Интел не любит. Поэтому есть больше мотивации делать более сложные адресные вычисления в процессоре, даже если для этого может потребоваться дополнительная логика. У Арм всё наоборот, система команд довольно гибкая, и при этом с приоритетом на низкое энергопотребление. Получается, 2 разных локально оптимальных решения для по-разному поставленных задач оптимизации архитектуры. И ещё насколько я знаю, адрес возврата из функций на х86 (интел и амд) дублируется в спец. кэше (return address stack) на несколько последних уровней стека. Поэтому лезть в память процессору как правило не нужно, даже для не-листовых функций. Могу предположить, что Арм это не делает(?) тоже из соображений энергопотребления, перекладывая ответственность за эффективную манипуляцию link регистра на компилятор. Сорри за стенку текста, у меня логорея от интересных лекций. 🤍 И я меньше половины посмотрел...
40:46 Рискну предположить, что двухадресные инструкции в x86 - тяжелая наследственность первых процессоров этой серии (8086 и 8088) и их предков (8080 и 8085), у которых было катастрофически мало, по современным меркам, регистров.
ох уж этот армовский ассемблер с его почти легальным (в 32-битном варианте) rsbs pc, sp, pc, ror sp xD зато его хорошо было видно в дампе по E* каждым четвертым байтом. или каждым первым из четырех в случае особых извращенцев с ARMBE (да, Nokia, я про вас). а risc-v настолько прост, что чтоб его заэмулировать до уровня "оно запускает линукс"- достаточно пары сотен строк кода на сишке... и как же хорошо, что делей слотов там нет. особенно в мипсовом варианте "у вас может выскочить прерывание между бранчем и делей слотом и вам надо в ядре ос держать целый эмулятор целого проца, чтоб правильно возвращаться из этих прерываний. ну или играться с mmu, как это делает линукс".
Используя ZMM регистры, мы не получим ускорение в 16 раз. Ускорение в 16 раз - это идеальное условие, где искомое находится в самом конце. И тут тоже возникает вопрос, а будет ли это ускорение в 16 раз? Если искомое будет в самом начале, то мы вообще ни чего не выиграем. А если искомое первое число, то тут даже проиграем по скорости обычным проверкам. Не забывайте такие вещи! Исключения из правил - это очень важно!
@@tilir, я больше к тому, что такие вещи учитывать важно. ))) Но вообще знать как использовать SIMD-инструкции достаточно полезно многим. Но вот использовать будут не многие.
Доброго времени суток! Подскажите пожалуйста, если я не ваш студент, есть ли возможность ознакомится где-то не только с практикой, но и лекциями по данному курсу? Может есть хотя бы в виде pdf документа? Или хотя бы узнать "содержание" или планы тем лекций? Заранее благодарю!
"Бренчи", "не требует внешнего компеир"... Ну есть же русские слова для этого...) Ветвления. Сравнения. 🤣 Но препод - огонь. Так искренне радуется, когда показал очередную фишку...) Побольше бы таких преподавателей, искренне любящих свой предмет. И нет, сорян, у меня в 2024-м году ноутбук с 32 гигами на Бродвелл, и дома десктопные компьютеры у меня на Бродвелл, и двухпроцессорный сервер с 896 гигами оперативки тоже на Бродвелл... Так что нет, извините, AVX-512 - это здорово, но не база, и не скоро ею станет. Меня мое оборудование устраивает, главое, чтобы какие-нибудь "оптимизаторы" после этих лекций не начали векторизовать все по максималке...) Гораздо важнее позволить программам эффективно работать на большем ассортименте выпущенного ранее железа, в т.ч на все еще актуальном железе, а не "оптимизировать" свой софт до такой степени, чтобы он быстро работал только на суперсвежем железе (хотя я убежден, что у вас хоть и свежие, но бюджетные камни, а серверные даже Скайлейки по деньгам не очень доступны), которое и так и код эффективнее выполняет, и частоты и прочие показатели там выше, в то время как на более старом железе все будет еле ползать. Это важно понимать. Свои хотелки тут нужно поумерить. Или как-то решать это взаимозаменяемыми библиотечками под конкретные процессоры, получая буст на самом свежем железе...
Я стараюсь насколько могу использовать русский язык, но именно для бранчей сложно т.к. "бранч" это в данном случае "инструкция ветвления" и это язык сломаешь.
На мой взгляд, студенты должны привыкать к хорошей практике, если у функции объявлен результат, то надо его возвращать. Потом, когда нибудь, сами , осмысленно могут экономить(чего?) и не писать return. Ещё хотел сказать, что начинающие программисты, не знают или забывают про то, что все операции занимают время. И если они дали команду, то результат может появиться не сразу. Особенно это касается всяких интерфейсов. И если мы используем векторизацию, то студентам надо понимать что загрузка/выгрузка данных хорошо так нагружает шину памяти, и ускорение от векторизации может не соответствовать теоретической, в том числе если ядро не одно работает с памятью
Константин, спасибо за очередную шикарную лекцию. У меня книжка Юрова, 2-е издание всё ещё лежит, я ещё в универе её приобрёл )) Как сокровище лежит. Она прям такая красивая, как игрушка была в магазине :D
Я уже давно не студент, но интересно посмотреть.
золотой вы человек благодарю вас
И снова рубрика на что можно залипнуть в час ночи 😂. Спасибо большое, никогда ещё лекции по ассемблер не были насколько интересными.
Лайк.
Смотрим
И снова лайк за ранее❤
За что лайк? )))
@@sibedir за ранее)
Класс, лайк заранее!
Никогда бы не подумал, что Варис из Игры престолов так хорошо разбирается в программировании
Хотелось бы еще один семинар с номером 6.6.6. В котором будет рассказано: как написать свой собственный компилятор. А в качестве домашки - сам компилятор)))
По парсерам должен был быть допсеминар после 5.3 до 6.1 увы мы его пропустили. Может дозапишу отдельно. Про кодогенератор есть лекция в конце второго курса с разбором как использовать для этого LLVM.
Большое спасибо за лекцию! Узнал новые вещи и получил пищу для размышлений.
Интересный вопрос, почему в x86 нет некоторых более экзотических сторов/лоадов. Из того что я читал, современные процессоры ARM тоже, как и x86, используют микрокод для более сложных своих инструкций. Поэтому на первый взгляд, вроде бы особых отличий между ними в этом плане нет - могу предположить, обе архитектуры разбивают обращения в память со сложной адресацией на несколько более простых инструкций.
Мне лично кажется (я вполне могу ошибаться), они могли их добавить для упрощения фронт-энда (и возможно для упрощения блока, отвечающего за адресную арифметику команд работы с памятью?). х86 нужно быстро работать с любыми х86 программами, при этом таких ограничений на энергопотребление как у АРМ у них обычно нет. При этом систему команд менять Интел не любит. Поэтому есть больше мотивации делать более сложные адресные вычисления в процессоре, даже если для этого может потребоваться дополнительная логика. У Арм всё наоборот, система команд довольно гибкая, и при этом с приоритетом на низкое энергопотребление. Получается, 2 разных локально оптимальных решения для по-разному поставленных задач оптимизации архитектуры.
И ещё насколько я знаю, адрес возврата из функций на х86 (интел и амд) дублируется в спец. кэше (return address stack) на несколько последних уровней стека. Поэтому лезть в память процессору как правило не нужно, даже для не-листовых функций. Могу предположить, что Арм это не делает(?) тоже из соображений энергопотребления, перекладывая ответственность за эффективную манипуляцию link регистра на компилятор.
Сорри за стенку текста, у меня логорея от интересных лекций. 🤍 И я меньше половины посмотрел...
40:46 Рискну предположить, что двухадресные инструкции в x86 - тяжелая наследственность первых процессоров этой серии (8086 и 8088) и их предков (8080 и 8085), у которых было катастрофически мало, по современным меркам, регистров.
ох уж этот армовский ассемблер с его почти легальным (в 32-битном варианте) rsbs pc, sp, pc, ror sp xD
зато его хорошо было видно в дампе по E* каждым четвертым байтом. или каждым первым из четырех в случае особых извращенцев с ARMBE (да, Nokia, я про вас).
а risc-v настолько прост, что чтоб его заэмулировать до уровня "оно запускает линукс"- достаточно пары сотен строк кода на сишке... и как же хорошо, что делей слотов там нет. особенно в мипсовом варианте "у вас может выскочить прерывание между бранчем и делей слотом и вам надо в ядре ос держать целый эмулятор целого проца, чтоб правильно возвращаться из этих прерываний. ну или играться с mmu, как это делает линукс".
Ну вот кстати да. Delay slots в современном мире отовсюду повыковыряли и я не стал даже рассказывать. Мне в своё время тоже они поели нервов.
Используя ZMM регистры, мы не получим ускорение в 16 раз. Ускорение в 16 раз - это идеальное условие, где искомое находится в самом конце. И тут тоже возникает вопрос, а будет ли это ускорение в 16 раз?
Если искомое будет в самом начале, то мы вообще ни чего не выиграем. А если искомое первое число, то тут даже проиграем по скорости обычным проверкам.
Не забывайте такие вещи! Исключения из правил - это очень важно!
Ну я огрубленно сказал. Точные замеры есть в моём допсеминаре по SIMD. Там действительно чуть меньше.
@@tilir, я больше к тому, что такие вещи учитывать важно. )))
Но вообще знать как использовать SIMD-инструкции достаточно полезно многим. Но вот использовать будут не многие.
Доброго времени суток! Подскажите пожалуйста, если я не ваш студент, есть ли возможность ознакомится где-то не только с практикой, но и лекциями по данному курсу? Может есть хотя бы в виде pdf документа? Или хотя бы узнать "содержание" или планы тем лекций? Заранее благодарю!
Насколько я знаю, публичной выкладки материалов и записей лекций нет.
@@tilir Понял, благодарю за ответ!
"Бренчи", "не требует внешнего компеир"... Ну есть же русские слова для этого...) Ветвления. Сравнения. 🤣 Но препод - огонь. Так искренне радуется, когда показал очередную фишку...) Побольше бы таких преподавателей, искренне любящих свой предмет. И нет, сорян, у меня в 2024-м году ноутбук с 32 гигами на Бродвелл, и дома десктопные компьютеры у меня на Бродвелл, и двухпроцессорный сервер с 896 гигами оперативки тоже на Бродвелл... Так что нет, извините, AVX-512 - это здорово, но не база, и не скоро ею станет. Меня мое оборудование устраивает, главое, чтобы какие-нибудь "оптимизаторы" после этих лекций не начали векторизовать все по максималке...) Гораздо важнее позволить программам эффективно работать на большем ассортименте выпущенного ранее железа, в т.ч на все еще актуальном железе, а не "оптимизировать" свой софт до такой степени, чтобы он быстро работал только на суперсвежем железе (хотя я убежден, что у вас хоть и свежие, но бюджетные камни, а серверные даже Скайлейки по деньгам не очень доступны), которое и так и код эффективнее выполняет, и частоты и прочие показатели там выше, в то время как на более старом железе все будет еле ползать. Это важно понимать. Свои хотелки тут нужно поумерить. Или как-то решать это взаимозаменяемыми библиотечками под конкретные процессоры, получая буст на самом свежем железе...
Я стараюсь насколько могу использовать русский язык, но именно для бранчей сложно т.к. "бранч" это в данном случае "инструкция ветвления" и это язык сломаешь.
@@tilir Спасибо за лекцию, и что размещаете на ютубе. Очень познавательно.
@@cafedead и вам спасибо, добрые комментаторы, что поясняете некоторые моменты ❤️
что такое фрейм нормально рассказать могут
Ахаха 😂 догнал трансляцию на последних секундах.
Все отлично, кроме одного : везде main() без return
Это допустимая форма, я это кажется уже раньше обсуждал.
На мой взгляд, студенты должны привыкать к хорошей практике, если у функции объявлен результат, то надо его возвращать. Потом, когда нибудь, сами , осмысленно могут экономить(чего?) и не писать return.
Ещё хотел сказать, что начинающие программисты, не знают или забывают про то, что все операции занимают время. И если они дали команду, то результат может появиться не сразу. Особенно это касается всяких интерфейсов.
И если мы используем векторизацию, то студентам надо понимать что загрузка/выгрузка данных хорошо так нагружает шину памяти, и ускорение от векторизации может не соответствовать теоретической, в том числе если ядро не одно работает с памятью
Про шины памяти и кеши см. следующий семинар, мы скоро начнём туда спускаться ))
Что до main то не писать в ней return это общепринято хороший стиль.