Теорема о ненужности и бесполезности, x86 архитектуры во встраиваемых системах Опции

[Evgeny_CD]

(С) на название - великий VLV
>>>>>>>>>>>>>>>>Доказательство №1<<<<<<<<<<<<<<<<<<<

http://www.slame.ru/support/katalog/mb_via_epia5000a.html
Смотрим внимательно. Что мы видим?
* два нехилых радиатора
* димовницу для DIMM
* PCI разъем
* Game, Sound (AC97), VGA

http://www.via-c3.ru/products/Eden/eden.shtml#pow
Смотрим внимательно. Мощность процессора от 3 до 5 Вт (второе значении, очевидно, более реальное). + еще мощность VT8601A North Bridge. Итого ватт 10 на устройство получим.

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

Ладно, питания нам не жалко, пусть жрет, сколько влезет – мы обдуем. Но вопрос в том, что мы получим за эти деньги???

IBM PC AT архитектуру. А оно нам надо? Все равно она скрыта от нас той или иной Осью, и нам на нее наплевать.

VGA контроллер. Круто, но зачем? Каков процент встроенных устройств нуждается в дисплее хотя бы 320x240x8 бит?

Разъемы для мыши и клавиатуры? Видеовыход? USB разъемы? Последнее хотя бы теоретически полезно.

PCI? Очень полезная вещь! Но есть много хорошего на эту тему
http://www.netsilicon.com/pdf/prd_nap_ns9750.pdf
http://www.freescale.com/files/microcontro...t/MPC5200TS.pdf - вообще сказка
на оба камня отладочные комплекты стоят в районе 1к евро – не так уж и фантастически дорого.

""Родное" x86 исполнение" (с сайта www.via-c3.ru) Вот оно!!!!

Вообще ситуация с x86 архитектурой мне напоминает следующее. ((С) из какой-то статьи в Компьютерре).

Представим, мы выпустили "копейку". Машина как машина, дешевая, неплохая. Она стала популярна. Мы заработали денег. Много денег.

Конкуренты осознали, что к чему. И готовят наступление. Что делать? Приходит маркетолог и говорит: "Наша машина должна ехать со скоростью 200 км/час!". Главный конструктор покрутил пальцем у виска и сказал: "Нужен полный редизайн. Надо M лет и N m$.". Но на беду маркетолог был с "фантазией" и предложил: "А давайте модернизируем дороги, чтобы слегка модернизированная копейка смогла ехать с нужной скоростью!". Подсчитали. Выяснилось, что основная масса юзеров ездит по ограниченному количеству дорог. На каждую такую дорогу поставили по комплексу, который ехал впереди машины и правил дорогу (уклоны, покрытие с допуском +- 1 мм и т.д.). На копейку поставили обтекатель, затьюнинговали подвеску, поменяли главную пару в коробке – и о чудо! Копейка поехала со скоростью 200 км/час. Юзеам объяснили, что им не надо покупать новый комплект инструментов, и что ключи от старой копейки подойдут к новой (хотя для 200/км час копейку надо сменить, и новая стоит как много наборов ключей – но этого юзерам уже не объяснили).

Прошло время. Мы снова заработали денег. Много денег. И снова конкуренты готовят засаду. Тот самый маркетолог говорит: "Надо 1000 км/час!". Фишка с "препроцессором дороги" уже не катит. Даже точность покрытия +-1 мкм, и громадный всасывающий вентилятор перед мордой у копейки не помогают – возникает резонанс в подвеске, и машина просто разлетается на части (ну не было у изначальной машины запаса прочности на 10 порядков!) Что делать? Выход есть!!! Мы механизируем дорогу, чтобы она ехала нам навстречу со скоростью 1000 км/час, а сам "механизатор" пустим со скоростью 200 км/час (машину подвешиваем в воздухе при помощи сильного магнита). По краям дороги пустим "механизированные" (а другую сторону) деревья, и юзерам будет казаться, что они едут с фантастической скоростью 2000 км/час!!!! Конкуренты повесились, у нас денег уже девать некуда.

Перед третьей итераций занавес предусмотрительно опускается. (К сожалению, архитектура P IV очень сильно напоминает этот "механизатор").

Вернемся в embedded мир. Что нам надо от этого Эдена? MMX? 533 мгц тактовой? Что они будут делать в нашей системе? Окошки рисовать? Но у нас нет экрана!!!! Да ничего нам от него не надо!!!!

Я уже не говорю о димовнице, которая не способствует надежности. И о том, что индустриального диапазона не будет в принципе (для этого конкретного решения). И что питается это все от ATX блока питания (ну-ка, покажите мне конвертер 12V -> ATX? Цена?).

http://www.via-c3.ru/pdf/epia_sales_kit.pdf - руководство по продажам! Вот оно, материализованное зло!

Что делать?

1. Искать.
Есть более удачные решения в области x86.
http://www.icop.com.tw/products_detail.asp?ProductID=223 (там много подобного, например http://www.icoptech.com/products_detail.asp?ProductID=119). Не думаю, что это будет стоить дороже ВИА.
* память запаяна
* процессор жрет много меньше, и эффективность по тактовой у него гораздо лучше. Это SIS 55x
http://www.sis.com/products/sis55xfamily_features.htm
http://www.dmp.com.tw/tech/hardware.htm#vortex86
http://www.vortex86.com/feature.htm
Когда-то на сервере SIS лежала дока, там было подробное сравнение SIS 55x с другим архитектурами – сейчас ее убрали, но у меня она есть, кому надо – пишите на мыло с SUBJ SIS_55X – вышлю.

Была еще фирма, она несколько лет назад чуть было концы не откинула, но вроде ожила
http://www.zflinux.com/pdf/ZF_IP_Returned_Final_4-7-05.pdf
У них очень интересный девайс
http://www.zflinux.com/zfx86.html

2. Выкинуть x86 нафиг!!!!
http://www.embeddedarm.com/
Что, кому-то ресурсов TS-7250, TS-7200 не хватит??? Так ВИА едва ли даст больше. Чего Вам на этой плате не хватает? Linux стоит. Патченный тулчейн под цигвин имеется. Дока наличествует. Понял!!! Негде мышкой ездить, набрасывая классы в проект в красивой графической IDE!!!

>>>>>>>>>>>>>>>> Доказательство №2<<<<<<<<<<<<<<<<<<<

http://www.rodnik.ru/htmls/pr_110403.htm
http://www.lantronix.com/device-networking...vers/xport.html

Проц, на котором все это сделано
http://www.lantronix.com/device-networking...x_dstni-ex.html

Я понимаю, что есть мазохисты, но не до такой же степени…Эти, вероятно, без segment:offset жить не могут. Что они такого уникального в этом проце нашли? Что, весь этот код нельзя перетащить под ARM какой-нибудь, да прицепить флешак с Ethernet'ом? (все равно внутри девайса многокристальная сборка – чипы даже в BGA не влезут по размерам. Не уж то custom (без корпуса) Cirrus EP9302, на котором TS-72хх сделана, будет дороже???) И не возиться со своим чипом.

http://www.cirrus.com/en/pubs/proBulletin/EP9302-pb.pdf
камень от цирруса

А все лень матушка. 10 лет назад какой-то студент залобал на VHDL ядро x86, они его купили, и понеслось… "А зачем? Вроде работает…".

Что касается http://www.1st-mile.net/product.php, www.netping.ru и других подобных контор, то когда вышел MC9S12NE64 от http://www.freescale.com/,
(http://www.telesys.ru/wwwboards/mcontrol/1059/messages/104989.shtml - ветка по процу)
думаю, они все упились в усмерть, ибо этот чип открыл перед ними такие перспективы…

Кстати, есть еще очень интересный чип почти на эту же тему
http://www.cyantechnology.com/ecog
Ethernet в нем нет, но если прикрутить какой-нибудь Realtek 8019, то можно будет очень даже зажигать! Цены обещаны очень интересные. Эти
http://www.premier-electric.com/
им занимаются

http://www.linuxdevices.com/articles/AT4313418436.html
нехилый обзор архитектур всяких

И вообще, если вдруг Вам покажется, что после освоения ARM/MIPS/PowePC наступит нирвана, гляньте сюда
http://www.tensilica.com/html/xtensa_lx.html
а потом сюда
http://www.ptsc.com/benchmarks/index.html
ссылку дал =AK=.

"Покой нам только снится!"

[AndrewKirs]

x86 тащит за собой жуткое количество устаревшего барахла - достаточно взглянуть на справочник по командам. Несколько сотен инструкций! Конечно, совместимость, я все понимаю, но есть сильное ощущение какой-то телеги с мусором. MMX/SSE/SSE2 трудно назвать удачными расширениями. Наверное, у Интела просто не осталось способа резко поднять производительность. Но получить хорошее ускорение хоть на MMX, хоть на SSE2 весьма непросто, в том числе из-за накладных расходов. Кстати, искать подстроку на MMX - по-моему, сомнительная идея. Как мало-мальски изящно проверить результат? Проще сравнивать строки как 32-битовые integer без всякого MMX. Уже быстрее, чем побайтно.

Эх, сам был энтузиастом лет 5-6 назад

[defunct]

Кстати, искать подстроку на MMX - по-моему, сомнительная идея. Как мало-мальски изящно проверить результат? Проще сравнивать строки как 32-битовые integer без всякого MMX. Уже быстрее, чем побайтно.

Это не сомнительная идея. Это уже реализованная и проверенная идея. В fastcode первое место заняли функции поиска именно с использованием MMX. Можете посмотреть результаты и взять исходники заинтересовавших вас функций http://dennishomepage.gugs-cats.dk/PosChallenge.htm
ссылка у меня почему-то в данный момент не открывается, но взята она из вполне достоверного источника:
http://qc.borland.com/qc/wc/qcmain.aspx?d=14084

Если вам интересна эта тема, то у меня где-то осталась тестовая программа А. Шарахова, которая позволяет довольно изящно проверить результат. В программе проверяются и сравниваются по быстродействию различные функции поиска, написанные под IA-32 и под все виды ускорителей для x86. Сам когда-то хотел принять участие в PosChallenge, но не сложилость.

[AndrewKirs]

Это не сомнительная идея. Это уже реализованная и проверенная идея. В fastcode первое место заняли функции поиска именно с использованием MMX. Можете посмотреть результаты и взять исходники заинтересовавших вас функций http://dennishomepage.gugs-cats.dk/PosChallenge.htm

Очень хочу посмотреть, но эта (первая) ссылка у меня дала ошибку 404.

ссылка у меня почему-то в данный момент не открывается, но взята она из вполне достоверного источника:
http://qc.borland.com/qc/wc/qcmain.aspx?d=14084

Если вам интересна эта тема, то у меня где-то осталась тестовая программа А. Шарахова, которая позволяет довольно изящно проверить результат. В программе проверяются и сравниваются по быстродействию различные функции поиска, написанные под IA-32 и под все виды ускорителей для x86. Сам когда-то хотел принять участие в PosChallenge, но не сложилость.

Эта вторая ссылка открылась, там сказано про программу А.Шарахова, которая "3.20 times faster than the current RTL Pos function". Но при этом "It is using basic IA32 instructions only and will run on all processors after 386." Если у вас есть исходный текст поиска с ММХ, интересно было бы посмотреть. Хотя бы на ключевые операторы. Учиться никогда не поздно.

[defunct]

Эта вторая ссылка открылась, там сказано про программу А.Шарахова, которая "3.20 times faster than the current RTL Pos function". Но при этом "It is using basic IA32 instructions only and will run on all processors after 386." Если у вас есть исходный текст поиска с ММХ, интересно было бы посмотреть. Хотя бы на ключевые операторы. Учиться никогда не поздно.

Новых функций, о которых на той странице идет речь у меня нет.
Есть тестовая программа за 2004 год с исходниками на которой тестировались функции, тогда еще Шарахов не писал свои функции на ассемблере, но там есть моя функция (posdefmmx), написанная совместно с GuAV, не принимавшая участие в fastcode и функции John'a PosJohnMMXA/B на 2004-й год - победители PosChallenge. Программу с исходниками прикрепил. Существенный выигрыш от MMX проявляется естественно только при поиске в длинных строках (SubBench2 в программе), на коротких строках там поиск выполняется на IA-32.

Прикрепленные файлы

 PosBV.zip ( 295.58 килобайт ) Кол-во скачиваний: 44

 

[AndrewKirs]

Новых функций, о которых на той странице идет речь у меня нет.
Есть тестовая программа за 2004 год с исходниками на которой тестировались функции, тогда еще Шарахов не писал свои функции на ассемблере, но там есть моя функция (posdefmmx), написанная совместно с GuAV, не принимавшая участие в fastcode и функции John'a PosJohnMMXA/B на 2004-й год - победители PosChallenge. Программу с исходниками прикрепил. Существенный выигрыш от MMX проявляется естественно только при поиске в длинных строках (SubBench2 в программе), на коротких строках там поиск выполняется на IA-32.

Спасибо, скопировал, буду изучать. Сообщу, что получилось. Почему засомневался - писал как-то FastCopy на SSE2. На коротких строках победил IA-32, на длинных - SSE2, но, насколько помню, исключительно за счет unrolled пар movdqa/movntdq.

[defunct]

писал как-то FastCopy на SSE2. На коротких строках победил IA-32, на длинных - SSE2, но, насколько помню, исключительно за счет unrolled пар movdqa/movntdq.

В задаче поиска ускорение за счет pcmpeqb и movq (с выравниваением на границу QWord).

[AndrewKirs]

Так, вроде разобрался. У вас основную работу делают характерные группы операторов типа:

Метка:
MovQ MM7, [EDx] // load a part of buffer that needs to be scaned
PCMPEQB MM7, MM6 // make a bit mask (mm6 filled by 1st char of da constant)
PACKSSWB MM7, MM7
MovD EAx, MM7 // get mixed dword
Test EAx, EAx // was there at least 1 bit set?
Jnz CharFound2 // yes - 1st char of the constant was found

Add EDx,8 // correct index
Sub ECx,8 // and buffer size
Cmp ECx,4
Jg Метка

Здесь вы ищете начало совпадения строки и подстроки - это в общем случае бОльшая часть работы.
То же самое можно сделать иначе. В моем примере ecx содержит число слов в строке, а edx в каждом байте - искомый начальный байт подстроки:

MainCycle:
mov esi, DWORD PTR[edi] // Загружаем очередные 4 байта строки
xor esi, edx

test esi, 0xFF
jz short Lab_1
test esi, 0xFF00
jz short Lab_2
test esi, 0xFF0000
jz short Lab_3
test esi, 0xFF000000
jz short Lab_4

add edi, 4
sub ecx, 1
jnz short MainCycle

Метки Lab_1..Lab_4 можно использовать, например, так:
Lab_4:
add eax, 1
Lab_3:
add eax, 1
Lab_2:
add eax, 1
Lab_1:
add eax, 1

тогда получим индекс искомого байта в DWORD. Или можно сдвигом получить совп.байт+остаток регистра (чтобы сравнивать дальше).

В тесте я брал строки разной длины и искал в них заведомо отсутствующий байт. Результаты получились следующие (на двух разных ПК с P4):
строка 1000 байт: версия IA-32 быстрее на 10-20%
строка 4000 байт: ММХ и IA-32 примерно равны
строка 8Мб: ММХ быстрее на 13-25%

MMX кроме графики применим хотя бы для банального поиска подстроки в строке (сравнение сразу 8 байт с одним шаблонным байтом) и подобных задач. Выигрыш по сравнению с IA-32 получается коллосальным (в 4-5 раз).

Где же здесь 4-5 раз?

Выходит то, о чем я и говорил: получить серьезное ускорение с SIMD-расширений x86 непросто. Лично мне это удавалось на операциях типа умножений векторов, или при параллельном делении - тогда IA-32 отстает безнадежно. Но и то, требуется полный цикл оптимизации, начиная с алгоритма (скажем, для ММХ - переход к целочисленному варианту).

[defunct]

В тесте я брал строки разной длины и искал в них заведомо отсутствующий байт. Результаты получились следующие (на двух разных ПК с P4):
строка 1000 байт: версия IA-32 быстрее на 10-20%
строка 4000 байт: ММХ и IA-32 примерно равны
строка 8Мб: ММХ быстрее на 13-25%

Неправда Ваша. Результаты и близко не соответствуют действительности. Пересмотрите пожалуйста. Для проверки можете использовать приведенную выше программу Шарахова. (Длинными там считаются строки более 64 байт).

[AndrewKirs]

Неправда Ваша. Результаты и близко не соответствуют действительности. Пересмотрите пожалуйста.

Что ж, вполне мог и ошибиться. Но ведь я привел код, который сравнивал. Что-то в нем неадекватно?

Для проверки можете использовать приведенную выше программу Шарахова.

Уточните, пожалуйста, это файл PosBV.zip? Если да, то код MMX взят именно оттуда.

(Длинными там считаются строки более 64 байт).

Интересный вопрос, что такое длинная строка. По-моему, если она помещается в 2..4 линии кэша, то длинной ее считать нельзя.