Как стать автором
Обновить

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

НЛО прилетело и опубликовало эту надпись здесь
Mips и Power — это тоже Risc.
Что ничего особо не значит. Внутри все эти процессоры кардинально разные. RISC давно уже ничего не значащая аббревиатура, как и противостояние CISC и RISC, когда и те и другие разбивают инструкции на микрооперации.
Вообще, разница между современными RISC и CISC есть, но она совсем не там, где её видит автор статьи (и чему он, к сожалению, посвятил половину этой самой статьи). От всего того противостояния архитектур сейчас выжил всего лишь один признак: RISC-процессоры имеют в своём наборе команд отдельно команды для пересылки данных между памятью и регистрами, и отдельно команды для операций над данными в регистрах. Команды CISC-процессоров же в своих операндах могут произвольно использовать как регистры, так и непосредственно адреса в памяти. Вот, собственно, и всё. Архитектурно же внутри и RISC, и CISC сейчас устроены схожим образом.
НЛО прилетело и опубликовало эту надпись здесь
Ну, есть, на самом деле, на низком уровне. Не конская, но есть. Просто для пользователя x86 ускоряют разными хаками, и ему кажется, что в общем-то, разницы особой нет. Но потом из-за этих хаков всякие интересные уязвимости появляются.
НЛО прилетело и опубликовало эту надпись здесь
Ну, так превращать одни команды в другие все равно надо.
НЛО прилетело и опубликовало эту надпись здесь

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

НЛО прилетело и опубликовало эту надпись здесь

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


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

Later, Intel included μop caches in its Sandy Bridge processors and in successive microarchitectures like Ivy Bridge and Haswell.[31]:121–123[35] AMD implemented a μop cache in their Zen microarchitecture.[36]

Fetching complete pre-decoded instructions eliminates the need to repeatedly decode variable length complex instructions into simpler fixed-length micro-operations, and simplifies the process of predicting, fetching, rotating and aligning fetched instructions. A μop cache effectively offloads the fetch and decode hardware, thus decreasing power consumption and improving the frontend supply of decoded micro-operations. The μop cache also increases performance by more consistently delivering decoded micro-operations to the backend and eliminating various bottlenecks in the CPU's fetch and decode logic.[34][35]

A μop cache has many similarities with a trace cache, although a μop cache is much simpler thus providing better power efficiency; this makes it better suited for implementations on battery-powered devices. The main disadvantage of the trace cache, leading to its power inefficiency, is the hardware complexity required for its heuristic deciding on caching and reusing dynamically created instruction traces.[37]

Насколько я понимаю, официальных утверждений как минимум от Intel про этот кэш нет; информацию находят косвенно и не совсем гарантированно по измерениям скорости, по патентам и т.п.? У всех этих упоминаний нет дальнейших ссылок.
Вообще спасибо, пропустил это — как-то последние годы была привычка больше смотреть в оф. доки, чем на всякие wikichip, после того, как в последних не находилось ответов на вопросы. (В оф. доке — тоже, но она как-то легче вспоминалась.)

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

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

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

Что-то схожее с ПЛМ там есть. В более новых версиях биоса встречались блобы, распаковывающие патчи микроопераций.
Значит, надо результаты ЛЮБОЙ спекулятивной операции устранять (чистить кэш). Туда ходить было нельзя, значит и кэшировать результаты выполнения любых действий над запрещённой областью тоже нельзя!
Но этого не делается, и вот она — уязвимость.

Мне очень интересно, как бы вы это реализовали с учётом того, что каждая выполняемая операция выполняется спекулятивно. Писать в кэши и в TLB только при retirement? Т.е. пять идущих подряд обращений к одной кэш-строке — будут все пять читаться мимо кэша?

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


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

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

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

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


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

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

НЛО прилетело и опубликовало эту надпись здесь

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


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

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


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

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

Давайте обойдёмся без истерик, а лучше обратимся к объективным данным
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.
НЛО прилетело и опубликовало эту надпись здесь
Где ноутбуки, работающие по многу суток при сопоставимой с i7 производительности?

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


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

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


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

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


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

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

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

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

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

НЛО прилетело и опубликовало эту надпись здесь

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

НЛО прилетело и опубликовало эту надпись здесь

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

НЛО прилетело и опубликовало эту надпись здесь

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


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

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

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

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

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

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

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

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

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

Вы же сами строчкой выше и ответили — слабые были процессоры.
Изменилось это буквально в последние 2-3 года.
НЛО прилетело и опубликовало эту надпись здесь
Извините, но поиск на хабре работает.

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


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

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

НЛО прилетело и опубликовало эту надпись здесь
И пока по тестам того, что есть — это где-то 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 раза.


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

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

НЛО прилетело и опубликовало эту надпись здесь
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.

НЛО прилетело и опубликовало эту надпись здесь
Вот за счёт более дорогого техпроцесса ЭПЛ может что и сделает, только кто сказал, что те же АМД на 5 нм не окажутся сильно лучше?

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


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

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

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

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

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

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

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

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


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

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

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

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

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


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

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

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

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

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

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


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

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

А кто сказал, что его можно разогнать? У процессоров есть технологические и микроархитектурные пределы, выше которых не прыгнешь. У всех процессоров они разные.
НЛО прилетело и опубликовало эту надпись здесь

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

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

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

НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Проблема не в нагреве. Банально нестабильно работают ядра на высоких частотах. В процессорах все намного сложнее, чем просто повысил частоты. Микроархитектура всегда играла важную роль, почему интел всегда имел частоты выше, но при этом за счет IPC амд могла быть быстрее. Так было во времена атлонов, так обстоит дело сейчас. АРМ я думаю точно так же упрется в пределы архитектуры конкретного процессора. Ну и тепловыделение конечно, куда без него. Вся энергоэффективность улетит в окно.

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


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

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

Хватит тиражировать уже эту фигню про конскую разницу в энергоэффективности. Нет ее, иначе все давно бы сидели на ARMах и даже отсутствие обратной совместимости с x86 не омрачило бы выигрыш от десятикратного увеличения быстродействия за те же Ватты.
разница есть, не десятикратная конечно, но всё еще «конская». Просто ARM производители раньше осваивали преимущественно развивающийся мобильный/embedded рынок, и только сейчас, когда он насытился, начали пытаться заходить в те сегменты, где доминирует x86. Короче ---сейчас мы здесь---, вот это вот всё
Тем более, что при такой разнице быстродействия программная эмуляция была бы сопоставима по скорости с «родными» процессорами.
эмулировать x86 мешают в первую очередь патенты intel
НЛО прилетело и опубликовало эту надпись здесь
И если внутри арма такое крутое ядро, то почему интел или амд не вкрутит его в свои камни и не получит [почти] такую же эффективность? Вот сугубо с теоретической точки зрения, а?
хех, потому что интелу надо поддерживать кучу легаси инструкций, инструкции переменной длины и всякие AVX512 (а в ARM SVE только недавно появился), и всё это задизайнено по принципу «исторически так сложилось» и никак не накладывается на нормальную структуру? Ну это так, предположения. Хотя на самом деле достаточно причины «потому что на переправе коней не меняют».

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

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

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


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


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


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


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

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

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

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

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

Но так было раньше. На ассемблере уже давно никто не пишет. Сейчас за программистов всё это делают компиляторы, поэтому никаких сложностей с написанием кода под 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?

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


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

Привет!


В среднем по больниц, понятно. Я мимоходом смотрел, например, на 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.

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


--


Приличный 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 действительно пробрасывался (а не перекладывался) в гостевую систему. И вот тут мне на ум приходят упомянутые ветряные мельницы ;)

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


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


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

Вопросов все равно много остается: проборс 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 (сильно разрозненно). Может быть у наших в МЦСТ дойдут руки, если их не отшибут "эффективные менеджеры" и давление диванных хейтеров.

Главное отличие в длине команды: в ARM она фиксирована, а в x86 она разная.
и это сильно усложняет архитектуру x86\x64.
Я думаю это усложняет разве что фронтэнд, который у современных процессоров ничтожную площадь кристалла занимает.
Главное отличие в длине команды: в ARM она фиксирована, а в x86 она разная.
В результате операция add eax, 12345678h, не помещающаяся ни в два, ни в четыре байта опкода, на ARM превращается в целый квест)
Так выглядит код одной и той же операции для 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


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

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

НЛО прилетело и опубликовало эту надпись здесь
Смотря для каких задач. Если надо потом вывести двухцифровое значение, например, на пару семисегментных индикаторов, которые подцеплены к GPIO через дешифраторы, то с такой кодировкой вывод делается по сути одной командой. Но да, вряд ли в применениях x86 (если не считать очень специфических) это очень полезно.
Ещё в 8080 была команда DAA команда для двоично-десятичной коррекции и её использовали для вывода чисел.
Да, у Z80 она так же называлась. В принципе допускаю, что и в сугубо компьютерных приложениях с ней могло было быть удобно преобразовывать небольшие числа в разряды для вывода на экран или каких-то расчётов, связанных именно с десятичными разрядами.
НЛО прилетело и опубликовало эту надпись здесь
Имхо, жуткий формат, когда число кодируется в десятичной системе по 4 бита на десятичный разряд.
Вот для конвертаций числа <-> строки, которые прикладной софт делает постоянно, такой формат очень удобен. И инструкции преобразования bcd<->binary тут бы помогли.

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

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

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

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

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

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

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

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


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

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


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

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

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

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


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

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


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

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

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

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


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

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

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

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

Емнип ранний бенчмарк дев кита запускали в режиме эмуляции x86 кода и еще тогда аналитики были очень оптимистичны.
Ну да. Я и говорю – будем ждать более шустрых и горячих армов.
> Вы наверняка знаете, что мир процессоров разбит на два лагеря.
Сказал — как отрезал.
Хотя, в принципе, таки два:
— Цифровые vs аналоговые
— Скалярные vs векторные
— фон Нейман vs Гарвард
— CISC/RISC/MISC/VLIW… ой, тут четыре, не считается.
А так ровно два, да.
Какая доля у MISC/VLIW на консьюмерском рынке?
VLIW-процессоры стоят примерно в каждом модеме и в каждой камере.
НЛО прилетело и опубликовало эту надпись здесь
Одна и та же команда на x86 выполняется за 3 шага, а на ARM за 9, а ещё есть SIMD инструкции где ситуация ещё более грустная.

Какая команда? Какие шаги?
А что с SIMD инструкциями? Слышали про Neon, SVE?
Современные CISC процессоры имеют как раз таки более «CISC-овое» ядро чем старые (K6/Pentium Pro)
НЛО прилетело и опубликовало эту надпись здесь
А что с расходом памяти? ARM прожорливее i386?
Процессоры не жрут память, они с ней работают
Да, и требуют выравнивания данных в этой самой памяти. x86 исторически жрёт невыровненные адреса (наследство 8088). А вот если говорить про арм — то данные должны быть выровнены на 8 байт минимум. Если вы полезете в память по невыровненному адресу, процессор кинет аппаратное исключение и пошлёт вас чинить компилятор. Впрочем, на большинстве реальных арм-камней стоит аппаратный обработчик этого аппаратного исключения, но он не всесилен — в отличие от х86 не может обработать ситуацию на границе страниц ДРАМ (8кб).
В реальности вам редко нужны 64-битные целые (указатели да, хотя оверкилл, но вас не спрашивают; double когда как; а вот именно целые скорее всего нет, обычно хватает 32-битного int или вообще char/bool). Но компилятор по умолчанию всё равно выделяет им по 8 байт, чтобы не нарваться на исключение. Так что технически одна и та же программа под армом может жрать больше памяти, чем под х86. А разбор внешних упакованных структур (например IP-пакетов, форматов файлов и пр.) превращается в утомительное жонглирование байтами в регистрах. Хотя компилятор это спрячет «под капот», длина кода будет сильно выше.

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

НЛО прилетело и опубликовало эту надпись здесь
А вот если говорить про арм — то данные должны быть выровнены на 8 байт минимум.

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

На смежную тему: в многопроцессорных системах выделение переменным разных строк кэша (т.е. выравнивание на >64 байта) может ускорять программу, предотвращая cache eviction при работе разных процессоров с соседними переменными.
Ну а чего спорить то в эпоху онлайн компиляторов.
Возьмите 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;
}

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


данные должны быть выровнены на 8 байт минимум
НЛО прилетело и опубликовало эту надпись здесь

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

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

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

НЛО прилетело и опубликовало эту надпись здесь
Который все равно проигрывает по размеру коду x86\x64
Это не так. х86-64 гораздо более рыхлый чем х86.

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

131 / 126 ≈ 1.04

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

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

Некстати вопрос из любопытства про декодеры инструкций тех же 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.

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


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

В системе команд 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)
И если бы Intel лицензировал x86 за деньги другим людям, то вероятно Apple просто адаптировали свою текущую микроархитектуру под x86.

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

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

Вот только нужно предварительно провести маркетинговые мероприятия по раскрутке новой крутой архитекторы собственных процессоров, чтобы после снижения себестоимости фанаты продолжили бы покупать продукцию Apple по старой цене. В результате и фанаты довольны, и у Apple растет прибыль. Как говорится «ничего личного, это просто бизнес».
Вот для примера некоторые «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
Зачем вы использовали кавычки?
По всем канонам это обычные RISC операции регистр-регистр.
Они элементарно реализуются в железе.
Более того, они имеются почти во всех RISC процессорах.
Большая часть это просто шафл/регистровый лукап.
Реализуется комбинаторным блоком.
FRSQRTE чуть посложнее, но это просто табличный лукап.

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

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

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

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

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

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

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

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

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

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

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

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 и аппроксимации квадратного корня это странно, мягко говоря.
Для того, чтобы ARM начал нормально отвоёвывать рынок серверов и рабочих станций, нужно разработать стандартную архитектуру компьютера, как это было сделано в компании IBM в свое время (IBM PC). Именно благодаря общепринятому стандарту мы сейчас имеем универсальную платформу и ПО. А пока этого нет, ARMу будет тяжко в этом сегменте.
Школота, мля.
Школота здесь, школота там.

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

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

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

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

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

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

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

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

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


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

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

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

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

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


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

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

В 2015г. AMD лицензировала китайцам ядро Ryzen первого поколения; но понятное дело, китайцы не могут получать последующие разработки AMD для актуализации своего микропроцессора, и тот идет теперь своим китайским путем.
А когда-то кто только х86-микропроцессоры не выпускал: Texas Instrumentis, Cyrix, UMC, IBM, NexGen, Transmeta (Crusoe), IDT (WinChip), Rise Technology (mP6), Chips&Technologies и др.
Пора бы уже отличать «архитектуру процессора» от «архитектуры компьютера».
Архитектура всем известного компьютера называется IBM PC. Это целая экосистема и свод стандартов, позволяющих без излишних танцев с бубном запустить софт на IBM PC совместимых компьютерах любых производителей. То же самое касается и дополнительного железа. А вот про ARM такого не скажешь. Нет для ARM единого стандарта построения компьютера, такого как IBM PC. Не изобрели еще.
Еще раз повторяю, не процессора, а компьютера. Процессор — это часть компьютера/аппаратной платформы.
Архитектура всем известного компьютера называется IBM PC

Интересно, с чего бы архитектура всем известного компьютера называется IBM PC, если IBM PC был выпущен четыре десятилетия назад, и с современным компьютером не совместим ни аппаратно, ни архитектурно, ни программно?
Нет для ARM единого стандарта построения компьютера

А что такое «стандарт построения компьютера»? ARM-системы используют абсолютно те же спецификации, что и системы на базе x64.
Я думаю имелись ввиду обычные рабочие станции. Грубо говоря, чтобы по «arm pc buy» можно было сразу купить себе компьютер и начать на нем разрабатывать.
Raspberry pi и аналоги не могут быть заменой нормальному пк.
Да, именно это я и имел в виду. Если Apple возьмется за разработку стандарта, аналогичного стандартам IBM-PC, то у ARM будут все шансы потеснить x86 на рынке.
С ARM процессорами в своё время была интересная путаница в процессорах. Особенно когда не указывали тип процессора. И получалось, что один и тот-же «процессор 1GHz» мог выдавать разную производительность. А покупателю оставалось удивляться, что его телефон или планшет тормозят. А получалось это из-за того, что в процессоре, к примеру, небыло инструкций сопроцессора, и команду, которую другой процессор мог выполнить за один такт — этот выполнял за три.
«RISC» и «CISC» — чистейший маркетинг. Ну, может быть эти слова и имели какой-то технический смысл лет 40 назад, когда процессор А умел только плюсовать, но не умел умножать, а процессор B умел и плюсовать и умножать, но тратил на это 100 тактов. Сейчас же все процессоры выполняют одни и те же операции, имеют на борту математические и векторные сопроцессоры, всякое шифрование и выполняют суммарно по сотне умножений за такт. Никакого риск и циск уже сто лет не существует. BTW, «трансляция команд х86», про которую орут из каждого утюга — такой же бред. ЛЮБОЙ сколько-нибудь серьёзный цпу использует микрокод и микрооперации! х86 даже не первый! Существенная разница в системах команд между арм и х86 в том, что х86 умеет адресовать память из любой команды, а арм — использует RMW-подход, зато имеет 13 регистров вместо 7. И это в принципе неплохо. Но главное — х86 имеет сложную систему кодирования команд переменной длины, а арм обходится 2 или 4-байтовыми командами. Как по мне, эта фиксированная длина команды — полнейшее говнище. Несколько упрощая реализацию процессора, она превращает код в полнейшее месиво. Простая загрузка константы в регистр или считывание значения по imm-адресу разворачивается в целую простыню мусора. Все эти таблицы констант, пихаемые между функциями — вот настоящие костыли. «Эффективному RISC» приходится по 2 раза лезть в память, сперва считывать команду, затем доставать константу из таблицы для простейшего mov reg,imm32! Но зато всякие NOP и прочие операции на одном регистре или вообще без аргументов занимают целое слово… И россказни про сложный декодер х86 команд совершенно несостоятельны. Кэши занимают половину кристалла, ещё львиную долю исполнительные блоки, декодеры же команд с лупой искать надо…
В целом всё верно, но на декодере заостряют внимание потому, что он должен поставить комманды во все конвееры для спекулятивных вычислений, так что он должен работать гораздо быстрей чем цепочка реально исполняемых комманд. И вот тут начинаются проблемы, потому что он по тем же топонормам делается и работает, и что бы он был не «такой как все», желательно бы его попроще или сделать специальные телодвижения, которы бы позволяли выбирать последующие комманды когда ещё текущие не декодированны. Эту проблему как раз решает фиксированная длинна комманды.
Как видно, вполне себе справляется. Более того, поспевает даже в случае SMT, когда, по идее, темпы фетчинга команд еще выше. Ходят слухи, что АМД и SMT4 может добавить.
Эту проблему как раз решает фиксированная длинна комманды.

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


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

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

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

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


Полная перестройка при смене разрядности?
Вот тут — надо учитывать историю.
Выпустив 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 битам выбросил старые неадекватные заморочки и такой проблемой не страдает. Штош, они оказались умнее строителей пирамид.

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

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


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


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


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

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


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

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


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

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

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

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

Выбрали первый байт. Декодировали. Нашли префикс. Идём к следующему байту. Однобайтный код операции, OK. Узнали, что за ним идёт mod-reg-r/m, который надо декодировать для получения аргументов. Выбрали. Декодировали. Узнали, что за ним идёт SIB, который надо разобрать. Выбрали. Декодировали…
Ну и что, никто не будет последовательно разбирать команду. Декодируют одновременно по всем основным шаблонам. Ну, несколько больше шаблонов, чем для всякого риска. Но не «на пару порядков» уж точно. Процессор и есть сложный, десятки миллиардов транзисторов уже. Значит и функциональность должна быть соответствующая, а не «здесь густо, здесь пусто». Зачем делать крутой набор команд и экономить копейки на кодировании? Чтобы банальное чтение слова по имм-адресу разворачивалось в просыню мусора? Сделать процессор можно один раз и потом тупо печатать, а с убогими примитивными командами придётся всё время мучаться при разработке софта!
Зачем делать крутой набор команд и экономить копейки на кодировании? Чтобы банальное чтение слова по имм-адресу разворачивалось в просыню мусора?

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


Но:


Чтобы банальное чтение слова по имм-адресу разворачивалось в просыню мусора?

Как часто такая операция вообще нужна?


а с убогими примитивными командами придётся всё время мучаться при разработке софта!

Мучаться придётся двум небольшим группам — 1) авторам компилятора — причём только той части, которая переводит в целевой код, 2) авторам ассемблерных переходников. Остальным пофиг.


Вот две последние разработки ISA — AArch64 и RISC-V. Обе разрабатывались командами грамотных инженеров с оптимизацией каждый под свою специфику, но под последние достижения отрасли. Видна масса одинаковых решений, например: общая схема RISC, операции с памятью отделены от операций с данными; нет слотов задержек; нет условного выполнения команд, так любимых в ARM/32… Много различного. Но для "банального чтения слова по имм-адресу" в обоих надо загрузить этот адрес (или близкий к нему) в регистр и затем только прочитать. Может, оно в стиле PDP-11 "MOV @#1234,@-(R2)" и не нужно?
Да, это отсылка к авторитету, но когда два заметно разных авторитета дают примерно одно и то же — это уже наводит на мысли.


Процессор и есть сложный, десятки миллиардов транзисторов уже.

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


Декодируют одновременно по всем основным шаблонам.

Я это сказал. Всё равно дороже. И да, думаю, раз 100 таки точно есть усложнения.

Может, оно в стиле PDP-11 «MOV @#1234,@-(R2)» и не нужно?
В мелкоконтроллерах постоянно приходится лазить в I/O-space и аналог характерного «or dword ptr [0x12345678],0x80000001» разворачивается в 7 команд и портит пару регистров. Да и просто аналог «or eax,0x80000001» написать нельзя — нужно доставать 0x80000001 из памяти, но и к памяти обратиться напрямую нельзя — нужно загружать адрес. Всё это выглядит крайне костыльно, нечитабельно, уродливо. Сотню раз исплюёшься пока что-нибудь на ассемблере напишешь. И всё это ради фиксированной длины… Ну сделали бы хоть бы 4/8, уже как-то можно было жить!
RISC-V похож на ARM, что тут удивительного, как альтернативу арму и делали…
or dword ptr [0x12345678],0x80000001

Ну именно простые микроконтроллеры и сейчас та область, где CISC стиля PDP-11 с потомками был бы очень вкусен. Всякое OoO там не нужно, даже минимальный конвейер часто излишен, тактовой достаточно низкой...


RISC-V похож на ARM, что тут удивительного, как альтернативу арму и делали…

Нет, он MIPS, из которого выкинули ошибки прежней реализации. Внутри RISC мира это фактически полная противоположность.

Существенная разница в системах команд между арм и х86 в том, что х86 умеет адресовать память из любой команды, а арм — использует RMW-подход, зато имеет 13 регистров вместо 7.

— 8086 и 8088 имели 14 16-битных регистров. Далее их количество постоянно росло.

Не путайте общее количество регистров и регистры общего назначения.


У 8086 — 14 регистров, их них 8 — общего назначения, полноценных — 7, причём они ещё и не равноправные.


У ARM — 16 целочисленных регистров, из них 13 — равноправные регистры общего назначения.

Два лагеря это CISC и RISC, а не x86 и ARM. Кроме того, после покупки ARM компанией NVIDIА, большинство здравомыслящих компаний начнут смотреть в сторону более открытых архитектур, таких, например, как RISC-V.
Мне бы интересно было рассмотреть и сравнить наборы команд. Помню, еще будучи студентом, по книге Зубкова восстановил таблицу команд x86 и обнаружил там недокументированную команду с кодом 0xF1, и затем уже в инете нашел что это некая ICEBP (INT01).
Ну и таблицу команд ARM в классическом виде было бы интересно посмотреть.

Статья весьма безграмотная, примеры и аналогии притянуты за уши.
Видимо, автор сам пороха не нюхал на ассемблере под обе сравниваемые архитектуры толком и не программировал. Всё отличие RISC от CISC можно пояснить двумя отдельными пунктами:


  1. Длина команды: у CISC она переменная, у RISC — постоянная. Это отчасти верно, но есть особенности, т.к. у тех же ARM и RISC-V есть возможность исполнять сокращённые в два раза по длине команды для увеличения плотности кода.
  2. Наличие отдельных выделенных команд пересылки данных между памятью и регистрами в RISC, в то время как в CISC команды могут в качестве операнда использовать ячейку памяти.

То, что в RISC какой-то убогий набор инструкций — уже давно миф и результат неправильного перевода самой аббревиатуры RISC на русский язык. В современных ARM и MIPS даже SIMD есть (который, к слову, местами попродвинутее SSE и AVX будет), который сейчас является одним из ключевых способов оптимизации производительности обработки данных.

1 — справедливо только если оба набора могут выполнятся одновременно в одном сегменте кода. Если для переключения набора требуется специальная инструкция, метка сегмента/страницы, запись в регистр, whatever еще — то это или безграмотность, или окажется что сумматор и умножитель использую разные системы команд, что неверно.

Так для arm thumb2 как раз может такое если старший байт <0xF4 16бит инструкция иначе 32бит.
image

Хорошо, процессоры с поддержкой Thumb2 можете считать не совсем чистыми RISC (а кто-то обещал реализацию прямо-вот академической модели?).
При том, до изменения длины инструкции в 15 раз при обилии префиксов и необязательных байт отсюда все равно что до Луны пешком, регулярность структуры сохранена; так что даже если судить настолько строго, все равно к чистому RISC он на порядок ближе, чем к реальному CISC.

Зарегистрируйтесь на Хабре , чтобы оставить комментарий