x86 vs ARM: сложность инструкций

Я не настолько в этом разбираюсь, но

1) какие x86 инструкции имеют значительно большую сложность

За этим - в мануалы Intel.

2) на сколько часто они попадаются в программах

Это самое простое - выясняешь, какие инструкции дороги, дизассемблируешь /usr/bin, и строишь гистограмму %)

3) на сколько сильно упадёт производительность если сложные команды разбить на простые

Кому разбить - компилятору? Думаю, заметно. В тех же мануалах Intel можно найти, как Intel советует использовать свою ISA.

Под сложностью я понимаю 1) то что выполняется много циклов или использует микрокод 2) не имеет аналогов в ARM

Ну, строковые, наверное.

Некоторые эмпирические наблюдения. Бинари под армы иногда больше, иногда меньше. Возможно, thumb виноват

x86 делался и для плотной упаковки инструкций тоже.

Надо mv скастовать - ему ближе все эти uops'ы.

Решил в асемблере под АРМ попрактиковаться? Назуя если есть языки повыше уровнем?

ARM всегда будет содержать больше инструкций, так как load/store архитектура, а в x86 почти все инструкции могут обращаться к памяти.

Сложность x86 - в сложности декодирования инструкций переменной длинны.

Решил в асемблере под АРМ попрактиковаться?

Нет, просто медитирую над армами и думаю как можно интерпретировать результаты теста.

Хотя при правильном дизайне набора инструкций переменной длинны (не x86) можно получить значительный прирост производительности за счет более плотной упаковки инструкций в кэше.

Сложность x86 - в сложности декодирования инструкций переменной длинны.

А как же thumb?

Thumb - это или 16 или 32, причем можно считать, что все 16, и если некоторые биты имеют определенные значения, то дочитывать вторую половину, и декодировать как 32.

А x86 может иметь тучу префиксов, и длинна любая от 1 до 15 байт.

выясняешь, какие инструкции дороги

Интересно, как?

дизассемблируешь /usr/bin

Проблема в том что интересна run-time статистика. Т.е. хочу знать сколько раз эти инструкции вызывались и как изменилась бы производительность если их заменить на эквивалентные армовские.

Я просто хочу понять насколько реально армам догнать x86 по производительности. Ну или хотя бы предугадать что грядущие 64-битные армы на принесут. И не возникнут ли у них свои затыки. А то я щас вижу, например, calxeda ставит по 4метра кэша на свои армы. Тут уже глупо утверждать «а у arm ядро маленькое» потому что общий транзисторный бюджет (слово-то какое) переплюнет иной x86 проц.

Я просто хочу понять насколько реально армам догнать x86 по производительности.

Реально уже сейчас, при сравнимом энергопотреблении, но вот только все оптимизируют ARM-ы по энергопотреблению, так что не скоро мы увидим высокопроизводительные ARM-ы.

выясняешь, какие инструкции дороги

Интересно, как?

Во времена, когда я еще читал эти мануалы, в них было число тактов на команду.

Проблема в том что интересна run-time статистика

...и можно без хлеба, да? %)

Т.е. хочу знать сколько раз эти инструкции вызывались и как изменилась бы производительность если их заменить на эквивалентные армовские.

Зачем? В x86 есть декодер CISC -> внутренний RISC, который занимается примерно этим. Т.е. дорогие инструкции уже заменены.

Я просто хочу понять насколько реально армам догнать x86 по производительности

ААААААА!!!111 Ты хочешь это понять на основании самостоятельного анализа «внешних» наборов команд, без учета трансляции в uops, без учета планирования по исполнительным устройствам и состава исполнительных устройств? Ты должен быть очень крутым для этого :)

Но я выскажу тебе мнение профессионального ЛОР-аналитика: ARM не догонит Intel в обозримом будущем - тупо потому, что у Intel длиннее^Wтолще^Wбольше бюджет на исследования. А сложность x86, о которой любят поговорить {ARM,MIPS}-любы - это фиксированные накладные расходы, которые при сегодншней степени миниатюризации можно не принимать в расчет.

Но я выскажу тебе мнение профессионального ЛОР-аналитика: ARM не догонит Intel в обозримом будущем - тупо потому, что у Intel длиннее^Wтолще^Wбольше бюджет на исследования. А сложность x86, о которой любят поговорить {ARM,MIPS}-любы - это фиксированные накладные расходы, которые при сегодншней степени миниатюризации можно не принимать в расчет.

Какая фееричная шизофазия :) Зачем АРМам чего-то догонять, когда из логики развития компьютерных систем следует, что все громоздкие вычисления будут производится на мейнфреймах, а у юзеров будут личные пк/звонилки/ололокоммуникаторы. IBM PC вымрет как динозавр, ну или превратится в обогреватель с функцией компьютера.

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

Ага, проходили уже это. Потом появились ПК и все вздохнули спокойно.

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

Почти, медитирую на hardware performance counters собранные с odroid-u2. Конкретно была намеряна производительность в instructions per cycle. Я вот думал можно ли этот параметр сравнивать с тем что выдаёт амд-шная тачка. Щас проверил, оказалась полная фигня.

Зачем АРМам чего-то догонять

Какая фееричная дислексия.

А чо, что-то типо плоншетика (с подключаемыми по воздуху клавой, мышкой и норм интерфейсом для всего этого), толстый интернет, «личный кобинет» на мейнфрейме и этот ЭЙБИЭМ CISC гроб становится не нужен.

Да у тебя ОБИДА :)

и этот ЭЙБИЭМ CISC гроб становится не нужен

Пока мейнфрейм не забанят по IP вместе с каким-нибудь торрент-трекером.

lol

Хм, я таки не поленился посчитать. Пока выходит что при вдвое меньшей частоте (1.7 vs 3.1) армы сливают в среднем в четыре раза amd fx-8120. Однако на тесте с apache+mysql+php+worpress неожиданно выиграли при гораздо более низкой частоте. Я ф шоке, сижу-перепроверяю.

Команды очень разные. Тяжело сравнивать. Например условное выполнение, в режиме arm, очень интересная, особенная вещь. Позволяет выполнять, либо не выполнять команды, в зависимости от флагов выставленных при выполнении одной из предыдущих команд. Часто позволяет обходиться без условных переходов. У Интела таких нет.

обладает такими вещами как thumb (плотная упаковка инструкций)

thumb - кастрированный тормоз, arm - быстрее. Если шина памяти слишком «узкая», thumb, конечно, тоже сможет что-то показать. thumb2 вроде бы приближается по скорострельности к arm(не проверял).

vfpv3 (FPU)

FPU у Интела традиционно мощный, arm-у пока нечего ловить.

какой-нить Cortex-A57

А они уже есть в железе? Или все еще где-то там «в недрах лабораторий TSMC»

Бэкэнд у x86 - давно RISC. Фронтэнд очень эффективно декодирует CISC и переводит в понятные бэкенду рисковые мюопсы.

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

ARM, по-моему, просрал полимеры, и в следующие несколько лет потеряет очень большую часть рынка. А как интел начнёт продавать процы с FPGA на той же пластине, да с quickpath interconnect между ними, то ARM'у будет совсем худо.

Интел ещё очень плотно работает с крупными заказчиками и дотачивает железки под реальный характер нагрузки. Взять хотя бы разворот с общим TLB для обычных и больших страниц в Хасвелле, похоже, что корпоративный интерес стоит за этим.

Не знаю, делает ли то же самое ARM...

Под сложностью я понимаю 1) то что выполняется много циклов

И еще, в своременных Out Of Order архитектурах количество циклов на команду потеряло столь большое значение, как было в In Order.

я очень удивлен встретив себя в списке кастов, это какой-то эксперимент?

К, сожалению, я не компетентен в низком уровне, а на тред подпишусь, т.к. интересно.

ARM, по-моему, просрал полимеры

По-моему так наоборот

А как интел начнёт продавать процы с FPGA на той же пластине, да с quickpath interconnect между ними, то ARM'у будет совсем худо.

Вообще ни о чем. Давно есть xilinx zynq и какой-то ощутимой доли рынка они не имеют. Железо бесполезно пока нет удобного софта, который позволит писать обычные программы всем кто пожелает а не только узким специалистам по FPGA на специальных HDL. Microsoft Research имеет наработки в этом направлении, так что скорей можно будет говорить об очередной победе MS.

Проблема в том что интересна run-time статистика. Т.е. хочу знать сколько раз эти инструкции вызывались и как изменилась бы производительность если их заменить на эквивалентные армовские.

Какой то сферический конь из сколково... Народ до сих пор холиварит, какой х86 лучше - интел или АМД. И это при одинаковых то командах. Так что твое сравнение команд арма и х86 еще более фееричное.

Я ф шоке, сижу-перепроверяю.

Нормальная ситуация, можно подобрать тест, который опустит любого нужного тестируемого. Уж больно разная может быть нагрузка и условия. Чистая математика/SIMD/дрочево счётчиков не вылезая из кэша против io-bound/многопоточки с большим кол-вом переключений контекстов могут дать совершенно феерические результаты.

первый годный тред на лоре за последний месяц. спс

арму не будет худо. в его ценовом диапазоне только мипс..

У Интела таких нет.

CMOVxx

CMOVxx

Не знал. Только же MOV есть?

берешь мануалы по инструкциям x86 и ARM, читаешь, сравниваешь

Только же MOV есть?

Если не считать JMP, то да, только для MOV. Есть ещё cmpxchg8b, cmpxchg16b, но это немного другое.

Да и вообще условное исполнение это спорное преимущество. Процессор же всё равно проматывает такты на не выполняющихся инструкциях. Что мешает на x86 посчитать обе ветки, а потом cmov сделать?

С натяжкой ещё SETxx назвать можно.

Процессор же всё равно проматывает такты на не выполняющихся инструкциях.

По одному такту.

Что мешает на x86 посчитать обе ветки, а потом cmov сделать?

Если считать, по одному такту не все получится.

Всем подписавшимся бонус — сравнение instructions per cycle для двух процов и рядом колонка на сколько быстрее выполняется задача на АМД. Как видим, прямой связи нет. В целом, каждая инструкции (чтобы это не значило, показания по perf stat) на АМД делают «больше работы», но при этом больше stalled cycles. Процы exynos 4412 и amd fx-8120 на частотах 1.7 и 3.1GHz соответственно.

http://imgur.com/KxlHLBY

http://tinypic.com/r/4jkdci/5 (зеркало)

Таблица по таймингам AMD/Intel: http://gmplib.org/~tege/x86-timing.pdf

RISC никогда не был «простыми инструкциями». Характеристики RISC:

1) Отдельные инструкции load и store для доступа к памяти. Никакие другие инструкции непосредственного доступа к памяти не имеют, а могут только читать и писать регистры.

2) Как следствие 1, большое число регистров (15 или больше)

3) Кроме load и store, все инструкции должны выполняться без задержки. Это в идеале, на самом деле, конечно же, все не так - те же инструкции деления выполняются за несколько тактов. Правда, их в ARM вплоть до CortexA9 и не было.

Вот и вся разница между «простым» и «сложным». То, что в x86 будет одной инструкцией с аргументами в памяти, в ARM будет несколькими load-ами, непосредственно инструкцией и затем store.

Железо бесполезно пока нет удобного софта, который позволит писать обычные программы всем кто пожелает а не только узким специалистам по FPGA на специальных HDL.

«Обычные» программы = программы на не-параллельных языках. От которых толку на FPGA не будет. Быдло не способно мыслить параллельно, и потому FPGA никогда не станут массовой технологией, независимо от удобства средств разработки. И так уже сложно придумать язык более простой, чем Verilog, а все равно сосунки не осиливают.

ARM, по-моему, просрал полимеры, и в следующие несколько лет потеряет очень большую часть рынка.

У ARM есть огромное преимущество - ARM умеют в SoC, и у ARM огромный опыт в снижении энергопотребления. Intel никогда ни тем, ни другим не заморачивался, и потому безнадежно отстал. «Intel SoC» сейчас звучит как оксюморон.

А как интел начнёт продавать процы с FPGA на той же пластине

Давно уже начал - Atom E6x5C.

то ARM'у будет совсем худо.

У ARM аналогично - Xilinx Zynq. Толку-то - что то, что другое, совершенно нишевые продукты. Еще раньше были аналогичные решения на базе PowerPC, и тоже никакого массового применения не имели.

Не знаю, делает ли то же самое ARM...

См. на ARMv8.

То, что в x86 будет одной инструкцией с аргументами в памяти, в ARM будет несколькими load-ами, непосредственно инструкцией и затем store.

Только вот компиляторы не делают на ARM «load+calc+store». Всё чаще «load+calc+load+calc+calc+...+calc+store».

RISC никогда не был «простыми инструкциями». Характеристики RISC:

Смелое заявление на фоне того, что само понятие RISC весьма расплывчато и со временем менялось.
Ко всем трём пунктам можно придраться. Особенно к 3му, ведь даже MIPS, который «without Interlocked Pipeline Stages» таковым сегодня ЕМНИП не является.
Так что, на мой взгляд, один из наиболее значимых критериев RISC - отсутствие микрокода, и выполнение инструкций максимально «железно» и «тупо», без продвинутого интеллекта. Хотя чистых RISC'ов тогда сегодня будет и не густо =)

Процессор же всё равно проматывает такты на не выполняющихся инструкциях.

По одному такту

сразу видно погромиста на жабе. на х86 такие инструкции просто выполняются спекулятивно. и на арме кстати тоже, т.к. в pipeline есть нехилая latency

Но я выскажу тебе мнение профессионального ЛОР-аналитика:

Ты некомпетентен.

ARM не догонит Intel в обозримом будущем

ARM давно обогнал Intel - в производительности на ватт, в площади на кристалле, в степени интеграции в SoC. Именно эти характеристики и представляют интерес для потребителей продукции ARM.

- тупо потому, что у Intel длиннее^Wтолще^Wбольше бюджет на исследования.

Intel исследует совсем не то, что ARM. Они вообще не пересекаются. Intel FinFET-ами балуется, а за ARM это делает TSMC. Intel ищет способы еще больше потоков в OoO засунуть, а ARM ищет, как бы ядро еще сильнее упростить и затупить.

А сложность x86, о которой любят поговорить {ARM,MIPS}-любы - это фиксированные накладные расходы,

Ты видел декодер x86? Такие накладные расходы в embedded недопустимы.

которые при сегодншней степени миниатюризации можно не принимать в расчет.

Каждый квадратный миллиметр на счету. Не переоценивай «степень миниатюризации».

А так, RISC - это прошлый век. Архитектуры, которые могли бы обогнать по производительности такие RISC, как ARM или x86, должны строиться на совсем иных принципах. Советую посмотреть на Hexagon, например.

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

Thumb - микрокод. OoO - уже не сочетается с «железно» и «тупо», потому что как минимум переименование регистров и тому подобный ад и мрак.

Так что, да, понятие «RISC» не имеет смысла. Я говорю о том, что понимается под RISC последние пятнадцать лет - а это как раз load/store-архитектуры с большим числом регистров. При этом внутри могут быть и сложные декодеры в микрокод, и OoO, и что угодно еще.

Только вот компиляторы не делают на ARM «load+calc+store». Всё чаще «load+calc+load+calc+calc+...+calc+store».

Мы тут говорим про количество инструкций, а не про порядок.

А то я щас вижу, например, calxeda ставит по 4метра кэша на свои армы. Тут уже глупо утверждать «а у arm ядро маленькое» потому что общий транзисторный бюджет (слово-то какое) переплюнет иной x86 проц.

Cache - это SRAM, то есть, когда не используется - не греется. Много кэша энергопотреблению не вредит, а много логики в CPU - вредит.

Мы тут говорим про количество инструкций, а не про порядок.

Из слов предыдущего анонима можно сделать вывод, что загрузка и сохранение делаются на каждый чих, утраивая число инструкций. На деле между загрузкой и сохранением довольно много вычислений, и накладные расходы оказываются не такими уж и большими. В конце-концов, если бы load-store было таким плохим подходом, как о нём говорят, ARM'ы вымерли уже.

сразу видно погромиста на жабе.

Только Pure C, с ассемблерными вставками, для ARM-а.

на х86 такие инструкции просто выполняются спекулятивно.

Выше то глянь: http://www.linux.org.ru/forum/development/9540074?cid=9540343 (комментарий)

и на арме кстати тоже

Далеко не на всех.

Никто не говорит, что это плохо. x86 делает то же самое, только на уровне микрокода.

добавлю про cpu+fpga.

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

однако числодробление в плавающей запятой, и порою и в целой решается на powervr / simd лучше чем на fpga.