aasheron чистый risc сдох еще в пеленках... я часто не понимаю что вы пытаетесь донести.
сечас все risc подобные архитектуры прекрасно справляются с simd. у них есть проблемы из за использования "укороченных команд" но не более. проблемы х86 в лице "cisc архитектуры с risc подобным ядром" более сложно решаемые - у них есть одно ед приемущество "больше наработанных инструментов для решения этих проблем" что на мой взгляд не удивительно. но опять есть подводный камень если будет глобальное обновление начинают всплывать косяки в этих самых инструментах. и тут опять risc в лице арма выигрывает более новые инструменты и более прогнозируемое развитие (потому что за время лидерства х86 инструментов разработки под армы было мало "да и кому это нужно" - сейчас все поменялось инструменты не только нужны но и пишутся они "свежачком" с понятно дело более документированные + развитие арма это х86 наши дни то есть в чем то они идут дальше но в большинстве копируют идеи х86 что тоже наруку разработчикам).
тут я думаю не стоит касаться различных risc подобных спарков и др. и vliw подобных интеловских поделок от которых он к стати не отказался до сих пор. я еще раз подчеркну не надо виснуть на тему "это лучше потому что проверенно и работает" иногда оно устаревает а с учетом х86 это как когда то про что то в линукс среде писали "попытка ремонтировать машину на оживленной трассе так еще и на ходу"... слишком много "заплаток и заклепок" и отказаться от совместимости брацы тож не могут.

Добавлено спустя 4 минуты 21 секунду:

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

Для справки, в арм есть несколько наборов инструкций, в том числе и самб с 16-и разрядными инструкциями. И ничо, все нормально переваривает, яб даже сказал, замечательно. Неон, кстати, это сопроцессор со своим набором инструкций. К arm, или thumb имеет ровно такое-же отношение, как и sse к x86.

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

А в магазине вы тоже будете на девбордах показывать превосходство АРМ?

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

Приходит молодой человек через пару лет в магазин планшет покупать и не знает что выбрать, на ARM или Intel. Хотя впрочем они и слов таких не знает, а продавец ему раз, и Кризис на планшете запустил, а Кризис я думаю, что он знает и выбрал чувак intel. Главное, что-бы денег хватило.

Не надо открывать мне таких секретов, я разрабатываю приложения под ARM, и могу сказать, что архитектура процессора в мультимедийных приложениях (а смартфоны и таблетки решают на 90% мультимедийные задачи) решает полностью - разница легко ощутима на примере использования SIMD движков - Neon и SSE-подобных .

Не знаю, что вы имели ввиду под порядком чередования байт. Я знаю порядок нумерации байт.

С'шные битовые хаки и ассемблерные операции используются часто - посмотрите библиотеки libjpeg, ffmpeg - добрую часть кода занимают функции, оптимизированные под конкретные железки.

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

Единицы пишут на асме/с ассемблерными вставками. Опять же, 95% софта никоим образом низкоуровневые оптимизации не юзает.


Битовые хаки не проблема, если программист догадывается о существовании архитектур с различным endianness. Потому и говорю - с ровными руками не страшно.
По поводу асм-вставок - а какая собссно разница, под какую архитектуру писать на асме? Не, ну кроме привычки ессно к тому или иному процу - ведь арм-разработчики с тем же успехом будут называть х86-андроиды, под которые их заставят пилить native библиотеки, неудобным говном (и будут правы).


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

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