LINUX.ORG.RU

Выпущена пилотная партия моноблочных ПК на базе микропроцессора «Эльбрус-2С+»

 , , ,


6

5

Компания МЦСТ совместно с компанией Kraftway выпустила первую пилотную партию моноблочных компьютеров с архитектурой «Эльбрус». Компьютеры предназначены для использования в качестве офисных автоматизированных рабочих мест.

Моноблочный компьютер оснащён материнской платой «Монокуб». Плата «Монокуб» разработана в ЗАО МЦСТ под гибридный микропроцессор «Эльбрус-2С+» (два ядра Elbrus E2K + 4 DSP фирмы Элвис) предназначена для широкого применения, в том числе в гражданском секторе. Компания Kraftway, в свою очередь, адаптировала под плату «Монокуб» моноблочную платформу KM4.

Внешний вид моноблочного компьютера: http://www.mcst.ru/image/news_121229_1.jpg

Плата «Монокуб»: http://www.mcst.ru/image/news_121229_2.jpg

Плата «Монокуб» имеет форм-фактор miniITX и содержит один процессор «Эльбрус-2С+». На плате имеются два разъёма DIMM DDR2-800 и один разъём PCI-Express x16 (используется 8 линий). Возможна установка до 16 ГБ памяти (используются модули с ECC). Имеются внешние выходы: Gigabit Ethernet, 4 порта USB 2.0, аудио, RS-232, DVI. Система охлаждения основана на тепловых трубках.

Состав оборудования компьютера следующий:

  • сенсорный экран с диагональю 20” и разрешением 1600х900;
  • жёсткий диск SATA диаметром 2.5”. В корпусе меется посадочное место для второго жёсткого диска;
  • дисковод DVD-RW;
  • адаптер Wifi b/g;
  • USB хаб с карт-ридером и панелью аудиоразъёмов;
  • два встроенных динамика мощностью 2 Вт.

Общая потребляемая мощность ПК ~100 Вт, вес ~11 Кг (с подставкой, но без источника питания).

Моноблок работает под операционной системой «Эльбрус». Она основана на ядре Linux 2.6.33 и включает в себя доработки, реализующие мандатную защиту. Комплект пользовательских программ привычен многим любителям Linux:

  • графическая оболочка Xorg;
  • оконный менеджер Xfce4;
  • средства работы с офисными документами (текстовый редактор ABIWord, электронная таблица GNumeric);
  • браузер Firefox;
  • СУБД Postgresql и Linter;
  • веб-сервер Apache;
  • прочие программные компоненты.

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

Информации о стоимости компьютера и возможности его приобретения в сети не обнаружено.

>>> Подробности

★★★★★

Проверено: tazhate ()

Ответ на: комментарий от Deleted

да, они.

ну ос на хаскеле ( House ) можно поковырять веточкой, или свой любимый веб-фреймворк.

или лучше, HLVM вместо ОС :)

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

современные микроядра пригодны только для запуска целых операционных систем - это неинтересно

а что ещё ты хотел запускать?

Я хочу запускать приложения разных ОС _в одной_, т.е. полноценные personalities. Поскольку современные $BUZZWORD-ядра этого не могут (это не их вина, конечно), я считаю их в основном бесполезными.

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

HLVM вместо ОС

К сожалению ее планируют использовать не как замену ОС http://www.ffconsultancy.com/ocaml/hlvm/, а как еще одну не ненужную прослойку, для виртуализации и запуска ядер Linux к примеру.

Есть примеры и инструкции как получить не графическую рабочую среду в консоли, хотя бы того же самого Haskell ? Как решаются простые задачи по общению с внешним миром - ввод-вывод, чтение и запись с дисков, аналоги драйверов для hlvm есть ?

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

С ценами у них интересная ситуация. Только в Китае можно сидеть полдня (в буквальном смысле обжираться) в ресторане толпой и заплатить за всё ~800р и все будут безумно счастливы. А за доллар тебя готовы на дцатый этаж на руках внести вместе с багажом, причём всех сразу. Чтобы получить аналогичный сервис в другой стране нужно расходы умножить на сотню-другую.

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

С ценами у них интересная ситуация.

Квалифицированные специалисты, которые поднаторели в чем либо, всегда будут просить цену не ниже - чем жить достойно, а не просто питаться тем, что удастся найти за гроши в гипермаркетах с отравой от корпораций. Американцы тоже не богатые люди, раз такие толстые, т.к. питаются только тем, на что денег хватает, а не на едой уготованной самой природой. Это только образ из Америки делают такой красивый, а сейчас и про Россию/Москву такое же сочиняют. Разные люди и здесь, но уровень цен в Москве задрали выше крыши, потому и специалисты оказавшись в Москве, за похлебку в 25рублей в день работать не будут. И еще интересная картина - высокий уровень цен расползся в последнее время по всей России - по всем ее крупным городам. Не иначе как благодаря банкирам и бизнесменам ничего не производящим, а лишь перепродающим недвижимость по нескольку раз, и каждый раз с необоснованной наценкой на ими же разогреваемую через ставку рефинансирования ЦБ (ЦБ РФ - филиал ФРС) и китайские товары и электронику в 2, а то и в 3 раза дороже чем ее можно заказывать на ebay.com с доставкой в Россию.

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

Им нужно было выкатить чисто маму. При цене 15к рублей оно

имело шансы на успех при наличие доки на dsp.

Давайте лучше попросим компанию Intel выложить в открытый доступ спеки, которые у них в таких желтеньких книжках с надписью «TOP SECRET» :)

чувак, ты хоть понимаешь, что обычно дока на dsp это *далеко* не «TOP SECRET» ?

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

чувак, ты хоть понимаешь, что обычно дока на dsp

я просто скромно промолчу.

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

И еще тем, что при этом компилятор не имеет той информации, которая есть у железа.

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

www_linux_org_ru ★★★★★ ()
Последнее исправление: www_linux_org_ru (всего исправлений: 1)
Ответ на: комментарий от pacify

я просто скромно промолчу.

очень хорошее начинание, только немного запоздавшее — это надо было делать еще тогда, когда ты писал про «TOP SECRET»

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

то надо было делать еще тогда, когда ты писал про «TOP SECRET»

да почему? мне уже насрать на эту документацию.

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

он может сгенерить команды, которые эту информацию у железа спросят и используют как *он* скажет

В этом топике явно не хватает VIT, так что я скажу, как сам понимаю:

1) чтобы спросить процессор о загрузке исполнительных узлов, нужно время, чтобы использовать ответ - еще время + ветвление; это время съест тебе всю экономию. Еще учти, что к моменту использования информации она уже может быть устаревшей.

2) ты хочешь выставить информацию о внутренностях процессора компилятору. Это патентованно плохая идея, потому что мешает менять внутреннюю архитектуру процессора. x86 ISA, которую недоучки любят ругать, дает Intel большую свободу в изменении этой внутренней архитектуры.

3) для VLIW, который ты фактически предлагаешь, никто не написал достаточно хороших компиляторов.

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

В этом топике явно не хватает VIT, так что я скажу, как сам понимаю

этот VIT?

1) чтобы спросить процессор о загрузке исполнительных узлов, нужно время, чтобы использовать ответ - еще время + ветвление; это время съест тебе всю экономию. Еще учти, что к моменту использования информации она уже может быть устаревшей.

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

афайк та хрень, которая занимается раскидыванием нагрузки по блокам, именно это и делает, только *непрограммируемо*

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

это можно и нужно делать (почти)параллельно основному процессу вычислений... епрст, ровно так же, как оно и делается сейчас — юзая ограниченный набор невытесняемой испеченной на проце памяти (а-ля та память, что юзает предсказатель ветвлений); при этом еще можно немного загружать туда инфы из кэша/оперативки и наоборот — вплоть до того, скажем, что сбрасывать в L2 и восстанавливать оттуда же память предсказателя ветвлений при переключении задач (я не утверждаю, что это полезно, но а вдруг?)

это время съест тебе всю экономию

см. выше

3) для VLIW, который ты фактически предлагаешь, никто не написал достаточно хороших компиляторов

это вопрос

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

2) ты хочешь выставить информацию о внутренностях процессора компилятору. Это патентованно плохая идея, потому что мешает менять внутреннюю архитектуру процессора. x86 ISA, которую недоучки любят ругать, дает Intel большую свободу в изменении этой внутренней архитектуры.

тут может быть надо подумать (но архитектура процессора похоже достаточно устоялась уже)

но очень вряд ли x86 ISA дает бОльшую свободу, чем risc; да и вообще это малорегистровое говно

вариант «кому нужна совместимость и не хватает денег купить компилятор, юзают risc, а кому нужна скорость, программят на более низкоуровневом ассемблере» возможно и подошел бы... подумать надо

p.s. хотя насчет свободы — возможно в этом что-то есть; в частности, заменив одну инструкцию add ax, [bx] на последовательность рисковых, мы получаем риск (каламбур типа) перехода откуда-то снаружи *вовнуть* последовательности

www_linux_org_ru ★★★★★ ()
Последнее исправление: www_linux_org_ru (всего исправлений: 1)
Ответ на: комментарий от tailgunner

насчет тормозов на конкретном примере add ax, [bx]

варианты:

1. компилятор знает, что [bx] сейчас в L1 скажем — значит, может сшедулить (куски этой) инструкции оптимально

2. компилятор знает, что [bx] сейчас в кэшах с *определенной* вероятностью — почти п.1

3. редкий случай, когда компилятор не знает, где будет [bx] — на крайняк тут можно запустить тупой железный алгоритм (пусть даже и упрощенный по сравнению с тем, что у интела в х86); вообще афайк эти железные алгоритмы это просто «когда операнд будет готов, тогда и поставим на очередь, а пока исполняем то, что можно reorder-нуть с этой инструкцией, или вообще ждем»

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

www_linux_org_ru ★★★★★ ()
Последнее исправление: www_linux_org_ru (всего исправлений: 1)
Ответ на: комментарий от tailgunner

зависимости инструкций, да, могут быть неизвестны до рантайма, скажем

add [ax], bx
add cx, [dx]

тут вопрос в том, ax=dx или нет

тут опять у компилятора может быть преимущество, если он выведет, что ax!=dx; а если он не знает, то всегда мог бы сделать fallback на тупой железный алгоритм

www_linux_org_ru ★★★★★ ()
Последнее исправление: www_linux_org_ru (всего исправлений: 1)
Ответ на: комментарий от www_linux_org_ru

Вообще-то стоит вспомнить про ситуацию с SBLive 5.1 с ихней реализацией EMU10K1.

Ни одной нормальной программы для настройки эффект-процессора под линух так и небыло написано.

Из того что есть - глючный демон ld10k1 для загрузки кода в DSP, и не менее кривая программулина lo10k1 для передачи данных в этот ld10k1. Оба непредсказуемо виснут в любой момент, могут проработать сутки, а могут заткнуться через минуту, снося вместе с собой kmix и все остальные проги, которые с ними взаимодействуют.

А если говорить о DSP-коде самих эффектов - так его официально вообще нигде не возьмешь. Хочешь эффектов - ставь винду, ставь фирменную SBLive тулзу, и будет тебе 250 эффектов. И все будет прекрасно работать без глюков, падений и заиканий. Но закрыто.

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

... для VLIW, который ты фактически предлагаешь, никто не написал достаточно хороших компиляторов.

И даже не начнут писать, пока не станут доступны платы и документация.

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

... для VLIW, который ты фактически предлагаешь, никто не написал достаточно хороших компиляторов.

И даже не начнут писать

Думаю, что VLIW старше тебя; и все эти годы люди пишут компиляторы для VLIW.

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

Думаю, что VLIW старше тебя; и все эти годы люди пишут компиляторы для VLIW...

«пишут» = «распиливают» бюджеты...

PS. Те кто их сейчас могут «писать» или «кодить занедорого» раза в два-три моложе меня. А те, кто начинали проектировать архитектуру, уже давно ничего не пишут сами.

Не начнут писать открытые реализации пока не будут доступны к приобретению платы с Эльбрусами и не будет открыта документация системного программиста (если действительно платы будут продаваться, то ее уже можно было бы и открыть).

Deleted ()
Последнее исправление: Deleted (всего исправлений: 4)
Ответ на: комментарий от Deleted

«пишут» = «распиливают» бюджеты...

Вот так простой ПТУшник с ЛОР подвел итог 30-летней работе.

Не начнут писать открытые реализации пока не будут доступны к приобретению платы с Эльбрусами

Да-да, Эльбрус выведет компиляторную промышленность из тупика.

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

Вот так простой ПТУшник с ЛОР подвел итог 30-летней работе.

4.3

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

БЭСМ-6

Я думал, что последний рабочий экземпляр предательски похоронил Горбачев, а мог бы и музей работающей техники организовать и поддерживать его, денег думаю много меньше потребует, чем содержание мавзолея, а пользы много больше будет для Родины, но к счастью, еще один экземпляр бережно сохраняют для возможности развертывания на новом месте, и даже специалистов, умеющих и знающих эту машину нашли:

http://ramlamyammambam.livejournal.com/110695.html

Пишут, что есть еще одна:

http://zavelos.ru/forum/24823-poslednyaya-iz-sohranivshihsya-EVM-BESM-6

И даже эмулятор БЭСМ-6 развивают:

http://sourceforge.net/projects/besm6/

Система команд БЭСМ-6:

http://www.mailcom.com/besm6/instset_ru.shtml

И далее по теме БЭСМ-6:

http://comvest.net.ru/istteh/03.htm

http://www.mailcom.com/besm6/index_ru.shtml

http://ru.wikipedia.org/wiki/БЭСМ-6

А вот пример, на что способен один человек:

http://www.mailcom.com/besm6/index_ru.shtml#trivia

Англия бережно хранит всю историю вычислительной техники, даже машины на декатронах у нее в рабочем состоянии:

http://xbohdpukc.livejournal.com/381812.html

http://ru.wikipedia.org/wiki/Декатрон

И причина этого одна - в Англии нет предателей, она увы сама правит (или точнее правила) миром.

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

Вот так простой ПТУшник с ЛОР подвел итог 30-летней работе.

А вот как такой 65-летней работе подводят итоги (замечу, что после средней школы, я успешно закончил вуз, и работаю не менеджером по перепродажам):

https://groups.google.com/forum/?fromgroups=#!msg/besm6/d1NgVRvcpo0/Hyg_5F96wGcJ

... Выбросил. Транслятором ТА-1М подвязывали что-то у него на даче. ПК и распечатки транслятора выброшены точно.

Не хотелось бы, но возможно и всей работе по Эльбрусам будет подведен такой же итог, когда эта архитектура станет не нужна военным - в связи с нездоровой ориентацией России (Медведев,Сурков,Кудрин) на нездоровую Европу и больные Штаты - это очень вероятно.

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

А вот как такой 65-летней работе подводят итоги

https://groups.google.com/forum/?fromgroups=#!msg/besm6/d1NgVRvcpo0/Hyg_5F96wGcJ

Конкретно, где там подводят итоги? Процитируй.

нездоровой ориентацией России (Медведев,Сурков,Кудрин) на нездоровую Европу и больные Штаты

Похоже, ты на врача учился.

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

Конкретно, где там подводят итоги? Процитируй.

... Выбросил. Транслятором ТА-1М подвязывали что-то у него на даче. ПК и распечатки транслятора выброшены точно.

Похоже, ты на врача учился.

Похоже Вам безразлично на кого я учился.

Но все же выделите 16 минут и посмотрите:

http://youtu.be/qgtg4vRyqM4

В этом ролике наглядно на цифрах из открытых источников показано «Почему Запад живет хорошо?» и является ли он «здоровым». Только вот мне не понятно почему не всем в руководстве страны это понятно, или они предатели ?

Deleted ()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от Deleted

... Выбросил. Транслятором ТА-1М подвязывали что-то у него на даче. ПК и распечатки транслятора выброшены точно.

И что? Свалки забиты миллионами человеко-лет труда, а на кладбищах вообще лежат бывшие живые люди.

Похоже Вам безразлично на кого я учился.

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

Но все же выделите 16 минут и посмотрите:

Уже давно понятно, что ты предпочитаешь именно этот вид вранья.

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

Похоже, ты на врача учился.

Блин, ну не переходи на личности, уныло смотрится.

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

ну не переходи на личности, уныло смотрится.

Ты, конечно, прав. Но фраза, на которую я отвечал, еще унылее.

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

К сожелению, большая часть обсуждения оказалась потёрта и я не могу понять суть вопроса.

И еще тем, что при этом компилятор не имеет той информации, которая есть у железа.

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

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

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

1. компилятор знает, что [bx] сейчас в L1

2. компилятор знает, что [bx] сейчас в кэшах с *определенной* вероятностью

3. редкий случай, когда компилятор не знает, где будет [bx]

За исключением двух случаев, обычно компилятор не знает, где находится значение. Первый случай, когда компилятор идентифицирует stream и генерирует prefetch инструкции. Тогда он предполагает худший вариант (значение в DRAM) и генерирует пару инструкций prefetch-reuse достаточно далеко, чтобы покрыть задержку. Второй случай связан с использованием cache line lock механизмов, но обычно такие инструкции не доступны в user mode (OS может использовать эти вещи для размещения своих таблиц), а значит компилятору нет нужды этим заморачиваться.

Я не встречал компиляторы, которые пытаются моделировать поведение cache и предсказывать его состояние. Это чрезвычайно сложная задача сама по себе. Мне известно несколько research проектов, ROSE, например, или Totalview имеет такую функциональность в своём memory tracing toolkit, но всё это скорее в зачаточном состоянии и редко бывает полезно на практике.

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

Или речь идёт о чём то другом?

Речь о текущей загрузке исполняющих устройств. Чтобы компилятор либо статически планировал команды между устройствами, либо, как предлагает www_linux_org_ru, генерировал команды, которые запрашивают текущую нагрузку, и, в зависимости от нее, как-то меняют поток управления.

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

Понятно. Насколько мне известно, компиляторы всегда планируют инструкции статически. Out-of-order процессор может незначительно изменить порядок исполнения инструкций в небольшом окне (8-16 инструкций), однако сейчас тенденция к возврату in-order.

Планировка инструкций np-полная задача и также до сих пор проблематична, как и распределение регистров.

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

однако сейчас тенденция к возврату in-order.

Хм. Это везде так? Просто я не слышал, чтобы AMD возвращалась к этому, да и Intel тоже - наоборот, подчеркивается, что новые Атомы будут с OOE (конечно, Атом не для HPC, но всё же).

Планировка инструкций np-полная задача и также до сих пор проблематична, как и распределение регистров.

А насчет идеи, что программа во время исполнения запрашивает состояние исполняющих узлов и в зависимости от этого как-то меняет свое поведение?

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

Хм. Это везде так?

В общем, да. Производители увеличивают количество ядер и упрощают само ядро. Активно используется SMT, также для того чтобы скрыть зависимости между регистрами и длину конвейера устройств. Внутри потока инструкции почти всегда выполняются in-order.

А насчет идеи, что программа во время исполнения запрашивает состояние исполняющих узлов и в зависимости от этого как-то меняет свое поведение?

Зачем это делать, если компилятор сам распределяет загрузку устройств? Даже если это было бы нужно, в зависимости от ответа пришлось бы генерировать несколько версий кода, раздувать размер text segment, потом выяснится, что нужная часть кода ещё (или уже) не в instruction cache...

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

Активно используется SMT

Это многое проясняет.

Зачем это делать, если компилятор сам распределяет загрузку устройств?

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

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

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

Но это единственное место, где можно сделать распределение загрузки максимально эффективно, просто потому что компилятору доступен полный контекст исполнения и зависимости между данными (системные вызовы и прерывания пока упустим). На этапе исполнения такой контекст доступен только внутри небольшого окна команд, как я сказал выше до 16, но реально меньше.

Вообще эта идея мне чем то напоминает out-of-order исполнение, при котором инструкция dispatch на нужный конвейер только если этот конвейер пустой. Определение пустоты и есть «запрос».

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

Мы только что объяснили, почему для VLIW архитектуры важность разработки качественного компилятора существенно возрастает. В традиционной обработке процессор может немножко «подправить» scheduling. VLIW инструкции по-существу исполняются in-order, отследить зависимости между 20-30 микро инструкциями в runtime не представляется возможным, да и размер инструкции возрастает - код ведь тоже где то хранить нужно.

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

Я думал, что последний рабочий экземпляр предательски похоронил Горбачев,

В музее атомной промышленности г.Саров (Арзамас-16) один такой экземпляр есть =)
Музей - открыт для жителей города.

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

Мы только что объяснили, почему для VLIW архитектуры важность разработки качественного компилятора существенно возрастает.

Это настолько очевидно, что вся разработка Эльбруса стратегически развивалась по пути низкой герцовки и мощного компилера, что как раз и ложится на вливовскую архитектуру. Никакими другими комбинациями известных технологий невозможно было бы получить сразу сравнимую с пнём-4 вычислительную мощность.

Xintrea ★★★★★ ()

Внешний вид моноблочного компьютера: http://www.mcst.ru/image/news_121229_1.jpg

У, блин! Я ожидал, что там будет "монокуб" объемом в кубометр…

На плате имеются два разъёма DIMM DDR2-800 и один разъём PCI-Express x16 (используется 8 линий)

Дохловато.

основана на ядре Linux 2.6.33

Старовато.

В общем, кроме как "распил", никаких ассоциаций не возникает.

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от Xintrea

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

Мне вот интересно, откуда появилась байка про «сравнимую с Pentium-4» производительность. Результатов независимого тестирования пока никто не представил.

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

Мне вот интересно, откуда появилась байка про «сравнимую с Pentium-4»
производительность. Результатов независимого тестирования пока никто не
представил.

Я думаю, что очень просто: нужно взять DSP-задачу и на Пентиуме её решать с помощью 8087 :)

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

Да ладно, не так уж всё печально с ними. Насчёт того, что DDR2 а не DDR3 - дык, чтобы успевать за технологическими новинками нужен частый выпуск партий, чтобы было денег и на R&D и на производство. А тут - ещё и с военными надо как-то вопросы решать.

Насчёт ядра - так всего примерно два года ему. У них же не GCC, им надо очень сильно «пячить» ядро, чтобы оно у них собиралось. Это вообще болезнь у ядра - его сборка прибита гвоздями к GCC. Сейчас правда clang учат его компилить, но что-то пока с ним непонятно все.

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

tailgunner точно охарактеризовал мои идеи как программно-управляемый ооe

просто потому что компилятору доступен полный контекст исполнения и зависимости между данными (системные вызовы и прерывания пока упустим)

мне бы тоже этого хотелось, но это иногда не так из-за aliasing-а

если i и j вычисляются как-то сложно, то совпадают ли адреса a[ i ] и a[ j ] компилятору неизвесно... и вот поэтому разные всякие личности начинают расхваливать динамическую типизацию ooe, выполняемое железом

понятно, что эти происки нужно как-то пресечь — т.е. инфа, доступная в рантайме (скажем, что i!=j) должна быть доступной для изменения планирования инструкций

btw, разве в итаниуме не так сделано? к своему стыду я еще не изучил этот вопрос — где прочитать кратко о платировании инструкций в итаниуме?

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

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

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

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