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

сервера = датацентры. датацентры = бизнес. бизнес = деньги.

сравнивай скорость выполнения типовых задач: nginx, apache, memcached, mysql, php - и потребление энергии.

«Вот и я про то же: как Интел в SoC въедет, так ARM потеряет кусок рынка.»

Так ведь у Интела был уже достаточно неплохой SoC (на то время) с собственной ARM подобной архитектурой XScale. Вбухали они туда кучу денег, а затем зачем-то слили в Marvell за гроши.

Сейчас модно сравнивать instructions per cycle (IPC) у x86 и у армов.

Чего толку их сравнивать, взять например это

http://techreport.com/news/24530/project-denver-based-soc-due-in-2015

гетерогенная система, собственный процессор с транслятором ISA ARM, изначально вообще планировался морфинг кода и два набора инструкций x86/arm. На серверах ARM однозначно займет часть рынка.

Так ведь у Интела был уже достаточно неплохой SoC (на то время) с собственной ARM подобной архитектурой XScale. Вбухали они туда кучу денег, а затем зачем-то слили в Marvell за гроши.

SoC с нормальным x86 лучше.

На серверах ARM однозначно займет часть рынка.

Не надо считать серверами коробочки, втыкаемые в розетку. И 0.1% - это не часть рынка.

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

А слили когда поняли, что им эта архитектура неинтересна. От така хурма.

Не надо считать серверами коробочки, втыкаемые в розетку

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

Под сложностью я понимаю

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

У x86 команды «отфонарные» и разной длины. Соответственно, при анализе потока инструкций приходится читать инструкцию, разбирать, в зависимости от результата — ещё что-то дочитывать из потока…

У ARM каждая команда (тонкости, типа thumb — это отдельная тема) строго фиксированного размера и формата. Т.е. процессор читает каждый раз равными порциями и тут же знает, что делать.

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

Было время (у кого точно — уже не вспомню), когда дешифратор команд у x86 занимал треть всего кристалла, включая кеши и сопроцессор. Сегодня x86 внутри стал RISC'ом, так что ситуация уже не столь критична.

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

В ассемблере есть псевдо-инструкции, которые помогают относительно просто загружать 32-битные константы. Стандартные макросы. А компилятор обычно данные из сегмента кода загружает.

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

Хороши Sparc, Power и Itanium. Для серверов.

Для десктопов - x86

Для консолей - cell

Для мобильных девайсов - ARM

Остальное - компромиссы и манагерские интриги

Хороши Sparc, Power и Itanium. Для серверов.

Чем хороши? Почему для десктопов плохи?

Для консолей - cell

Отчего же новые приставки делаются на AMD? :)

«А слили когда поняли, что им эта архитектура неинтересна. От така хурма.»

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

почему Intel этот потенциал не увидела

Увидела и пилила свой xscale. Но тогда рынок был слишком мал для intel. Знай она текущие объёмы рынка, уверен, расклад был бы иным.

Но тогда рынок был слишком мал для intel.

Скорей наоборот - почуяв объемы мобильного рынка избавились от конкурирующего решения на ARM в пользу своих атомов. Но им все равно нихера не светит - полимеры уже просрали.

«Знай она текущие объёмы рынка, уверен, расклад был бы иным.»

Согласен. А ведь мог бы быть хороший вендор чипов для Embedded. В последнее время все вендоры скотились в г**** в плане техподдержки и стабильности софта.

«Скорей наоборот - почуяв объемы мобильного рынка избавились от конкурирующего решения на ARM в пользу своих атомов. Но им все равно нихера не светит - полимеры уже просрали.»

Как-бы Атомы всегда были в разных нишах с XScale вплане энергопотребления. Что мешало супортить два продукта?

избавились от конкурирующего решения на ARM в пользу своих атомов.

1) они продали xscale в 2006 который применялся во всяких кпк и, вроде, некоторых смартфонах.

2) atom появился в 2009 и изначально работал на нетбуках и только нетбуках. Армов на нетбуках тогда не было. Во всяком случае в продаже. Версия для мобильников вышла настолько позже что ясно что изначально это не планировалось. Или же решили выждать время.

В общем, не похоже что они правильно поняли вектор развития мобильной техники.

в плане техподдержки и стабильности софта.

меня пугает что чипы устаревают быстрее чем появляется вменяемая поддержка в линухе.

Хороши Sparc

Это у которых один маленький FPU на все ядра? Ну ну.

1) Такие компании планируют на много лет вперед, ты еще ничего про андроид не слышал, а они уже знали что wince (которая для ARM) MS поддерживать не собирается

2) см. 1

Если даже ISA перелопатят на более компактно упакованную, то выигрыша ни в скорости, ни в размере кристалла не будет.

Вот по этому (точнее — это одна из многих причин) я и перестал переживать из-за кривой архитектуры x86 ещё во времена Pentium :) Как начали MMX и SIMD засовывать… Где-то в те времена я на ассемблер окончательно и забил.

«меня пугает что чипы устаревают быстрее чем появляется вменяемая поддержка в линухе.»

+100500

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

Я тебя удивлю, наверное, но абсолютно любой алгоритм - FSM. Потому как машина Тьюринга - FSM.

Чем ты на жизнь зарабатываешь? В FSM'е нет даже натуральных чисел, памяти на них не хватает, дилдо.

Ну ты-то чо ведёшься на этот бред?

Ну формально-то «computers are state machines» :)

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

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

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

какой следует сделать вывод?

Зависит от того чем ты на жизнь зарабатываешь :).

Ну я так и написал там в конце, да.

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

Не знаю какой тебе дать ответ чтобы ответить и при это не показать свою некомпетентность. Наверно, как-то так: Если если эти промахи не имеют значительного влияния на производительность (например, скомпенсированы префетчингом) то всё в порядке. Иначе это проблема. Т.е. программа программе рознь.

Возможно, тут расскажут про это: http://jug.ru/archive/-/blogs/20987 (уже пол года не доберусь посмотреть этот доклад)

Короче, какой следует сделать вывод?

Выводов следует сделать два. 1) преждевременная оптимизация - корень всех бед 2) оперативная память, как и все остальные носители, любит последовательный доступ.

А не проще реализовать оба варианта и скорость измерить? В perf есть возможность посмотреть счётчики производительности, кеш-промахи, неверно предсказанные переходы и тому подобное.

В FSM'е нет даже натуральных чисел, памяти на них не хватает, дилдо.

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

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

Выбор же AMD для нового поколения консолей это, имхо, просчёт со стороны IBM и общая тенденция к удешевлению разработки за счёт максимальной унификации. По тем же причинам проприетарные платформы на названных выше серверных процах также проигрывают x86 уже и в серверном сегменте

при этом обеспечивая нужную производительность для соответствующих типов нагрузки

Можно парочку примеров соответствующих типов нагрузки? Желательно с бенчмарками, хочу увидеть как x86 подчистую сливает более прогрессивным платформам.

для массовых десктопов очень критична цена - в отличии от серверов, где цена процессора не первичный критерий выбора.

Неужели? :) Ты наверно о банках подумал, да? Ну, разве что для банков фактор цены такой роли не играет.

SoC с нормальным x86 лучше.

лучше чем грузины?

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

http://www.phoronix.com/vr.php?view=18202

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

Это они не ноду целиком имеют в виду, а конкретные поля в ноде. Зачем, мол, подтягивать «паровозом» всю ноду, если нужно всего пару полей.

советуют использовать не список структур, а структуру массивов

Интересный подход. Именно тем, что советуют не массив структур, а структуру массивов. Это должно работать.

SPARC
не являются нагромождением костылей и подпорок

О-хо-хо!
А елозящее регистровое окно? А branch delay slot?
Не костыли?

А 32->64? А V7->V8->V9?
Чем эти подпорки принципиально отличаются от интеловских?

для производительности надо считать реальное время выполнения задачи

Это для бизьнеса, это скучно =)
А вот посчитав такты на выполнение пачки тестов какого-нибудь SPECint можно при известной частоте и время получить и какую-то «эффективность» железа и компилятора.

Дык, то computers, а не Turing machine.

А ты сравни процессор intel x86 1999 года и 2013-го, например. Мне так кажется, что развитие всё-таки идёт очень по-разному в линейке sparc и x86... Но на самом деле, детально я не готов спорить, я вижу лишь то, как много приходится менять со стороны ПО каждый раз, когда выходит очередной simd

OLTP - нагрузка нехарактерная для десктопов и характерная для определённых серверов.

Я подумал о всех типичных потребителях «большого» железа.

Для мелких контор порой и старенький нетбук - Сервер, а школьник-эникей - чудо Админ.

Sparc Для серверов.

Если посмотреть на количество серверов, производимых Ораклом на x86 и на SPARC, есть некоторые сомнения на этот счёт.

Для консолей - cell

Сам я под Cell не программировал, но приятель из Crytek'а очень матерился при портировании Crysis 2 на PS3. Говорил, что для них PS3 - самая геморойная консоль.

SPARC не являются нагромождением костылей и подпорок

О-хо-хо! А елозящее регистровое окно? А branch delay slot? Не костыли?

А что с ними не так? Регистровое окно облегчает конвенции ABI при вызове подпрограмм. Если это - костыль, как оно должно выглядеть без костыля?

(branch) delay slot чётко определяет, какая инструкция выполнится следующей. И он не специфичен для SPARC. Есть ещё и в mips и в pa-risc. В MIPS, их к слову, даже несколько.

Ну, это ведь уже другой вопрос, для многих разработчиков - c# рай, а си - отсталое и неудобное старьё

А V7->V8->V9?

Вдогонку. О какой именно подпорке V7->V8 речь? Что V8->V9 - костыль - тоже можно поспорить. Накладные расходы на поддержку старых программ отказались минимальны. Эти же идеи через 10 лет использовала AMD в своей архитектуре x86_64.

Ну, чтобы быть лучшим для консолей, что-то процессор обязан делать лучше конкурентов, не так ли? А если нету софта, который реализует потенциал процессора, то вся его крутость остаётся на бумаге.

Регистровое окно облегчает конвенции ABI при вызове подпрограмм

Ну не верю =)
Когда-то оно было хорошо для быстрой обработки прерываний, но сегодня такое решение я нахожу сомнительным.

Что V8->V9 - костыль - тоже можно поспорить.

Я утрирую, конечно, ведь всё развитие архитектур делается такими добавками. Потому я и сказал, что нельзя считать упомянутые ISA принципиально менее костыльными, чем x86.

(branch) delay slot чётко определяет, какая инструкция выполнится следующей.

Да, где его только нету, но это же не красиво и по началу вообще крышесносно.

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

Больно, сука? :) Изобрази FSM'ой сложение двух натуральных чисел, гадёныш. Ну, или, если тебе этого вдруг мало будет, изобрази алкоритм Карацубы :) Посмотрим, как ты корчишься. Ведь твои слова:

Я тебя удивлю, наверное, но абсолютно любой алгоритм - FSM.

Отвечай за слова, лоровский мутант.