Иногда очень хочется отследить кто первым вбросил этот тезис про «x86 ограничивает количество декодируемых инструкций за такт» и преимущество ARM. Все его бездумно повторяют, потому что не имеют ни малейшего представления что это значит)
Реальное бутылочное горлышко в OOOE ядрах это не декодер, а Register Renaming. Представьте что нужно переименовать 8 инструкций за такт. Блок переименования видит все 8, ему нужно выяснить зависимости между всеми 8 коммандами, выделить все sources для всех комманд и прочитать таблицы переименования регистров для их всех. Сложность переименования как минимум квадратичная от количества комманд в такт. То есть блок переименования на 8 инструкций будет в 4 раза больше, чем блок переименования на 4 инструкции. И это еще в лучшем случае. Не забываем, что сама процедура переименования должна завершиться на один такт, потому в следующем такте будут новые инструкции.
И все это верно для любого OOOE и вообще не зависит от оригинального instruction set.
AMD сделали renaming шириной в 6 в Ryzen, Intel шириной в 5 в IceLake. Сделать его шириной в 8 и одновременно сохранить заоблачные частоты под 5Hgz физически невозмодно на данный момент. Даже на частотах, на которых работает M1 возникает много вопросов «как они это смогли?» Есть предположение, что Apple использует скрытые предположения в блок register renaming, например что их компилятор гарантирует что в блоке из 8 инструкций никогда не будет 8 взаимно зависимых. Это бы сильно облегчило работу register renaming. Он может даже поддерживать этот случай, но сбрасываться на 4 инструкции в такт, например. Тогда на хорошем коде (а Apple контролирует свой код) все будет хорошо, а у остальных будет просто все работать.
Есть еще несколько вопросов типа «как они это сделали» вроде Data Cache 128KB на 3 такта latency или 8 блоков выполнения комманд. Это конечно все возможно, но тоже может считаться великим технологическим достижением. Но самая богатая в мире кампания может себе позволить набрать самых крутых CPU инженеров и сделать самый крутой в мире процессор на пару поколений обгонящий всех конкурентов.
Но это еще не значит, что они смогут удержать пальму первенства надолго. M1 возможно самое мощной монолитное ядро которое вообще можно построить на нынешних технологиях. Дальше нужно что-то другое, например много-кластерное ядро. Но создать такое, чтобы работало лучше монолитного прошлого поколения пока никто не смог. Посмотрим если гипотетический M3 или M4 сможет. От M2 можно обидать разве что минорных изменений и увеличения частоты, они уже на пределе.
Отлично, значит вам не составит труда найти тест в котором выполняется одна и та же задача на разных пк и одной версии ос, а лучше сразу несколько задач.
Компиляция в Xcode в сравнении с топовым intel Macbook Pro 16. На этом же канале много разных сравнений разных систем сборки (только смотреть надо внимательно, часть компиляторов во время записи видео ещё работала через Rosetta).
Сравнение компиляции Webkit на разных компьютерах. Горка разных бенчмарков сред исполнения.
По поводу монтирования видео достаточно в Youtube вбить "M1 vs MBP 16", их там тысячи от разных видеоблоггеров.
Просто бенчмарки есть на anandtech, notebookcheck и многих других сайтах.
Купить наугад сырой продукт в максимальной комплектации.
Я его взял на пробу новой архитектуры, с возможностью вернуть в первые 2 недели. Теперь это мой основной компьютер.
Всем бы такие "сырые" продукты.
AMD 4800u имеет 8 полноценных ядер и SMT. Apple M1 — 4 производительных ядра и 4 слабеньких энергоэффективных (они дают примерно ту же производительность, что второй SMT поток на ядре). При этом 4800u выигрывает в лучшем случае (в разных ноутбуках производительность может отличаться) на 25% в Cinebench, при двухкратном реальном энергопотреблении (не путайте с TDP).
Вроде как амд 4000(и тем более 5000) серии быстрее м1 в многопотоке.(имею в виду мобильные 15 ваттные камни). Так что не до конца ясно откуда столько пафоса.
Стоит. У меня был макбук про 13 с 2020 года с i5-1038ng7, 16gb ram. Покупал прошлой осенью. Вот недавно продал и купил новый с m1. Операционной памяти столько же, SSD такого же размера, а стоил на 30т рублей дешевле, чем тот с процессором intel.
Никаких лагов. Как intel не греется вообще — вентилятор не слышал ни разу. Сама ОС очень отзывчивая, многие программы, запускающиеся через rosetta2 работают быстрее, чем нативно на intel. Батарея вообще на другом уровне, ты наверняка видел разные тесты в инете.
Но все это не только благодаря m1, но также ssd быстрее, чем у всех предыдущих моделей.
Единственный минус — меньше портов usb c, у предыдущего было 4, а тут только 2.
Он реально такой, каким его показывают многие блогеры. Сначала сам не верил, все таки не хотелось признать, что купил макбук с intel, когда можно было подождать пару месяцев и купить с m1 по мощнее, но за дешевле))
к ним нужно специальное ПО, привязанное именно к конкретным блокам.
Что же это за ПО такое? Прям в регистры железу пишет небось? =)
Про операционную систему слышали что-нибудь?
Именно по этой причине Intel и AMD не идут по такому пути.
А по какому?
Давайте ознакомимся с «начинкой» процессора Интел:
Мы тут можем увидеть GPU, программируемый DSP для ускорения кодеков, IPU для обработки изображений с камеры.
В задачах широкого профиля (а не задачах показывать кинчик очередному адепту яблочного культа) классический процессор будет быстрее и удобнее
А в M1 не «классический процессор»? =)
О, сколько нам открытий чудных(с)
Через год выйдет процессор Apple M2+ с другим «декодером» или блоком DSP. И вот незадача: все ПО от M1 к нему уже не подходит.
Пишете нам из будущего?
Странно, ведь ПО написанное под A7, прекрасно работает на A14 и M1. Чудеса.
Достаточно определить номер бита, с которого начинается конкретная из 8-ми инструкций.
ну ну вся идея в том, что на определение этого номера бита нужно времени как на сам декодинг.
Если получится сделать логику, выполняющую разбиение куска данных на 8м инструкций и укладывающееся в такт, то получится только дополнительная стадия, логика и лишнее потребление на переключения
если вы можете реализовать такую логику, смело идите работать в intel на миллионную зарплату.
Да, отличается от ARM, но особой проблемы нет, а тем более падения производительности.
вот в вашей спекуляции проблемы нет, а по факту, в реальных x64 процах, есть.
Здесь нет большой разницы, учитывая ещё и то, что x86 код поплотнее будет, чем у ARM
В аппаратуре боттлнек не может появится при вычислении границ инструкций, если последнее выполняется за такт. Если получится сделать логику, выполняющую разбиение куска данных на 8м инструкций и укладывающееся в такт, то получится только дополнительная стадия, логика и лишнее потребление на переключения. Никаких падений производительности здесь не появится.
Шина данных у меня — это строка или несколько строк кэша L1I. Разрежено разложить — это то, что я и написал. Вариантов этого разложение я могу придумать 2-3 уже сходу. Достаточно определить номер бита, с которого начинается конкретная из 8-ми инструкций. Число комбинаций конечное значение. Можно даже вручную их перебрать. Да, отличается от ARM, но особой проблемы нет, а тем более падения производительности.
Кэш не оперирует инструкциями и он не требует значений, зависящих от размера инструкций. Здесь нет большой разницы, учитывая ещё и то, что x86 код поплотнее будет, чем у ARM. Более того, у x86 есть ещё кэш microop, а это уже подобие RISC от ARM. Кстати, этот microop кэш можно трактовать как ещё и декодер инструкций, раз результат его работы такой же, как у декодера.
там, где вы должны границы каждой инструкции вычислить, то есть проанализировать что там вам на входе пришло, причем по байту. А потом надо это разреженно разложить в вашу «шину данных» (кеш инструкций), чтобы оно было выровнено. А на ARM просто берутся N*4 байт и подаются на N декодеров. И еще учтите что в вашей схеме кеш инструкций требует 16 байт на инструкцию, а на ARM — 4. То есть вам для равной производительности уже нужен кеш в четыре раза больше и в четыре раза быстрее. Собственно, поэтому x86 процы сразу декодируют невыровненные инструкции, настолько быстро, насколько могут
Берём 8*16байт шину данных, формируем из неё 8 x86 инструкций и отправляем на 8м декодеров. Исходные 8*16байт данных сдвигаем на число найденных x86 инструкций с учётом их размера и добавляем новую порцию данных. Где здесь появляется боттлнек? Естественно необходимо каждый такт считывать до 8*16 байт данных, в худшем случае. Подкачка последовательных инструкций — не является боттленком уже довольно давно.
На частоте в два раза меньшей 8 декодеров x86 точно влезут
в случае ARM декодер берет i-е 32-битное число из памяти и декодирует независимо от остальных. В случае x86 декодер начинает с i-ого байта, пытается распарсить команду, и попутно думает, попал он в третий байт команды, пятый или четырнадцатый. И если попал не в начало команды, то надо дождаться, пока предыдущий декодер скорректирует конфликтующую команду. И логика такого декодера, сами понимаете, далека от тривиальной. Итого apple будет проще нарастить число декодеров до 16 чем intel/amd до 8.
Можно поставить предварительную стадию, которая разбивает на отдельные инструкции и попутно считая их число. Она будет достаточно простой функционально, но длинной, и всё-равно может влезть. Сомневаюсь, что у Intel/AMD не так сделано, а стоят подряд 4-е полноценных декодера x86. Вообще, кажется, читал, что декодеров там 2-3 разных типов, полный и несколько попроще.
А ещё, 8-м декодеров дадут прирост только в том случае, если конвейер инструкций не успевает за вычислительным. Вероятность, что Intel/AMD упустили это из виду, стремится к 0.
Хотя из статьи есть одна интересная идея. Каждая инструкция x86 переходит в последовательность мелких инструкций, которые зависят друг от друга. Т.е. для параллельного исполнения N инструкций x86 нужно сделать Reorder буфер(ROB) размером N*k, где k — длина x86 инструкций. У ARM, получается, ROB вмещает больше исходных инструкций и эффективнее используется. Но это проценты от общей производительности, если не меньше.
Они пытались сделать подобную микроархитектуру, но не преуспели. Это был один из последних производителей, пытавшихся сделать свои мощные ядра, а не лицензировать у ARM.
Возможно, через некоторое время Qualcomm выпустит продукт разработок Nuvia.
На частоте в два раза меньшей 8 декодеров x86 точно влезут. Тем более у M1 и техпроцесс поновее 5нм/TSMC против 7нм/TSMC у Zen3.
С бизнес моделью — вообще чушь какая-то. Ничего не мешает AMD понатыкать в свои чипы CPU/GPU/DSP/ISP/"другие ускорители"/SRAM, а сверху нахлобучить DRAM. Два основных производителя и несколько разных API для работы с этой мишурой. Вот будет радость-то!
В общем, в статье ни одного существенного препятствия для того, чтобы Intel и AMD догнали и перегнали конкретно чип M1, не приведено. Предположу, что просто не ожидали такого поворота событий. Помимо этого Intel с AMD могут не бояться Apple, так как последняя существует в своём закрытом мирке. Только косвенно, из-за возросшего интереса к ARM в целом.
Реальное бутылочное горлышко в OOOE ядрах это не декодер, а Register Renaming. Представьте что нужно переименовать 8 инструкций за такт. Блок переименования видит все 8, ему нужно выяснить зависимости между всеми 8 коммандами, выделить все sources для всех комманд и прочитать таблицы переименования регистров для их всех. Сложность переименования как минимум квадратичная от количества комманд в такт. То есть блок переименования на 8 инструкций будет в 4 раза больше, чем блок переименования на 4 инструкции. И это еще в лучшем случае. Не забываем, что сама процедура переименования должна завершиться на один такт, потому в следующем такте будут новые инструкции.
И все это верно для любого OOOE и вообще не зависит от оригинального instruction set.
AMD сделали renaming шириной в 6 в Ryzen, Intel шириной в 5 в IceLake. Сделать его шириной в 8 и одновременно сохранить заоблачные частоты под 5Hgz физически невозмодно на данный момент. Даже на частотах, на которых работает M1 возникает много вопросов «как они это смогли?» Есть предположение, что Apple использует скрытые предположения в блок register renaming, например что их компилятор гарантирует что в блоке из 8 инструкций никогда не будет 8 взаимно зависимых. Это бы сильно облегчило работу register renaming. Он может даже поддерживать этот случай, но сбрасываться на 4 инструкции в такт, например. Тогда на хорошем коде (а Apple контролирует свой код) все будет хорошо, а у остальных будет просто все работать.
Есть еще несколько вопросов типа «как они это сделали» вроде Data Cache 128KB на 3 такта latency или 8 блоков выполнения комманд. Это конечно все возможно, но тоже может считаться великим технологическим достижением. Но самая богатая в мире кампания может себе позволить набрать самых крутых CPU инженеров и сделать самый крутой в мире процессор на пару поколений обгонящий всех конкурентов.
Но это еще не значит, что они смогут удержать пальму первенства надолго. M1 возможно самое мощной монолитное ядро которое вообще можно построить на нынешних технологиях. Дальше нужно что-то другое, например много-кластерное ядро. Но создать такое, чтобы работало лучше монолитного прошлого поколения пока никто не смог. Посмотрим если гипотетический M3 или M4 сможет. От M2 можно обидать разве что минорных изменений и увеличения частоты, они уже на пределе.
Компиляция в Xcode в сравнении с топовым intel Macbook Pro 16. На этом же канале много разных сравнений разных систем сборки (только смотреть надо внимательно, часть компиляторов во время записи видео ещё работала через Rosetta).
Сравнение компиляции Webkit на разных компьютерах.
Горка разных бенчмарков сред исполнения.
По поводу монтирования видео достаточно в Youtube вбить "M1 vs MBP 16", их там тысячи от разных видеоблоггеров.
Просто бенчмарки есть на anandtech, notebookcheck и многих других сайтах.
Я его взял на пробу новой архитектуры, с возможностью вернуть в первые 2 недели. Теперь это мой основной компьютер.
Всем бы такие "сырые" продукты.
Энергопотребление CPU M1 измерено очень точно, и в тесте Cinebench R23 составляет 15 Вт. Максимальное наблюдаемое потребление — 21 Вт при полной загрузке всех исполняемых блоков синтетической нагрузкой.
4800u при этом может потреблять до 35 Вт в Cinebench даже в профиле на "15 Вт TDP": https://next.lab501.ro/notebook/english-lenovo-ideapad-s540-13are-vs-13iml-amd-ryzen-7-4800u-vs-intel-core-i7-10710u/14
AMD 4800u имеет 8 полноценных ядер и SMT. Apple M1 — 4 производительных ядра и 4 слабеньких энергоэффективных (они дают примерно ту же производительность, что второй SMT поток на ядре). При этом 4800u выигрывает в лучшем случае (в разных ноутбуках производительность может отличаться) на 25% в Cinebench, при двухкратном реальном энергопотреблении (не путайте с TDP).
Никаких лагов. Как intel не греется вообще — вентилятор не слышал ни разу. Сама ОС очень отзывчивая, многие программы, запускающиеся через rosetta2 работают быстрее, чем нативно на intel. Батарея вообще на другом уровне, ты наверняка видел разные тесты в инете.
Но все это не только благодаря m1, но также ssd быстрее, чем у всех предыдущих моделей.
Единственный минус — меньше портов usb c, у предыдущего было 4, а тут только 2.
Он реально такой, каким его показывают многие блогеры. Сначала сам не верил, все таки не хотелось признать, что купил макбук с intel, когда можно было подождать пару месяцев и купить с m1 по мощнее, но за дешевле))
Что же это за ПО такое? Прям в регистры железу пишет небось? =)
Про операционную систему слышали что-нибудь?
А по какому?
Давайте ознакомимся с «начинкой» процессора Интел:
Мы тут можем увидеть GPU, программируемый DSP для ускорения кодеков, IPU для обработки изображений с камеры.
А в M1 не «классический процессор»? =)
О, сколько нам открытий чудных(с)
Пишете нам из будущего?
Странно, ведь ПО написанное под A7, прекрасно работает на A14 и M1. Чудеса.
если вы можете реализовать такую логику, смело идите работать в intel на миллионную зарплату.
вот в вашей спекуляции проблемы нет, а по факту, в реальных x64 процах, есть.
в теории да, в реальности нет.
В аппаратуре боттлнек не может появится при вычислении границ инструкций, если последнее выполняется за такт. Если получится сделать логику, выполняющую разбиение куска данных на 8м инструкций и укладывающееся в такт, то получится только дополнительная стадия, логика и лишнее потребление на переключения. Никаких падений производительности здесь не появится.
Шина данных у меня — это строка или несколько строк кэша L1I. Разрежено разложить — это то, что я и написал. Вариантов этого разложение я могу придумать 2-3 уже сходу. Достаточно определить номер бита, с которого начинается конкретная из 8-ми инструкций. Число комбинаций конечное значение. Можно даже вручную их перебрать. Да, отличается от ARM, но особой проблемы нет, а тем более падения производительности.
Кэш не оперирует инструкциями и он не требует значений, зависящих от размера инструкций. Здесь нет большой разницы, учитывая ещё и то, что x86 код поплотнее будет, чем у ARM. Более того, у x86 есть ещё кэш microop, а это уже подобие RISC от ARM. Кстати, этот microop кэш можно трактовать как ещё и декодер инструкций, раз результат его работы такой же, как у декодера.
Берём 8*16байт шину данных, формируем из неё 8 x86 инструкций и отправляем на 8м декодеров. Исходные 8*16байт данных сдвигаем на число найденных x86 инструкций с учётом их размера и добавляем новую порцию данных. Где здесь появляется боттлнек? Естественно необходимо каждый такт считывать до 8*16 байт данных, в худшем случае. Подкачка последовательных инструкций — не является боттленком уже довольно давно.
Можно поставить предварительную стадию, которая разбивает на отдельные инструкции и попутно считая их число. Она будет достаточно простой функционально, но длинной, и всё-равно может влезть. Сомневаюсь, что у Intel/AMD не так сделано, а стоят подряд 4-е полноценных декодера x86. Вообще, кажется, читал, что декодеров там 2-3 разных типов, полный и несколько попроще.
А ещё, 8-м декодеров дадут прирост только в том случае, если конвейер инструкций не успевает за вычислительным. Вероятность, что Intel/AMD упустили это из виду, стремится к 0.
Хотя из статьи есть одна интересная идея. Каждая инструкция x86 переходит в последовательность мелких инструкций, которые зависят друг от друга. Т.е. для параллельного исполнения N инструкций x86 нужно сделать Reorder буфер(ROB) размером N*k, где k — длина x86 инструкций. У ARM, получается, ROB вмещает больше исходных инструкций и эффективнее используется. Но это проценты от общей производительности, если не меньше.
Они пытались сделать подобную микроархитектуру, но не преуспели. Это был один из последних производителей, пытавшихся сделать свои мощные ядра, а не лицензировать у ARM.
Возможно, через некоторое время Qualcomm выпустит продукт разработок Nuvia.
На частоте в два раза меньшей 8 декодеров x86 точно влезут. Тем более у M1 и техпроцесс поновее 5нм/TSMC против 7нм/TSMC у Zen3.
С бизнес моделью — вообще чушь какая-то. Ничего не мешает AMD понатыкать в свои чипы CPU/GPU/DSP/ISP/"другие ускорители"/SRAM, а сверху нахлобучить DRAM. Два основных производителя и несколько разных API для работы с этой мишурой. Вот будет радость-то!
В общем, в статье ни одного существенного препятствия для того, чтобы Intel и AMD догнали и перегнали конкретно чип M1, не приведено. Предположу, что просто не ожидали такого поворота событий. Помимо этого Intel с AMD могут не бояться Apple, так как последняя существует в своём закрытом мирке. Только косвенно, из-за возросшего интереса к ARM в целом.