[объясните] экономичность ARM

Испытал вот такой тест, http://paste.org.ru/?qhfoav

На ARM920T 180MHz и на Intel(R) Celeron(R) CPU 1.70GHz

X86
$ gcc -o hw -O3 hw.c
$ ./hw
val = fec656a4
time = 968624 usec

ARM
# ./hw
val = fec656a4
time = 3407379 usec

Считаем,
octave:2> t_x86 = 968624.0
t_x86 = 968624
octave:3> t_arm = 3407379.0
t_arm = 3407379
octave:4> f_x86 = 1700
f_x86 = 1700
octave:5> f_arm = 180
octave:10> (1.0 / (t_arm * f_arm)) / (1.0 / (t_x86 * f_x86))
ans = 2.6848

т.е. ARM был бы в ~2.5 раза быстрее при одинаковой частоте.

Надо бы ещё потестить на чем то реально используемом, tremor например.

> Не забываем, что arm это кастрат без fpu.

К арму фпу легко приделать. Это модульная конструкция.

Сравнение MIPS'ов это сравнение сферических коней в вакууме.

Смотрим 2004 & 2005 год:
Intel® I/O Processors
http://www.intel.com/design/iio/index.htm
Many storage, networking, and embedded applications require fast I/O throughput for optimal performance. Intel® I/O processors allow servers, workstations and storage subsystems to transfer data faster, reduce communication bottlenecks, and improve overall system performance by offloading I/O processing functions from the host CPU.
The table below provides a quick overview of the Intel I/O processor family. The Intel® IOP34x family of processors, with Intel XScale® microarchitecture, builds on more than a decade of leadership in I/O processor technology.

--------------

А какое хитрое маркетоидное дурацкое название - IOP3xx :)))
и никто не знает ничего.

Да, тогда все CPU i386 от Intel это полуфабрикаты "общего назначения" :))
Cобственно,IOP34x- это однокристальные системные платы (system on chip -SOC) и если , Atom подползет к этому уровню ... но , весьма это сомнительно . Там уже больше политики чем техники.

> без аппаратного декодера

Это зря, аппаратные декодеры - отличная вещь.

Да и сейчас для этого нужен очень неслабый камень. Аналогов по частоте и количеству ядер среди ARM никто не сделал. А вообще на десктопе эту задачу модно на видеокарту возложить.

>Сравнение MIPS'ов это сравнение сферических коней в вакууме.

сказал, что в лужу пернул.

Если arm такой весь белый и пушистый, чтож у меня он не может выполнить такую тривиальную операцию как прокачать 100мегабит по сети? 100% загрузка проца и 13 мегабит на выходе. С такой операцией даже древние 486е справлялись отлично.

>С такой операцией даже древние 486е справлялись отлично.

лолшто?

А у меня прокачивает и нищебродские ARM9 (и это даже не MIPS 4k) для китайского ширпотреба дают вам обильную пищу для фантазии :))

Еще раз: самые быстрые из живых ARM - это Xscale и поставки их под задницей у Intel.

> С такой операцией даже древние 486е справлялись отлично.
Вот тут ты попал - уж кого , а 486 StrongARM вставлял по всем статьям
ps: найду доки и покажу

>100% загрузка проца и 13 мегабит на выходе

DMA?

>Возьмем теперь Атом - по самым оптимистичным тестам он дает 4MIPS/MHz, потребляя при этом 2 Вт. Даже тут оставание более чем в три раза.

Тесты тестами, а реальные задачи все ставят на свои места, arm9 200 МГц:
# mplayer 1.mp3
MPlayer 1.0rc1.atmel.2-4.2.4 (C) 2000-2006 MPlayer Team
CPU: ARM

Playing 1.mp3.
Audio file file format detected.
Clip info:
Title: A State of Trance 250 (Classic
Artist: Armin van Buuren
Album: A State of Trance
Year: 2006
Comment: broadcasted by DI.fm
Track: 1
Genre: Trance
==========================================================================
Opening audio decoder: [mp3lib] MPEG layer-2, layer-3
mpg123: Can't rewind stream by 34 bits!
AUDIO: 44100 Hz, 2 ch, s16le, 192.0 kbit/13.61% (ratio: 24000->176400)
Selected audio codec: [mp3] afm: mp3lib (mp3lib MPEG layer-2, layer-3)
==========================================================================
AO: [oss] 44100Hz 2ch s16le (2 bytes per sample)

Это топ от него

CPU: 92.7% usr 6.3% sys 0.0% nic 0.0% idle 0.0% io 0.1% irq 0.7% sirq
Load average: 0.34 0.08 0.02 2/22 341
PID PPID USER STAT VSZ %MEM CPU %CPU COMMAND
337 321 root R 5664 19.0 0 98.8 mplayer 1.mp3

звук прерывистый - слушать невозможно.

# mplayer -ac mad 1.mp3

CPU: 10.6% usr 2.3% sys 0.0% nic 86.0% idle 0.0% io 0.0% irq 0.9% sirq
Load average: 0.00 0.05 0.02 2/22 345
PID PPID USER STAT VSZ %MEM CPU %CPU COMMAND
344 321 root R 5704 19.1 0 12.7 mplayer -ac mad 1.mp3


Так что если код не оптимизировать специально под arm (libmad не использует float - только фиксированную точку, целочисленку) то arm однозначно отсосет :)

а если Валуеву от резать руки, выколоть глаза и связать ноги, то его однозначно уделает Вася с раёна, такаова логика что ли?

Какой смысл "не оптимизировать" код risc-процессоры, когда это делать намного проще, чем оптимизировать под x86? Чтоб дебилизм собственный продемонстрировать?

>Так что если код не оптимизировать специально под arm (libmad не использует float - только фиксированную точку, целочисленку) то arm однозначно отсосет :)

Ведь mp3lib оптимизирован для современных x86. А mad как раз "православный". Как и должно быть. Так что назвать mad "оптимизацией" язык не поворачивается.

тесты дурацкие и непонятно чего и как и начем тестировали,
аппаратный декодер mp3 вообще стоит ~ 1 $ на промпоставках и при нулячей загрузке СPU под DMA - это даже микрочип потянет и не сильно "потея".:))

>если Валуеву от резать руки, выколоть глаза и связать ноги, то его однозначно уделает Вася с раёна, такаова логика что ли?

вы не понимаете о чем речь

>Какой смысл "не оптимизировать" код risc-процессоры, когда это делать намного проще, чем оптимизировать под x86?

"оптимизировать" в случае с arm - это отказаться от вычислений с плавающей запятой, если вам так просто от них отказаться - то поздравляю, будете грести деньги лопатой на одних алгоритмах, а пока даже qte таким кодом изобилует, и как то не могут они от него отказаться - глупцы которым отрезали руки и ноги ?

>"оптимизировать" в случае с arm - это отказаться от вычислений с плавающей запятой, если вам так просто от них отказаться - то поздравляю, будете грести деньги лопатой на одних алгоритмах, а пока даже qte таким кодом изобилует, и как то не могут они от него отказаться - глупцы которым отрезали руки и ноги ?

А ничего, что mp3 по своей сути и есть оперции _без_ плавающей точки?

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

>А mad как раз "православный". Как и должно быть. Так что назвать mad "оптимизацией" язык не поворачивается.

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

>mad уже пять лет не обновляется. Изюминка его как раз в цеолчисленных >вычислениях и оптимизирующих ассемблерных вставках - если это не >оптимизация то что тогда вообще можно назвать оптимизацией ??

"оптимизирующих ассемблерных вставках " ну хоть сами читайте ЧТО пишете
А вставки видимо для AVR & MIPS ? :)))

>mad уже пять лет не обновляется. Изюминка его как раз в цеолчисленных вычислениях и оптимизирующих ассемблерных вставках - если это не оптимизация то что тогда вообще можно назвать оптимизацией ??

АФАИК изначально mp3 - целочисленный алгоритм.

Да и само утверждение идиотское "что ж это за процессор, если под него оптимизировать надо?".

>"оптимизирующих ассемблерных вставках " ну хоть сами читайте ЧТО пишете
А вставки видимо для AVR & MIPS ? :)))

Ты в исходники libmad хоть раз заглядывал клоун ?
imdct_l_arm.S

>АФАИК изначально mp3 - целочисленный алгоритм.

Ну и дальше то что ? Есть альтернативы libmad который не разввивается использующие "изначальный" подход ?

Добавлю ещё вот это,

# gcc -o hw -O3 -mthumb hw.c # ./hw val = fec656a4 time = 2827546 usec

16-бытный thumb код, увеличил разрыв до ~3.2 раза :)

>Ну и дальше то что ? Есть альтернативы libmad который не разввивается использующие "изначальный" подход ?

Есть. mpg321 например.

>Ты в исходники libmad хоть раз заглядывал клоун ?

болтун доки на Xscale конкретно смотрел ?
а общеколхозная ARM реализация от 2001 не впечатляет.


The Intel XScale® core implements the integer instruction set architecture specified in ARM
V5TE. T refers to the Thumb instruction set and E refers to the DSP-Enhanced instruction set.
ARM V5TE introduces a few more architecture features over ARM V4, specifically the addition of
tiny pages (1 Kbyte), a new instruction (CLZ) that counts the leading zeroes in a data value,
enhanced ARM-Thumb transfer instructions and a modification of the system control coprocessor,
CP15.

>Есть. mpg321 например.

хотя там тот-же mad кажется. Но так или иначе - mad есть и баста.

>>АФАИК изначально mp3 - целочисленный алгоритм.

>Ну и дальше то что ? Есть альтернативы libmad который не разввивается использующие "изначальный" подход ?

вот как ARM обороты набрал так и появятся подходящие решения. Хватит метанировать.

>болтун доки на Xscale конкретно смотрел ?
а общеколхозная ARM реализация от 2001 не впечатляет.


>The Intel XScale® core implements the integer instruction set architecture specified in ARM
V5TE.

arm926ej-s тесты на котором я приводил это и есть ARM V5TE в общеколхозной реализации, а system control coprocessor которым ты видимо хотел удивить это вовсе не тот сопроцессор о котором ты подумал :)

>Хватит метанировать.

Собственно я не метанировал а привел конкретные факты, тебе про себя лучше знать :)

>arm926ej-s тесты на котором я приводил это и есть ARM V5TE в >общеколхозной реализации, а system control coprocessor которым ты >видимо хотел удивить это вовсе не тот сопроцессор о котором ты >подумал :)

возьми документацию тогда на Xscale и сам посмотри
код там написан с учетом горбатости компилятора и чтоб работало на ВСЕХ
ARM - вот и вся оптимизация.

>код там написан с учетом горбатости компилятора и чтоб работало на ВСЕХ
ARM - вот и вся оптимизация.

Я вижу ты знаток в части оптимизации :) Чтобы работало на ВСЕХ - наоборот от ассемблерных вставок избавляются - для этого есть ключи компилятора через которые можно заточить код под конкретный процессор даже тот которого еще не было при написании кода. Там ассемблерный код - чистой воды оптимизация под конкретные архитектуры.

>Я вижу ты знаток в части оптимизации :) Чтобы работало на ВСЕХ - >наоборот от ассемблерных вставок избавляются - для этого есть ключи >компилятора через которые можно заточить код под конкретный процессор >даже тот которого еще не было при написании кода. Там ассемблерный >код - чистой воды оптимизация под конкретные архитектуры.

Ну возьми ключами и заточи и получи точно такой же код на выхлопе в ассемблере .
зы :подобный финт удавался мне только на AVR & IAR C:)))

> $ time ./test real 14m 22.74s user 10m 7.17s sys 0m 0.08s

всего 14 минут, в юзерспейсе 10, в ядре 0. Зачем ты мешал ему работать 4 минуты? :-)

>И что работать на таком можно?

Ну, я с линуксом _работал_ на 486dx 33МHz. Т.ч. можно.

>Не забываем, что arm это кастрат без fpu.

Все нормальные КПК - с FPU :) Без FPU - только совсем уже дешёвка на Самсунгах и ОМАПах.

>т.е. ARM был бы в ~2.5 раза быстрее при одинаковой частоте.

В тесте у тебя где-то ошибка.

>А вообще на десктопе эту задачу модно на видеокарту возложить.

Так это, как раз, неважно. Видеокарта (с той же CUDA) в этом случае просто внешний универсальный сопроцессор. Который всё равно будет десятки ватт жрать.

>Вот тут ты попал - уж кого , а 486 StrongARM вставлял по всем статьям

Так чего тут сравнивать. 486 - это 266MIPS у самых последних топовых. Массовые ARM - это от 206 до 600+MIPS. Чаще от 400 до 520. Новые - уже за 1000MIPS.

>Все нормальные КПК - с FPU :)

Потому что эти КПК на xscale и подобных. К arm эти fpu имеют такое же отношение как рюказак к туристу - он с ним не родился :)

>Какой смысл "не оптимизировать" код risc-процессоры, когда это делать намного проще, чем оптимизировать под x86?

Кхм. А вот компиляторщики говорят, что оптимизировать под RISC намного сложнее. Сложность оптимизации экспоненциально растёт с ростом числа РОН. У современных RISC часто в компилированных программах 3/4 регистров оказываются вообще не задействованы :) (у меня несколько знакомых под ARM коммерческий софт пишут - жаловались ;))

> Потому что эти КПК на xscale и подобных. К arm эти fpu имеют такое же отношение как рюказак к туристу - он с ним не родился :)

А прикол : x86 c fpu тоже не родился :)) новость ?
тады в google шукать 8087 сопроцессор fpu :)))

>Потому что эти КПК на xscale и подобных. К arm эти fpu имеют такое же отношение как рюказак к туристу - он с ним не родился :)

XScale - «32-битный RISC-микропроцессор базирующийся на Архитектуре ARM». У тебя рюкзаки являются производными туристов? :)

Потребляют XScale тоже они как и любые ARM'ы.

Всё остальное - шашечки.

>Кхм. А вот компиляторщики говорят, что оптимизировать под RISC >намного сложнее. Сложность оптимизации экспоненциально растёт с >ростом числа РОН. У современных RISC часто в компилированных >программах 3/4 регистров оказываются вообще не задействованы :) (у >меня несколько знакомых под ARM коммерческий софт пишут - жаловались ;))

если речь о gcc - то ничего удивительного тут.

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

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

Кроме того, предлагаю Reset'у следующий тест: а пусть он сравнит включит в сравнение процессоры Intel с _отключенным_ кэшем. Посмотрим, что умеет "архитектура". Какой смысл? Ну а такой, что добавить быстрый кэш к проце не проблема, тем более что, его объем можно подстроить под требуемое энергопотребление и производительность

>Да и большая производительность на единицу частоты, чем у x86

Откуда?
ARM == RISC.
x86 == CISC.

У RISC команды короткие, они одного размера, но их нужно много.
У CISC команды переменного размера, и их нужно столько, сколько нужно.
За счёт "гонки мегагерц" с одновременным поднятием кэша CISC опередили в своё время RISC и похоронили DEC Alpha. С выходом Pentium-II для RISC всё было предрешено. А медный Athlon Thunderbird от 650МГц окончательно похоронил RISC в массовом сегменте за счёт открывшихся перспектив продолжения "гонки мегагерц" и дальнейших оптимизаций эксклюзивного кэширования L1/L2.

Это да, моя ошибка. Особенно если учесть особенности архитектуры последних intel.

> У RISC команды короткие, они одного размера, но их нужно много.

У ARM есть возможность на ходу менять форматы команд:
(thumb mode) 16 экономичние по коду или 32 разрядные и быстрые (arm mode )

> С выходом Pentium-II для RISC всё было предрешено.

Не-а ,c выходом Pentium-III.

>А медный Athlon Thunderbird от 650МГц окончательно похоронил RISC в >массовом сегменте за счёт открывшихся перспектив продолжения "гонки >мегагерц" и дальнейших оптимизаций эксклюзивного кэширования L1/L2.

нифига , только массовость и технологии - и практически любого "черта горбатого" можно заставить при хорошем кэше L1/L2 выглядеть прилично.

Появление на рынке ПК решений на MIPS 64 может вызвать кандражку у Intel :)) НО, тогда надо иметь решимость бороться почти со всем миром
и полчищами Reset-ов.

Посмотрим что на Tegra выйдет.