Архитектура ARM vs x86 что лучше?

В общем, вопрос?
Что лучше? ARM или x86?
На форуме в основном инфа про х86, на счёт ARM что-то совсем мало.
Реально ли полностью заменить ARM в место х86, в сегменте ПК, в том числе стационарных ПК, в том числе в будущем, лет через 10-20, или даже 50-100, или даже 500-1000 лет.
Или перспективны ещё какие-то архитектуры?

 

арм процы позиционируются акь "холодные", однако с ростом выч. нагрузок получишь те же яйца, только в профиль другой вопрос, что x86-64 дико перегружен легаси, а это роняет производительность, секуру и надёжность.

 

А кто сильней: кит или слон? У х86 гориллиард программ и утилит, сделанных за несколько десятилетий десятками миллионов программистов. Лишь часть из них опенсурс, только часть портированы хоть куда-то, много чего не имеет аналогов. Полностью отказаться от х86 может изрядное число пользователей, это те, кому достаточно браузера+офиса+плеера+калькулятора (их легко отличить по наличию у них планшета на андроеде). Осталось придумать зачем это вдруг может понадобиться индустрии - отказаться от х86.

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

 

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

 

Intro, ARM штука крутая. Но у него есть ряд минусов. Разработка идёт медленно. Для замены ПК им нужен более стремительный рост. В ближайшее 10 лет не приблизится.

Ребята из Амазон недавно выпустили сервер на ARM у них это 2 попытка. Какая это попытка по миру не скажу.
Так вот ихней ARM обогнал x86 по производительности.
https://habr.com/ru/company/dcmiran/blog/479074/

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

Сравнивать x86 и ARM задачка не простая.

Это в плоть до конца 80 ISA определяла первенство. А после появления больших микросхем позволило организовать кэш-микрокоманд. И теперь уже определяет не ISA и микро-архитектура. Так как 90% времени съедает обращение к памяти, то у кого кэш больше тот и выигрывает. Эти чип-мейкеры идиоты полнейшие. Им в книжках теорию расписали ещё в 20-ных если не раньше. А они ARM сделали производительный только вчера.

Сильная сторона i386 вернее 8086 процессора это индексное обращение к памяти. Т.е работа со структурами, массивами и объектами. У ARM в этом плане по хуже так как загрузка индекса это плюс 1 так по сравнению с 8086. В принципе в ARM это можно решить, но пока технологию нулевой-latence придерживают.
Так же сильной стороной 8086 являеются строковые команды rep movs и rep cmps. Да конечно одно время эти команды проигрывали MOVNTDQ и даже MOVD.
Но не суть, суть в том что строки UTF-8 легко сравнивать этими командами и передавать из переменной в переменную. А на уровнее микроахитектуры можно ускорять в разы.
Одна только оптимизация строк Borland'у позволила ускорить свои приложения в 2 раза! и обойти ближайших конкурентов.

У ARM для этого ничего такого нету. Единственное это SIMD для пересылки большого набора данных. За счёт SIMD пересылка строк будет одинаковой. Что мы и видим в тесте кэширования веб-запросов.

Что касается домашнего применения ARM то тут нужны быстрые парсеры. ARM пытается выиграть за счёт оптимизации ветвлений x:=5=6 ? 5:4;
Когда как в x86 это решают за счёт SIMD обработки. У ARM с SIMD в этом плане тоже всё нормально, Для быстрых паресров нужна технология внедрения битов. Сурагатовые пары UTF как раз облегчают такую работу, но тут вопрос к программистам которые не умеют непосредственно работать с UTF8, а в начале декодируют его UCS16 или подобные кодировки. За счёт комбинации SIMD с маской ARM может выигрывать в парсинге данных.

Что касается графики то AlphaBlit это основная операция и тут выигрывает тот у кого регистры больше. У Intel проблемы с AVX512 приходится использовать AVX256. У ARM т128 битные регистры поэтому они в 2 раза медленнее и если Интел справится с 512 то будет в 4 раза медленнее. Зато ARM может с маской оптимизироваться. Так что тут ARM проигрывает, но за счёт оптимизированного софта незначительно. И плюс ARM это планшеты и смартфону у которых разрешение ниже чем на ПК.

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

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

В целом обе архитектуры идут на ровне, но Интел впереди на голову. В перспективе ARM даже будет по быстрее. Но сейчас у ARM нету процессора который бы смог превзойти intel на десктопе, а вот в серверном сегменте при цене в 2 раза ниже он выглядит неплохо. Что-бы догнать intel фирме ARM потребуется ещё 10 лет.

 

Занятно.
Я тут гуглю инфу по ассемблеру ARM. Есть вопросы, а как работает стек возвратов из функции? Если помещать в регистр r14, то он же затрётся, если вызовем функцию из текущей функции.
И во обще, насколько сложней программировать на ассемблере ARM по сравнению x86, особенно если кода достаточно много.

 

Стек работает как тут описано.
http://www.cs.uwm.edu/classes/cs315/Bacon/Lecture/HTML/ch10s07.html
Данные выгружаются из стека и выполняется jr.

Код (Text):

1. # Stack frame:
2. #   $a0         Saved register used to cache argument
3. #   $ra         Return address
4. #   N           Argument
5.  
6. # Subprogram body
7.     .text
8. factorial:
9.     # Push rest of stack frame.  Already contains argument
10.     # pushed by caller.
11.     addi    $sp, $sp, -8
12.     sw      $ra, 0($sp)
13.     sw      $a0, 4($sp)
14.    
15.     lw      $a0, 8($sp)     # Get argument from the stack
16.    
17.     # Initialize N! to 1 and then multiply by all values from N to 2
18.     li      $v0, 1
19. factorial_loop:
20.     blt     $a0, 2, factorial_done
21.     mul     $v0, $v0, $a0
22.     addi    $a0, $a0, -1
23.     j       factorial_loop
24.    
25. factorial_done:
26.    
27.     # Pop stack frame
28.     lw      $ra, 0($sp)
29.     lw      $a0, 4($sp)
30.     addi    $sp, $sp, 12    # Account for argument on stack
31.    
32.     jr      $ra

Тут только одна проблема официальная документация отстойная. Проще нагуглить альтернативную.

 

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

 

UbIvItS, вот есть у тебя команда rep movs у ARM аналог
loop:
ld1d z1.d, p0/z, [x0, x4, lsl #3] // p0:z1=x
st1d z2.d, p0, [x1, x4, lsl #3] // p0?y=z2
incd x4 // i+=(VL/64
whilelt p0.d, x4, x3 // p0=while(i++<n)
b.first .loop

5 тактов против 1. Плюс код не надо пересматривать.

Интер он горячий из-за гипер-три6инка и опяряжающего исполнения команд. Поэтому он будет горячее чем там в 2 раза. Даже смарт-кэш не сильно спасёт.

Ну вот смотри Intel® Core™ i7-1060G7 Processor (8M Cache, up to 3.80 GHz) нарисовали TDP 9 Вт(можно настроить 13Вт) а по факту базовая частота 1ГГц против арма RK3399 у которого 2 Ггц. Вот только интел всегда отключает лишнее что-бы вписаться в 10 ВТ. А Арм получит только если всё включит. Основное тепловыделения приходится на кэш. У интела он самый большой. Вот тебе и экономия.

 

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

 

Pavia, а разве реп мовс - 1 такт? с каких пор одна команда == один такт?

 

q2e74, да там не 1 такт. Забыл поправить. Суть в том что у intel благодаря грамотному интерфейсу(технике сокрытия информации) может наращивать производительность как угодно. У арм тоже сделаны безразмерные вектора, но гораздо хуже.

Сейчас у Интела производительность будет такая 4 такта загрузка из кэша 4 выгрузка увеличение регистров выполняется в порту чтения. (за счёт этого всегда на 2 такта быстрее)
и 1-2 такт для уменьшения ECX проверку флага и если надо выход из rep (вроде AMD за 1 так делала).
Суть в том что у ARM это будет дольше там куча накладных расходов против 1 команды там 5 команд.
В лучшем случае в перспективе это выльется в то что скорость будет 4+4+4.
Получается 9-10 против 12 тактов. Т.е АРМ всегда будет процентов 20-33% медленнее в безразмерных-векторах чем Интел только из-за его архитектуры команд.
В перспективе если сейчас так не сделано rep movs можно целиком отдать порту Load/Store разгрузив ALU для гипер-тригенга, а вот у арма так всё печально и останется.

И такая картина и с другими командами. ARM только за счёт специальных блоков вытягивает блок для быстрого сжатия файлов, аппаратное дешифровка трафика, аппаратное декодирование видео, аппаратные НС.

 

Pavia, вся скорость ынтЭля и аMЪуди в основном пролегает в спекулятивке == доступ к кэшу прозрачный (зеро проверок на секуру) + куча теневых регистров, к коим юзверь прямого доступа не имеет, и отседова получаем out of order execution + zero idle time 4 cpu. выкинут х86 получат обрубку лагов на проверку/переключение режимов разрядности, только х64. другой вопрос, что жестокая реальность может всё же заставить усилить защиту цпу от атак чрез спекулятивку и тогда вся гламурная скорость амуди и ынтеля сделает пшикЪ

 

А как у АРМ с индексными регистрами?
Можно ли так?, mov r1,array777[r2+r3*8]

 

Там адресация возможна только (imm), (reg+offset), (pc+offset), и выборка-сохранение в память только ld*/st*-инструкциями. То есть обычной инструкцией можно работать только с содержимым регистра. 'mov r1,array777[r2+r3*8]' станет тремя инструкциями: сдвигом r3 на 3 бита влево, сложением с r2 и выборкой в r1 (r3+array777). Если бы это был не mov, а add например, то 4 инструкции.

 

Кстати, забыл сказать, на самом деле не mov r1,array777[r2+r3*8].
А mov r1, segreg:array777[r2+r3*8]
Аж ТРИ регистра, и все очень быстро работает, максимум за ДВА такта(если данные в кеше), чаще за ОДИН, т.к. успевает пред вычисляться.
Так что нормальная архитектура должна поддерживать индексацию памяти, хотя бы двумя регистрами с масштабированием, желательно 3-х битным.

 

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

 

Есть ли эмуляторы ARM'а, какие лучшие? Чисто одноплатники это разберипай, но это пока накладно.

 

Надо чтобы можно было по программировать на ассемблере, сам точно не знаю, может эмулятор Raspberry Pi или ещё что ни будь в этом роде.
Просто не убедили что ARM круче х86, разве только для всяких тетрисов.

 

Intro, купи андройд приставку, ввали туда линь и чрез ссх гоняй акь хошЪЪЪ