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

да, они.

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

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

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

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

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

HLVM вместо ОС

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

этот VIT?

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

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

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

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

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

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

см. выше

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

это вопрос

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

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

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

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

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

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

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

варианты:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Злокачественная маниловщина.

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

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

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

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

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

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

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

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

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

4.3

БЭСМ-6 можно за VLIW считать, это 65й.

БЭСМ-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/Декатрон

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

http://youtu.be/qgtg4vRyqM4

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

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

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

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

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

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

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

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

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

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

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

http://www.linexp.ru/mtsst-vypustila-pervuyu-partiyu-protsessorov-elbrus

Уже было

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

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

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

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

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, но всё это скорее в зачаточном состоянии и редко бывает полезно на практике.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Да, настоящий программно-управляемый OOE.

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

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

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

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

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

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

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

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

Дохловато.

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

Старовато.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

У них же не GCC

А почему?