Любой сколь-нибудь интенсивный код будет декодирован однажды и исполняться пока не будет остановлен. Вклад декодеров в потребленную энергию будет стремиться к нулю по мере длительности его работы. Без 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 не меняется и это не предвидится. Да и смысла мало. Маленькие шаги наделают фрагментацию. И так куча разных векторных расширений.
Думаю они правильно сделали.
Брюзжу и буду брюзжать. А знаете почему? Потому что только так можно чего то добиться. Сломать донаты в батлфронт, перенести принятие новой политики приватности ватсап, удалить игру из каталога сони
Серьезно? Кто-то передумает из-за вашего мнения?
Я например смотрю тесты и все. Ну норм. Смотрю цены и… возможно беру. Как-то так наверно происходит обьективный выбор. Не?
>И никаких board support package, всё простое и открытое. Да, процессор без этих сложных конвейеров с предсказаниями, да, с производительностью в три раза ниже за ту же энергию, но простой, понятный, и открытый.
Да если современное железо упростить скорость и энергоэффективность только лучше станет
2 x ethernet то нахрена? Даже у x86 плат один обычно. Или я проспал что-то?
Что можно с двумя чего с одним нельзя? — Правда интересно.
>Посмотри на десктопный интел, прямо сейчас в днс 114 материнских плат, и 54 процессора. Из них я могу сложить 6156 компьютеров, и почти все будут работать. Кто еще так может?
Ну если считать процессоры с одинаковым числом ядер в пределах 500Mhz как за один(потому что разницы не чувствуется), то 6156 превратится в примерно 1000.
Да, у ARM все еще меньше будет выбор, но я с вами уже и согласился насчет периферии.
>«покупаем асус и баста»
Я так не делаю. Да, пару тестов и все.
Можно самому проверить, иногда.
>Теперь остается узнать, что если ноуты, то каждый производитель реализует систему охлаждения в разных моделях по своему, а именно от неё зависит насколько задушат процессор.
В таблетах выбор на порядок меньше чем в ноутбуках.
Я взял cube mix plus. Не очень удачная вещь)
Но к нему оказалось легко приделать медную пластинку и процессор упал с 90 до 60 градусов. На полные 2.6 работает.
>от я не понимаю, внутри процессоров Intel всё равно используется ARM
Вы имели ввиду risc внутри? Там не arm.
>Qualcomm же выпустила ARM+x86 процессор, где можно на лету аппартаную архитектуру переключать.
Нет, там программная эмуляция и не от qualcomm а от microsoft
Причем тут бюджет? У меня выходит не больше 40 000 р раз в 3-4 года.
Может вы не так поняли.
1.Я УЖЕ знаю про эффективные zen 2 u-серии.
2.Я УЖЕ знаю что ice lake оказался не слабой печкой.
Покупал ноут на ice lake, мне вместо 2-ух 4 ядра достались.
Он вентилятор не заглушал вообще. Я сдал. Попутно узнал что и 2-ядерных вариантов все еще нет с пассивным охлаждением
3. К моменту покупки останется найти тесты Zen 3 и tiger lake.
Я уже предпочел zen 2 вместо ice lake, если новые не ждать. И все.
В утечках tiger lake было упоминание что intel займется эффективностью транзисторов, только не в смысле техпроцесса а в их количестве.
Самое важное:
Чтобы все это узнать — не нужно на форумах сидеть где люди это все обсуждают. Тесты SPEC в среднем по больнице — отличный показатель.
Я был там. Тогда я не понимаю как L3 занимает даже меньше чем x86.
Даже 64-битные умножители так много не занимают.
Про x86 часто говорят:
1.Кэши потребляют бОльшую часть энергии
2.Декодер требует мало энергии/площади.
И эти два противоречат.
Как я уже написал, сложность ISA вероятно имеет более глубокие последствия.
Вроде одна из самых простых вещей в 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 не меняется и это не предвидится. Да и смысла мало. Маленькие шаги наделают фрагментацию. И так куча разных векторных расширений.
Думаю они правильно сделали.
Серьезно? Кто-то передумает из-за вашего мнения?
Я например смотрю тесты и все. Ну норм. Смотрю цены и… возможно беру. Как-то так наверно происходит обьективный выбор. Не?
Да если современное железо упростить скорость и энергоэффективность только лучше станет
Что можно с двумя чего с одним нельзя? — Правда интересно.
>Посмотри на десктопный интел, прямо сейчас в днс 114 материнских плат, и 54 процессора. Из них я могу сложить 6156 компьютеров, и почти все будут работать. Кто еще так может?
Ну если считать процессоры с одинаковым числом ядер в пределах 500Mhz как за один(потому что разницы не чувствуется), то 6156 превратится в примерно 1000.
Да, у ARM все еще меньше будет выбор, но я с вами уже и согласился насчет периферии.
Решил с вами поделиться новостью.
Май настал)
www.anandtech.com/show/15813/arm-cortex-a78-cortex-x1-cpu-ip-diverging/4
Я так не делаю. Да, пару тестов и все.
Можно самому проверить, иногда.
>Теперь остается узнать, что если ноуты, то каждый производитель реализует систему охлаждения в разных моделях по своему, а именно от неё зависит насколько задушат процессор.
В таблетах выбор на порядок меньше чем в ноутбуках.
Я взял cube mix plus. Не очень удачная вещь)
Но к нему оказалось легко приделать медную пластинку и процессор упал с 90 до 60 градусов. На полные 2.6 работает.
Вы имели ввиду risc внутри? Там не arm.
>Qualcomm же выпустила ARM+x86 процессор, где можно на лету аппартаную архитектуру переключать.
Нет, там программная эмуляция и не от qualcomm а от microsoft
Может вы не так поняли.
1.Я УЖЕ знаю про эффективные zen 2 u-серии.
2.Я УЖЕ знаю что ice lake оказался не слабой печкой.
Покупал ноут на ice lake, мне вместо 2-ух 4 ядра достались.
Он вентилятор не заглушал вообще. Я сдал. Попутно узнал что и 2-ядерных вариантов все еще нет с пассивным охлаждением
3. К моменту покупки останется найти тесты Zen 3 и tiger lake.
Я уже предпочел zen 2 вместо ice lake, если новые не ждать. И все.
В утечках tiger lake было упоминание что intel займется эффективностью транзисторов, только не в смысле техпроцесса а в их количестве.
Самое важное:
Чтобы все это узнать — не нужно на форумах сидеть где люди это все обсуждают. Тесты SPEC в среднем по больнице — отличный показатель.
Даже 64-битные умножители так много не занимают.
Про x86 часто говорят:
1.Кэши потребляют бОльшую часть энергии
2.Декодер требует мало энергии/площади.
И эти два противоречат.
Как я уже написал, сложность ISA вероятно имеет более глубокие последствия.