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

И все упрется в скорость памяти, которая к архитектуре процессора отношения не имеет.

>XScale - «32-битный RISC-микропроцессор базирующийся на Архитектуре ARM»

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

>а если взять мат плату с процессором intel и с 4 видеокартами nvidia и задействовать их gpu для вычислений то это тоже формально будет процессорный блок базирующийся на архитектуре intel

Если GPU nvidia будут работать в системе команд центрального процессора и не повлияют заметно на энергопотребление - то, таки да, всё равно будет архитектура Intel.

Тут уже правильно напомнили, что и x86 изначально не имела плавучки. Но сегодня ни один идиот не будет разделять x86 и FPU/MMX/SSE/3DNow.

Или ты считаешь, что в x86 плавучки нет? :)

>Пипец рассуждения, а если взять мат плату с процессором intel и с 4 >видеокартами nvidia и задействовать их gpu для вычислений то это тоже >формально будет процессорный блок базирующийся на архитектуре intel - >в какой тогда г..ой дали будет ваш xscale ?

вы не внимательны - по ссылкам ранее есть уже МБ с возможностью установки видеокарт nvidia & ati ... и "в какой тогда г..ой дали будет ваш Штеуд ?"

Толсто.

>Но сегодня ни один идиот не будет разделять x86 и FPU/MMX/SSE/3DNow

Я про это и говорю, что у x86 fpu by design, если же посмотреть на arm9 на основе которого большинство КПК на xscale, то даже последние из них
http://www.arm.com/products/CPUs/families/ARM9EFamily.html

>Optional VFP9 coprocessor delivers floating-point performance

Про cortex ничего не скажу - потому что я их еще не видел.

>Я про это и говорю, что у x86 fpu by design

Как это by design? Даже у 486 это ещё раздельные компоненты. А взять SSE? Оно и сегодня не на всех процессорах этого семейства есть. Или 3DNow!

На КПК надо малое потребление и нафиг там не нужен FPU.
Снижение тактовой у модуля FPU - это как основной прием уменьшения потребления x86 ( у AMD ) с сохранением общих параметров CPU.

>На КПК надо малое потребление и нафиг там не нужен FPU.

Без FPU кино на КПК не посмотришь.

Офигеть !!,и что же тогда я смотрел ранее на 486SX ? :)))

Это все твои слова:

>Но сегодня ни один идиот не будет разделять x86 и FPU/MMX/SSE/3DNow
>Как это by design? Даже у 486 это ещё раздельные компоненты.

Или современные x86 процессоры уже не проектируют ? :)
Да и в каком это году было ? даже не 10 лет назад. Я вообще не понимаю зачем это было вспоминать, как факт что _когда-то_ на х86 не было fpu ? так когда-то и х86 не было, в общем не понял логику.

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

Можно ещё замерять время работы gcc на каком нибудь тяжелом коде, это более реальный тест. Сейчас попробую.

Какой смысл сравнивать одни и те же fpu прилепленные к разным процессорам?

>Какой смысл сравнивать одни и те же fpu прилепленные к разным процессорам?

Не знаю, думаю никакого смысла, а к чему ты это спросил ? Или ты думаешь что fpu у xscale такой же как у p4 ?

Ну вот,

$ arm-unknown-linux-uclibcgnueabi-gcc -v
...
gcc version 4.3.3 (GCC)

$ time arm-unknown-linux-uclibcgnueabi-gcc -c -Wall -std=c99 -O2 -pipe -I../include/ -D_XOPEN_SOURCE=600 -D__LITTLE_ENDIAN__ -D_VIEW_BACKEND_FB -o view.o view.c
view.c: In function 'main':
view.c:130: warning: unused variable 'dt_min'

real 0m9.771s
user 0m8.661s
sys 0m0.276s

# time gcc -c -Wall -std=c99 -O2 -pipe -I../include/ -D_XOPEN_SOURCE=600 -D__LIT
TLE_ENDIAN__ -D_VIEW_BACKEND_FB -o view.o view.c
view.c: In function 'main':
view.c:130: warning: unused variable 'dt_min'
real 1m 26.26s
user 1m 25.64s
sys 0m 0.58s

octave:8> (1.0 / (t_arm * f_arm)) / (1.0 / (t_x86 * f_x86))
ans = 0.95514

Здесь ARM показывает 95% производиьтельности x86 при одинаковых частотах ядра и различных скоростях памяти и размеров кэшей. Такое сравнение не корректно.

> И все упрется в скорость памяти, которая к архитектуре процессора отношения не имеет.

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

> когда-то и х86 не было, в общем не понял логику.

логика простая - fpu как-бы костыль к x86 и arm.
И надо будет и прилепят fpu к arm намертво , и годочков
эдак через пять, новый imhotep будет задавать подобные вопросы и
не понимать "а зачем это было вспоминать"- ведь у ARM всегда был и есть FPU.:))
От тиража и задач все зависит.

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

Я бы с удовольствием купил бы себе не-x86 машинку, если бы она была по скорости не медленнее x86 и по цене не выше, поэтому со мной бороться точно не придется :) Ессесно наличие 64х бит и аппаратного double обязательно, иначе смысла нет. Но чую такого никогда не случится.

К тому что ARM не DSP, что бы сравнивать его с чем то на только числодробильных задачах, результат будет как и у всех, потому что fpu у всех аналогичны. Это ни чего не скажет о преимуществах и недостатках самого ARM.

>К тому что ARM не DSP, что бы сравнивать его с чем то

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

На самом деле ближе всех к этому Broadcom с 4-х ядерными mips:
http://www.broadcom.com/products/Data-Telecom-Networks/Communications-Process...
И слепить ПК на этом не составляет большого труда.
Кстати , 2-х ядерники MISP у Broadcom уже были раньше чем в x86 на пару лет.
Но зачем им война на рынке ПК за каждый цент и продажные азиаты в союзниках ?
У них свой рынок и свои клиенты ,а лупится насмерть с Intel и Amd - оно им надо ?:))

>Офигеть !!,и что же тогда я смотрел ранее на 486SX ? :)))

1. Я говорил о КПК.

2. На 486SX ты не сможешь посмотреть DivX в 640x480.

Даже для VideoCD мало будет.

>Или современные x86 процессоры уже не проектируют ? :)

ARM - тоже.

>Я вообще не понимаю зачем это было вспоминать, как факт что _когда-то_ на х86 не было fpu ?

Затем, что непонятно с какого рожна ARM с FPU не считать за ARM.

>Затем, что непонятно с какого рожна ARM с FPU не считать за ARM.

Я тебе ссылку давал - fpu не входит в состав ядра arm9, во всех х86 последние 10 лет он запроектирован изначально - это не нашлепка от стороннего производителя. Разница в том что на базе arm делают soc где все нашлепки на том же кристалле что и ядро (ebi, mci, smc, sdramc/ddramc, usb, spi, i2c, lcdc, mac, isi, adc & etc), а на х86 все нашлепки как правило монтируются на плате где ядро - сам центральный процессор. Пойми наконец разницу между soc от конкретного производителя и ядром arm. Как еще тебе это объяснить ? Я не говорю что это не arm просто нельзя сказать что тот же arm9 и утверждать что у него есть fpu.

>Я тебе ссылку давал - fpu не входит в состав ядра arm9

Точно также, как не входил FPU в ядро 486.

>Как еще тебе это объяснить ?

Вот я тем же вопросом задаюсь.

Впрочем, выше про тебя уже хорошо сказали.

> 1. Я говорил о КПК.

А это не честно - как и все время "настольный утюг от Штеуд" сравнивать с CPU в мобильном телефоне.

>>Я тебе ссылку давал - fpu не входит в состав ядра arm9

>Точно также, как не входил FPU в ядро 486.

не входил - не значит что не входит в современные х86

>>Как еще тебе это объяснить ?

>Вот я тем же вопросом задаюсь.

чтобы побыстрей дошло - посмотри тут
http://www.arm.com/products/CPUs/ARM_Cortex-A8.html
>ARMv7 architecture compliant including:
...
* NEON™ signal processing extensions to accelerate media codecs such as H.264 and MP3

Смотрим что такое NEON
http://www.arm.com/products/multimedia/neon/index.html
....
Support for both integer and floating point operations ensures adaptability to a broad range of applications, from compression decoding to 3D graphics.

Вот тут fpu есть by design или ты будешь утверждать что его нет потому что на ARMv5 к которому относится arm9 его не было ?

>Впрочем, выше про тебя уже хорошо сказали.

понятно - мнения пердунов сошлись :)

>>Офигеть !!,и что же тогда я смотрел ранее на 486SX ? :)))

>2. На 486SX ты не сможешь посмотреть DivX в 640x480.

Какой DivX ?! Фантазеры ! Да он на MPEG-1 ляжет в таком разрешении, не говоря уже про DivX. Как раз для вариантов типа 486SX существовали платы-аппаратные декодеры MPEG, только с ними можно было смотреть.

>>>Я тебе ссылку давал - fpu не входит в состав ядра arm9

>>Точно также, как не входил FPU в ядро 486.

>не входил - не значит что не входит в современные х86

Включи мозг. Это значит что fpu просто на одном ядре с cpu. Фактически - это два разных устройства.

> не входил - не значит что не входит в современные х86

Вы вообщее в состоянии архитектуру процессора отличить от коммерческой реализации ?
Завтра на чипе CPU будет стоять светодиод и кнопка RESET или встроенный
БПФ - тоже будете мозги пропаривать о этой "неотьемлемой части " архитектуры CPU ?

Предлагаю всем дебилам сходить все же по ссылке
ARMv7 architecture compliant including
чего тут непонятно, какаие кнопки ресет, вы чего тут все так тупите ? на ядре cortex-a8 neon будет неотъемлемой частью хотят этого дебилы или нет ядро будет содержать его. все soc любых производителей на базе этих ядер будут его содержать. Для более дешевых моделей будут другие модификации cortex - они будут маркироваться соответственно. Прогресс не стоит на месте. Это уже заложено контсруктивно в отличии от arm9 в которых разработчиком не предусмотрен fpu - если он есть в составе soc то это расширение сторонних производителей.

> Предлагаю всем дебилам сходить все же по ссылке

вот сами и проследуйте туда

> Как только ARM без аппаратного декодера научится на декстопе хотя бы 1080p воспроизводить - тогда вернёмся к разговору :)

Встречное предложение, давайте откажемся от SIMD на x86 и обсудим производительность на задаче декодирования h264,1080p? Да, и предварительно драйвер видео переключим на VESA, дабы плеер не пытался возложить часть работы по преобразованию цветовых пространств на видеокарту.

В отличие от аппаратного декодера SIMD вещь универсальная.

>на задаче декодирования h264,1080p?

Я предлагаю Дирак/Шрёдингер 1080p оценить :)

> В отличие от аппаратного декодера SIMD вещь универсальная.

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

> Я предлагаю Дирак/Шрёдингер 1080p оценить :)

:D Не думаю, что что-то из x86 сумеет сделать это.

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

Поэтому в КПК стоят ARM'ы, а на десктопе - x86 :)

>Не думаю, что что-то из x86 сумеет сделать это.

Ну, пускай 720p. Идею-то ты понял? :)

> Ну, пускай 720p. Идею-то ты понял? :)

Конечно понял! и в случае системы на x86(atom) и в случае ARM этот h264,дирак/шредингер будет декодировать GPU :D

>будет декодировать GPU :D

Тогда о какой экономии может идти речь? :)

> Тогда о какой экономии может идти речь? :)

так конкуренция же выгодна экономически для потребителя ;)