После смерти Transmeta их интеллектуальную собственность получили все, кто хотел ее лицензировать. Intel, Nvidia и другие получили все, включая CMS source code.
В Intel это вылилось в проэкт MoonRun который пытался воссоздать binary translation assisted VLIW процессор, под руководством Dave Ditzel. Но проэкт вовремя был признан не перспективным и похоронен.
Тогда как в Nvidia зашли подальше и родили Denver (https://en.wikipedia.org/wiki/Project_Denver). Denver CMS это прямой наследник Transmeta Efficion CMS да и микроархитектура очень похожа на VLIW. Так что у Transmeta был хотя бы один не мертворожденный наследник !
Первый концепт называется AOS (Array of Structures), второй SOA (Structure of Arrays).
У каждого свои плюсы и минусы. Еще один плюс SOA это возможность работать с векторыми инструкциями процессора (SIMD).
Из крутых фич компиляторов стоило бы напомнить, что Intel Compiler умеет сам автоматически преобразовывать одно в другое в вашей программе на этапе компиляции и получать нехилый выигрыш производительности.
В Китае очень популярны так называемые sleeping bus когда междугородний автобус оборудован внутри вот такими вот капсулами-кроватями в два этажа и идёт между городами ночью. До сих пор не пойму почему кроме Китая никто это ещё не перенял!
Первые ноутбучные Centrino (Banias, Dothan и Yonah который и есть Core2Duo) это самые что ни на есть Pentium III. Их ядро базируется на ядре Pentium III Tualatin.
Драйвером всех этих удвоений flops каждое поколение всегда были алгоритмы HPC и machine learning. Первые уже ушли в GPU а для вторых нагородили мостра по кличке AMX. А остальным и того, что есть пока хватит. Теперь AMX будет каждый год удваивать пока TPU не получится)
Не х86, а используемая схема VLE с 1-15 байтовыми командами. И в этой статье написано почему это мешает.
К тому же на большой частоте декодер просто может не успеть вытащить 8 инструкций, даже если они в 1 кэш-строке.
Тут вопрос не про успеть. Декодирование вполне себе параллельная операция. Дергаем 16 байт (в новых ядрах 32 байта) и строим 32 отдельных декодера, декодер #N работает независимо в предположении, что он декодирует инструкцию которая начинается с байта N. На выходе получаем декодированные инструкции для всех возможных комбинаций instruction length. Лишнее можно выкинуть, а реальные инструкции взять. На деле конечно так никто не извращается, но реальная жизнь не сильно отличается от этой упрощенной картинки. Например один блок декодера может обрабатывать несколько offsets.
Декодер не такая страшная штука даже в х86 и уж точно там нет ничего сериального. Даже если декодировать каждый байт все равно выйдет меньше размером чем uop cache на 4000 микроопераций. Вот только это будет hotspot, горячая точка покруче FMA. Плюс у декодеров есть гораздо большая проблема — branches. В современном коде каждые 5-7 инструкций есть branch а декодировать через branch декодерам очень тяжело.
Имея 4-way декодер x86 процессоры могут доставать 6-8 МОПов, точно так же как и на ARM Cortex-A77+.
Reaming у Skylake все равно 4-way. В uops. Кстати, сколько это было инструкций уже никого после декодеров не волнует. И совсем не важно, что Uop Cache умел давать 6 в такт, а декодеры 5. Опять же uops, сколько это было инструкций уже никому не интересно. Может одна, а может и 8 из-за Macro-Fusion. И бутылочное горлышко оно здесь.
Zen2 не только переименовывает 6 МОП-ов, к тому же делает ещё и mov elimination.
С чего вы вообще взяли что переименование представляет собой проблему?
Потому что не 8 :)
Мы уже давно хотим 8, и уверен AMD тоже хотели.
Кэш 128КБ у них уже 3 поколения.
Ключевое слово «за 3 такта».
У AMD 32К за 4. У Intel 48K за 5.
Почему вы про гигантский ROB на 630 инструкций или про предсказатель ветвлений ничего не сказали?
Потому что не имею представления насколько крутой у них предсказатель ветвлений по сравнению с Intel или AMD. А про ROB — все субъективно, мы знаем как построить и больше, просто это пока никому не надо. Нужно чтобы все остальное соответствовало, в том числе и renaming и количество ALU. Архитектура должна быть сбалансированная.
FP это floating point? Тогда без комментариев. Супер популярный тип данных доступный даже в ЯВУ (float/double), почему бы не сделать его значительно быстрее?
Хотел бы я увидеть software emulation который будет работать за приемлемое время. С удовольствием включу в исходники Bochs:)
>Как умножение за 2-3 такта происходит?
Sorry, ни разу не интересовался. Это удобно рассматривать EXE-units as black box которые просто работают. Моя область это MEU + OOOE.
>Кстати есть такое что отдельные части запускают на >бОльшей частоте?
Уже нет. Мутотень с несколькими clock domains перевешивает все достоинства. В AlderLake AMX на своем clock domain сидит на меньшей частоте, такой вот огромный ALU :)
Потому что в монолитном ядре (без кластеров) любой из ALU может поставлять результат в любой другой ALU, то есть они между собой соеденены в bypass network. И этот bypass network становится все сложнее и сложнее с каждым новым ALU.
Я собственно свое мнение озвучил. Мой ответ именно так и выглядел — у Apple настолько более крутые инженеры/инструменты что они смогли сделать то, что в AMD и Intel считали невозможным.
Естейственно с оговорками. Это невозможно на 5Ghz, а Apple M1 даже не 3Ghz. А частота тоже не маленький фактор в производительности.
Напомню: Performance := IPC * Freq
Да, Apple M1 порвали всех по IPC но они только приблизились к топовым Intel и AMD по производительности, потому что у них на 40% меньше частота.
Но так как Power = V*F^2
то получается что сравнимой производительности у Apple M1 гораздо ниже энергопотребление, на чем они и выигрывают.
Чего ждать в будущем?
И Интел и AMD будет наращивать IPC пытаясь догнать M1. При приросте в 15% за поколение догонят через 2-3 поколения. Apple скорее всего уже не сможет увеличивать IPC с такой же скоростью, они и так на пределе. Будут делать 5-10% и понемногу увеличивать частоту. Гипотетический Apple M3 будет на 20% больше по IPC но на 20-30% меньше по частоте и опять на примерно той же производительности как Intel и AMD. Вот только разница в энергоэффективности сильно сократится не в пользу Apple.
Я как раз про распределение переменных по явно доступным регистрам. Меньше load store и потенциально меньше проблем в renaming. Что вы далее и написали.
Потенциально это не про hardware. Hardware должен умень кушать worst case который от количества регистров не меняется.
>И, судя по всему, он не помогает догнать условный IPC у M1
Он не для этого сделан. Даже если Uop Cache будет поставлять 16 интрукций в такт и декодеры тоже — это никак не поможет «догнать условный IPC у M1»
Потому что нужно будет 8-wide renaming, соответствующее количество ALU и соответсвующую глубину внутренних буферов. А скорее всего еще и соответствующий размер кешей данных.
Т.е. на TSMC 5nm сложные схемы должно быть труднее строить, чем на Intel 14nm?
Наоборот, чем меньше gate delay тем выше частота, на которой можно работать. Или как вариант можно поставить больше logic gates в такт и уменьшить частоту — по этому пути пошли в Apple M1. Больше logic gates в такт — можно позволить себе более сложные алгоритмы не разбивая их на несколько тактов.
Хм, быть того не может. Зачем же в процессе увеличили количество явно доступных регистров?
Количество регистров никак не позволяет делать алгоритмы в железе проще. Если есть больше регистров, компилятор сможет ими пользоваться и хранить в них какие-то значения. Скорее всего это позволит сократить количество обращений к памяти потому что больше переменных можно будет просто хранить в регистрах. В результате код может будет немного оптимальнее. Но не факт, потому что существующие ABI требуют сохранять регистры в стек на входе в каждую функцию а потом восстанавливать на выходе, что тоже накладно.
Но да, в среднем количество LOAD и STORE на Arm в программах на Aarch64 процентов на 10 меньше, в основном благодаря 32 регистрам.
Я не озвучивал :)
Более того — на том же форуме недавно обсуждали Uop Cache от Intel и AMD. Более 70% всех команд выполняются из Uop Cache и декодеры там вообще спят.
А пропускная способность Uop Cache уже и сейчас гораздо превышает способности Renaming у всех.
После смерти Transmeta их интеллектуальную собственность получили все, кто хотел ее лицензировать. Intel, Nvidia и другие получили все, включая CMS source code.
В Intel это вылилось в проэкт MoonRun который пытался воссоздать binary translation assisted VLIW процессор, под руководством Dave Ditzel. Но проэкт вовремя был признан не перспективным и похоронен.
Тогда как в Nvidia зашли подальше и родили Denver (https://en.wikipedia.org/wiki/Project_Denver). Denver CMS это прямой наследник Transmeta Efficion CMS да и микроархитектура очень похожа на VLIW. Так что у Transmeta был хотя бы один не мертворожденный наследник !
А если я сам шкипер, скидку дадите?
Доказать, что ты чей то сын можно и ДНК тестом, а не только свидетельством о рождении.
У каждого свои плюсы и минусы. Еще один плюс SOA это возможность работать с векторыми инструкциями процессора (SIMD).
Из крутых фич компиляторов стоило бы напомнить, что Intel Compiler умеет сам автоматически преобразовывать одно в другое в вашей программе на этапе компиляции и получать нехилый выигрыш производительности.
В Китае очень популярны так называемые sleeping bus когда междугородний автобус оборудован внутри вот такими вот капсулами-кроватями в два этажа и идёт между городами ночью. До сих пор не пойму почему кроме Китая никто это ещё не перенял!
qntm.org/mmacevedo_ru
Тут вопрос не про успеть. Декодирование вполне себе параллельная операция. Дергаем 16 байт (в новых ядрах 32 байта) и строим 32 отдельных декодера, декодер #N работает независимо в предположении, что он декодирует инструкцию которая начинается с байта N. На выходе получаем декодированные инструкции для всех возможных комбинаций instruction length. Лишнее можно выкинуть, а реальные инструкции взять. На деле конечно так никто не извращается, но реальная жизнь не сильно отличается от этой упрощенной картинки. Например один блок декодера может обрабатывать несколько offsets.
Декодер не такая страшная штука даже в х86 и уж точно там нет ничего сериального. Даже если декодировать каждый байт все равно выйдет меньше размером чем uop cache на 4000 микроопераций. Вот только это будет hotspot, горячая точка покруче FMA. Плюс у декодеров есть гораздо большая проблема — branches. В современном коде каждые 5-7 инструкций есть branch а декодировать через branch декодерам очень тяжело.
Reaming у Skylake все равно 4-way. В uops. Кстати, сколько это было инструкций уже никого после декодеров не волнует. И совсем не важно, что Uop Cache умел давать 6 в такт, а декодеры 5. Опять же uops, сколько это было инструкций уже никому не интересно. Может одна, а может и 8 из-за Macro-Fusion. И бутылочное горлышко оно здесь.
Потому что не 8 :)
Мы уже давно хотим 8, и уверен AMD тоже хотели.
Ключевое слово «за 3 такта».
У AMD 32К за 4. У Intel 48K за 5.
Потому что не имею представления насколько крутой у них предсказатель ветвлений по сравнению с Intel или AMD. А про ROB — все субъективно, мы знаем как построить и больше, просто это пока никому не надо. Нужно чтобы все остальное соответствовало, в том числе и renaming и количество ALU. Архитектура должна быть сбалансированная.
FP это floating point? Тогда без комментариев. Супер популярный тип данных доступный даже в ЯВУ (float/double), почему бы не сделать его значительно быстрее?
Хотел бы я увидеть software emulation который будет работать за приемлемое время. С удовольствием включу в исходники Bochs:)
>Как умножение за 2-3 такта происходит?
Sorry, ни разу не интересовался. Это удобно рассматривать EXE-units as black box которые просто работают. Моя область это MEU + OOOE.
>Кстати есть такое что отдельные части запускают на >бОльшей частоте?
Уже нет. Мутотень с несколькими clock domains перевешивает все достоинства. В AlderLake AMX на своем clock domain сидит на меньшей частоте, такой вот огромный ALU :)
Так и получается
I manage ;)
Естейственно с оговорками. Это невозможно на 5Ghz, а Apple M1 даже не 3Ghz. А частота тоже не маленький фактор в производительности.
Напомню: Performance := IPC * Freq
Да, Apple M1 порвали всех по IPC но они только приблизились к топовым Intel и AMD по производительности, потому что у них на 40% меньше частота.
Но так как Power = V*F^2
то получается что сравнимой производительности у Apple M1 гораздо ниже энергопотребление, на чем они и выигрывают.
Чего ждать в будущем?
И Интел и AMD будет наращивать IPC пытаясь догнать M1. При приросте в 15% за поколение догонят через 2-3 поколения. Apple скорее всего уже не сможет увеличивать IPC с такой же скоростью, они и так на пределе. Будут делать 5-10% и понемногу увеличивать частоту. Гипотетический Apple M3 будет на 20% больше по IPC но на 20-30% меньше по частоте и опять на примерно той же производительности как Intel и AMD. Вот только разница в энергоэффективности сильно сократится не в пользу Apple.
Потенциально это не про hardware. Hardware должен умень кушать worst case который от количества регистров не меняется.
Он не для этого сделан. Даже если Uop Cache будет поставлять 16 интрукций в такт и декодеры тоже — это никак не поможет «догнать условный IPC у M1»
Потому что нужно будет 8-wide renaming, соответствующее количество ALU и соответсвующую глубину внутренних буферов. А скорее всего еще и соответствующий размер кешей данных.
Наоборот, чем меньше gate delay тем выше частота, на которой можно работать. Или как вариант можно поставить больше logic gates в такт и уменьшить частоту — по этому пути пошли в Apple M1. Больше logic gates в такт — можно позволить себе более сложные алгоритмы не разбивая их на несколько тактов.
Количество регистров никак не позволяет делать алгоритмы в железе проще. Если есть больше регистров, компилятор сможет ими пользоваться и хранить в них какие-то значения. Скорее всего это позволит сократить количество обращений к памяти потому что больше переменных можно будет просто хранить в регистрах. В результате код может будет немного оптимальнее. Но не факт, потому что существующие ABI требуют сохранять регистры в стек на входе в каждую функцию а потом восстанавливать на выходе, что тоже накладно.
Но да, в среднем количество LOAD и STORE на Arm в программах на Aarch64 процентов на 10 меньше, в основном благодаря 32 регистрам.
Я не озвучивал :)
Более того — на том же форуме недавно обсуждали Uop Cache от Intel и AMD. Более 70% всех команд выполняются из Uop Cache и декодеры там вообще спят.
А пропускная способность Uop Cache уже и сейчас гораздо превышает способности Renaming у всех.