(С) на название - великий 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=.

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

Моё мнение - очень часто бывает, что под рукой есть готовые решения для x86, банда программеров под x86, и крайне сжатые сроки разработки. Потому и лепят на промкомпах что попало и кто попало. И закладывают P4 2GHz с WindowsXP embedded (это вообще sic! - в нашем политехе есть люди, которые развивают систему модернизации АЭС именно в таком варианте оборудования).

Зашибись! А где там Ваша АЭС расположена? Надо на карте флажек поставить. И никогда к той точке ближе чем на 100 км не подъезжать.

Программеров для x86 не бывает. Либо это программер, и ему надо 1 мес для освоения новой архитектуры, либо это ацтой, и надо дать ему швабру в руки, а не клавиатру.

За написание непортируемого кода надо расстреливать сразу.

А подобрать грамотные средства разработки и доку - это уже задача менеджера.

Почему именно x86? Потому что C#/MicrosoftAPI/VisualStudio. Под другие платформы этого нет... И слава богу.
А расстрел тогда придётся начинать с Билла - за самое большое количество непортируемого кода

Да TS 7250 штука потрясающая. Только мне не найти, кто ей торгует в розницу в России.

Может подскажите где можно пару штук купить.

Есть еще военные. Из-за них мы (т.е. у нас в конторе) МНОГО лет тянем х86 за собой. Даже 486, который сейчас снимают с производства, мы, очевидно, будем делать на ПЛИС. Я, мягко говоря, ругался с ними на эту тему, но надо признать, что у них тоже есть резоны.

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

"Теорема о ненужности и бесполезности"

Фигня все это! Вы не используете, не значит что другие не используют. А раз они используются -> небесполезны! Что в вашем понимании встраиваемые системы? Лично я мобильных роботов отношу тоже к "встраиваемым системам", т.к там используется такая же электроника как и везде! У меня скажем есть кое какие программы для работы с видео, распознования образов, речи и т.д. Что прикажете, на вашем любимом арм все это по второму кругу городить?Мне че делать больше нефиг, когда места в роботе хватает и питание позволяет. Тем более что эти "обычные" армы с этим не справятся, да и по цене платки с их участием мне гораздо дороже выглядят.


Ну мне надо. даже не 1 а 3 ЖК, на двух глаза выводятся на третьем рот!

Помимо всего прочего, не стоит забывать и о "доступности" всех рекламируемых вами плат!
Мое мнение-вы фанат арм! Эта обычная, одна из многих архитектур не лучше не хуже других, а вы пытаетесь всех своими постами склонить к их использованию. Думаю в 99% это бесполезно.
Я привел простой пример где одноплатники виа имеют большое преимущество, думаю если каждый поднапрежется можно будет еще 1000 примеров привести где арм-бесполезная вещь.

Неа. Фанат здравого смысла!

Если робот размером с танк- тогда ок.

Что касается переносимости - обычно серьезные проекты пишут переносимо, с HAL, ОСью и прочими давно придуманными фишками, которые позволяют забыть об аппаратуре. Или у Вас все на асме под DOS?

Для обработки multimedia давно DSP придуманы, использование любого (в том числе ARM) процессора общего назначения в качестве серьезного DSP - глупость.

Естественно, что выбирать - решать только Вам. Ну и Вашим потребителям

Да ладно вым скромничать. Была б у вас возможност вы б наверное все пики, авр и прочее(все что не арм) запретили бы продовать, как ненужное барахло



Ну до танка нам далеко, а питаемся от автомобильного аккума 80 Ампер/часов.



Написано все под винду, и кое что под qnx, не мной. Не имею ни малейшего желаие переносить куда либо и вообще в этом ковырятся



Это правильно конечно, но пока ни мозгов не хватит ни денег с ДСП заниматься, маленький еще.

P.S.
И все таки одноплатники виа это хорошо когда места много, но не спортивно.

а как же MMX, SSE, SSE2 и прочие SIMD ускорители. Или сопры, такого класса тоже отнести к DSP?

MMX, SSE,SSE2 в основном больше подходят для графики. Сам когда-то баловался с преобразованием цветов, интерполяцией с помощью этого.

А что x86 уже делает аппаратно бабочку ?
А поддержка кольцевых буферов на аппаратном уровне ?
А где нормальный ПДП, все через зад для совместимости с СТАРЫМ барахлом, хватаем по очереди PCI Bus Master.

А чем хуже AltiVec - Нормальная подсистема векторного вычисления тоже 128 бит. А потребляет G4 всетаки поменьше PIII.

Ну не должен ЦП заниматся графикой - для этого есть свой специальный процессор. Все четко разделено по кирпичикам.

Абсолютно согласен с этим пунктом! Это одно из самых узких мест x86 архитектры применительно к embedded решениям с большим объемом I/O. Современные процы с Descriptor DMA позволяют просто "вышивать крестиком" в памяти - и это очень экономит ресурсы ядра.

Насчет перого - так то оно так, хотя и не совсем. MMX кроме графики применим хотя бы для банального поиска подстроки в строке (сравнение сразу 8 байт с одним шаблонным байтом) и подобных задач. Выигрыш по сравнению с IA-32 получается коллосальным (в 4-5 раз).
SSE2 и более новые ускорители, чем не подойдут скажем для расчета например ДПФ? По две/четыре экспоненты за раз.


Меня судьба x86 не особо-то волнует. Вопрос на который хотелось бы услышать ответ - можно ли мат. сопроцессор с SIMD ускорителем назвать DSP..

Вообще-то, любой процессор, способный обрабатывать сигнала, можно назвать DSP. Вопрос состоит в том, какие это сигналы и какое время потребует обработка этих сигналов. Специализированные DSP строятся таким образом, чтобы это время существенно сократить. Типичная операция при обработке - вычисление интеграла свертки. Здесь происходит умножение входного сигнала на некоторый коэффициент и накопление частичных произведений. В DSP такая операция реализуется в виде одной специальной инструкции, которая к тому же часто выполняется за 1 такт. Кроме того, для устранения ошибок округления или переполнения АЛУ в таких процессорах делается повышенной разрядности.
Если же больших требований к быстродействию процесоора не предъявляется (сигналы лежат в области низких частот), то в качестве DSP можно использовать любой подходящий контроллер общего назначения, хоть автономно, хоть с сопроцессором.

Наверное признаком DSP является не только наличие быстрого умножителя с накопителем, а в значительной мере, аппаратная поддержка пересылок без команд mov и аппаратная поддержка организации циклов: индексации в массивах и переходов. В общем всего, что связано с матричными вычислениями

Я как раз об этом и написал. Выполнение цикла за 1 такт.

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

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

Видимо, это какой-то тайный закон Мэрфи, который знают Интел & AMD. Как говорят дети "почему все, что полезное - невкусное?". На свете существует штук 5 правильных процессорных архитектур MIPS | PowerPC | Alpha | Sparc | ARM ( с некоторой натяжкой ) - но их суммарные тиражи много меньше, чем у кривого x86. И перспектив покончить с безобразием нет. AMD продает Alchemy, Intel собирается продавать PXA.

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

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

Да, и вписывая нелегкие алгоритмы в 8 регистров общего назначения, я жестоко завидовал RISC-"коллегам по цеху". У них команд было мало, а регистров много!

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


Эта вторая ссылка открылась, там сказано про программу А.Шарахова, которая "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.

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

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

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

Метка:
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%



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

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

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

Что ж, вполне мог и ошибиться. Но ведь я привел код, который сравнивал. Что-то в нем неадекватно?
Уточните, пожалуйста, это файл PosBV.zip? Если да, то код MMX взят именно оттуда.
Интересный вопрос, что такое длинная строка. По-моему, если она помещается в 2..4 линии кэша, то длинной ее считать нельзя.

Я тоже так считаю. Однако, даже на строках длиной в 64 байта поиск с помощью MMX выполняется быстрее.

Да, (exe-шник в архиве предназначается для оценки скорости). SubBench1 - короткие строки (до 8-ми символов). SubBench2 "длинные" - все остальные (больше 8ми символов), доминирует размер 64 байта.


В коде ничего неадкватного нет, и трактовка кода у Вас правильная. Однако результат сравнения несправедлив. Вероятно Вы рассматривали при тестировании какой-то частный случай (к примеру один из частных случаев - искомая подстрока находится постоянно очень близко к началу строки, при этом сказывается замедление вызываемое инициализацией MMX). Рассматривайте также и худший случай - когда искомой подстроки в строке нет.

Кажется, я где-то выше писал, что при тестировании рассматривал только один случай - именно наихудший - когда подстроки в строке нет. Для этого вот таким образом был сформирован бинарный файл размером 8x10**6 байт:

for (int iIdx=0; iIdx < iFileLen; iIdx++)
sOutput[iIdx] = iIdx % 0xFF;
(Это писалось в Memory-mapped файл)

Он состоял из значений от 0 до 0xFE, а 0xFF отсутствовал. Именно он и искался в строке. Были проверены варианты с длиной 1000, 4000 байт и с полным файлом. Вот код, запускавший нужную функцию:

for (int i=0; i<CYCLE_QUANT; i++){
GetProcClocksFull(&i64Time);

// int iResult = TestMMX(pbSubStr,pbStr,1000);
// int iResult = TestMMX(pbSubStr,pbStr,iBufLen);
// int iResult = TestIA32(pbSubStr,pbStr,1000);
int iResult = TestIA32(pbSubStr,pbStr,iBufLen);

GetProcClocksFull(&i64Time2);
DWORD dwDeltaTime = (DWORD)((i64Time2 / 1000) - (i64Time / 1000));
// DWORD dwDeltaTime = (DWORD)((i64Time2) - (i64Time));
ToLog(REPORT_FILE,"%u\n",dwDeltaTime);
}

Чтобы не спорить впустую, проще довериться цифрам. Я подготовлю несколько файлов для запуска и выложу их здесь.

Сорри за долгое отсутствие, эту проблему я для себя решил, поэтому потерял к ней интерес, вследствие большой загрузки по работе. Но потом подумал, что кто-нибудь еще может заинтересоваться данной темой, и не будет знать правильного ответа.

Коротко говоря: defunct прав и не прав одновременно. Прав, потому что на ММХ можно получить заметный выигрыш (для P4 Intel говорил, что "хорошо" - это 10%). Не прав, потому что выигрыш будет не 3-4 раза, и не на любой задаче.

Вот данные по выигрышу ММХ на задаче поиска отсутствующего байта, полученные на моем P4:

16 байт: 18% - 21%
128 байт: 1.48 - 2.28 раза
1000 байт: 1.42 - 1.84 раза
8 млн.байт: 1.54 - 1.55 (для I вызова I прогона - 1.25).

Это суммарный результат, "сырые" данные в файле Report.Full.P4.txt. Тестовые программы для ММХ и для IA32 включали по два прогона, в каждом по 10 вызовов тестовой функции. Всего получилось 8 программ для ММХ и 8 - для IA32 (4 варианта длин "только чтение" и 4 варианта "чтение/поиск"). Обратите внимание, что результаты либо в тактах, либо в тактах, деленных на 1000. Первая цифра в первом тестовом прогоне стабильно больше - здесь выигрыш ММХ сводится к нескольким процентам. Для второго прогона вычисляется среднее за 10 вызовов функции. Соответственно, есть 2 паттерна применения подобных функций. По моим результатам получается, что наиболее удачный для MMX паттерн - повторяющийся поиск строк длиной порядка 100-1000 байт, выигрыш составит 1.5 - 2 раза. То есть получается что-то вроде поиска в большом массиве или списке, строковые элементы которого расположены вместе в едином блоке памяти. В принципе, реально, хотя выигрыш и не в 3-4 раза. Поиск в большом файле - даст меньший выигрыш, и только при повторном поиске.

В любом случае, есть смысл "разгонять" только "узкие места" программы. Не факт, что скорость программы будет зависеть именно от поиска. Например, поиск в буфере 8 млн.байт на IA32 занял 14.5 млн.тактов(машина 1.7ГГц). Это значит 0.0085 сек.

Выигрыш под x64 гораздо больше (3 раза на 8 мб), но там новая архитектура и об оптимизации нужно думать тоже заново.

В целом, я такого мнения об ММХ - он мне кажется "тяжеловатым", что ли. "Легкие" команды IA32 стартуют "с места" и требуют по 0.5/1 такта, в 2 параллельных потока. Поэтому полезно использовать их всегда, когда возможно.

Конкретно, мне удавалось получать хороший выигрыш на ММХ на графических задачах с большим числом целочисленных умножений. Но, например, при копировании данных ММХ/SSE/SSE2 выигрывали только начиная с определенного размера (16 Кб).

Attached-файлы: Report.RO.P4.txt - тесты для ММХ/IA32, разные длины буферов, только чтение; Report.Full.P4.txt - то же, но с поиском.

exe-файлы, наверное, выкладывать не стану. Если кому нужны, пишите - передам вместе с инструкциями по использованию.