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

> Пока он достойно решает только одну задачу: распил бюджета

Пруф?

>>Есть, наверное (мобилы!!!11). Но туда не ставят R-150 в шкафном исполнении.

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

Если ты не заметил - последние лет 10 все пытаются догнать x86.

да-да. сам найдешь когда у других появилось 64бит, когда memory controller мигрировал onchip и когда у штеуда и иже с ним? это так, на вскидку.

>трансмета вообще не VLIW, т.к. нет компилятора, который генерит для нее код (а без этого все преимущества VLIW теряются)

SIGFPE

вообще интел была не заинтересована растить своему х86 конкурента, в котором она была бы не 100% с

Вообще, штеуд собирался пересадить народ на итаники чуть ли не с Pentium II :)

>Пруф?

У меня один знакомы в МЦСТ работал программистом. Они там в основном с генералами пили :)

Комп на основе Эльбруса (полностью на нашием железе) стоит около $50000, при этом по мощности ~ кластеру из восьми P III

А это поделище точно на Е2К? Что-то система маркировки подозрительно напоминает R-150/500/500S

> У меня один знакомы в МЦСТ работал программистом. Они там в основном с генералами пили :)

Серьезно? Генералы любят забухать с простыми девелоперами? o_O Или твой знакомый, вместо того чтобы работать, генералам свечку держал? :D

> Комп на основе Эльбруса (полностью на нашием железе) стоит около $50000, при этом по мощности ~ кластеру из восьми P III

Себестоимость железок определяется массовостью производства. Страшно подумать, сколько стоил инженерный образец какого-нибудь core i7.

>Нет ровно никаких причин делать всё самим

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

да еще на такой сомнительной на сегодня технологии, как VLIW.

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

>Себестоимость железок определяется массовостью производства.

Ясен пень, но по факту вместо работы идет (в основном) распил

Сравнение с редхотом некорректно - все мешаешь в одну кучу. Древнюю стабильную версию они конечно имеют, но основную работу в апстриме над всеми компонентами свежей нестабильной версии (которая потом будет заморожена, зарелизена и сразу станет старой стабильной) ведут также они.

Вот у меня есть программа под андроид, в которую мне потребовалось притащить библиотеку, которая сходу под этот андроид не скомпилировалась. Благо исходники есть, проблемы совместимости мелкие, но их много и они размазаны по всему коду библиотеки. Значит я ее напатчил, скомпилил, запустил, а через месяц вышла новая версия библиотеки, на которую мои патчи просто так не лягут - где-то класс переименовали, где-то функцию перенесли и т.д и тп. Таким образом, у меня есть уже готовая стабильная публичная версия моего приложения, которое использует версию библиотеки x.1 дремучего года (пропатчить его по мелочи для повышения стабильности проблемы не составляет) и в разработке находится новая версия, в которой я хочу опять использовать новую версию библиотеки x.2, но просто так взять ее и слинковать вмести со своим приложением я не могу по причине проблем, перечисленных выше - мне нужно заново провести процесс портирования, причем фактически с нуля - старые патчи помогают очень мало. Это адЪ, при этом самое страшное не то, что через него как-то необходимо пройти, а то, что через него нужно проходить снова и снова с каждым новым релизом. При этом если бы мои первые патчи приняли в апстрим (конечно в том случае, если бы я их туда послал), а сам я заделался меинтейнером новой фичи в центральном продукте «поддержка платформы андроид», все бы было совершенно подругому - мелкие патчи, которые были размазаны по разным классам в процессе рефакторинга просто бы двигались вместе с этими классами, а новые функции, добавляемые другими разработчиками, проверялись бы мной на совместимость с моей платформой до того, как библиотека выходила в релиз новой версии. Да, это тоже работа, но совершенно другая и по объему и по качеству.

В общем, если подытожить - если есть какие-то наработки/исправления, которые не могут существовать ни в каком другом виде, кроме как в виде патчей к основной системе - нужно полюбому эти патчи отправлять в апстрим и не жопить - иначе выйдет себе дороже. Если же основная разработка существует от материнского проекта сбоку и только использует публичные интерфейсы и стабильные API, то уже могут быть разные варианты, хотя даже в этом случае может быть выгоднее принимать активное участие в разработке этих самых API, чтобы не оказалось так, что при следующем их релизе боковую систему не пришлось переписывать под них заново.

> шкафное исполнение это реально шкафное? фото какое может?

Фото с 4-процессорной материнкой в линке к новости. Пишут, «CompactPCI 6U».

>Если ты не заметил - последние лет 10 все пытаются догнать x86.

но кто-то же должен похоронить эту гадость :)

>10-летней давности

Да уж со времен советского союза ничего не по менялось. Тогда тоже от разработки до внедрения уходило 10 лет.

> по факту вместо работы идет (в основном) распил

Никак не могу понять, откуда ты взял такой «факт»? Распил, конечно идёт: это болезнь эрэфии в целом, странно было бы полагать, что она внезапно миновала госзаказы на военную технику. Однако результаты инженерной работы вполне впечатляют.

Если вдруг кто-то серьёзно начнёт теснить Intel - Microsoft успеет приспособиться очень быстро.
Microsoft - да. Остальные проприетарщики - нет. В результате: ситуация с софтом будет хуже, чем на Linux десять лет назад.

вполне неплохо ведь, в мобилку конечно не засунешь, но оно и не надо.

Кстате интересное - на второй картинке говорится что готовится плата формата ITX. Т.е. они десктоп собираются делать.

>имхо будущее как раз в повышении скорости за счет VLIW

будущее в повышении скорости за счет SIMD и out-of-order

>за счет SIMD и out-of-order

DSP (FPGA) и многоядерность/многопоточность

>Если на него нормально не встанет Линукс, накой он тогда нужен?

Зато Win 3.1 работает!

> будущее в повышении скорости за счет SIMD и out-of-order

SIMD и out-of-order - это вчерашний день, есличо. Сегодня все дружно ударились в повышение скорости за счет многоядерности/многонитевости. Что будет завтра - хз.

DSP. На десктопе. Стремно это как-то)

>>Есть, наверное (мобилы!!!11). Но туда не ставят R-150 в шкафном исполнении.

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

И во что же из этого ставят R-150? Правильно, ни во что. Для этого есть всякие «Багеты» (тоже угребище, кстати).

или шкафное исполнение это реально шкафное? фото какое может?

Да, он реально шкафное: http://www.mcst.ru/10-11.htm Еще на ранних моделях были прикольные трекболлы из бильярдных шаров (даже в реальные изделия такие ставили - сам видел на МАКС-2007).

Если ты не заметил - последние лет 10 все пытаются догнать x86.

да-да. сам найдешь когда у других появилось 64бит,

amd64 (только не надо про «amd64 - это не штеуд!!11»)? Так специально для тебя я сделал оговорку «последние 10 лет».

когда memory controller мигрировал onchip и когда у штеуда и иже с ним?

Результаты SPEC или GTFO.

>SIMD и out-of-order - это вчерашний день, есличо. Сегодня все дружно ударились в повышение скорости за счет многоядерности/многонитевости.

Одно другому не мешает, многоядерность тоже давно используется.

>> Нет ровно никаких причин делать всё самим

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

Ну епт. Сценарий: ты купил или украл _лицензию_ на MIPS, развернул производство у себя. Где тут зависимость? Или твои инженеры не осилят дальнейшее развитие MIPS? Китайцы вон осилили. И этот сценарий уже много раз опробован (см. развитие авиации в СССР, например; после войны так поднялась Япония).

>Стремно это как-то

А я бы не отказался от чего-нибудь с мощным FPGA для PCI/PCIe как замену opencl

> 1. данный процессор нелзя на прямую сравнивать с x86 и ARM, реально с чем можно сравнить это с процами Transmeta и Intel Itanium, они VLIW и имеют истинный параллелизм, что обеспечивает бОльшую производительность для хорошо распараллеливаемых вычислений.

Эту чушь начинают говорить, когда хотят скрыть собственные ошибки. Производительность любого процессора можно измерить в терминах количества выполненных инструкций за единицу времени. Берешь тестовую программу, а лучше 10, запускаешь и сравниваешь. И никаких «хорошо распараллеливаемых вычислений».

>даже в реальные изделия такие ставили - сам видел на МАКС-2007

Я припоминаю не только на МАКСе ;-).

>Сегодня все дружно ударились в повышение скорости за счет многоядерности/многонитевости

Наивно полагать, что большинство приложений сможет получить выигрыш от увеличения числа ядер

>> даже в реальные изделия такие ставили - сам видел на МАКС-2007

Я припоминаю не только на МАКСе ;-).

Ну я тоже, но на МАКСе мог видеть любой :)

>> Честно, твой коммент тоже. Мы с VIT обсуждали проблемы реализации CMS

не важно, что вы там обсуждали, важно то, что аналогия VIT, примененная как аргумент против VLIW, дырявая

Очень важно при влезе в разговор знать контекст. Это не аргумент против VLIW, это аргумент против аргумента о технической превосходности Трансметы.

> VIT тупо троллит. Сыпет абсурдными фразами из умных слов.

А Вы, кстати, все эти умные слова понимаете?

>Ну епт. Сценарий: ты купил или украл _лицензию_ на MIPS, развернул производство у себя.

А можно было вообще взять бесплатный UltraSparc T2 и клепать :)

>А я бы не отказался от чего-нибудь с мощным FPGA для PCI/PCIe как замену opencl

но не вместо CPU же :)

>> DSP - это accumulate-multiply на большой скорости и в SIMD, ни на что больше они не годятся

Неправда. Многие DSP успешно делают general-purpose computing. Хотя и не слишком шустро.

Например?

Э-3М - управляющая машина (т.е. многозадачная ОС)

Для нормальной многозадачной ОС - нужна возможность переключать контексты и поддержка виртуальной памяти. Причем тут vliw/не-vliw, dsp/не-dsp?

Управляющая машина должна быть быстрой. Это достигается за счет out-of-order, branch prediction, FPU, иерархии кэшей; для ОС нужно еще и MMU. Всех этих вещей на DSP обычно нет. А нагрузишь всё это на DSP - он станет хреновеньким процом общего назначения.

>> Ну епт. Сценарий: ты купил или украл _лицензию_ на MIPS, развернул производство у себя.

А можно было вообще взять бесплатный UltraSparc T2 и клепать :)

Конечно.

>>И во что же из этого ставят R-150?

а что так конкретно к р150 прицепился? р500 то ничего по параметрам.

Да, он реально шкафное:

есть не только такое бабо-робот из 80-х

http://www.mcst.ru/hardware.shtml

amd64 (только не надо про «amd64 - это не штеуд!!11»)?

и что? все-равно это 2000 год.

Результаты SPEC или GTFO.

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

тут вот еще сорока на хвосте принесла, что штеуд собирается 10гигабит тоже onchip воткнуть. не знаю насколько это правда. но тенденция однако...

>> да еще на такой сомнительной на сегодня технологии, как VLIW.

ну расскажи, чем она сомнительна

Даже в этом обсуждении несколько раз прозвучало, чем она сомнительна. Ну прочитайте хоть, что люди пишут!

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

Ну что тут непонятного? Не может компилятор в compile-time обеспечить/определить/расчитать оптимальный instruction scheduling. Система недетерминированная.

>>И во что же из этого ставят R-150?

а что так конкретно к р150 прицепился?

Я только его в деле видел.

р500 то ничего по параметрам.

Ага, ничего выдающегося.

amd64 (только не надо про «amd64 - это не штеуд!!11»)?

и что? все-равно это 2000 год.

2000 год - это 10 лет назад, или ты говоришь о временах 8086? А я - о последних 10 годах.

Результаты SPEC или GTFO.

резыльтаты чего?

Вопросов больше нет.

>Ну что тут непонятного? Не может компилятор в compile-time обеспечить/определить/расчитать оптимальный instruction scheduling. Система недетерминированная.

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

>>2000 год - это 10 лет назад, или ты говоришь о временах 8086? А я - о последних 10 годах.

я к тому что оно всегда было отставающей. и будет.

Вопросов больше нет.

хокум-стайл начинается?

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

>> будущее в повышении скорости за счет SIMD и out-of-order

SIMD и out-of-order - это вчерашний день, есличо. Сегодня все дружно ударились в повышение скорости за счет многоядерности/многонитевости. Что будет завтра - хз.

SIMD и out-of-order - это настоящее. Все современные CPU общего назначения являются out-of-order. И послединие Xeon, и Opteron, и Power 7. Все GPGPU являются SIMD. Впрочем и все FP расширения, такие как AVX, тоже таки SIMD. Учите значения слов, тогда абсурда во фразе будет видеться меньше.

>>Вопросов больше нет.

хокум-стайл начинается?

Когда на вопрос «где результаты SPEC» следует ответ «чего?», дальше разговаривать бессмысленно.

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

Тесты процессоров относятся вот к этой фразе:

EvgGad_303> вечно догоняющий x86?

Вечность кончилась лет 10 назад.

>Управляющая машина должна быть быстрой. Это достигается за счет out-of-order, branch prediction, FPU, иерархии кэшей; для ОС нужно еще и MMU. Всех этих вещей на DSP обычно нет

Только не все это понимают, к сожалению.

> + любая вариация в архитектуре проца либо сведет на нет оптимизацию программы, заточенной под другую модель, либо вообще сделает бинарник несовместимым

Про непереносимость программ и методов компиляции я даже не заикался. Тут люди и с понятиями попроще путаются...

Вообще оптимизация - дело тонкое и без всяких VLIW. Посмотрите на реализации memcpy для разных Intel ядер.

>Вечность кончилась лет 10 назад.

И теперь x86 гордо бежит впереди, потому что костыли самые длинные :)

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

>> Вечность кончилась лет 10 назад.

И теперь x86 гордо бежит впереди, потому что костыли самые длинные :)

Это не костыли, это ходули.

>> Многие DSP успешно делают general-purpose computing. Хотя и не слишком шустро.

Например?

Несколько лет назад возился с DSP-шками (кажется, производства TI, сейчас лень искать). Так вот программируются они на обыкновенном Си. Критичные (по быстродействию) участки кода - на vliw ассемблере.

А нагрузишь всё это на DSP - он станет хреновеньким процом общего назначения.

.. при этом не утратив сильных сторон DSP - способности эффективно решать численные задачи, когда такие подворачиваются. Да и степень «хреновенькости» крайне не очевидна.