Все новости от 28 сентября 2004 г.

Компания сделала ставку на аппаратное ускорение Java

Компания разработала процессор Vega, специальную аппаратную платформу Java, более быстродействующую по сравнению с программным обеспечением серверов приложений от BEA, IBM, Oracle, Sun Microsystems и др. Однако Azul уверена, что заказчики потянутся к ее аппаратуре не столько ради ускорения, сколько ради эффективности этой технологии.

Она, говорит генеральный директор Azul Стивен Девитт, сделает для Java-ПО то, что сетевая технология сделала для хранения данных: позволит использовать пул ресурсов, эффективно распределяемых между многими серверами. В первом полугодии 2005 года Azul планирует выпустить системы с 4-16 спецпроцессорами, которые будут исполнять Java-программы, работая в существующей инфраструктуре серверов заказчика.

По мнению аналитика RedMonk Стивена Огрейди, такие устройства могут оказаться полезными для крупных компаний. «Думаю, что эта ниша наиболее привлекательна для тех, кому приходится иметь дело с тяжелыми рабочими нагрузками… Средние же пользователи Java-серверов вряд ли этим заинтересуются».

История процессоров, ускоряющих Java, полна взлетов и падений. Большинство проводников этой идеи, таких как Nazomi Communications, Ajile Systems и ARM, нацеливались на многофункциональные мобильные телефоны; проект Java-процессора разрабатывала и Sun, но прекратила его.

Однако серверы — не сотовые телефоны, и на этом рынке к спецпроцессорам уже привыкли. Так, несколько компаний предлагают специальные чипы для ускорения операций шифрования в интернете, а компания ClearSpeed работает над процессорами, которые возьмут на себя груз математических вычислений.

Java — широко распространенное ПО, разработанное Sun, которое позволяет исполнять одну и ту же программу на разных компьютерах. Программа исполняется в среде, называемой виртуальной машиной Java (Java virtual machine, JVM), по существу представляющей собой программную версию компьютера, изолирующую исполняемую программу от изменчивых деталей аппаратуры.

Размен ПО на аппаратуру
Процессор Azul Vega эффективно заменяет часть этой платформы Java аппаратурой. А так как каждый чип Vega содержит по 24 процессорных ядра, машина с 16 процессорами сможет исполнять целых 384 JVM. «Мы создали массивные запасы вычислительной мощности, доступные любому приложению, построенному на виртуальной машине Java», — говорит Девитт.

Системы Azul подключаются к существующим серверам приложений, в которых нужно лишь минимально подправить конфигурацию, переадресовав Java-программы к Azul JVM, вместо обычной версии сервера приложений. Azul работает над сертификацией своих продуктов на совместимость с лидерами рынка, серверами приложений от IBM и BEA Systems.

Кроме того, Azul старается заручиться поддержкой Microsoft, необходимой для согласования ее систем с инфраструктурой .Net, где вместо языка программирования Java и JVM используются C# и Common Language Runtime (CLR).

Работа с .Net не требует «абсолютно никакой модификации аппаратуры. Разница между миром CLR и миром Java состоит лишь в том, что Java открыта. Мир CLR — это мир Microsoft, — говорит Девитт. — Чтобы влезть в этот код, нужно вступать в деловые отношения с Microsoft».

Другое направление развития, которое планируется для будущих чипов, это способность лучше справляться с отказами. Сейчас в случае отказа виртуальной машины транзакции, которые она обрабатывала, необходимо повторять заново, а будущий продукт сможет продолжать процесс как ни в чем не бывало, уверяет Девитт. «У нас пока нет отказоустойчивости на уровне транзакций. Это логическое продолжение пути».

Процессоры Azul Vega имеют принципиально новую конструкцию, не опирающуюся ни на какие из существующих чипов. Компания уже работает над последователем модели первого поколения.

С заходом в Sun
У Девитта уже есть некоторый опыт Java-центрического взгляда на мир. Когда Sun приобрела (почти за $2 млрд) его компанию Cobalt Networks, производителя серверов, то сначала позиционировала ее продукты как платформу для Java-приложений, отвлекая внимание от того факта, что она всего лишь впустила в семейство своих продуктов, наряду с основной платформой UltraSparc, процессоры Intel. Однако приобретение Cobalt не стало успешным, и в 2002 году Девитт покинул Sun.

Опять сам себе хозяин, Девитт не побоялся сделать высокую ставку на технологию Azul. «Она должна стать предвестником великого периода инноваций, когда люди будут писать приложения, способные использовать преимущества этой технологии», — убежден он.

Однако Огрейди более осторожен в своих прогнозах и напоминает о других недостатках Java. «Я не злоупотребляю рекомендациями своим заказчикам по поводу того, на чем должна работать их JVM. По-моему, есть более серьезные проблемы, связанные с кодированием и разработкой».

Девитт не сказал, кто именно занимается испытаниями прототипов процессоров компании, но это, по его словам, крупные заказчики из сферы финансовых услуг, связи, транспорта и ИТ.

Azul планирует организовать прямые продажи процессоров заказчикам, усилив эту бизнес-модель партнерскими отношениями с поставщиками серверов и Java-ПО. Компания будет продавать технологию в форме малых, средних и крупных, или «гигантских» пулов обрабатывающей мощности, сказал Девитт.

Azul прошла три раунда финансирования. В числе инвесторов компании Accel Partners, Redpoint Ventures, Worldview Technology Partners, ComVentures и Austin Ventures. 

 Предыдущие публикации:

 В продолжение темы:

Обсуждение и комментарии

	Коляныч - kolanychmail.ru 28 Sep 2004 4:06 PM
Не понимаю, чем же так специфичем код жабы или clr, что стандартные числодробилки типа интел/амд/ибм там будут хуже, чем эта сомнительная прилада, которая наверняка дороже массовых процессоров?
	добрый 28 Sep 2004 4:24 PM
здравая мысль. маршрутизаторы циско дороже программных, надо бы их заменить на стандартныя числодробилки. опять же рейд-массив можно программно делать - экономия выйдет:)
	Коляныч - kolanychmail.ru 28 Sep 2004 4:34 PM
Неудачная аналогия, т.к. в статье не сказано, что их проц будет исполнять именно msil-код .net и ... (как там код VM жабы правильно называется?), скорее наоборот ... на что наталкивает вот этот абзац: "Работа с .Net не требует «абсолютно никакой модификации аппаратуры. Разница между миром CLR и миром Java состоит лишь в том, что Java открыта." Или вы считаете, что msil дотнета и псевдо-код жабы одно и то же?!!
	добрый 28 Sep 2004 4:51 PM
что наоборот?
	Следопыт 28 Sep 2004 4:55 PM
конечно не одно и то же но смысл одинаковый Для Явы это называется байт код
	Коляныч - kolanychmail.ru 28 Sep 2004 5:19 PM
>что наоборот? < то, что описываемый проц будет исполнять свой *собственный* (нативный) код, а не байт-код или msil-код, соответственно он будет делать то же самое, что и ЦП компутера, т.е. интерпретировать псевдо-код с помощью VM/CLR?. Отсюда вопросы: 1. какое нафик "аппаратное ускорение Java" ? 2. чем этот проц круче стандартного интела/амд/поверпц? - т.е. процессоров от контор которые эту собаку уже 20-30 лет, как едят?
	bvz 28 Sep 2004 6:07 PM
Не знаю, что Azul нам готовит, но спецпроцессор Sun (который, правда, свернули) имел такие приятные возможности, как real-time вычисления и аппаратную поддержку инкрементальной сборки мусора. Эти вещи и для MSIL очень нужны, да и не так уж он отличается от байт-кода. Если Azul может байт-код молотить, ему на вход простой байтодробилкой привести MSIL к байт-коду, и понеслась...
	Следопыт 28 Sep 2004 7:02 PM
интересно сколько такое будет стоить?? никто не знает сколько стоили аналоги??
	Не Лох 28 Sep 2004 9:24 PM
2 Следопыт Стоить это будет явно дорого. В статье говорится, что не для средних компаний. А только для тех, у кого проблемы с нагрузкой. Понятно что с таких клиентов и спрос особый :))
	Black ANti-KDE.* 29 Sep 2004 12:55 PM
странно а мне казало таки проц давно уже есть.. по крайне мере у ARM есть встроенны сопроцесор для JAVA..( дженис кажется назвается). причем как раз для втсриваемы систем ... и стоит в пределах $30-$50.( вместе с CORE)..
	Black ANti-KDE.* 29 Sep 2004 1:08 PM
насчт того что он будет испольнять свой код. это нечего не значит.. трансмета тоже выполняете свой код а не x86. но так ка делай морфинг на ходу. то замедления не сильное. просто что бы сэмулировать настоящий байт код обычнным CPU.. нужно что: взять байт код.. его проонализировать найти соотвественную цепочку команд ... те на одну команду байт кода может уйти до 100 ( а может того и больше команд проца ).. и когда форфинг идет апаарнто даже леи проц выполняет свои команды а не непостредственно байт код. ускорения существенно... тут ведь главное не это А ВИРУАЛТЗАЦИЯ пространства.... потому как обынч проц еще кучу вских проверок делает.. так что ускрорение как минмуи в 20-40 раз.... и причем главное что японял из это стайтьи главней смылс РАПСПАРАЛЕРИВАНИЕ.. причем эффективное.. те елси у вас грутисять 100 задач VM.. вы их и запихнете на 100 VM CPU. а главнй проц будет заниматсят общей стуковвкой .. все очень разумно.. но это дейительно нужно там где нагрузка на VM больше чем на накладный расходы типа рабоыт с диском и обще базой.. но ВЕДь что значит будет стоить дорого.. может быть да $1000 это дорого. с дургй стороны.. если это проц.. всталяющий ся в срверер то сервре стоит уже порядка $10000. так что не дорого. тем более что альтернатива ставть больше срерверов ли больше CPU в кадлы сервак? дороже обойдется. другое делао врядле эта технлогия дойдет до ШИРпотреба.
	Коляныч - kolanychmail.ru 29 Sep 2004 1:46 PM
6 лет назад на этом крест уже поставили: http://news.com.com/Java+chip+not+picking+up+steam/2100-103 3_3-216359.html?tag=nl с тех пор универсальные процы добросовестно следуя закону Мура выросли в перформансе в десятки раз, а жаба-чипы где были, там и остались ... т.е. в заднице
	1 29 Sep 2004 5:43 PM
жабу долой с пляжа!
	1 29 Sep 2004 5:46 PM
-> Black * упрямо пишешь с ошибками попробуй почитать свои сообщения хотя-бы недельной давности сплошной crc-error!
	Blind 29 Sep 2004 7:29 PM
Долой, долой... Опять предлагают убивать голубоглазых или рыжеволосых. И когда интернет-фашисты закончатся? 2Коляныч. Месье не слышал про Cray, в котором аппаратно реализован алгоритм DES? Это был ночной кошмар для КГБ, когда выяснилось, что простые DES сообщения NSA способен ломать в real-time. Я не говорю, что таких машин было много, но Java и не DES. Вероятно люди посчитали, что можно выиграть по performance. Поэтому и предлагают. Посмотрим. если посчитают плохо - прогорят. Но независимо от Коляныча. Свободный рынок однако. Это вам не ЮКОС потрошить. Сказал Путин нет, значит нет!
	Коляныч - kolanychmail.ru 29 Sep 2004 8:58 PM
>Месье не слышал про Cray, в котором аппаратно реализован алгоритм DES? Это был ночной кошмар для КГБ, когда выяснилось, что простые DES сообщения NSA способен ломать в real-time.< Вообще КГБ использовал ГОСТ-NNNN, а не DES :)))) >Вероятно люди посчитали, что можно выиграть по performance.< Вероятно они решили, что люди забыли, что жабачипы - это надувательство, жаба код ничем не отличается от любого другого для массовых процессоров, которые на порядок дешевле. >Посмотрим. если посчитают плохо - прогорят. Но независимо от Коляныча. Свободный рынок однако.< Да я не возражаю, потом еще раз поугораем...
	добрый 30 Sep 2004 10:29 AM
>Вообще КГБ использовал ГОСТ-NNNN Гы-гы-гы...На ДВК ИСКРА? Гы-гы-гы! А серьезные машинки типа ЕС и СМ были цельнотянутые. И совместимые программно с западными оригиналами, ессно. И с западными стандартами, ессно. Впрочем, месье позволительно это не знать. Месье ведь тогда децкий садик посещал, а не машинные залы :)
	{12b8ea86-4084-4535-82a0-1830905ade92} 30 Sep 2004 12:29 PM
2добрый так ты, значит, машинные залы КГБ посещал? ;)
	добрый 30 Sep 2004 12:33 PM
2{12b8ea86-4084-4535-82a0-1830905ade92}: а то!:)
	Коляныч - kolanychmail.ru 30 Sep 2004 12:53 PM
>А серьезные машинки типа ЕС и СМ были цельнотянутые. И совместимые программно с западными оригиналами, ессно. И с западными стандартами, ессно. Впрочем, месье позволительно это не знать. < > а то!< Ну ка скажи добрый, чем RT-11 от RSX-11 отличается и почему фс RT-11 позволяет записать файло не более половины оставшегося свободного пространства диска? Сколько метров на дисках DK, DP, DB к примеру? Чем TED от EDT отличается? Название цельнотянутого аналога VAX/VMS? Какой командой приоритет задачи изменить? Как система программирования С на PDP-11 называлась? Кстати, там весь софт был опенсорс, но расшифровщик DES отсутствовал ... вобщем пукнул в лужу.
	plug 1 Oct 2004 6:17 AM
2 Коляныч : >> Ну ка скажи добрый, чем RT-11 от RSX-11 отличается и почему фс RT-11 позволяет записать файло не более половины оставшегося свободного пространства диска? Гы. А вот это гон полнейший. Во-первых, в сисколе (или как они там назывались) RT-11 для создания файла можно указать явно желаемый размер. И если он даже равен всему свободному пространству (при условии, что оно лежит "одним куском" :-), то ... отдаст все свободное, никуда не денется. А во-вторых, "безразмерных" запроса (типа "дай побольше, сколько сможешь") там два разных. Один означает - "максимальный кусок" ФС, ну и понятно, что если все свободное пространство и есть этот кусок, то опять же - отдаст под новый файл все, что есть. И вот только второй "безразмерный" запрос на создание файла формулировался немного замысловато - дай бОльшее из "второй по размеру свободный кусок ФС" и "половина нибольшего свободного куска". Проще говоря смысл был такой - дай столько, чтобы еще осталось на файл такого же размера. А то, что вы говорите ... это вы с каим-то редактором перепутали, тем же TED, наверное. Дело в том, что он открывал сразу два временных файла - один для выходного, а другой просто временный, как буфер для своих манипуляций. Этот второй так и оставался временным, то есть просто освобождался при окончании работы. Вот и получалось, что под результат редактирования можно было отхватить не больше половины свободного пространства диска. (Замечательно то, что размер редактируемых файлов ограничивался только вот этими размерами свободного дискового пространства и никак не зависел от ОЗУ. На машинках с памятью не более 56 _килобайт_ совершенно прозрачно редактировались мегабайтные текстовый файлы. После него так противно было в MSDOS'е, на машинках с 640 Кб, видеть сообшения типа "не могу отредактировать файл, потому как он в память не влезает" :-).
	Коляныч - kolanychmail.ru 1 Oct 2004 12:07 PM
Хм, ну может у нас разные РТ-11 были:)) Помню точно это сообщение про половину свободного места и объяснение из книжки, что система создавая файло должна то ли вторую копию хранить, то ли еще что-то ... таким образом попросив метр, нужно было иметь 2 свободных, чтобы она смогла сделать операции с этим файлом. Кстати, на самом деле это немного перекликается с описанным " вторым "безразмерным" запросом"