Аппаратный XML-парсер от Intel

[Smerig]

Ну что можно сказать? Возвращаются к истокам :)
Были математические сопроцессоры, щас снова будут сопроцессоры :)

[ZUB]

может еще будут сопроцессоры для Crysis 3 и для Half-Life 3 :))

[spyhabit]

Сопроцессор для Crysis 3 и для Half-Life 3 называется видеокарта :)

[leoneed]

Винда по идее, чисто теоретически, на мой взгляд будет быстрее на этом работать.
Очень много у них всего на XMLе.
А HTML то тоже должно быстрее парсить? Хотя существенно разницы тут думаю не будет. По крайней мере не заметно для глаза.

[superhabra]

Не будет, так как чтобы оно работало быстрее надо чтобы код был написан с использованием SSE 4.2

[mace]

Если написано на дотнете, то достаточно будет поставить новую версию фреймворка под процессоры с поддержкой SSE 4.2 и сразу получим прирост без всяких перекомпиляций.

[superhabra]

Так-же и с жабой, но вот только винда не написан на дотНете :)

[leoneed]

Простите за оффтоп.
Мне кажется вполне реальным возможность создать Addон, скажем к FF, который будет вырезать из страницы строку с загрузкой jQuery библиотек, и поключать свою. Тем самым ускоряя работу сайта.
Тока пару проблем: с версиями и вдруг разработчикам встукнет в голову что-то изменить в jQuery.
На счёт остальных браузеров не скажу, больше addоны никому не писал.

[oWeRQ]

Сомнительное преимущество, разве что на загрузке лишних 15кб… а вот сделать что то подобное в движке js было бы интересней, только опять будет проблемма совместимости и придется плодить кучу костылей. Хотя есть тенденция делать движки js генерирующие машинный код(в какой то мере, если я правильно понимаю jit).

[svartalfar]

Может быть, появится возможность собирать производительные системы под свои нужды на уровне процессора.
Вместо того, чтобы втыкать графические ускорители, physiX, платы параллельных вычислений и проч.

[oWeRQ]

Ждем наборы собери себе процессор сам.

[homm]

Блин, плата аппаратного xslt-преобразования! Почему бы и нет, есть же аппаратные ssl-контроллеры.

[tegger]

А есть уже. Только не плата, а отдельная машинка: www-01.ibm.com/software/integration/datapower/xa35/

[beeruser]

Это ещё в прошлом веке (~96г) было сделано для клона ZX-Spectrum.
en.wikipedia.org/wiki/Sprinter_(computer)

В буржуйляндиях подобное появилось только на несколько лет позже.

[beeruser]

Это возможно только в условиях узкоспециализированного применения и рождает массу проблем.
Ну а основная проблема, я думаю, в программистах с отличным знанием VHDL и MAX+ plus II =)

[aleks_raiden]

переводите дальше и опубликуйте, будет интересно, как минимум мне. спасибо заранее

[RomanL]

поддерживаю интерес к теме!

[pomkaster]

почему же «со»? тут именно фишка что сам процессор умеет делать всякие вещи (например парсить xml или же выполнять операции с плав. точкой).

[pietrovich]

интересно, когда к MS SQL Server 2005/2008 выйдет апдейт под это дело… тип данных XML у них есть, и довольно удобный, почему бы не ускорить работу с ним?!..

[Goodkat]

Давно же уже есть

[shai_xylyd]

Настоящих случайных чисел вообще нет.

[Kroz]

Ну вот утверждается, что они есть. В принципе, это даже смотрится логично: leo.yuriev.ru/114
Для тех, кому лень читать: случайные числа делаются на основе шума от звуковой карты.

[Regis]

Интересная идея. Основной минус — либо такой генератор будет довольно медленным (процессору придется обратиться к весьма небыстрому внешнему устройству), либо процессор должен заранее запасать данные со звуковой карты и постоянно держать их «на готове».

[Kroz]

Ну в принципе, мне кажется, что последовательность «случайных» чисел будет достаточно случайной, если сделать случайным первое ее число (seed). Дальше должно все работать нормально. Думаю, в простых системах этого должно хватить.

[Regis]

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

[Captcha]

Подходит. Только период последовальности должен быть как можно больше и алгоритм генерации должен быть хороший.

[dbf]

Нет, типа такого: i005.radikal.ru/0803/6a/084ad473e7a7.jpg

[ssve]

Сделать-то не сложно, сложно стабильные характеристики получить

[Indalo]

В SSE4.2 есть даже инструкция для подсчёта CRC32, так и называется «CRC32» :)

[ZakharS]

Да, есть. Я об этом не упоминал, т.к. не по теме статьи

[yelbota]

> В следующей версии будет аппаратная поддержка JavaScript? :-)

на счет JavaScript не знаю, но но аппаратная поддержка Java есть в ARM9

[beeruser]

Jazelle ускоряет основные команды jvm байткода. Далеко не все.
Собственно суть технологии в том, что фронтэнд процессора преобразует
байткод в последовательность обычных ARM операций.
Хотя этот «аппаратный интерпретатор» и работает вдвое быстрее
программного интерпретатора, с JIT движком ему не сравниться по скорости.

[tegger]

Валидация XML — это просто хороший пример использования новых «строковых» инструкций (очень уж много сравнений строк делается при валидации). На самом деле эти инструкции подойдут для самых разных задач.

[tegger]

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

[mace]

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

[tegger]

Во-первых, валидация — это проверка XML не только на синтаксическую корректность, но и на соответствие схеме.
Во-вторых, посмотрите в Conclusion статьи:
"… Intel SSE4.2/STTNI instructions are used in schema validation component… to speed up performance and reduce memory consumption in attribute/element declaration lookup, string enumeration facet validation and model group state transion, which are hot bottlenecks in core schema validation."

[denim]

было бы неплохо почитать перевод! буду признателен автору, хочется понять что там до чего. теоретически идея довольно неплоха, парсить иксэмэль по быстрому фсягда хотелось. а это значит что xslt тож станет быстрым? хочется надеятся

[PingWin]

В рамках бредовой идеи и оффтопа — а что если для такого написать xslt, который… как бы это сказать-то… «компилирует» в общем… :) может получиться пинтересней всяких брейнфаков и интерколов :)))

[mraleph]

не может

добавление кучи угловых скобочек, равенств, ковычек и слэшей ничего кроме мусора в язык ассемблера не добавляет… более я сталкивался с inhouse языками с подобной концепцией и я вам честно скажу, я от них поблевал… вообще я считаю, что XML в данный момент суют во всякие лешие места…

[wdk]

Круто, круто.
Но я таки жду процессоров, нативно исполняющих код на CIL (.NET типа).

[Indalo]

В чём же тогда будет прелесть байткода, если он станет аппаратно-зависимым?

[wdk]

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

[beeruser]

java процессоры давно существуют, как и форт-процессоры.
Только всё это — медленное и никому не нужное железо.

[wdk]

Есть два типа проектов — к одному приложила руку MS, к другому — нет.

[tegger]

В мобилах на базе ARM-процессоров аппаратное ускорение Java используется давно и, похоже, успешно. Получается существенно быстрее, чем при тупой интерпретации. Оптимизирующий hotspot-компилятор, конечно, еще лучше, но в телефон он не влезает.

[beeruser]

ARM Jazelle и java процессор это вещи какбэ совсем разные.
habrahabr.ru/blogs/xml/44123/#comment_1104209

CLDC hotspot не много занимает. ~мегабайт кода + 1-2 мега хипа и вполне можно жить.

[tegger]

Jazelle и hotspot друг друга вовсе не исключают.
Проблема в том, что сам по себе CLDC hotspot умеет делать только простейшие оптимизации. Но при этом он может компилировать код под набор инструкций Jazelle RCT.
Конечно, процессор с Jazelle — это нифига не честный java-процессор, но зато он хоть для чего-то полезен:)

[beeruser]

А я и не писал что исключают. Я собственно портировал эту JVM под другую платформу, поэтому немного представляю как там что устроено ;)
Я думаю это не секрет что сложные оптимизации и _не нужно_ делать. Это tradeoff скорости компиляции против скорости работы. В дотнете компилятор тоже особо не утруждает себя оптимизациями.

[LDEV]

И в следующей версии будут аппаратные переполнения буферов и полный хак компов — вплоть до нереальных перегревов процессоров и их сжигание вирусами. Лукьяненко это предугадал уже давно…