ARM против x86: В чем разница между двумя архитектурами процессоров?

    Вы наверняка знаете, что мир процессоров разбит на два лагеря. Если вы смотрите это видео со смартфона, то для вас работает процессор на архитектуре ARM, а если с ноутбука, для вас трудится чип на архитектуре x86.

    А теперь еще и Apple объявила, что переводит свои Mac на собственные процессоры Apple Silicon на архитектуре ARM. Мы уже рассказывали, почему так происходит. А сегодня давайте подробно разберемся, в чем принципиальные отличия x86 и ARM. И зачем Apple в это все вписалась?


    Итак, большинство мобильных устройств, iPhone и Android'ы работают на ARM'е. Qualcomm, HUAWEI Kirin, Samsung Exynos и Apple A13/A14 Bionic — это все ARM-процессоры.

    А вот на компьютере не так — там доминирует x86 под крылом Intel и AMD. Именно поэтому на телефоне мы не можем запустить Word с компьютера.

    x86 — так называется по последним цифрам семейства классических процессоров Intel 70-80х годов.



    Чем же они отличаются?

    Есть два ключевых отличия.

    Первое — это набор инструкций, то есть язык который понимает процессор


    x86 процессоры используют сложный набор инструкций, который называется CISC - Complex Instruction Set Computing.

    ARM процессоры наоборот используют упрощенный набор инструкций — RISC - Reduced Instruction Set Computing.

    Кстати ARM расшифровывается как Продвинутые RICS машины - Advanced RISC Machines.

    Наборы инструкций ещё принято назвать архитектурой или ISA - Instruction Set Architecture.

    Второе отличие — это микроархитектура. Что это такое?


    От того на каком языке говорят процессоры, зависит и то, как они проектируются. Потому как для выполнения каждой инструкции на процессоре нужно расположить свой логический блок. Соответственно, разные инструкции — разный дизайн процессора. А дизайн — это и есть микроархитектура.

    • x86 — CISC
    • ARM — RISC

    Итак, запомнили. Говорим x86 — подразумеваем архитектуру CISC, ARM — это RISC.

    Но как так произошло, что процессоры стали говорить на разных языках?

    История CISC



    Памятка программиста, 1960-е годы. Цифровой (машинный) код «Минск-22».

    Всё началось в 1960-х. Поначалу программисты работали с машинным кодом, то есть реально писали нолики и единички. Это быстро всех достало и появился Assembler. Низкоуровневый язык программирования, который позволял писать простые команды типа сложить, скопировать и прочее. Но программировать на Assembler'е тоже было несладко. Потому как приходилось буквально “за ручку” поэтапно описывать процессору каждое его действие.

    Поэтому, если бы вы ужинали с процессором, и попросили передать его вам соль, это выглядело бы так:

    • Эй процессор, посмотри в центр стола.
    • Видишь соль? Возьми её.
    • Теперь посмотри на меня.
    • Отдай мне соль. — Ага, спасибо!
    • А теперь снова возьми у меня соль.
    • Поставь её откуда взял
    • Спасибо большое! Продолжай свои дела.
    • Кхм… Процессор, видишь перец?
    • И так далее....

    В какой-то момент это всё задолбало программистов. И они решили: Хей, а почему бы нам просто не не написать инструкцию «Передай мне соль»? Так и сделали. Набор таких комплексных инструкций назвали CISC.

    Этот подход стал настоящим спасением как для разработчиков, так и для бизнеса. Захотел клиент новую инструкцию — не проблема, были бы деньги — мы сделаем. А деньги у клиентов были.

    Недостатки CISC


    Но был ли такой подход оптимальным??? С точки зрения разработчиков — да. Но вот микроархитектура страдала.

    Представьте, вы купили квартиру и теперь вам нужно обставить её мебелью. Площади мало, каждый квадратный метр на счету.  И вот представьте, если бы CISC-процессор обставил мебелью вам гостиную, он бы с одной стороны позаботился о комфорте каждого потенциального гостя и выделил бы для него своё персональное место.

    С другой стороны, он бы не щадил бюджет. Диван для одного человека, пуф для другого, кушетка для третьего, трон из Игры Престолов для вашей Дейенерис. В этом случае площадь комнаты бы очень быстро закончилась. Чтобы разместить всех вам бы пришлось увеличивать бюджет и расширять зал. Это не рационально. Но самое главное, CISC-архитектура существует очень давно и те инструкции, которые были написаны в 60-х годах сейчас уже вообще не актуальны. Поэтому часть мебели, а точнее исполнительных блоков, просто не будут использоваться. Но многие из них там остаются. Поэтому появился RISC…

    Преимущества RISC


    С одной стороны писать на Assembler'е под RISC процессоры не очень-то удобно. Если в лоб сравнивать код, написанный под CISC и RISC процессоры, очевидно преимущество первого.

    Так выглядит код одной и той же операции для x86 и ARM.

    x86

    • MOV AX, 15; AH = 00, AL = 0Fh
    • AAA; AH = 01, AL = 05
    • RET

    ARM
    • MOV R3, #10
    • AND R2, R0, #0xF
    • CMP R2, R3
    • IT LT
    • BLT elsebranch
    • ADD R2. #6
    • ADD R1. #1
    • elsebranch:
    • END

    Но так было раньше. На ассемблере уже давно никто не пишет.  Сейчас за программистов всё это делают компиляторы, поэтому никаких сложностей с написанием кода под RISC-процессоры нет. Зато есть преимущества.

    Представьте, что вы проектируете процессор. Расположение блоков на х86 выглядело бы так.



    Каждый цветной квадрат — это отдельные команды. Их много и они разные. Как вы поняли, здесь мы уже говорим про микроархитектуру, которая вытекает из набора команд. А вот ARM-процессор скорее выглядит так.



    Ему не нужны блоки, созданные для функций, написанных 50 лет назад.

    По сути, тут блоки только для самых востребованных команд. Зато таких блоков много. А это значит, что можно одновременно выполнять больше базовых команд. А раритетные не занимают место.

    Еще один бонус сокращенного набора RISC: меньше места на чипе занимает блок по декодированию команд. Да, для этого тоже нужно место. Архитектура RISC проще и удобнее, загибайте пальцы:

    • проще работа с памятью,
    • более богатая регистровая архитектура,
    • легче делать 32/64/128 разряды,
    • легче оптимизировать,
    • меньше энергопотребление,
    • проще масштабировать и делать отладку.

    Для примера вот два процессора одного поколения. ARM1 и Intel 386. При схожей производительности ARM вдвое меньше по площади. А транзисторов на нем в 10 раз меньше: 25 тысяч против 275 тысяч. Энергопотребление тоже отличается на порядок: 0.1 Ватт против 2 Ватт у Intel. Шок.

    Поэтому наши смартфоны, которые работают на ARM процессорах с архитектурой RISC, долго живут, не требуют активного охлаждения и такие быстрые.

    Лицензирование


    Но это все отличия технические. Есть отличия и организационные. Вы не задумывались почему для смартфонов так много производителей процессоров, а в мире ПК на x86 только AMD и Intel? Все просто — ARM это компания которая занимается лицензированием, а не производством.

    Даже Apple приложила руку к развитию ARM. Вместе с Acorn Computers и VLSI Technology. Apple присоединился к альянсу из-за их грядущего устройства — Newton. Устройства, главной функцией которого было распознавание текста.

    Даже вы можете начать производить свои процессоры, купив лицензию. А вот производить процессоры на x86 не может никто кроме синей и красной компании. А это значит что? Правильно, меньше конкуренции, медленнее развитие. Как же так произошло?



    Ну окей. Допустим ARM прекрасно справляется со смартфонами и планшетами, но как насчет компьютеров и серверов, где вся поляна исторически поделена? И зачем Apple вообще ломанулась туда со своим Apple Silicon.

    Что сейчас?


    Допустим мы решили, что архитектура ARM более эффективная и универсальная. Что теперь? x86 похоронен?

    На самом деле, в Intel и AMD не дураки сидят. И сейчас под капотом современные CISC-процессоры очень похожи на RISC. Постепенно разработчики CISC-процессоров все-таки пришли к этому и начали делать гибридные процессоры, но старый хвост так просто нельзя сбросить.



    Но уже достаточно давно процессоры Intel и AMD разбивают входные инструкции на более мелкие микро инструкции (micro-ops), которые в дальнейшем — сейчас вы удивитесь — исполняются RISC ядром.

    Да-да, ребята! Те самые 4-8 ядер в вашем ПК — это тоже RISC-ядра!

    Надеюсь, тут вы окончательно запутались. Но суть в том, что разница между RISC и CISC-дизайнами уже сейчас минимальна.

    А что остается важным — так это микроархитектура. То есть то, насколько эффективно все организовано на самом камне.

    Ну вы уже наверное знаете, что Современные iPad практически не уступают 15-дюймовым MacBook Pro с процессорами Core i7 и Core i9.



    А что с компьютерами?

    Недавно компания Ampere представила свой 80-ядерный ARM процессор. По заявлению производителя в тестах процессор Ampere показывает результат на 4% лучше, чем самый быстрый процессор EPYC от AMD и потребляет на 14% меньше энергии.





    Компания Ampere, лезет в сегменты Cloud и Workstation, и показывает там отличные цифры. Самый быстрый суперкомпьютер в мире сегодня работает на ARM ISA. С обратной стороны, Intel пытается все таки влезть в сегмент low power и для этого выпускает новый интересный процессор на микроархитектуре lakefield.

    Пока у ноутбуков и процессоров от Intel есть одно неоспоримое достоинство - (охлаждение и) единство архитектуры. Пока на рынке ARM-процессоров существуют Qualcomm, Samsung, MediaTek, в мире x86 творится монополия и разработчикам сильно легче делать софт и игры под “взрослые” процессоры.

    И Apple та компания, которая способна мотивировать достаточное количество разработчиков пилить под свой ARM. Но суть этого перехода скорее не в противостоянии CISC и RISC. Поскольку оба подхода сближаются, акцент смещается на микроархитектуру, которую делает Apple для своих мобильных устройств. И судя по всему микроархитектура у них крута. И они хотели бы ее использовать в своих компьютерах.

    И если бы Intel лицензировал x86 за деньги другим людям, то вероятно Apple просто адаптировали свою текущую микроархитектуру под x86. Но так как они не могут этого сделать, они решили просто перейти на ARM. Проблема для нас с микроархитектурой в том, что она коммерческая тайна. И мы про нее ничего не знаем.

    Итоги




    Спрос на ARM в итоге вырастет. Для индустрии это не просто важный шаг, а архиважный. Линус Торвальдс говорил, что пока рабочие станции не станут работать на ARM — на рынке серверов будут использовать x86.

    И вот это случилось — в перспективе это миллионы долларов, вложенных в серверные решения. Что, конечно, хорошо и для потребителей. Нас ждет светлое будущее и Apple, действительно, совершила революцию!

    Редактор материала: Антон Евстратенко. Этот материал помогли подготовить наши зрители Никита Куликов и Григорий Чирков. Спасибо ребята!
    Droider.Ru
    Компания
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 184

      +4
      А как же MIPS, PowerPC и еще куча архитектур?
        0
        Mips и Power — это тоже Risc.
          +6
          Что ничего особо не значит. Внутри все эти процессоры кардинально разные. RISC давно уже ничего не значащая аббревиатура, как и противостояние CISC и RISC, когда и те и другие разбивают инструкции на микрооперации.
            +15
            Вообще, разница между современными RISC и CISC есть, но она совсем не там, где её видит автор статьи (и чему он, к сожалению, посвятил половину этой самой статьи). От всего того противостояния архитектур сейчас выжил всего лишь один признак: RISC-процессоры имеют в своём наборе команд отдельно команды для пересылки данных между памятью и регистрами, и отдельно команды для операций над данными в регистрах. Команды CISC-процессоров же в своих операндах могут произвольно использовать как регистры, так и непосредственно адреса в памяти. Вот, собственно, и всё. Архитектурно же внутри и RISC, и CISC сейчас устроены схожим образом.
        +37
        Хватит тиражировать уже эту фигню про конскую разницу в энергоэффективности. Нет ее, иначе все давно бы сидели на ARMах и даже отсутствие обратной совместимости с x86 не омрачило бы выигрыш от десятикратного увеличения быстродействия за те же Ватты.

        Тем более, что при такой разнице быстродействия программная эмуляция была бы сопоставима по скорости с «родными» процессорами.
          –5
          Ну, есть, на самом деле, на низком уровне. Не конская, но есть. Просто для пользователя x86 ускоряют разными хаками, и ему кажется, что в общем-то, разницы особой нет. Но потом из-за этих хаков всякие интересные уязвимости появляются.
            +7
            Нафига хаки, если внутри давно RISC?
            Современный x86 вполне мог бы быть тем же ARM-ом под транслятором команд.
              0
              Ну, так превращать одни команды в другие все равно надо.
                +13
                Это не так дорого, как многие думают.

                Взгляните на «политическую» карту кристалла современного x86, где условно показано разделение функциональных блоков. Видите там огромный блок транслятора команд? Не видите. Это потому, что его там пара процентов площади, даже обводить толком нечего. А как может такой маленький кусок кристалла жрать всю ту разницу, которую приписывают x86? Он же расплавится.
                  +1

                  Но при этом в процессорах Intel есть кэш декодера микроопераций. В последних по-моему около 2000 элементов. Странно кэшировать то что не тормозит. И в "Intel Tremont" предназначенного для "low-power" этого кэша как раз нет. Зачем выкидывать то что не сильно влияет на энергопотребление, ведь по идее чем более похожим будет новый Atom на остальные CPU тем всем легче.

                    +4
                    Не нужно путать декодирование команд и их трансляцию. Декодер есть в любом процессоре.

                    Странно кэшировать то что не тормозит.

                    Странно отказываться от повышения производительности, когда есть такая возможность.

                    Зачем выкидывать то что не сильно влияет на энергопотребление

                    Из ULP-процессоров выкидывают все, что не влияет радикально на производительность, но позволяет экономить энергию. Многоканальный контроллер памяти тоже часто выкидывают, но это совсем не значит, что он жрет киловатты.
                      0

                      кэш декодера микроопераций


                      Микрооперации декодировать нет смысла, они уже представлены в целевом виде конкретной модели процессора.
                      Кэш декодера инструкций (команд) системы x86 назывался trace cache и, насколько мне известно, последняя модель, в которой он был, назывался Pentium 4 — и от него отказались в Core.
                      Если у вас другие данные, укажите источник.

                  +8

                  Не думаю, что корректно говорить, что внутри RISC, потому что внутри мощных RISC'ов (ARM) все равно то же самое происходит. Декодирование инструкций в микрооперации, кэши микроопераций, реордеринг и внеочередное исполнение, векторизация, конвейеризация. И все это твикают. Улучшили чуть-чуть предсказатель ветвлений, улучшили конвейрезицию запросов к памяти, улучшили кэширование, там, сям, и выжимают те самые проценты прироста производительности. Чтобы ARM имел ту же "производительность" на такт (не говорю инструкцию на так, потому что, к примеру, можно улучшать подсистему памяти ипр), ему потребуются те же хаки и улучшения.

                  +10
                  Какие хаки? Внеочередное исполнение, предсказания, спекулятивное исполнение использовать будет любой процессор, которому нужно быть быстрым. АРМы в том числе, как тот же cortex-A9 и старше. Это очевидные оптимизации. x86 ускоряют выносом все большего числа инструкций в железо, добавкой расширений и постоянными твиками микроархитектуры. Вон на райзены посмотреть, как там достигли таких успехов. А уязвимости появляются из-за того, как это все реализовано. АМД при все тех же оптимизациях большинство уязвимостей миновала. Как и армыминовали большинство, но не все. Спектр всех зацепил.
                    +5
                    Но потом из-за этих хаков всякие интересные уязвимости появляются.
                    Ага, то-то Meltdown в ARM обнаружили, а в AMD нет.
                      +3

                      Если подумать — Spectre и Meltdown — это следствие "протечки абстракций", но никак не архитектуры в целом.
                      Процессор дошёл до точки ветвления, зависимой от значения в некоей ячейке памяти — и чтобы не ждать, решил просчитать предсказанную ветвь (или сразу обе). И это момент первой протечки: права доступа не проверяются.
                      Далее, оказалось, что прав нет. Значит, надо результаты ЛЮБОЙ спекулятивной операции устранять (чистить кэш). Туда ходить было нельзя, значит и кэшировать результаты выполнения любых действий над запрещённой областью тоже нельзя!
                      Но этого не делается, и вот она — уязвимость. Померил время доступа к паре доступных ячеек, одна из которых уже прочиталась в кэш из-за спекуляции над недоступной памятью — и знаешь, что за битик там стоял…
                      И всё это — следствие не разницы между x86/arm, а скорее разницы в микрооптимизациях и архитектуры (будь там не намертво втравленная в кремний схема, а ПЛМ, у которой можно поменять алгоритм этого микроулучшения с помощью микропрошивки — и проблемы бы не было).

                        0
                        Что-то схожее с ПЛМ там есть. В более новых версиях биоса встречались блобы, распаковывающие патчи микроопераций.
                    +5

                    Я тоже не понимаю этого срача. Есть архитектура, а есть реализация архитектуры в конкретных процессорах. Оценивать архитектуру по процессорам, которые ещё и занимают разные ниши — бесполезная затея.


                    Современные x86 процессоры прожорливые не потому, что архитектура такая, а потому что они занимают нишу, где производительность важнее энергоэффективности. Уберите из современных x86 процессоров самые прожорливые части — внеочередное выполнение команд и предсказатели переходов, уменьшите размер кэша, понизьте частоту и вольтаж. И получите на выходе процессор, по энергоэффективности сравнимый с ARM-процессорами. Вот только из-за своей производительности он никому не будет нужен.

                      +1

                      ну intel пыталась выйти с атомами на рынок телефонов, что-то отношение производительность/энергопотребление не особо оказалось.

                        +6
                        У меня был Asus Zenfone 2 на Атом 4 х 2ГГц*, мощный и работа от батареи не отличалась от других чем-то особенно.
                        *Без подключения к зарядке работал по умолчанию на 1,8.
                          +1
                          Кстати, хороший телефн, я сам пользовался, потом сын таскал, потом дочь, пока экран не разбила.
                          +3
                          Там дело было не в производительности а в том, что x86 оказался банально не нужен на телефоне.

                          Во-первых, он при прочих равных оказался дороже из-за своей немассовости.
                          Во-вторых, программы для Windows все равно запускать нельзя.
                          В-третьих, многие андроид-программы с нативным кодом до сих пор компилируются только под ARM и MIPS, и на x86 не работают вообще никак.
                            +2
                            …из-за своей немассовости.

                            вас послушать — ни одна новая технология никогда не займёт свою долю на рынке, она же дороже из-за своей немассовости.


                            …с нативным кодом до сих пор компилируются только под ARM и MIPS…

                            то есть под MIPS разработчикам не лень компилировать, а под x86, на котором они и разрабатывают в 99% случаев — лень?

                              +2
                              ни одна новая технология никогда не займёт свою долю на рынке, она же дороже из-за своей немассовости

                              Если она при этом ничем не лучше существующих, то не займет, все правильно. И x86 на телефоне как раз ничем не лучше ARM или MIPS.

                              то есть под MIPS разработчикам не лень компилировать, а под x86, на котором они и разрабатывают в 99% случаев — лень?

                              Выходит, что да. У меня была медиаприставка на адроиде с процессором Intel, и я регулярно сталкивался с «это приложение не поддерживается вашим устройством» (при этом телефон с меньшим количеством памяти и более низкой версией андроида все это запускал аж бегом).

                              Содержимое типичного /lib внутри нативной андроид-программы
                              image
                              И это еще не самый плохой случай. У половины найденных в интернетах APK-файлов (смотрел в основном игрушки и браузеры) даже MIPS нет.
                                0

                                было бы просто не лучше — заняло бы какую-то долю рынка. потому что у всех на слуху (и x86, и intel), потому что разработчикам чуть удобнее (можно отлаживать код прямо на рабочей станции безо всяких эмуляторов), потому что пользователям чуть удобнее (можно запускать статически собранный софт для linux, а в chroot — и не статически)


                                Во-вторых, программы для Windows все равно запускать нельзя.

                                btw, можно (как минимум теоретически), wine и kvm в помощь. и если первое на arm просто не сможет запустить x86 бинарники, то второе сможет, но будет тормозить.


                                но спроса на x86 нет. настолько нет, что вы сами пишете, что разработчики скорее соберут бинарники под экзотический mips (не помню ни одного устройства на mips, выпущенного в последние годы, за исключением роутеров, разумеется).
                                так что я делаю вывод, что atom оказался не просто «не лучше», а хуже.

                        +8
                        Хватит тиражировать уже эту фигню

                        Давайте обойдёмся без истерик, а лучше обратимся к объективным данным
                        anandtech.com/show/16084/intel-tiger-lake-review-deep-dive-core-11th-gen/8



                        Видно, что однопоточная производительность примерно одинаковая.
                        А вот если посмотреть на энергопотребление в этом тесте, то картина более интересная:
                        10900k — 40W (однопоток+турбо 5,3ГГц)
                        1185g7 — 20W (4,8ГГц)
                        A13 — 4W (2.66ГГц)
                        865 — 2W (3.1ГГц)
                        (цифры от автора)

                        выигрыш от десятикратного увеличения быстродействия за те же Ватты

                        Это работает в обратную сторону: 40W/4W = 10x
                        Кстати, по имеющейся информации A14 обещает быть на ~16% быстрее -> Score = ~60+

                        Энергоэффективность идёт от правильной микроархитектуры.
                        Влияние архитектуры не такое значительное (хотя и есть), но производительность явно не зависит от наличия команд типа AAA (кто придумал этот бессмысленный пример?).
                        Специально для автора:
                        AAA and AAS are not available in 64-bit code on x86-64 processors
                        А в Pentium4 эта команда занимала 27 тактов, к примеру.

                        Тем более, что при такой разнице быстродействия программная эмуляция была бы сопоставима по скорости с «родными» процессорами.

                        Так уже :)
                        browser.geekbench.com/v5/cpu/3804101
                        browser.geekbench.com/v5/cpu/3027088
                        В GB5 A12Z набирает ~1100+ попугаев и ~840+ в режиме эмуляции х86.
                        Т.е. уровень десктопного Haswell/Ryzen 7 1700
                        A14 на 40% быстрее чем A12.
                          +5
                          Вот каждый раз видя эти тесты, задаюсь вопросом: и где это все? Где ноутбуки, работающие по многу суток при сопоставимой с i7 производительности? Где сервера с десятками процессорных ядер, каждое из которых потягается с целым современным Xeon-ом? Почему такая красивая диаграмма остается диаграммой, а предлагаемые редкими хостинг-провайдерами ARM-сервера — гиковские недоразумения с производительностью из 2010-х?
                            0
                            Где ноутбуки, работающие по многу суток при сопоставимой с i7 производительности?

                            Процессор — далеко не единственное, что потребляет энергию в ноутбуке. Улучшение энергоэффективности может дать рост пиковой производительности в том же теплопакете, или снизить теплопакет при той же производительности, но кардинального повышения времени автономной работы ожидать не стоит.


                            Где сервера с десятками процессорных ядер, каждое из которых потягается с целым современным Xeon-ом?

                            Не надо передёргивать, никто такого нигде не обещает.


                            Почему такая красивая диаграмма остается диаграммой, а предлагаемые редкими хостинг-провайдерами ARM-сервера — гиковские недоразумения с производительностью из 2010-х?

                            Хостинги начинают появляться со вполне нормальнойпроизводительностью, но на продвижение нужно время. Бизнесы не любят бросаться в авантюры по смене архитектуры не оценив затрат и рисков.


                            Нормальные ноутбуки на ARM начнут появляться в конце этого — начале следующего года.
                            Чтобы выпустить удачный потребительский ноутбук, голой производительности процессора маловато, нужно как минимум решить вопросы доступности софта.
                            Именно это мешает какому-нибудь Surface Pro X стать популярным устройством.

                              +6
                              Ну была Toshiba A100 на тегре. По ощущениям, сливала eeePC на атомах.
                                0

                                Да, в то время ARM не мог тягаться по производительности с x86, а x86 с трудом влезал в теплопакет мобильника (хотя были отдельные девайсы вроде Nokia 9000/9110).
                                С тех пор ситуация немного изменилась.

                                  0
                                  Были)
                                  Справедливости ради, тошиба на тегре – это скорее 2009 год, а не 1998.
                                  Потом у меня был Asus TF700, на котором убунту адово тормозила, но это вопрос скорее про оптимизацию ОС
                                    0

                                    У меня был Asus T91mt, на вполне себе атоме, но пользоваться им было крайне мучительно как под Windows, так и под собранным с оптимизациями Gentoo.

                                0
                                Не надо передёргивать, никто такого нигде не обещает.
                                Уже два стартапа пообещали за этот год. Кто передергивает?
                                Нормальные ноутбуки на ARM начнут появляться в конце этого — начале следующего года.
                                Нет. Ноутбуки от Эпл начнут появляться. Будут ли они нормальными или уровня слабых процессоров — можно лишь гадать.
                                А так то ноутбуки на арме уже вроде как были. Что в них было не нормального?
                                  –1

                                  Голая производительность уже у них на уровне. Дайте нормальную шину к памяти, а не сравнивайте 128bit@4800 DDR4 с 16bit@1333 DDR3, чтобы успевать прокачивать данные, да дата-кешей побольше — и случится закономерное чудо.

                                    +5
                                    Вы забыли частоты нарастить, после чего потребление окажется, потребление окажется, окажется потребление… закономерным, ага.
                                      0

                                      3 ГГц — вполне нормальная частота, 5ГГц любой ценой оставим синим.
                                      Ну и кроме голой частоты на производительность влияет еще множество факторов. И, в целом, потолок у армов видится более высоким при том же потреблении.

                                        +4
                                        В целом, если выкинуть из x86 так нужные для серверов части, которых нет у арм, то вероятно и потолок окажется одинаковым. Или если добавить к арм. То есть сравнение хотелось бы на всём спектре возможностей.
                                        Более того, в анонсах у армов, кстати, шина памяти-то как раз будет аналогичная эпикам, если не лучше даже. Один нюанс.
                                        Это всё анонсы. Ну знаете, как анонсы про то, что вот-вот новые супер аккумуляторы будут, учёные уже придумали. Немного раздражает)
                                          +1

                                          Скорее, не для серверов, а для x86. Современный CPU — это связка из бутылочных горлышек, и каждое лишнее (транслятор, да) ухудшает быстродействие в целом и порождает артефакты при взаимодействии с другими. Плюс у армов есть Thumb, который увеличивает плотность кода, а с ним и максимально достижимую скорость обработки команд и населенность кешей инструкциями, условное выполнение, позволяющее вообще не сбрасывать конвейер независимо от удачи или неудачи предсказания, что обратно упрощает конвейеры…


                                          Ну и наличие вменяемой конкуренции здорово сказывается на потребителе ) А линуксам все равно, на какой архитектуре работать.

                                            –1
                                            Под ARM Linux работает, но совсем неоптимально.
                                              +1
                                              Плюс у армов есть Thumb

                                              У 64-битных нету.
                                                0

                                                Да, и вправду, можно использовать только в режиме aarch32, что не поддерживается тем же Apple…
                                                Видимо с переходом к 64-бит адресации решили не экономить, по крайней мере, пока.

                                      –2
                                      сервера с десятками процессорных ядер, каждое из которых потягается с целым современным Xeon-ом"

                                      Уже два стартапа пообещали за этот год.

                                      Поделитесь именами этих стартапов, желательно со ссылками на их заявления.
                                      Нет. Ноутбуки от Эпл начнут появляться.

                                      А ноутбуки Apple уже не считаются что ли?
                                      Будут ли они нормальными или уровня слабых процессоров — можно лишь гадать.

                                      Не нужно гадать, чтобы понять, что в ноубуках не будет процессоров слабее, чем в телефонах. А текущий телефонный процессор уже затыкает за пояс всю U линейку Intel.
                                      А так то ноутбуки на арме уже вроде как были. Что в них было не нормального?

                                      Вы же сами строчкой выше и ответили — слабые были процессоры.
                                      Изменилось это буквально в последние 2-3 года.
                                        0
                                        Поделитесь именами этих стартапов, желательно со ссылками на их заявления.
                                        Извините, но поиск на хабре работает.
                                        А ноутбуки Apple уже не считаются что ли?
                                        В продаже уже есть, что рвёт i7 или R7 как тузик грелку или нет?
                                        Если нет, то значит пока ещё ничего нет.
                                          0
                                          Извините, но поиск на хабре работает.

                                          На такой булшит никакой поиск не работает. Никто не делал заявлений, что одно ядро какого-то ARM тягается с многоядерными Xeon.


                                          В продаже уже есть, что рвёт i7 или R7 как тузик грелку или нет?
                                          Если нет, то значит пока ещё ничего нет.

                                          Вы с чем спорите, с голосами в голове? Я писал, дословно, "Нормальные ноутбуки на ARM начнут появляться в конце этого — начале следующего года."

                                            +2
                                            И пока по тестам того, что есть — это где-то i3.
                                            Никто не делал заявлений, что одно ядро какого-то ARM тягается с многоядерными Xeon.
                                            человек утрировал, потому как анонсы порвателей ксеонов и эпиков уже который раз обещают что вот вот выйдет 64 ядерный арм, который шустрее 64 ядер интела и амд.
                                            Только проблема в том, что вторые эпики уже используют активно в серверном сегменте, на подходе третьи, а армы по сути всё обещают, обещают и обещают. Скажем так, уже несколько лет как это всё остаётся на подобной стадии, хотя уже должны были бы порвать.
                                            Очень напоминает процесс, как у нулевые обещали выход эльбруса, который интел заткнёт за пояс.
                                              +1
                                              И пока по тестам того, что есть — это где-то i3.

                                              Пока по тестам того, что есть — это где-то на одном уровне с топовыми U-процессорами как в однопотоке, так и в многопотоке:
                                              https://browser.geekbench.com/processors/intel-core-i7-8569u
                                              https://browser.geekbench.com/ios_devices/ipad-pro-12-9-inch-4th-generation
                                              Только с разницей в тепловыделении в 4 раза.


                                              человек утрировал

                                              Поэтому я и написал, что не надо передёргивать. После чего вы влезли утверждая, что аж два стартапа такое заявляли.

                                                +1
                                                8 поколение — давно уже не сильно топовое, уж два года прошло.
                                                Тут и 10 нм от интела, и 7 нм от амд.
                                                Причём там ядер больше. Поэтому даже если производительность ±, то вот потребление снизилось капитально.
                                                Поэтому я и написал, что не надо передёргивать
                                                Да, не верно понял ветку, извиняюсь.
                                                  0
                                                  8 поколение — давно уже не сильно топовое, уж два года прошло.

                                                  Ок, не заметил, что Intel замудрила маркировку своих "экономичных" процессоров. Но результат от этого не сильно поменялся.
                                                  Если открыть каталог Intel потом взять топовые индексы по каждому постфиксу и выбросить всё, что 45+ Вт (и жалкий 7 Вт i7-10510Y), то остаётся вот такой набор.
                                                  Из них только для i7-1068ng7 есть сводная статистика, но можно и поиском воспользоваться (1, 2), чтобы увидеть не очень впечатляющие результаты.


                                                  Да и A12Z по факту тот же двухлетний процессор A12X с ещё одним графическим ядром.


                                                  Тут и 10 нм от интела, и 7 нм от амд.
                                                  Причём там ядер больше

                                                  Я не нашёл в каталоге Intel 10 нм процессора с больше, чем 4 ядрами.
                                                  6 ядер на 14 нм не сильно помогли: i7-10810U


                                                  Поэтому даже если производительность ±, то вот потребление снизилось капитально.

                                                  Но всё ещё далеко до реальных 7-8 Вт A12Z.

                                                    0
                                                    Из них только для i7-1068ng7 есть сводная статистика, но можно и поиском воспользоваться (1, 2), чтобы увидеть не очень впечатляющие результаты.
                                                    Стоп, вы там говорили про ватты ещё. У него именно в оном выигрыш, про что я и говорил, что если производительность ±, то потребление упало.
                                                    По ядрам — интел так и не смогли победить и пока не вышло 10 нм многоядерных >4. Это к его конкуренту. Серии 4хххU
                                                    Но всё ещё далеко до реальных 7-8 Вт A12Z.
                                                    Ну вот новый от эпл будет на 5 нм, которые пока не будут доступны тому же АМД. Вот за счёт более дорогого техпроцесса ЭПЛ может что и сделает, только кто сказал, что те же АМД на 5 нм не окажутся сильно лучше?
                                                    Так что максимум конкуренция кошельков за производство может что выиграть, вот только… Её сможет вести эпл, а все прочие могут остаться на старых нормах и смогут ли на них конкурировать с тем же АМД.
                                                    Интел пока не понятно что будет делать, ибо ему срочно нужны новые техпроцессы, а он в них никак не может.
                                                      0
                                                      Вот за счёт более дорогого техпроцесса ЭПЛ может что и сделает, только кто сказал, что те же АМД на 5 нм не окажутся сильно лучше?

                                                      У них не только техпроцесс, но и своя микроархитектура, которая, похоже, довольно хороша.
                                                      AMD сегодня на тех же 7нм не догоняет позапрошлогодный Apple в производительности на ядро при многократном энергопотреблении.


                                                      Я вообще с надеждой смотрю в будущее. Скорее всего все будут двигаться примерно в одном направлении, и усиление конкуренции на рынке процессоров для ноутбуков и десктопов ещё одним игроком в виде Apple пойдёт только на пользу конечным потребителям, как с прорывами AMD в последние 2-3 года.

                                                        0
                                                        У Амд очень неплохие ядра, но у них есть проблема в виде чиплетного дизайна. Не совсем честно сравнивать их в таком виде который эффективен в экономическом смысле.
                                                          0

                                                          Почему не честно? Мы цены тут совсем не рассматриваем, только производительность в каком-то условном теплопакете.

                                                            0
                                                            Потому что компания сознательно идет на удешевление чипов которые потенциально могут больше. Возможно, в будущем сделают все на одном кристалле без лишних задержек и потерь на соединении чипов, тогда увидим что может их архитектура. А пока что можно посмотреть только новые ноутбучные процессоры.
                                                              0
                                                              Она на это идет, чтобы быть лучше интела, который как раз с монолитными кристаллами уперся в потолок на серверном рынке. Первый зен и так был монолитным более менее кристаллом, но внутри все так же была infiinity fabric. Последняя самое главное достижение их архитектуры и было бы странно видеть отказ от этого подхода. Кристаллы дешевле не становятся, наоборот чем тоньше процесс, тем дороже выходит. Производительность однопотока сильно не растет, а ядер много в один кристалл не засунешь. Интел то уж знает. Вот и выбрала амд путь, который дал им победу.
                                                                0

                                                                Так же можно сказать, что Apple сознательно идёт на ухудшение производительности, чтобы телефоны не обжигали руки. А Intel сознательно не идёт печататься к TSMC, чтобы сохранить контроль над производством, потеряв сегодня в техпроцессе.
                                                                Но это их внутреннее дело, мы сравниваем не то, что компании могли бы выпустить в теории, а реальные продукты, которые можно сейчас купить.

                                                                  0
                                                                  А пока что можно посмотреть только новые ноутбучные процессоры.
                                                                  вообще-то, уже можно посмотреть и на апушки для компов, если что.
                                                                  но там такое, ядра объединили, а кеш урезали. В итоге то на то и вышло.
                                                                  Ну и новый зен будет представлен скоро, где так же ядра на чиплет увеличат до 8.
                                          0
                                          Процессор — далеко не единственное, что потребляет энергию в ноутбуке
                                          практически единственное. Процессор в ноутбуке жрет до 15/25/45/65 ватт в зависимости от класса ноутбука и утилизации, плюс дискретка в игровых, экран — пару ватт, wifi полтора-два, bluetooth еще меньше, а что еще может жрать? Ну, I/O а-ля thunderbolt, но обычно подключенный к монитору ноутбук еще и на зарядке. В итоге даже в ультрабуке процессор будет составлять порядка 2/3 от общего энергопотребления.
                                            +1
                                            Процессор в ноутбуке жрет до 15/25/45/65 ватт

                                            Он такие цифры жрёт только под нагрузкой, при которой автономная работа любых ноутбуков плачевная, батареи больше 100 Вт*ч практически никто не ставит.
                                            В спокойном режиме, в котором как раз все сравнивают автономность что ноутбуков, что телефонов-планшетов, мобильный процессор может потреблять от единиц до долей ватта.

                                              +4

                                              Как раз экран — самое прожорливое. Пару ватт он жрёт, если яркость выставлена на минимум, а при нормальной яркости и с диагональю 15.6" — больше 5 Вт так точно.


                                              Процессор тоже жрёт много, но только под нагрузкой. А постоянная нагрузка процессора — не самый частый сценарий использования ноутбука при работе от батареи. В среднем он потребляет пару Вт при обычной офисной работе.

                                              +1
                                              Процессор — далеко не единственное, что потребляет энергию в ноутбуке. Улучшение энергоэффективности может дать рост пиковой производительности в том же теплопакете, или снизить теплопакет при той же производительности, но кардинального повышения времени автономной работы ожидать не стоит.

                                              Не единственное, но, пожалуй, самое прожорливое (под нагрузкой).

                                              Понятно, что есть чипсет, что есть ОЗУ, что энергонезависимая память, но когда у меня начинает активно нагружаться процессор, компьютер начинает греться как печка, а процессорный вентилятор — выть. И оценка автономной работы падает раза в два-три.
                                                0

                                                А я зарезал TDP до 15W, и когда у меня начинает нагружаться процессор, то вентилятор только включается и начинает слегка шуршать. При этом разница в производительности по сравнению с TDP 35W незначительна. И если экран работает постоянно, то процессор в таком режиме — всего несколько секунд.


                                                Аналогично со смартфоном: высокая яркость экрана заметно быстрее высаживает батарею.

                                                  0
                                                  Ну, видимо зависит от профиля нагрузки. У меня на корпоративном ноуте постоянно либо браузер выжирает ЦПУ, либо корпоративные AV/DLP системы. Либо вместе.
                                                  0

                                                  Как я упоминал выше, автономную работу под нагрузкой никто не пытается замерять, потому что она у всех устройств сейчас не очень впечатляет.
                                                  Даже айфон можно заставить сесть за 2-3 часа, хорошо нагрузив.

                                              +1

                                              Эти графики как раз показывают, что процессоры достигли технологического предела в однопотоке. Для процессора Intel увеличение производительности на +14% обернулось ростом энергопотребления в 2.5 раза. Ну и сам тест, судя по всему, вообще не задействует векторые операции.

                                                +1
                                                А можно ещё для сравнения их же, но при сжатии видео в н265, режим- ультра, с полностью перелопачеными настройками, включая какие-нибудь таблицы квантизации, 5 проходов?
                                                или хотябы ффмпег с фильтрами: де-эхо, удаление тишины, фильтры высоких и низких частот?
                                                ПыСы Asus ROG Phone3 описание охлаждениявызывает уважение.
                                                  +2
                                                  но при сжатии видео в н265, режим- ультра, с полностью перелопачеными настройками, включая какие-нибудь таблицы квантизации, 5 проходов

                                                  Не будет такого, перегреется айфон за минуту другую да и уйдет тротлить(ну или видео в три секунды перекодировать :) ); когда тяжелые приложения дебажишь то летом прям видно когда начинает тротлить, резко яркость экрана падает для
                                                  охлаждения.
                                                  +2

                                                  Вот я чего не понимаю: а почему нельзя этот A13 разогнать в полтора раза, поставить нормальную систему охлаждения (пусть он даже будет вместо 1.5*4W жрать все 40W)? Будет процессор, который на 40% быстрее самого быстрого X86, если верить этому графику.


                                                  Почему бы не сделать так (хотя бы в тесте) и не хвастаться везде абсолютно самим быстрым процессором и закрыть спор раз и на всегда?

                                                    0

                                                    Потому что самому эпплу неинтересны такие пиписькомерки в отрыве от реальных устройств, они не продают эти чипы никому.
                                                    Реальные устройства с большим теплопакетом пока готовятся.

                                                      0
                                                      А кто сказал, что его можно разогнать? У процессоров есть технологические и микроархитектурные пределы, выше которых не прыгнешь. У всех процессоров они разные.
                                                        0
                                                        Почему бы АМД не разогнать свои процессоры не до 4,7 Ггц, а до 5Ггц, тогда имея уже выше производительность на ядро при равной частоте — они б вообще и в однопотоке больше очков вышибали? Но вот, не получается…
                                                          0

                                                          Греться будет слишком сильно. Но у АРМ с его в 10 раз меньшим потреблением таких проблем быть не должно.

                                                            0
                                                            Греться будет слишком сильно.
                                                            Так у АМД с сильно этим лучше, чем у интелов. Раза в полтора так. Просто банально не могут в проммасштабе, а не на отдельных камнях на машинах энтузиастов под каким-нибудь жидким азотом. И это у них чиплеты и поставленная на поток сортировка по качеству ядер, чтоб лучшие ставить в более дорогие процессоры.
                                                            Но у АРМ с его в 10 раз меньшим потреблением таких проблем быть не должно.
                                                            Там с разгоном частоты потребление растёт квадратично.
                                                            Итого два фактора, которые отвечают «почему нельзя разогнать».
                                                              +1
                                                              Там с разгоном частоты потребление растёт квадратично.

                                                              Квадратично относительно напряжения и линейно относительно частоты.
                                                              Если для +20% частоты придётся поднять напряжение с 0.8V до 1.5V, то потребление вырастет больше, чем в 4 раза.

                                                                0
                                                                А как ещё разогнать можно чип, если сейчас у них и так авторазгоны до частот считай максимальных у данного чипа работают лучше, чем вручную гнать? То есть частоту можно нарастить только поднимая жор проца…
                                                                  0
                                                                  Кстати, нашёл вот такой график для примера на просторах интернета:
                                                                  Для даунвольтнутого амд
                                                                  image
                                                                  image
                                                                0
                                                                Проблема не в нагреве. Банально нестабильно работают ядра на высоких частотах. В процессорах все намного сложнее, чем просто повысил частоты. Микроархитектура всегда играла важную роль, почему интел всегда имел частоты выше, но при этом за счет IPC амд могла быть быстрее. Так было во времена атлонов, так обстоит дело сейчас. АРМ я думаю точно так же упрется в пределы архитектуры конкретного процессора. Ну и тепловыделение конечно, куда без него. Вся энергоэффективность улетит в окно.
                                                                  +1

                                                                  У них наверняка и частотный потолок будет ниже. Он определяется огромным количеством вещей, от варианта техпроцесса (Haswell как пример) до межсоединений, которые могу оказаться просто не приспособлены к работе на высоких частотах.
                                                                  Не забывайте, что ARM только начали осваивать частоты, до этого они много лет были жестко оптимизированы под минимальное потребление.


                                                                  Ну и, как заметили ниже, тупой разгон — бесперспективен, к нему прибегают только когда ничего больше сделать нельзя. Вырвать +5% производительности ценой +30% жора.

                                                              +1

                                                              То есть вы утверждаете следующее: в intel и amd работают настолько бездарные инженеры, что их разработки можно вот так вот взять и обставить практически в 10 раз по энергоэффективности?
                                                              Звучит как-то сомнительно. Вот прямо максимально сомнительно.

                                                              0
                                                              Хватит тиражировать уже эту фигню про конскую разницу в энергоэффективности. Нет ее, иначе все давно бы сидели на ARMах и даже отсутствие обратной совместимости с x86 не омрачило бы выигрыш от десятикратного увеличения быстродействия за те же Ватты.
                                                              разница есть, не десятикратная конечно, но всё еще «конская». Просто ARM производители раньше осваивали преимущественно развивающийся мобильный/embedded рынок, и только сейчас, когда он насытился, начали пытаться заходить в те сегменты, где доминирует x86. Короче ---сейчас мы здесь---, вот это вот всё
                                                              Тем более, что при такой разнице быстродействия программная эмуляция была бы сопоставима по скорости с «родными» процессорами.
                                                              эмулировать x86 мешают в первую очередь патенты intel
                                                                +2
                                                                Уже не раз сказано, что внутри и армов и интелов находятся вычислительные ядра, которые выполняют «нативный» код через транслятор инструкций. То есть, другими словами, быстрых процессоров, которые исполняют код «голым» ядром уже нет. Везде примерно одинаковая эмуляция native instruction set.

                                                                И если внутри арма такое крутое ядро, то почему интел или амд не вкрутит его в свои камни и не получит [почти] такую же эффективность? Вот сугубо с теоретической точки зрения, а?
                                                                  0
                                                                  И если внутри арма такое крутое ядро, то почему интел или амд не вкрутит его в свои камни и не получит [почти] такую же эффективность? Вот сугубо с теоретической точки зрения, а?
                                                                  хех, потому что интелу надо поддерживать кучу легаси инструкций, инструкции переменной длины и всякие AVX512 (а в ARM SVE только недавно появился), и всё это задизайнено по принципу «исторически так сложилось» и никак не накладывается на нормальную структуру? Ну это так, предположения. Хотя на самом деле достаточно причины «потому что на переправе коней не меняют».
                                                                    +2

                                                                    Декодеры инструкций занимают в процессоре жалкие проценты от площади кристалла.

                                                                    –1
                                                                    И если внутри арма такое крутое ядро, то почему интел или амд не вкрутит его в свои камни и не получит [почти] такую же эффективность? Вот сугубо с теоретической точки зрения, а?

                                                                    хороший вопрос.


                                                                    сначала хотел ответить: не нужно, производительность устраивает, а энергопотребление на десктопах и серверах не так важно.
                                                                    потом вспомнил про многоядерные серверные процессоры, которые снижают частоту под нагрузкой, то есть высокое потребление снижает производительность, таки оно важно (я уже молчу про проблемы с охлаждением и потреблением датацентров). да и ноутбучный рынок очень заметен, там экономичные процессоры очень важны.


                                                                    следующая мысль была: ничего из этого не получится, слишком они разные. но так уже в x86 инструкции разбирает/выполняет микрокод, «скрестить» его с исполняющими блоками arm, наверное, сложно, но возможно.


                                                                    последняя идея: intel за счёт использования идеологии чучхе получает сверхприбыли, проблем до недавнего времени у него не было, зачем ему было тратиться на лицензирование ядер arm? да и сейчас логичнее выйти из анабиоза и сделать своё ядро, благо ресурсы позволяют.


                                                                    P. S. согласен, что предположение «если у арма такое крутое ядро» может оказаться неверным, но пока всё выглядит так, будто у сегодняшнего arm существенно меньшее потребление при примерно той же производительности на поток.

                                                                      0
                                                                      У Intel вроде как есть лицензия на ARM, а получить в несколько раз более экономичный x86-процессор при той же мощности — это значит взорвать рынок мобильных платформ, миллиарды долларов заработать без капитальных вложений в разработку.
                                                                        +1
                                                                        То есть АМД несколько лет пилили свою архитектуру, кучу шагов по улучшению сделали, чтоб догнать и перегнать Интел, когда могли просто скрестить с великим армом и давно порвать интел, а потом ещё и мобильный сегмент?
                                                                  +17
                                                                  Вроде это хабр, а разжевывают как для школьников младших классов.
                                                                  x86(-64) давно CISC только снаружи, внутри же RISC, начиная примерно с Pentium Pro.
                                                                  С лицензированием какие проблемы? Купить AMD или VIA, денег у Apple вагон.
                                                                    0
                                                                    Это очень будет довольно тоскичная покупка. Ну и не покупают же компании, потому что денег — вагон.
                                                                      0
                                                                      Это было вот к этому.
                                                                      И если бы Intel лицензировал x86 за деньги другим людям, то вероятно Apple просто адаптировали свою текущую микроархитектуру под x86. Но так как они не могут этого сделать, они решили просто перейти на ARM.

                                                                      Если реально Apple требуется лицензия на x86 архитектуру, то можно было бы прикупить одного из трех обладателей. Видимо решили, что своя разработка принесет больше прибыли. Скоро увидим.
                                                                      0
                                                                      Элементы RISC архитектуры были уже в 486.
                                                                        0
                                                                        AMD почти $100 лярдов стоит, поздно покупать даже для эпла, надо было 5 лет назад покупать когда AMD было на грани банкротства.
                                                                          0
                                                                          Первые слухи о скором переходе на ARM были еще в 2016 году. Так что время было, желания не было.
                                                                        0
                                                                        А, есть вероятность, что на уровне микроархитектуры применяется MISC ядро?
                                                                        Как пример многоядерного-асинхронного MISC контроллера — GA144 (асинронное переключение ядер ~700МГц у данного кристалла с минимальным потреблением в работе)
                                                                          +7
                                                                          x86 процессоры используют сложный набор инструкций, который называется CISC — Complex Instruction Set Computing.

                                                                          ARM процессоры наоборот используют упрощенный набор инструкций — RISC — Reduced Instruction Set Computing.

                                                                          мгимо финишд, блин. и помимо этого в статье полно ляпов. мусор.

                                                                            +4
                                                                            Но так было раньше. На ассемблере уже давно никто не пишет. Сейчас за программистов всё это делают компиляторы, поэтому никаких сложностей с написанием кода под RISC-процессоры нет.

                                                                            Вообще-то, пишут. И иногда на CISC асемблере писать проще, чем на C. Посмотрите ядро Linux или более или менее быструю криптобиблитеку (OpenSSL, WolfSSL, Tempesta TLS). Простой пример: как сложить два 128-битных числа (каждое из которых по 2 long'а)? На C вам прийдется делать телодвижения с битом переноса, а на ассеблере у вас уже есть инструкция, которая в старшее 64-битное число добавит перенос со сложения прошлых 64-х битных чисел. Но, с другой стороны, те, кто упирается в бенчмарки, погемороятся с RISC ассемблером.


                                                                            Я не очень хорошо знаком с ARM, но интересует что у этой архитектуры с virtual APIC? На x86 без vAPIC сеть в виртуалке очень тормозит.


                                                                            Слышал от знакомых жалобу на другую проблему с APIC на каких-то ARM процессорах: на 8-и ядерном ARM (не знаю точно каком) нельзя было разбросать очереди прерываний с сетевой карты на разные ядра — все прерывания уходили на одно ядро. Как у современных ARM (которые по 128 потоков и выше умеют) дела с APIC?

                                                                              +1

                                                                              Саня, у Штеуда с APIC-ами исторически лучше было. Они это выстрадали, начиная с конца 90x и где-то до середины нулевых. У ARMов в среднем по больнице с этим плохо, но (буквально, скорее всего) если взять не "телефонный" ARM, а "серверный" (т.е. рассчитанный на виртуализацию), то всё будет принципиально лучше.


                                                                              Тем не менее, если есть зажать на прерывания, то всё равно тормозит (даже с "тремя" VAPIC) в сравнении с DPKD/Netmap/Seastar ;)

                                                                                0

                                                                                Привет!


                                                                                В среднем по больниц, понятно. Я мимоходом смотрел, например, на Marvell ThunderX2, которые до 256 потоков имеют, и как-то не понятно как там с APIC, а что с виртуализацией — тем более. Работал с ними или смотрел подробнее? У Xeon с vAPIC не очень — 4 машины (entry level) взяли и ни у одной не было vAPIC полного, чтобы KVM не воткнула на I/O.


                                                                                С сетью у нас интересная история. С packet forwarding/filtering на уровнях L2-L4 все понятно — логики мало и она относительно легко скейлится на ядра, DPDK и пр. kernel bypass рулят. У нас же HTTPS прокси и в perf top, как правило, HTTP parser, криптография, различная прикладня логика, например генерация cookie или javascript челленджей, матчинг HTTP заголовков опять же. Т.е. сетевых функций Linux networking мы не видим. Но при, этом без vAPIC в KVM и мы и Nginx "втыкаем" по полной и разница по произволительности 2 раза в лучшем случае.


                                                                                Кстати, я недавно писал про user-space TCP в приложении для HTTP. У Seastar реализация TCP фейковая (в смысле "fake it before you make it") — просто, чтобы поставить рекодные бенчмарки: очень мало кода и с кучей TODO. F-stack показывает хорошие результаты, но я проверил сделали ли они что-то с известной проблемой хеш таблицей TCP соединений (она же давно была описана CloudFlare), но и в ядре Linux, и FreeBSD, и F-stack реализация все та же и примерно с одним подходом.


                                                                                Итого, несмотря на отличные бенчмарки и безумное число ядер ARM, если у них нет хорошего APIC — с сетью, и думаю, с дисковым I/O тоже, все будет плохо. Нет поддержики виртуализации (в т.ч. virtual page talbe) — все плохо будет в облаках. И что останется? Числодробилки для ML?.. Возможно, и это ложится в карту NVIDIA.

                                                                                  0

                                                                                  Видимо я тебя не понял, ибо мне кажется что вы не просто бьётесь с мельницами, а сначала их шевелите и только потом бьётесь ;)


                                                                                  --


                                                                                  Приличный NIC позволит через MSI генерировать любые 2 прерывания для каждого dma-ring в зависимости от его наполнения (не пуст/заполнен больше половины и т. п.), для local APIC любого приличного процессора (с поддержкой PCI-E). Далее, приличный CPU (либо его серверный мост либо MSI-контроллер) позволит из обработчика прерывания прочитать битовую маску актуальных «взведенных» IRQ. Это примерно оптимальный режим обработки прерываний связкой «приличных» NIC+CPU.


                                                                                  При наличии гипервизора требуется чтобы он понимал «приличное железо» и умел с ним взаимодействовать (настраивать NIC и контроллер MSI) чтобы исключить какую-либо возню с IRQ-масками на пути от железа к гостевой системе. Соответственно https://www.linaro.org/blog/kvm-pciemsi-passthrough-armarm64/ и т.п.


                                                                                  --


                                                                                  Но в нагруженной системе старый-добрый NAPI (с приличными драйверами приличного NIC) должен быть не хуже (если не лучше) всей вышеописанной магии, главное чтобы dma-ring действительно пробрасывался (а не перекладывался) в гостевую систему. И вот тут мне на ум приходят упомянутые ветряные мельницы ;)

                                                                                    +1

                                                                                    Про ветярнные мельницы я не понял. Мы бьемся за быстрый HTTPS. Для нас "нагруженной системой" может быть, как массивный bare metal, так и однопроцессорная VM, которая тоже должна работать быстро. Для нас, как и большинства людей, не очень приемлемо молотить все доступные CPU на 100% даже при простое.


                                                                                    C теорией NAPI и сетевых прерываний я знаком, но за ссылку спасибо :) Вопросов все равно много остается: проборс VF с VM и SR-IOV — это один только из кейсов, а что будет с трафиком между двумя VM на одном хосте? Будет куча VM-EXIT и в perf kvm stat будут EXTERNAL_INTERRUPT.


                                                                                    Поживем, увидим как будут развиваться серверные ARM, но пока у них use cases очень ограничены.

                                                                                      0
                                                                                      Вопросов все равно много остается: проборс VF с VM и SR-IOV — это один только из кейсов, а что будет с трафиком между двумя VM на одном хосте? Будет куча VM-EXIT и в perf kvm stat будут EXTERNAL_INTERRUPT.

                                                                                      Трафик между двумя VM неплохо разруливал-бы 1Hippeus, но в 2014 его посчитали ненужным (включая массу простых и разумных предложений по всяким mailboxes для VM<->HV и VM<->VM, и т.п.).


                                                                                      Тем не менее, если без "бы", то для коммуникаций VM->VM все равно потребуется дешевый и безопасный (не ломающий гипервизор) wake из VM. Пока у меня нет сведений о каких-либо подвижках в железе для акселерации этих моментов (Штеуд погряз в spectre и тех-процессе, другие сюда пока не смотрят).


                                                                                      Соответственно, без такого wake придется дергать гипервизор, в лучшем случаи с учетом порогов/гистерезисов. Но пока (вроде-бы, не знаю) никто не считает это проблемой заслуживающей переделки кодовой базы (virtio и т.д.). Поэтому vSwitch (сам-по-себе он не плох) и разумные страданья за виртуализацию.


                                                                                      Т.е. мне более-менее понятно что и как следует делать (собственно могу), но не понятно кто и как все это организует/возглавит/оплатит. По ощущениям (имею право быть не правым) Штеуд скатывается в некукопожатные по темам касающимся API/BAPI и взаимодействия (ибо "решето"). MIPS — ищут куда продать куки (им не до концептов), ARM (вот на покупателя), RISCV (сильно разрозненно). Может быть у наших в МЦСТ дойдут руки, если их не отшибут "эффективные менеджеры" и давление диванных хейтеров.

                                                                              +2
                                                                              Главное отличие в длине команды: в ARM она фиксирована, а в x86 она разная.
                                                                                +2
                                                                                и это сильно усложняет архитектуру x86\x64.
                                                                                  0
                                                                                  Я думаю это усложняет разве что фронтэнд, который у современных процессоров ничтожную площадь кристалла занимает.
                                                                                  +4
                                                                                  Главное отличие в длине команды: в ARM она фиксирована, а в x86 она разная.
                                                                                  В результате операция add eax, 12345678h, не помещающаяся ни в два, ни в четыре байта опкода, на ARM превращается в целый квест)
                                                                                  +5
                                                                                  Так выглядит код одной и той же операции для x86 и ARM.
                                                                                  Заголовок спойлера
                                                                                  x86

                                                                                  • MOV AX, 15; AH = 00, AL = 0Fh
                                                                                  • AAA; AH = 01, AL = 05
                                                                                  • RET


                                                                                  ARM
                                                                                  • MOV R3, #10
                                                                                  • AND R2, R0, #0xF
                                                                                  • CMP R2, R3
                                                                                  • IT LT
                                                                                  • BLT elsebranch
                                                                                  • ADD R2. #6
                                                                                  • ADD R1. #1
                                                                                  • elsebranch:
                                                                                  • END


                                                                                  Что вообще хотел сказать автор в этом параграфе?..
                                                                                    +3

                                                                                    Видимо, что в ARM нет операций для Binary-Coded Decimal значений. И надо писать код. Имхо, жуткий формат, когда число кодируется в десятичной системе по 4 бита на десятичный разряд.

                                                                                      +5
                                                                                      Более того, этой команды уже нет в x86_64. Крайне натянутый пример, короче.
                                                                                        +1
                                                                                        Смотря для каких задач. Если надо потом вывести двухцифровое значение, например, на пару семисегментных индикаторов, которые подцеплены к GPIO через дешифраторы, то с такой кодировкой вывод делается по сути одной командой. Но да, вряд ли в применениях x86 (если не считать очень специфических) это очень полезно.
                                                                                          0
                                                                                          Ещё в 8080 была команда DAA команда для двоично-десятичной коррекции и её использовали для вывода чисел.
                                                                                            0
                                                                                            Да, у Z80 она так же называлась. В принципе допускаю, что и в сугубо компьютерных приложениях с ней могло было быть удобно преобразовывать небольшие числа в разряды для вывода на экран или каких-то расчётов, связанных именно с десятичными разрядами.
                                                                                            +2
                                                                                            Просто x86 как правопреемник 8080 унаследовал многие его команды. А во времена становления микропроцессоров было еще не до конца понятно, кто и как будет их использовать. Посмотрите на тот же Altair 8800, это же не компьютер даже, а скорее контроллер, размером с чемодан, но контроллер. А контроллеру подобные команды действительно полезны для простой связи с внешним миром.
                                                                                            0
                                                                                            Имхо, жуткий формат, когда число кодируется в десятичной системе по 4 бита на десятичный разряд.
                                                                                            Вот для конвертаций числа <-> строки, которые прикладной софт делает постоянно, такой формат очень удобен. И инструкции преобразования bcd<->binary тут бы помогли.
                                                                                              +1

                                                                                              Команды типа AAA, DAA… — не помогли бы. Эти команды хороши только для варианта операций непосредственно с десятичными числами в BCD без преобразования. И то, достаточно дёшево реализуются только сложения и вычитания. Умножение уже сложно, деление — кошмарик, дальше можно и не вспоминать.
                                                                                              Реально для сколь-нибудь сложных операций лучше сразу перевести в двоичное и работать в нём. Причём и для этого перевода не нужны BCD команды, умножения работают лучше.
                                                                                              Это касается и десятичной арифметики с плавающей точкой (финансовые расчёты): использовать десятичный порядок при основной двоичной арифметике проще и надёжнее.
                                                                                              Поэтому всякие DAA и выкинули наконец из x86-64, а в ARM и другие новые архитектуры даже не вводили. Кто их вынужден тянуть по легаси (как SystemZ), как-то дотягивают, но новый софт просят на них не делать.

                                                                                                0
                                                                                                Эти команды хороши только для варианта операций непосредственно с десятичными числами в BCD без преобразования
                                                                                                да это и не нужно. Профит может быть от самого преобразования bcd<->bin и именно для преобразования чисел в строки.

                                                                                                Если интересно подробнее
                                                                                                Обычно для преобразования числа в строку надо реализовать два метода — вычисление длины печатаемого числа и собственно заполнение строкового буфера этого размера. Вычисление размера еще как-то можно подхачить через clz и проверки против соответствующих степеней десятки, а вот заполнение сильно оптимальнее чем цикл с x % 10 не сделаешь (точнее, оптимальный вариант — x % 100 и таблица short'ов), а idiv очень противная операция.

                                                                                                В то же время вычислить длину и распечатать bcd — тривиальная задача. Длина через clz без if'ов, печать — цикл со сдвигом на 4 бита.

                                                                                                Кстати, сконвертировать в bcd вручную векторизацией получается намного медленнее, я пробовал.
                                                                                                  +1
                                                                                                  Профит может быть от самого преобразования bcd<->bin и именно для преобразования чисел в строки.

                                                                                                  Вот вам поступило, например, число стандартного размера int32 (до 2 миллиардов с хвостом), как BCD операции помогут перевести его в десятичный формат? А если int64?


                                                                                                  На командах типа DAS этого не сделаешь. Нужно полноценную конверсию с делением.


                                                                                                  а idiv очень противная операция.

                                                                                                  Мнэээ… простите, какой idiv? Компиляторы уже много лет заменяют деление на константу на обратное умножение. Вот я сходил на godbolt — скопирую результаты:


                                                                                                  unsigned d100(unsigned num) {
                                                                                                      return num / 100;
                                                                                                  }

                                                                                                  d100(unsigned int):
                                                                                                          mov     eax, edi
                                                                                                          imul    rax, rax, 1374389535
                                                                                                          shr     rax, 37
                                                                                                          ret

                                                                                                  Работает в разы быстрее (условно говоря, 3 такта вместо 70).


                                                                                                  В то же время вычислить длину и распечатать bcd — тривиальная задача. Длина через clz без if'ов, печать — цикл со сдвигом на 4 бита.

                                                                                                  Это понятно. Вопрос в другом: BCD резко теряет эффективность, когда вам надо сделать больше, условно, 3 арифметических операций с числами. От этого уровня выгоднее потратиться на преобразование в двоичное представление, операции в нём и обратную конвертацию.
                                                                                                  А где все операции короче такого? Это калькулятор и Excel (который в базовой функциональности — калькулятор на таблице).


                                                                                                  Кстати, сконвертировать в bcd вручную векторизацией получается намного медленнее, я пробовал.

                                                                                                  Медленнее чего? Надо сравнивать не с другой конвертацией, а полный цикл конвертации, вычислений и обратной конвертации.

                                                                                                    0
                                                                                                    Вот вам поступило, например, число стандартного размера int32 (до 2 миллиардов с хвостом), как BCD операции помогут перевести его в десятичный формат? А если int64?
                                                                                                    удвоением ширины регистра? На худой конец для больших чисел можно разбивать число на 2, всё равно быстрее, особенно учитывая что печатаются чаще маленькие числа
                                                                                                    Работает в разы быстрее (условно говоря, 3 такта вместо 70).
                                                                                                    скорее 5 против 42, но да, эту особенность я забыл.
                                                                                                    Это понятно. Вопрос в другом: BCD резко теряет эффективность, когда вам надо сделать больше, условно, 3 арифметических операций с числами. От этого уровня выгоднее потратиться на преобразование в двоичное представление, операции в нём и обратную конвертацию.
                                                                                                    так никто и не говорит об арифметических операциях в bcd формате, боже упаси. Только конвертация в строки и обратно.
                                                                                                    Медленнее чего? Надо сравнивать не с другой конвертацией, а полный цикл конвертации, вычислений и обратной конвертации.
                                                                                                    медленнее описанной мной выше референсной реализации.
                                                                                                      0
                                                                                                      удвоением ширины регистра?

                                                                                                      Так и в 32 битах таких операций нет. Ну, в x86.
                                                                                                      Вот в System/Z есть как наследие S/360. Но — не рекомендуется.


                                                                                                      так никто и не говорит об арифметических операциях в bcd формате, боже упаси. Только конвертация в строки и обратно.

                                                                                                      Которая всё-таки неплохо делается двоичными операциями — лучше, чем если бы реализовывалась в BCD.


                                                                                                      медленнее описанной мной выше референсной реализации.

                                                                                                      Ну, по-моему, там вообще в рамках одного конвертируемого числа векторизовать тупо нечего. Поэтому неудивительно.

                                                                                                        –1
                                                                                                        Так и в 32 битах таких операций нет. Ну, в x86.
                                                                                                        в смысле мы всегда можем положить число в регистр вдвое шире а потом преобразовать, и с переполнением никогда не столкнемся.
                                                                                                        Которая всё-таки неплохо делается двоичными операциями — лучше, чем если бы реализовывалась в BCD.
                                                                                                        да точно не лучше. Вот смотрите, есть у вас какое-нибудь число а-ля 119. Если преобразовать его в bcd, будет 0x119. Для перекладывания в строку внутри цикла достаточно and 0xf, add '0', shr 4, трех однотактовых операций. В бинарном варианте — полюбуйтесь сами, на методы count_digits и format_decimal_result, еще можно глянуть в листинг лукап табличек.
                                                                                                        Ну, по-моему, там вообще в рамках одного конвертируемого числа векторизовать тупо нечего. Поэтому неудивительно.
                                                                                                        попытайтесь реализовать и оптимизировать конвертацию в bcd-формат, сразу найдете простор для векторизации
                                                                                                          +2
                                                                                                          Если преобразовать его в bcd, будет 0x119. Для перекладывания в строку внутри цикла достаточно and 0xf, add '0', shr 4, трех однотактовых операций. В

                                                                                                          Я про арифметику говорил, а не про текстовую конвертацию.
                                                                                                          Во сколько раз на BCD дороже хотя бы сложение, вычитание, умножение, деление? Даже с аппаратной поддержкой?
                                                                                                          А если перейти к плавучке?


                                                                                                          полюбуйтесь сами,

                                                                                                          Полюбовался. Ничего фантастического. Деление и умножение в цикле с некоторым ускорением.


                                                                                                          попытайтесь реализовать и оптимизировать конвертацию в bcd-формат, сразу найдете простор для векторизации

                                                                                                          Для целых фиксированного размера, типа int32 — не окупится, разгон дороже. Для более длинных — нереально.

                                                                                                            0
                                                                                                            Я про арифметику говорил, а не про текстовую конвертацию.
                                                                                                            А зачем вы вообще говорите про арифметику? Я с самого начала треда, уже три раза как, написал что нужна именно сама конвертация, а не bcd арифметика
                                                                                                            Полюбовался. Ничего фантастического. Деление и умножение в цикле с некоторым ускорением.
                                                                                                            ну с таким же успехом можно сказать что криптография без аппаратного ускорения тоже «умножение да сдвиги в цикле с некоторым ускорением». И всякая архивация/декодинг. Вот одну конкретную инструкцию преобразования bin->bcd могли бы и добавить/оставить.
                                                                                                              +1
                                                                                                              А зачем вы вообще говорите про арифметику?

                                                                                                              Затем, что конвертация это не главная цель, а трижды вспомогательная и занимает очень малую часть затрат в обычных задачах.
                                                                                                              И то, основные проблемы в конвертации плавучих чисел — которые этим не решатся.


                                                                                                              Вот одну конкретную инструкцию преобразования bin->bcd могли бы и добавить/оставить.

                                                                                                              Просто не нужно (на фоне прочих проблем).

                                                                                          +8

                                                                                          "Ну вы уже наверное знаете, что Современные iPad практически не уступают 15-дюймовым MacBook Pro с процессорами Core i7 и Core i9" – э… Не знаю такого. По просочившимся сведениям – мак мини на эппл силикон чуть слабее, чем на i3. Ждём более шустрых (и более горячих) армов.

                                                                                            0
                                                                                            Тут начинается task-oriented сравнение. И воспоминания о том, что ASIC может одну операцию (скажем, сжатие в JPEG, или вычисление каких-нибудь хешей) делать эффективнее GP CPU
                                                                                              0
                                                                                              По просочившимся сведениям – мак мини на эппл силикон чуть слабее, чем на i3
                                                                                              это не мак мини, это developer kit, и поставленный в него A12Z по сути чип из 2018-ого года, который сейчас выдает в geekbench 5 1100/4700 очков, столько же, сколько i3-10300. При том что энергопотребление i3 больше в 10 раз.

                                                                                              Емнип ранний бенчмарк дев кита запускали в режиме эмуляции x86 кода и еще тогда аналитики были очень оптимистичны.
                                                                                                0
                                                                                                Ну да. Я и говорю – будем ждать более шустрых и горячих армов.
                                                                                              +18
                                                                                              > Вы наверняка знаете, что мир процессоров разбит на два лагеря.
                                                                                              Сказал — как отрезал.
                                                                                              Хотя, в принципе, таки два:
                                                                                              — Цифровые vs аналоговые
                                                                                              — Скалярные vs векторные
                                                                                              — фон Нейман vs Гарвард
                                                                                              — CISC/RISC/MISC/VLIW… ой, тут четыре, не считается.
                                                                                              А так ровно два, да.
                                                                                                0
                                                                                                Какая доля у MISC/VLIW на консьюмерском рынке?
                                                                                                +4
                                                                                                «Ну вы уже наверное знаете, что Современные iPad практически не уступают 15-дюймовым MacBook Pro с процессорами Core i7 и Core i9» Ну если вы используете компьютер только для запуска тестов то да, во всех остальных случаях это не так.
                                                                                                Грубо говоря это можно пояснить на примере с кодами операций.
                                                                                                Одна и та же команда на x86 выполняется за 3 шага, а на ARM за 9, а ещё есть SIMD инструкции где ситуация ещё более грустная.
                                                                                                Да и ответ намного проще, потому что по сути CISC процессоров сейчас нет, все современные CISC процессоры имеют RISC ядро.
                                                                                                  +1
                                                                                                  Одна и та же команда на x86 выполняется за 3 шага, а на ARM за 9, а ещё есть SIMD инструкции где ситуация ещё более грустная.

                                                                                                  Какая команда? Какие шаги?
                                                                                                  А что с SIMD инструкциями? Слышали про Neon, SVE?
                                                                                                  Современные CISC процессоры имеют как раз таки более «CISC-овое» ядро чем старые (K6/Pentium Pro)
                                                                                                    +2
                                                                                                    Какая команда? Какие шаги?

                                                                                                    Команда AAA из статьи, хотя сравнение не всовсем правильное, но оно отображает главную идею, потому что на самом деле команда AAA на x86 выполняется больше чем за 1 такт, например на Pentium это 3 такта.
                                                                                                    А что с SIMD инструкциями? Слышали про Neon, SVE?

                                                                                                    Это конечно хорошо что они развивают это направление и Helium показывает что они развивают это направление, но если сравнивать то AVX конечно даёт намного больше возможностей.
                                                                                                    Современные CISC процессоры имеют как раз таки более «CISC-овое»

                                                                                                    Не соглашусь, если посмотреть на современные микроархитектуры то видно что они продолжают развивать идею «RISC under the hood», т.е. так-же разбивают µOP до простых команд для EU.
                                                                                                    ps: Я вообще не очень хотел писать коментарий к этой статье, потому что там так много ерунды что чтобы объяснить это более-менее нормально надо написать коментарий раза в 2-3 больше этой статьи :)
                                                                                                  –5
                                                                                                  А что с расходом памяти? ARM прожорливее i386?
                                                                                                    +14
                                                                                                    Процессоры не жрут память, они с ней работают
                                                                                                      –1
                                                                                                      Да, и требуют выравнивания данных в этой самой памяти. x86 исторически жрёт невыровненные адреса (наследство 8088). А вот если говорить про арм — то данные должны быть выровнены на 8 байт минимум. Если вы полезете в память по невыровненному адресу, процессор кинет аппаратное исключение и пошлёт вас чинить компилятор. Впрочем, на большинстве реальных арм-камней стоит аппаратный обработчик этого аппаратного исключения, но он не всесилен — в отличие от х86 не может обработать ситуацию на границе страниц ДРАМ (8кб).
                                                                                                      В реальности вам редко нужны 64-битные целые (указатели да, хотя оверкилл, но вас не спрашивают; double когда как; а вот именно целые скорее всего нет, обычно хватает 32-битного int или вообще char/bool). Но компилятор по умолчанию всё равно выделяет им по 8 байт, чтобы не нарваться на исключение. Так что технически одна и та же программа под армом может жрать больше памяти, чем под х86. А разбор внешних упакованных структур (например IP-пакетов, форматов файлов и пр.) превращается в утомительное жонглирование байтами в регистрах. Хотя компилятор это спрячет «под капот», длина кода будет сильно выше.
                                                                                                        0

                                                                                                        Не знаю как в ARM, а вот в x86-64 есть фича — зануление верхних 32 бит 64-битного регистра при использовании 32-битных операндов. Это позволяет сократить место на хранение индексов.

                                                                                                          +1
                                                                                                          И создает WTF-эффект у неподготовленных системщиков, которые привыкли, что «mov AL, 0FFh» и «mov AX, 0FFFFh» никак не затрагивает старшую половину AX/EAX, а вот «mov EAX, 0FFFFFFFFh» почему-то обнуляют верхнюю половину RAX.
                                                                                                          +3
                                                                                                          А вот если говорить про арм — то данные должны быть выровнены на 8 байт минимум.

                                                                                                          компилятор C++ для x86 использует по-умолчанию 'natural alignment': выравнивание равно размеру данных. и гугл говорит, что на arm та же фигня. откуда инфа про 8 байтов?

                                                                                                            0
                                                                                                            На смежную тему: в многопроцессорных системах выделение переменным разных строк кэша (т.е. выравнивание на >64 байта) может ускорять программу, предотвращая cache eviction при работе разных процессоров с соседними переменными.
                                                                                                              +1
                                                                                                              Ну а чего спорить то в эпоху онлайн компиляторов.
                                                                                                              Возьмите godbolt и посмотрите, во что скомпилится следующая структура на С
                                                                                                              #include "stdio.h"
                                                                                                              struct Bad_Align
                                                                                                              {
                                                                                                              bool b;
                                                                                                              char c;
                                                                                                              short s;
                                                                                                              int i;
                                                                                                              float f;
                                                                                                              double d;
                                                                                                              void* p;
                                                                                                              }  ba;
                                                                                                              int main() {
                                                                                                              printf("%d",sizeof(ba));
                                                                                                              return 0;
                                                                                                              }
                                                                                                              

                                                                                                                +2

                                                                                                                тыц
                                                                                                                и в arm 32/64, и в интеле 32/64 размер структуры 32 байта. выравнивание полей, как я сказал выше — natural alignment.
                                                                                                                сама структура выравнивается по размеру самого длинного типа в структуре.
                                                                                                                так откуда инфа про:


                                                                                                                данные должны быть выровнены на 8 байт минимум
                                                                                                                +1
                                                                                                                Разница в том, что на x86 не выровненное поле структуры просто читается или пишется с дополнительной задержкой, а на ARM само обращение к такому адресу бросает исключение.
                                                                                                                  0

                                                                                                                  и не только на arm. так что избегать невыровненных чтений на C — нормальная практика (а на более высокоуровневых языках, даже если работа с указателями доступна, её следует избегать)

                                                                                                                    0

                                                                                                                    SIMD-операции на x86 тоже раньше бросали исключения.

                                                                                                                +1

                                                                                                                Ну почему же, есть ещё вопрос плотности системы команд. Вот я приводил варианты компиляции одной и той же программы в одинаковых режимах под разные архитектуры. Можно заметить, x86-64 и ARM/64 вровень, но есть и сильно более прожорливые (MIPSʼам не повезло).
                                                                                                                Эту таблицу можно дополнить: я чуть более современный вариант той же программы проверил на gcc10 — 420K для x86-64 и 320K для RV64G (RISC-V 64-битный с разрешением "сжатых" команд — сразу сократило объём на четверть).

                                                                                                                +1
                                                                                                                А что с расходом памяти? ARM прожорливее i386?

                                                                                                                теоретически наоборот у АРМ есть компактные сеты инструкций Thumb которые должны помогать формировать более «насыщенный» код
                                                                                                                  0
                                                                                                                  Который все равно проигрывает по размеру коду x86\x64
                                                                                                                    +2
                                                                                                                    Это не так. х86-64 гораздо более рыхлый чем х86.

                                                                                                                    Aarch64 код не только плотнее, но и обычно требует меньше инструкций чем х86-64.
                                                                                                                      +3
                                                                                                                      х86-64 гораздо более рыхлый чем х86

                                                                                                                      131 / 126 ≈ 1.04

                                                                                                                      0
                                                                                                                      Я насчитал соотношение размеров 97/101/106/107 для AArch64/ARMv7A/i386/x86_64 соответственно.
                                                                                                                        0

                                                                                                                        у этого llvm исходный код одинаковый для всех процессоров?

                                                                                                                  0
                                                                                                                  Некстати вопрос из любопытства про декодеры инструкций тех же ARM или IA64:
                                                                                                                  с чем связан выбор тех или иных битов в инструкции для указания imm, SIB?
                                                                                                                  Например в arm thumb инструкция MOVT кодируется так:
                                                                                                                  11110 i 101100 imm4 0 imm3 Rd imm8
                                                                                                                  и imm побитово собирается потом в порядке imm4, i, imm3, imm8
                                                                                                                  Для IA64 вариативность ещё шире.
                                                                                                                  Какие особенности декодера инструкций (или чего-то ещё) это диктуют?
                                                                                                                  x86-64 конечно тоже завёз таких отдельных битов с префиксами Rex.XXX, но тут всё же дело в совместимости с x86.
                                                                                                                    0

                                                                                                                    IA64 это на самом деле Итаниум, там VLIW.


                                                                                                                    Если же говорить про IA32, то основной жупел случился из-за многократного "улучшения и расширения" набора команд с сохранением совместимости. Причем команды изначально были переменной длины, начиная с однобайтовых (что привело к неэффективному и запутанному использованию пространства кодов). Короче, думали не про декодер инструкций, а про совместимость и маркетинг.

                                                                                                                      +1
                                                                                                                      В системе команд ARM не было 16-битных иммедиейтов.
                                                                                                                      Вот операнд и распихали в доступные места согласно карте инструкций.
                                                                                                                      Если посмотреть чисто регистровые инструкции, например MLS,
                                                                                                                      видно, что в этих битах (imm4/imm3) находятся регистры Rn, Ra.

                                                                                                                      Стараются мух и котлеты опкод и регистры+данные держать отдельно, и не перемещать поля потому как таким образом их проще читать и мультиплексировать.
                                                                                                                      ALU команды с непосредственными операндами так же содержат поля imm вместо одного из регистров, но размер операнда ограничен по понятным причинам.

                                                                                                                      imm8 в младших битах это традиционное место хранения непосредственного операнда и в ARM режиме.
                                                                                                                      iitd-plos.github.io/col718/ref/arm-instructionset.pdf
                                                                                                                      См. 4-2 / 4-10 (Operand2)
                                                                                                                      +2
                                                                                                                      И если бы Intel лицензировал x86 за деньги другим людям, то вероятно Apple просто адаптировали свою текущую микроархитектуру под x86.

                                                                                                                      Эппл, купила компанию, которая разрабатывала PowerPC (силами именно этих разработчиков она сделала рывок и лучшие АРМ процы), вполне могла бы возобновить разработки, но зачем ей PowerPC или x86, если она уже по уши в разработке АРМ?
                                                                                                                        –2
                                                                                                                        Учитывая, что делать RISC'и в целом проще (грубо говоря, их может клепать слабоквалифицированный дядя Вася в сарае), есть большая вероятность, что будущие неизбежные заплатки «очень-серьёзная-уязвимость-минус-20-процентов-производительности» сведут на нет все текущие преимущества архитектуры.
                                                                                                                          +4
                                                                                                                          Мне кажется, что когда говорят про Apple, то это не про технологии, а про бабки. Когда говорят, что производительность телефонов/планшетов Apple на ARM почти не уступает производительности компьютеров Apple на Core i7/i9, то это всего лишь говорит об избыточной мощности архитекторы x86 для программного обеспечения, которое работает на оборудовании Apple.

                                                                                                                          Отсюда для бизнесменов из Apple следует достаточно очевидный вывод, сформулированный по результатам проведенного функционально-стоимостного анализа (ну или как там это сегодня называется), что в их продукцию можно легко впихнуть более дешевый процессор без потери потребительских свойств оборудования для конечного пользователя (то есть для фанатов Apple).

                                                                                                                          Вот только нужно предварительно провести маркетинговые мероприятия по раскрутке новой крутой архитекторы собственных процессоров, чтобы после снижения себестоимости фанаты продолжили бы покупать продукцию Apple по старой цене. В результате и фанаты довольны, и у Apple растет прибыль. Как говорится «ничего личного, это просто бизнес».
                                                                                                                            +3
                                                                                                                            Вот для примера некоторые «RISC» инструкции ARMv8:
                                                                                                                            UZP1 — Unzip vectors
                                                                                                                            TBL — Table vector Lookup
                                                                                                                            FRSQRTE — Floating-point Reciprocal Square Root Estimate
                                                                                                                            SHA512H — SHA512 Hash update part 1
                                                                                                                            AESD — AES single round decryption
                                                                                                                              –1
                                                                                                                              Зачем вы использовали кавычки?
                                                                                                                              По всем канонам это обычные RISC операции регистр-регистр.
                                                                                                                              Они элементарно реализуются в железе.
                                                                                                                              Более того, они имеются почти во всех RISC процессорах.
                                                                                                                              Большая часть это просто шафл/регистровый лукап.
                                                                                                                              Реализуется комбинаторным блоком.
                                                                                                                              FRSQRTE чуть посложнее, но это просто табличный лукап.

                                                                                                                              Забавно, что в ARM есть load-op инструкции, свойственные CISC, но вы не написали ни одну.
                                                                                                                                +3
                                                                                                                                Ну это тонкий момент что считать RISC, а что CISC. Если исходить из аббревиатуры, то у риска набор команд ограничен, поэтому всякие квадратные корни и хэши выглядят странно.
                                                                                                                                  –1
                                                                                                                                  Ну это тонкий момент что считать RISC, а что CISC.

                                                                                                                                  Есть вполне чёткие критерии RISC ISA.

                                                                                                                                  Если исходить из аббревиатуры, то у риска набор команд ограничен, поэтому всякие квадратные корни и хэши выглядят странно.

                                                                                                                                  Выглядит для вас странно, а на самом деле совершенно естественно.
                                                                                                                                  Разработчики RISC архитектур так же с вами совершенно не согласны.
                                                                                                                                  Вы запрещаете им добавлять новые команды в ISA? Так?

                                                                                                                                  Смысл RISC не в общем количестве команд, а в:
                                                                                                                                  1) Избегании лишних команд, которые не используются компиляторами или без которых можно обойтись.
                                                                                                                                  2) Разделении команд на вычислительные и команды для работы с памятью.
                                                                                                                                  3) Использовании простых команд, которые можно реализовать в «железе» вместо микрокода.

                                                                                                                                  Как я и написал, то что для вас кажется сложной командой, на самом деле простая.
                                                                                                                                  Вычисление корня или шафлы по-вашему должны на RISC процессорах тормозить?
                                                                                                                                    +2
                                                                                                                                    Есть вполне чёткие критерии RISC ISA.

                                                                                                                                    Для вас может есть. Но во всем остальном мире четких критериев, которых все придерживаются, нет. Тем более таких, чтобы в них хорошо помещался АРМ современный. Иначе бы этот спор, что RISC, а что нет, не существовал банально.

                                                                                                                                    Использовании простых команд, которые можно реализовать в «железе» вместо микрокода.

                                                                                                                                    Довольно странный критерий. Микрокод явно используют не потому что невозможно что-то в железе реализовать. Его использовать, потому что что-то выгоднее в железе делать, а что-то нет. При желании все можно было засунуть в железо. ARM нынче содержит инструкции вроде AES и CRC, которые явно не простые, но в железе, как и в x86. Это прямо противоречит RISC подходу и заимствование у CISC, когда в ISA добавляются инструкции, которые нужны реальным приложениям. Не всегда, но довольно часто. В противоречие первому пункту вашему, без них тоже можно было обойтись. Не говоря уже о всяких микроопсах, микроопс фьюзинге и прочих CISC трюках, призванных ускорить выполнение сложных инструкций.

                                                                                                                                    Вычисление корня или шафлы по-вашему должны на RISC процессорах тормозить?

                                                                                                                                    А зачем в ISA то, что может сделать код самостоятельно? Если мы придерживаемся RISC идеологии, то это все должен делать софт. Без инструкции можно обойтись? Можно. Но зачем-то даже в RISC-V похоже добавили это, хоть и в качестве расширения, а не части основного ISA. В арме так вообще стало обязательной частью, как и AES с CRC.
                                                                                                                                      0
                                                                                                                                      Тем более таких, чтобы в них хорошо помещался АРМ современный.

                                                                                                                                      ARM руководствуется принципами эффективности, а не архитектурной частоты.

                                                                                                                                      Иначе бы этот спор, что RISC, а что нет, не существовал банально.

                                                                                                                                      О чём спор? Вы показываете красный носок и говорите что он зелёный?
                                                                                                                                      Если вас пугают крипто-инструкции, то уж три первые вами упомянутые инструкции это 100% RISC инструкции без каких-либо сомнений.

                                                                                                                                      Что же делает SHA512H? Читает 3 регистра, выполняет некую операцию и записывает обратно в регистр. У неё нет ни состояния, ни чего либо ещё. Ничем не отличается от какого-нибудь FMAD, только проще. Т.е. умножение и сложение — RISC, а эта операция не RISC? Л — Логика.

                                                                                                                                      Что характерно, вы так и не осилили назвать CISC инструкции ARMv8, а они есть.

                                                                                                                                      А зачем в ISA то, что может сделать код самостоятельно?

                                                                                                                                      Ответ очень прост — производительность и объём кода.
                                                                                                                                      По-вашему получается и SIMD не нужен, ведь всё можно сделать на скалярном ALU :)

                                                                                                                                      Если мы придерживаемся RISC идеологии, то это все должен делать софт

                                                                                                                                      Это где такое написано? Сами выдумали?

                                                                                                                                      Это прямо противоречит RISC подходу и заимствование у CISC, когда в ISA добавляются инструкции, которые нужны реальным приложениям.

                                                                                                                                      То что вы говорите не имеет никакого смысла.
                                                                                                                                      RISC как раз про эффективность. И если реальные приложения могут получить выгоду от конкретных инструкции, они там просто обязаны быть.

                                                                                                                                      Не говоря уже о всяких микроопсах, микроопс фьюзинге и прочих CISC трюках, призванных ускорить выполнение сложных инструкций.

                                                                                                                                      Это не CISC трюки. Это микроархитектурные трюки. Нужно понимать разницу.
                                                                                                                                      Простой ADD со сдвигом может разбиваться на 2 инструкции на сложном ARM процессоре и выполнять за 1 такт на простейшем микроконтроллере.
                                                                                                                                      Не потому что инструкция какая-то CISC-овая. Просто она не успеет отработать на (целевой) высокой частоте из-за задержек.

                                                                                                                                      Но зачем-то даже в RISC-V похоже добавили это, хоть и в качестве расширения, а не части основного ISA.

                                                                                                                                      Потому что вы себе придумали какую-то альтернативную трактовку RISC и возмущаетесь тому что говорю я или тому что делают Дэвид Паттерсон и все остальные архитекторы MIPS. Power, ARM.

                                                                                                                                      Это базовые возможности для современных процессоров.
                                                                                                                                      Конкретно криптоакселератор я бы предпочёл иметь сопроцессором,
                                                                                                                                      но уж возмущаться SIMD и аппроксимации квадратного корня это странно, мягко говоря.
                                                                                                                              +2
                                                                                                                              Для того, чтобы ARM начал нормально отвоёвывать рынок серверов и рабочих станций, нужно разработать стандартную архитектуру компьютера, как это было сделано в компании IBM в свое время (IBM PC). Именно благодаря общепринятому стандарту мы сейчас имеем универсальную платформу и ПО. А пока этого нет, ARMу будет тяжко в этом сегменте.
                                                                                                                                +1
                                                                                                                                Школота, мля.
                                                                                                                                Школота здесь, школота там.

                                                                                                                                ARM и так импользует «стандартную архитектуру компьютера, как это было сделано в компании IBM в свое время (IBM PC)» — PCI-E, память DDR3-4 и т.д.

                                                                                                                                По статье:
                                                                                                                                Грамматика никакая.

                                                                                                                                Даже вы можете начать производить свои процессоры, купив лицензию. А вот производить процессоры на x86 не может никто кроме синей и красной компании.

                                                                                                                                — есть VIA и несколько СП с китайцами.

                                                                                                                                И если бы Intel лицензировал x86 за деньги другим людям, то вероятно Apple просто адаптировали свою текущую микроархитектуру под x86. Но так как они не могут этого сделать, они решили просто перейти на ARM. Проблема для нас с микроархитектурой в том, что она коммерческая тайна. И мы про нее ничего не знаем.

                                                                                                                                — защита x86 патентами кончилась по истечении сроков.

                                                                                                                                в мире x86 творится монополия

                                                                                                                                — такого никогда не было.
                                                                                                                                .
                                                                                                                                .
                                                                                                                                После покупки ARM Нвидией Яблоко может убежать на другие наборы команд.
                                                                                                                                  0
                                                                                                                                  защита x86 патентами кончилась по истечении сроков

                                                                                                                                  Но новые наборы инструкций и некоторые нюансы архитектуры новых процессоров таки защищены новыми патентами, что несколько осложняет создание актуального и, что важно, мало-мальски совместимого x86-64.
                                                                                                                                  Совместимость уровня того же четвертого пня уже почти никому не нужна.
                                                                                                                                  А развивать новую экосистему вокруг того же x86, только немного другого (а потому в некоторых вопросах несовместимого) — трудно будет обосновать потребителям, зачем им переходить туда из привычного x86-64 от AMD-Intel.


                                                                                                                                  | в мире x86 творится монополия
                                                                                                                                  — такого никогда не было.

                                                                                                                                  По крайней мере когда появился первый 8086 — была абсолютная монополия — 100%, хотя и недолго. :)
                                                                                                                                  Впрочем, Intel вроде достаточно долго держал больше половины рынка x86, что вроде как достаточно, чтобы считать его монополией.

                                                                                                                                    0
                                                                                                                                    Но новые наборы инструкций и некоторые нюансы архитектуры новых процессоров таки защищены новыми патентами

                                                                                                                                    Если вы помните как Интел топил за Итаниниум, то должны помнить и то, что Интел заявляла, что не будет 64 бит x86. Поэтому теперь Интел лицензирует 64битное расширение комманд у АМД. И по сути оно amd64, а не x86-64. А уже помимо этого существуют всякие sse и прочее. Просто напишите, какой сет вы считате необходимым и его нельзя лицензировать.
                                                                                                                                      0

                                                                                                                                      Насколько я наслышан, Intel и AMD сильно повязаны этой архитектурой (не может AMD без технологий Intel, а с некоторых пор и Intel без технологий AMD) и антимонопольным законодательством (не может Intel без AMD), а потому достаточно свободно лицензируют друг другу всякие технологии.
                                                                                                                                      Тем, кто вне этой пары, вроде все уже не так просто, судя по некоторым косвенным данным.


                                                                                                                                      И по сути оно amd64, а не x86-64

                                                                                                                                      И как её только не обзывали, эту архитектуру.

                                                                                                                                      0
                                                                                                                                      В 2015г. AMD лицензировала китайцам ядро Ryzen первого поколения; но понятное дело, китайцы не могут получать последующие разработки AMD для актуализации своего микропроцессора, и тот идет теперь своим китайским путем.
                                                                                                                                      А когда-то кто только х86-микропроцессоры не выпускал: Texas Instrumentis, Cyrix, UMC, IBM, NexGen, Transmeta (Crusoe), IDT (WinChip), Rise Technology (mP6), Chips&Technologies и др.
                                                                                                                                    0
                                                                                                                                    Я думаю имелись ввиду обычные рабочие станции. Грубо говоря, чтобы по «arm pc buy» можно было сразу купить себе компьютер и начать на нем разрабатывать.
                                                                                                                                    Raspberry pi и аналоги не могут быть заменой нормальному пк.
                                                                                                                                    0
                                                                                                                                    С ARM процессорами в своё время была интересная путаница в процессорах. Особенно когда не указывали тип процессора. И получалось, что один и тот-же «процессор 1GHz» мог выдавать разную производительность. А покупателю оставалось удивляться, что его телефон или планшет тормозят. А получалось это из-за того, что в процессоре, к примеру, небыло инструкций сопроцессора, и команду, которую другой процессор мог выполнить за один такт — этот выполнял за три.
                                                                                                                                      +6
                                                                                                                                      «RISC» и «CISC» — чистейший маркетинг. Ну, может быть эти слова и имели какой-то технический смысл лет 40 назад, когда процессор А умел только плюсовать, но не умел умножать, а процессор B умел и плюсовать и умножать, но тратил на это 100 тактов. Сейчас же все процессоры выполняют одни и те же операции, имеют на борту математические и векторные сопроцессоры, всякое шифрование и выполняют суммарно по сотне умножений за такт. Никакого риск и циск уже сто лет не существует. BTW, «трансляция команд х86», про которую орут из каждого утюга — такой же бред. ЛЮБОЙ сколько-нибудь серьёзный цпу использует микрокод и микрооперации! х86 даже не первый! Существенная разница в системах команд между арм и х86 в том, что х86 умеет адресовать память из любой команды, а арм — использует RMW-подход, зато имеет 13 регистров вместо 7. И это в принципе неплохо. Но главное — х86 имеет сложную систему кодирования команд переменной длины, а арм обходится 2 или 4-байтовыми командами. Как по мне, эта фиксированная длина команды — полнейшее говнище. Несколько упрощая реализацию процессора, она превращает код в полнейшее месиво. Простая загрузка константы в регистр или считывание значения по imm-адресу разворачивается в целую простыню мусора. Все эти таблицы констант, пихаемые между функциями — вот настоящие костыли. «Эффективному RISC» приходится по 2 раза лезть в память, сперва считывать команду, затем доставать константу из таблицы для простейшего mov reg,imm32! Но зато всякие NOP и прочие операции на одном регистре или вообще без аргументов занимают целое слово… И россказни про сложный декодер х86 команд совершенно несостоятельны. Кэши занимают половину кристалла, ещё львиную долю исполнительные блоки, декодеры же команд с лупой искать надо…
                                                                                                                                        0
                                                                                                                                        В целом всё верно, но на декодере заостряют внимание потому, что он должен поставить комманды во все конвееры для спекулятивных вычислений, так что он должен работать гораздо быстрей чем цепочка реально исполняемых комманд. И вот тут начинаются проблемы, потому что он по тем же топонормам делается и работает, и что бы он был не «такой как все», желательно бы его попроще или сделать специальные телодвижения, которы бы позволяли выбирать последующие комманды когда ещё текущие не декодированны. Эту проблему как раз решает фиксированная длинна комманды.
                                                                                                                                          +1
                                                                                                                                          Как видно, вполне себе справляется. Более того, поспевает даже в случае SMT, когда, по идее, темпы фетчинга команд еще выше. Ходят слухи, что АМД и SMT4 может добавить.
                                                                                                                                            0
                                                                                                                                            Эту проблему как раз решает фиксированная длинна комманды.

                                                                                                                                            У x86 бо́льшая проблема этого декодера не в переменной длине, а в количестве промежуточных шагов, которые необходимы, чтобы определить реальную длину.
                                                                                                                                            Выбрали первый байт. Декодировали. Нашли префикс. Идём к следующему байту. Однобайтный код операции, OK. Узнали, что за ним идёт mod-reg-r/m, который надо декодировать для получения аргументов. Выбрали. Декодировали. Узнали, что за ним идёт SIB, который надо разобрать. Выбрали. Декодировали… Да, это параллелится. Но дорого — на каждый шаблон свой детектор на несколько байт. Не зря говорят "выравнивайте точки перехода на 16 байт", потому что запускать весь декодер с любой позиции — дорого… делают, конечно, но медленнее.


                                                                                                                                            Теперь сравним с System/Z. Выбрали два первых байта, в них есть два бита в конкретном месте: 00 — 2 байта длины, 01 и 10 — 4, 11 — 6. Декодер проще на пару порядков, не надо уметь быстро разбирать очень сложные конструкции.
                                                                                                                                            То же для RISC-V, но там префикс длины с бо́льшим количеством вариантов (считаем, почти любым), и тоже декодировать легко и просто.

                                                                                                                                              +1

                                                                                                                                              я думаю, что если бы это заметно влияло на производительность, то уже давно бы сделали альтернативные машинные коды для тех же самых ассмеблерных инструкций.

                                                                                                                                                0
                                                                                                                                                то уже давно бы сделали альтернативные машинные коды для тех же самых ассмеблерных инструкций.

                                                                                                                                                Дублирующие коды для всех основных команд?
                                                                                                                                                Если просто дублирование, то сразу каша — какие лучше и почему, при том, что уже наработаны гигабайты скомпилированного кода, который вряд ли будут менять: старый код надо продолжать поддерживать. То есть это будет уже два декодера, суммарная сложность только вырастет за счёт таки используемого старого варианта.


                                                                                                                                                Полная перестройка при смене разрядности?
                                                                                                                                                Вот тут — надо учитывать историю.
                                                                                                                                                Выпустив 8086, пытаются опередить весь мир, сделав iAPX432. Не взлетает. В режиме судорожной затычки выпускают 286. Плохо взлетает, выпускают 386. Это уже на что-то нормальное похоже, но сделано в условиях, когда весь пар ушёл в свисток и надо запускаться на оставшихся копейках. Времени и сил на перекраивать нет, делают просто пришлёпки к имеющемуся. Только запустившись, оно обрастает легасями и менять уже нельзя — никто не пойдёт опять переписывать весь код.
                                                                                                                                                Проходит 15-17 лет. Ресурсы есть, запускается очередная пирамида Хеопса — IA-64 ("ну, теперь точно весь мир взуем"), и затычка Pentium4. Не взлетает. Пока ожидают у моря погоды, нищий AMD в состоянии исторического минимума проектирует 64-битку, опять ничего не перекраивая, а только делая чуть нашлёпок. Взлетает, тут же создавая легаси. Intel барахтается ещё пару лет и заимствует полученное. И опять перекраивать нормально уже некогда, успели наработать много готового кода.


                                                                                                                                                Это не только в формате команд. Вот, например, 32-битные операции над регистрами в 64-битном режиме чистят старшие половины. А 8- и 16-битные операции — не чистят. А почему? И снова легаси — они уже не чистят биты 31...16, значит зависимость по данным сохраняется, зачем тогда чистить 63...32?
                                                                                                                                                Воображаю, какими словами Intel сейчас клянёт разработчиков i386 и IA-64, но "был бы я таким умным, как моя жена завтра"...


                                                                                                                                                А ARM при переходе к 64 битам выбросил старые неадекватные заморочки и такой проблемой не страдает. Штош, они оказались умнее строителей пирамид.

                                                                                                                                                  0
                                                                                                                                                  Дублирующие коды для всех основных команд?

                                                                                                                                                  что-то вроде thumb в arm (вернее, anti-thumb, пожалуй, за компактностью гнаться не надо). некий режим процессора, в котором те же самые мнемоники кодируются иначе — логично, удобно для декодера.


                                                                                                                                                  давай оно хоть пару процентов производительности — код для него быстро появился бы, благо в gcc/llvm приделать вообще ничего не стоит.


                                                                                                                                                  но я думаю, что выигрыша бы не было. могу ошибаться.


                                                                                                                                                  Если просто дублирование, то сразу каша — какие лучше и почему, при том, что уже наработаны гигабайты скомпилированного кода, который вряд ли будут менять: старый код надо продолжать поддерживать

                                                                                                                                                  ну arm как-то живёт с несколькими системами команд


                                                                                                                                                  То есть это будет уже два декодера, суммарная сложность только вырастет за счёт таки используемого старого варианта.

                                                                                                                                                  так вы говорите, что новый декодер может оказаться заметно проще (и притом производительнее). x64 приделали, 100500 вариантов simd приделали, а ещё один простой декодер не приделают?


                                                                                                                                                  Вот, например, 32-битные операции над регистрами в 64-битном режиме чистят старшие половины. А 8- и 16-битные операции — не чистят.

                                                                                                                                                  это уже все кодогенераторы умеют и на скорость не влияет.

                                                                                                                                                0
                                                                                                                                                Выбрали первый байт. Декодировали. Нашли префикс

                                                                                                                                                Так это прямое следствие лапшекода вместо ISA, тут ничего не попишешь, оно с рождения такое.
                                                                                                                                                Был момент, когда можно было это исправить…