Ага, а МОП кэши придуманы просто так, да? Они нужны чтобы увеличить ширину декодирования.
Имея 4-way декодер x86 процессоры могут доставать 6-8 МОПов, точно так же как и на ARM Cortex-A77+.
Вот блин, а я понять не мог.
Вроде x86 isa не такой уж и cisc(именно даже с т.з. внешней isa) чтобы zen 3, декодируя 4-5 инструкций, держался близко к m1.
Вроде читал статьи, а как-то пропустил этот момент.
P.S.
Комменты полезнее любой статьи)
Хотел бы я увидеть software emulation который будет работать за приемлемое время. С удовольствием включу в исходники Bochs:)
Понятно что эмуляция медленная.
Но в целом.
1. В некоторых вычислениях прослеживаются участие лишь какого-то спектра чисел.
2. Иногда мантисса такая не нужна. Иногда экспонента.
3. Всякие зависимости бывает прослеживаются бит-в-бит и прочее.
4. По устройству misc cpu например сильно проще и в теории может достигать скорости достаточной для эмуляции 16 fmac fp32 per cycle
5. Для компилятора пропадает стена между типами данных = более продвинутый компилятор может вообще зависимости отдельных бит отслеживать втечение всей программы. (Ну это пока немного фантастика)
6. Кастомные типы данных из-за 1,2 и 3.
7. fixed point, правда это частный случай из п.6
И так далее.
То есть именно все вместе это могло быть лучше современного hard fp)
Ну это просто такая вот моя теория.)
P.S.
Вообще последний раз intel удвоили теоретический максимум fp32 до 32(16 fmac) per cycle в Haswell. С тех пор только задержки уменьшаются, но верхний предел тот же. У zen и arm в основном также +-. В GPU то же не сильно прогресс. «Жирные» они(fp блоки).
FP операции.
Никогда не понимал смысл hardware fp.
Специфический тип данных по причине фиксированной мантиссы и экспоненты.
Можно же и софтварно реализовать, развернуть цикл.
Получится чуть больше общий поток инструкций, но можно сильно нарастить темп исполнения более простых операций.
+
Компилятор больше не будет ориентироваться на типы данных. Будет дополнительные зависимости находить, когда смешанный код.
Таким образом мне кажется компилятор можно будет сделать более продвинутым. А пока получается искусственный барьер между data types.
+
Кастомная мантисса и экспонента.
2. Как умножение за 2-3 такта происходит? Там же вроде зацикливается ALU, который для этого имеет дополнительный небольшой circuit, чем и отличается от обычных ALU.
Но это слишком быстро по моему даже для wallec tree или booth. Он как будто на повышенной частоте работает.
3. Кстати есть такое что отдельные части запускают на бОльшей частоте? Как в каком-то pentium вроде было, снаружи 3Ghz, внутри alu на 6Ghz.
Любой сколь-нибудь интенсивный код будет декодирован однажды и исполняться пока не будет остановлен. Вклад декодеров в потребленную энергию будет стремиться к нулю по мере длительности его работы. Без uops cache(в идеальном мире с идеальной ISA) просто из цепочки (компиляция-трансляция в uops — тсполнение) трансляция кода «внутрь» исчезнет. Это как «прогрев» кода jit'ом.
Количество регистров никак не позволяет делать алгоритмы в железе проще.
Я этого не говорил. Это бред.
Я как раз про распределение переменных по явно доступным регистрам. Меньше load store и потенциально меньше проблем в renaming. Что вы далее и написали.
Но действительно с тех пор больше не увеличивают. Значит смысла нет.
В упор не понимаю, как сложность схемы связана с частотой.
слабо связано с физическими ограничениями полупроводников
Так абсолютно согласен. Я даже к этому ниразу и не вел. У x86-декодеров в этом смысле задача сильно проще.
Решается за O(n) но расспараллелить сложно из-за переменной длины.
Т.е. по-вашему «сложные» схемы собираются не из тех же логических элементов, что и «простые»?
Нет.
Из тех же — NOT, AND gates, обычно.
Я не думаю что блок ренэйминга будет настолько огромным.
Тут действительно с частотой у apple проблем не должно быть.
Или вы представляете себе настолько гигантскую схему декодера, что в нём время распространения электрического поля в проводнике начинает быть сравнимым с временем переходного процесса при частоте 5ГГц, а при 3ГГц ещё ок?
full hardware multiplier из за O(n^2) быстро вырастет до момента когда упрется в ограничения.
И тогда
То, что сложные алгоритмы чисто математически не раскладываются на однотактовое выполнение на логических элементах, к делу не относится
К делу относится.
В умножителях Booth'а, «wallac tree» часть сложности срезается оптимизацией.
И вообще сложность алгоритма всегда к делу относится. В железе не чудеса происходят.:
Бут придумал алгоритм. Затем его реализовали в железе. Стала меньше сложность.
Напишем алгоритм умножения столбиком. shift-add.
uint64_t mul(uint64_t a, uint64_t b) {
uint64_t c = 0;
while (a != 0) {
c += b & (0 - (a & 1));
b = b << 1;
a = a >> 1;
}
return c;
}
В худшем случае 64 64-битных сдвига и 64 n-битных сложений, где n в спектре 1...64.
Для 32 бит получится 32 32 битных сдвигов и соответственно для сложений(вдвое короче, в два раза меньше)
В случае full-hardware multiplier где будут просчитаны зависимости каждого конечного бита эта O(n^2) сложность отобразится на его площади.
Но даже интуитивно наивно полагать что можно строить цифровую схему неограниченного размера срабатывающую за тоже время без резкого увеличения power consumption и каких-либо других физ.ограничений.
В упор не понимаю, как сложность схемы связана с частотой.
Чем больше схема тем меньше ее предельная частота. Слишком сложная схема не будет срабатывать за такт обычного ALU.
Потому не используют full hardware умножители в CPU.
Иногда очень хочется отследить кто первым вбросил этот тезис про «x86 ограничивает количество декодируемых инструкций за такт»
Я не так выразился. Имею ввиду что нужно сделать 3+ операций чтобы выяснить следующее смещение и параллельно начать декодировать следующую инструкцию. Получется конвеер из инструкций с долгой задержкой между.
Но это еще не значит, что они смогут удержать пальму первенства надолго.
Ни разу не собирался такое заявлять.
Насчет ренэйминга отчасти да, O(n^2) это конечно плохо. Но в идеале код может быть построен компилятором так что это не потребуется.
В общем современные компиляторы неплохо с этим справляются, как минимум в простых случаях. И используют небольшое подмножество инструкций что тут(x86) что там(ARM).
Иногда очень хочется отследить кто первым вбросил этот тезис про «x86 ограничивает количество декодируемых инструкций за такт» и преимущество ARM. Все его бездумно повторяют, потому что не имеют ни малейшего представления что это значит)
Я не стал много расписывать, но думаю эта проблема имеет свое место. (Может я и не прав, но идем далее).
Декодеры отрабатывают немного транслируя код внутрь. И там уже программа выполняется. В случай интенсивного кода(какй-нибудь вычислительный цикл) декодеры вообще не играют роли. Расход на них стремится к нулю по мере длительности исполнения этого цикла.
Но например вэб, мне кажется один из тех случаев когда это влияет.
Веб — часто подгружаемый код на той же странице или в процессе постоянного браузинга.
По моей теории на вэб это влияет в смысле длительности прогрузки страницы.
Наверно еще не качественный код на скриптовом языке может попадать в этот кейс.
Интересен ваш вариант.
Edit:
Подумал еще про ренэйминг.
То есть блок переименования на 8 инструкций будет в 4 раза больше, чем блок переименования на 4 инструкции. И это еще в лучшем случае.
Не факт что блок этот — жесткий hardware. Может там простой(ые) процессор(ы) с ПЗУ. Хотя я точно не могу говорить как лучше.
Несмотря на такую сложность можно брать 8 micro uops за раз и начинать с нескольких мест… Может таким образом константа подрезается.
производительный процессор поменяли на дешевую арм затычку
ARM не значит медленно. Это просто набор инструкций. Уже сотни раз писали что x86 ISA ограничивает количество декодируемых инструкций за раз.
x86 ISA не меняется и это не предвидится. Да и смысла мало. Маленькие шаги наделают фрагментацию. И так куча разных векторных расширений.
Думаю они правильно сделали.
Брюзжу и буду брюзжать. А знаете почему? Потому что только так можно чего то добиться. Сломать донаты в батлфронт, перенести принятие новой политики приватности ватсап, удалить игру из каталога сони
Серьезно? Кто-то передумает из-за вашего мнения?
Я например смотрю тесты и все. Ну норм. Смотрю цены и… возможно беру. Как-то так наверно происходит обьективный выбор. Не?
aras-p.info/blog/2021/01/18/Texture-Compression-on-Apple-M1
Почему то один qualcomm решил что достаточно int8 и сделал int8-only NPU
Хотя тренду они чуть-чуть последовали, Adreno умеет всё.
Интересно что с идеей бинаризации.
software.intel.com/content/www/ru/ru/develop/articles/optimizing-binarized-neural-networks-on-intel-xeon-scalable-processors.html
Вот блин, а я понять не мог.
Вроде x86 isa не такой уж и cisc(именно даже с т.з. внешней isa) чтобы zen 3, декодируя 4-5 инструкций, держался близко к m1.
Вроде читал статьи, а как-то пропустил этот момент.
P.S.
Комменты полезнее любой статьи)
Понятно что эмуляция медленная.
Но в целом.
1. В некоторых вычислениях прослеживаются участие лишь какого-то спектра чисел.
2. Иногда мантисса такая не нужна. Иногда экспонента.
3. Всякие зависимости бывает прослеживаются бит-в-бит и прочее.
4. По устройству misc cpu например сильно проще и в теории может достигать скорости достаточной для эмуляции 16 fmac fp32 per cycle
5. Для компилятора пропадает стена между типами данных = более продвинутый компилятор может вообще зависимости отдельных бит отслеживать втечение всей программы. (Ну это пока немного фантастика)
6. Кастомные типы данных из-за 1,2 и 3.
7. fixed point, правда это частный случай из п.6
И так далее.
То есть именно все вместе это могло быть лучше современного hard fp)
Ну это просто такая вот моя теория.)
P.S.
Вообще последний раз intel удвоили теоретический максимум fp32 до 32(16 fmac) per cycle в Haswell. С тех пор только задержки уменьшаются, но верхний предел тот же. У zen и arm в основном также +-. В GPU то же не сильно прогресс. «Жирные» они(fp блоки).
Никогда не понимал смысл hardware fp.
Специфический тип данных по причине фиксированной мантиссы и экспоненты.
Можно же и софтварно реализовать, развернуть цикл.
Получится чуть больше общий поток инструкций, но можно сильно нарастить темп исполнения более простых операций.
+
Компилятор больше не будет ориентироваться на типы данных. Будет дополнительные зависимости находить, когда смешанный код.
Таким образом мне кажется компилятор можно будет сделать более продвинутым. А пока получается искусственный барьер между data types.
+
Кастомная мантисса и экспонента.
2. Как умножение за 2-3 такта происходит? Там же вроде зацикливается ALU, который для этого имеет дополнительный небольшой circuit, чем и отличается от обычных ALU.
Но это слишком быстро по моему даже для wallec tree или booth. Он как будто на повышенной частоте работает.
3. Кстати есть такое что отдельные части запускают на бОльшей частоте? Как в каком-то pentium вроде было, снаружи 3Ghz, внутри alu на 6Ghz.
Как я понял через регистры уже задержка будет.
Сейчас страшно стало что-то глупое отморозить…
Получается для моментальной передачи между двумя любыми ALU эта сеть растет в квадрате от их количества?
Надеюсь я вас не утомил вопросами)
Просто у меня их еще есть.
Вроде одна из самых простых вещей в modern cpu.
Или это потому что они тактируются как одна схема?
Я вас понял.
Любой сколь-нибудь интенсивный код будет декодирован однажды и исполняться пока не будет остановлен. Вклад декодеров в потребленную энергию будет стремиться к нулю по мере длительности его работы. Без uops cache(в идеальном мире с идеальной ISA) просто из цепочки (компиляция-трансляция в uops — тсполнение) трансляция кода «внутрь» исчезнет. Это как «прогрев» кода jit'ом.
Я как раз про распределение переменных по явно доступным регистрам. Меньше load store и потенциально меньше проблем в renaming. Что вы далее и написали.
Но действительно с тех пор больше не увеличивают. Значит смысла нет.
Хм, быть того не может. Зачем же в процессе увеличили количество явно доступных регистров?
Если для удобства, то, на ассемблере даже в те времена мало кто писал.
И разве это не упрощает переименование регистров в случае когда программисту/компилятору доступно больше регистров?
Так абсолютно согласен. Я даже к этому ниразу и не вел. У x86-декодеров в этом смысле задача сильно проще.
Решается за O(n) но расспараллелить сложно из-за переменной длины.
Нет.
Из тех же — NOT, AND gates, обычно.
Я не думаю что блок ренэйминга будет настолько огромным.
Тут действительно с частотой у apple проблем не должно быть.
full hardware multiplier из за O(n^2) быстро вырастет до момента когда упрется в ограничения.
И тогда
К делу относится.
В умножителях Booth'а, «wallac tree» часть сложности срезается оптимизацией.
И вообще сложность алгоритма всегда к делу относится. В железе не чудеса происходят.:
Бут придумал алгоритм. Затем его реализовали в железе. Стала меньше сложность.
Напишем алгоритм умножения столбиком. shift-add.
В худшем случае 64 64-битных сдвига и 64 n-битных сложений, где n в спектре 1...64.
Для 32 бит получится 32 32 битных сдвигов и соответственно для сложений(вдвое короче, в два раза меньше)
В случае full-hardware multiplier где будут просчитаны зависимости каждого конечного бита эта O(n^2) сложность отобразится на его площади.
Что-то вроде как-то так.
На данный момент мне уровень знаний не позволяет точно вам ответить.
Но это является проблемой. Не просто так этим занимаются.
core.ac.uk/download/pdf/234643291.pdf
Но даже интуитивно наивно полагать что можно строить цифровую схему неограниченного размера срабатывающую за тоже время без резкого увеличения power consumption и каких-либо других физ.ограничений.
Чем больше схема тем меньше ее предельная частота. Слишком сложная схема не будет срабатывать за такт обычного ALU.
Потому не используют full hardware умножители в CPU.
В ARM это упрощает, но не значительно.
Физических регистров все равно сильно больше.
Хотя некоторые оценили.
superpowered.com/64-bit-arm-optimization-audio-signal-processing
Иногда упоминаются кейсы что возможность явного(руками) доступа к большему числу регистров лучше.
Я не так выразился. Имею ввиду что нужно сделать 3+ операций чтобы выяснить следующее смещение и параллельно начать декодировать следующую инструкцию. Получется конвеер из инструкций с долгой задержкой между.
Ни разу не собирался такое заявлять.
Насчет ренэйминга отчасти да, O(n^2) это конечно плохо. Но в идеале код может быть построен компилятором так что это не потребуется.
В общем современные компиляторы неплохо с этим справляются, как минимум в простых случаях. И используют небольшое подмножество инструкций что тут(x86) что там(ARM).
Я не стал много расписывать, но думаю эта проблема имеет свое место. (Может я и не прав, но идем далее).
Декодеры отрабатывают немного транслируя код внутрь. И там уже программа выполняется. В случай интенсивного кода(какй-нибудь вычислительный цикл) декодеры вообще не играют роли. Расход на них стремится к нулю по мере длительности исполнения этого цикла.
Но например вэб, мне кажется один из тех случаев когда это влияет.
Веб — часто подгружаемый код на той же странице или в процессе постоянного браузинга.
По моей теории на вэб это влияет в смысле длительности прогрузки страницы.
Наверно еще не качественный код на скриптовом языке может попадать в этот кейс.
Интересен ваш вариант.
Edit:
Подумал еще про ренэйминг.
Не факт что блок этот — жесткий hardware. Может там простой(ые) процессор(ы) с ПЗУ. Хотя я точно не могу говорить как лучше.
Несмотря на такую сложность можно брать 8 micro uops за раз и начинать с нескольких мест… Может таким образом константа подрезается.
ARM не значит медленно. Это просто набор инструкций. Уже сотни раз писали что x86 ISA ограничивает количество декодируемых инструкций за раз.
x86 ISA не меняется и это не предвидится. Да и смысла мало. Маленькие шаги наделают фрагментацию. И так куча разных векторных расширений.
Думаю они правильно сделали.
Серьезно? Кто-то передумает из-за вашего мнения?
Я например смотрю тесты и все. Ну норм. Смотрю цены и… возможно беру. Как-то так наверно происходит обьективный выбор. Не?