LINUX.ORG.RU

Завершены государственные испытания «Эльбрус-S»

 , ,


0

0

В декабре 2010 года в ЗАО «МЦСТ» завершились:

  • приемка ОКР в части процессорной микросхемы (системы на кристалле) «Эльбрус-S»;
  • государственные испытания микросхемы (системы на кристалле) контроллера периферийных интерфейсов (КПИ);
  • государственные испытания 4-х процессорного модуля МВ3S/C на базе микросхемы «Эльбрус-S».

Решениями комиссий, проводивших приемку микросхемы «Эльбрус-S» и испытания микросхемы КПИ, разрешено приступить к выпуску серийных образцов микросхем и использовать серийные образцы для оснащения образцов вооружения и военной техники, а также информационно-вычислительных и управляющих систем в промышленной сфере.

Модули МВ3S/C рекомендованы комиссией для использования в качестве вычислительных средств в перспективных образцах вооружения и военной техники.

Для архитектуры Эльбрус поддерживается ОС Linux на ядре 2.6.14 в стандартной и real-time версиях. Поддерживается библиотека glibc 2.7 и множество стандартных утилит, также имеется графическая среда на базе сервера Xorg версии 6.9.0 с несколькими оконными менеджерами. Портирован большой комплект прикладных программ. В настоящее время идет работа по поддержке ядра 2.6.33 и свежей версии Xorg.

Из средств разработки поддерживаются: оптимизирующий компилятор собственной разработки (совместимый с gcc 3.4.6) для языков C, C++, Fortran, отладчик gdb, инструмент профилирования gprof. Компилятор поддерживает режимы нативной и кросс-компиляции.

Подробности:
http://www.mcst.ru/news.shtml
http://www.mcst.ru/image/101108/elbrus_ex1_101108.jpg
http://www.mcst.ru/image/101108/elbrus_ex2_101108.jpg

★★★★★

Проверено: Shaman007 ()
Последнее исправление: maxcom (всего исправлений: 2)
Ответ на: комментарий от tailgunner

> В рантайме хотя бы больше данных для ее решения.

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

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

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

В рантайме есть то чего нет у компилятора - статистика. Вспомни про JIT.

r ★★★★★
()
Ответ на: комментарий от r

В рантайме есть то чего нет у компилятора - статистика. Вспомни про JIT.

и какая такая статистика есть в рантайме, чтобы ее не было у компилятора *и у загрузчика* и затраты на ее сборы и пере-JIT-ование кода были меньше профита?

и если проц не используется в роли dsp, то пока успеешь набрать статистику, она уже устареет

рассмотрим поиск максимума в глубину в *неупорядоченном* дереве (допустим, у нас игра (против природы) с двумя ходами в каждой позиции, а value это оценка позиции) :

Node* find_max (int value, Node* tree, Node* sample)
{
  if( tree->is_leaf() ) 
    return value >= tree->value ? sample : tree; // cmove вероятно
  Node* l = find_max( value, tree->left(),  sample );
  Node* r = find_max( value, tree->right(), sample );
  return l->value > r->value ? l : r; // опять наверно cmove
}

ну и что ты можешь сказать про статистику *данного запуска*, которую можно собрать и она дальше будет работать, но про которую не знает компилятор и которую нельзя собрать как среднее *многих* запусков?

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

>ну и что ты можешь сказать про статистику *данного запуска*, которую можно собрать и она дальше будет работать,

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

То есть оптимизации могут лежать в области специфицирования обобщенных алгоритмов на конкретные данные. Конечно для одноразового кода это не имеет смысла - а для долгоживущих программ открывает определенные перспективы.

Другой вариант - оптимизация под специфику конкретного процессора - что фактически и делается во всяких жабанетах. На достаточно микроуровне таким занимается Gallium3d.

r ★★★★★
()
Ответ на: комментарий от r

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

Жаверам понятно мечтания... а у нас http://en.wikipedia.org/wiki/Profile-guided_optimization

(почему, собственно, я и справшивал о некой таинственной статистике *данного* запуска)

www_linux_org_ru ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.