Пользователь
0,0
рейтинг
9 декабря 2013 в 10:02

Железо на службе у алгоритма

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

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

Мне удалось побеседовать на эту тему с Борисом Арташесовичем Бабаяном, директором по архитектуре компании «Интел».

Борис Бабаян известен как главный архитектор компьютерных вычислительных систем «Эльбрус-1», «Эльбрус-2» и «Эльбрус-3». Некоторые из его идей использованы в архитектуре Transmeta. В настоящее время Борис возглавляет разработку новой микропроцессорной архитектуры в компании «Интел».

Чтобы совсем покончить с формальностями, перечислю звания, степени и должности Бориса: член-корреспондент РАН, доктор технических наук, профессор, заведующий кафедрой «Микропроцессорные технологии» МФТИ, Intel Fellow, лауреат Государственной и Ленинской премий.

Дальнейшее повествование построено от лица Бабаяна. Мои скупые комментарии оформлены в виде врезок либо ссылок на интернет-страницы.


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

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

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

В общем, тема моей беседы – это история развития нашего дела, всей вычислительной техники, компьютерной технологии. Попутно я буду рассказывать о роли наших российских ученых, советских ученых, что ли… Но это не моя цель. Это, так сказать, попутно. К сожалению, об этом в России совсем немногие знают.

Всё, это было последнее предисловие. Теперь начнем.

Вот смотрите: вычислительная техника – это что такое? Это реализация алгоритмов в железе с помощью языков программирования. То есть, имеем три важнейших компоненты: алгоритмы, языки и железо. Поэтому если мы собираемся что-то анализировать, то прежде всего необходимо посмотреть именно на эти компоненты.

Начнем с алгоритмов. Алгоритмы – это нечто абстрактное, нечто вечное. Как числа, например. Может существовать множество разных алгоритмов, и каждый из них вечен.

Каким образом представляются алгоритмы? В них, как и во многих других вещах, связанных с реальным миром, можно выделить две компоненты: временнУю и пространственную. ВременнАя компонента – это последовательность выполнения операций: что за чем выполняется. Эта компонента – предельно параллельная. Конечно, существуют чисто последовательные алгоритмы, но в принципе понятие алгоритма – это представление о параллельной структуре. Обычно граф вычислений очень параллелен и предельно структурирован.

Теперь пространственная компонента. Пространственная компонента тоже параллельна и структурирована. Что она из себя представляет? Это объекты, с которыми работают операции. Масса объектов. Эти объекты могут ссылаться друг на друга, быть вложенными друг в друга. Но их много и с ними работают разные операции. Очень всё параллельно.

Вот что такое алгоритмы.

А железо? А железо, в отличие от алгоритмов, не вечно. Оно сильно меняется в течение времени. Вначале железо было очень примитивным. Когда я начинал… — а начинал я на Физтехе, в 51-ом году туда поступил – так вот, тогда ещё первая БЭСМ не работала. Один бит информации тогда был представлен двумя электронными лампами. Это кубический дециметр! Невероятный объем. И было всего одно исполняющее устройство. Оно занимало три комнаты. Как я всегда шучу, перенос бита начинался в одной комнате, а заканчивался через две комнаты. Это ужасный размер.

И посмотрите, что сейчас. На одном кристалле невероятное количество исполняющих устройств размещается.

А ведь БЭСМ-первая была уже далеко не первая. Самые первые машины я не видел. Например, Урал. Это была строго последовательная машина. Бит-последовательная машина. То есть был магнитный барабан. По одному биту с него считывалась информация. Далее считанные значения, например, складывались и снова по одному биту писались на барабан. Ужасно. Но нужно было такие машины проектировать. Куда деваться? Тогда не было никакой возможности отразить на аппаратуру такое невероятное великолепие, как параллелизм и во времени, и в пространстве. Просто даже нечего было говорить об этом.

Нужно было упрощение. Ну какое упрощение было бы в данном случае естественным? Линеаризовать всё! Всё в линеечку превратить. Это очень просто. Ничего не стоит параллельный алгоритм превратить в линейку. Причем и в пространстве, и во времени. Вот первые машины так и были сделаны. И это гениальное решение, конечно. Хотя… трудно назвать его гениальным, раз уж оно такое простое. Но это эффективное решение для того времени. Потому что превратить сложный алгоритм в линейку – никакой оптимизации не нужно. Компилятору это делать проще простого. Правда, тогда про компиляторы и языки программирования вообще не слышали. Все в битах программировали. Состояние вычислительной техники было такое, что не позволяло ориентироваться на программистов. С ними вообще не считались. Программисты работали с тем, что давали им разработчики аппаратуры. Да и программы были крошечные. Поэтому проще и эффективнее было в битах писать, чем на каком-либо языке. Тогда использование языков было пустой тратой машинного времени.

Моей любимой шуткой в те времена было, что настоящие мужчины работают в ассемблере, а языки – это так, баловство.

В отсутствие языков и компиляторов, человек собственноручно представлял алгоритм в виде линейки. И это соответствовало какой-то привычной концепции времени. Время последовательное – ну и алгоритм последовательный. Это всё естественно. Поэтому компиляторам (к тому моменту, когда они появились) делать эту работу было очень просто. Для машины – ещё проще. Линейная последовательность инструкций, в которую превращался алгоритм, выполнялась строго последовательно. Для этого нужна очень простая аппаратура! Тогда – а я тогда машины уже делал – нам даже в голову не приходило моделировать поведение аппаратуры.

Сейчас без моделирования нельзя. Современные архитектуры очень динамичны. Невозможно их оптимизировать, не проводя моделирования. А в ту эпоху время исполнения приложения равнялось сумме времен исполнения отдельных операций. Ничего не нужно было моделировать, всё и так было понятно. Никаких регистров не было и кешей не было. Первый БЭСМ так и работал: считывал одно число из памяти, второе число, выполнял операции, писал обратно. Считывание из памяти, по сравнению с операцией, происходило мгновенно. Операции тогда занимали многие такты.

Пространство тоже было очень простым. Никаких объектов не было. Была просто последовательность битов.

О безопасности, т.е. о защите процессов друг от друга, речи вообще не шло. Машина стояла в отдельной комнате. У какого-то человека ключ был от этой комнаты – вот и вся безопасность. Приходил программист, садился за машину, начинал работать. Кончал – снимал свою магнитную ленту, уходил, другой приходил. Каждый приносил и уносил свои данные с собой, и на машине работал только один процесс. 100% безопасность.

Жизнь программиста была непростой. Каждая новая машина – новая система команд. Все программы переписывались. Спасало только то, что программ очень мало было, так что с переписыванием можно было мириться.

Таким было начало.

Трагедия заключается в том, что совместимость с этим началом мы имеем до сегодняшних дней. Все современные системы команд – линейны. Хотя аппаратура сейчас очень параллельная. И это очень плохо. Это усложняет программирование. Масса ошибок возникает. Мы имеем большие проблемы с безопасностью из-за указателей, которые позволяют из произвольного места до любой информации достучаться. Ужасно! Но и это ещё не всё. От первых персональных машин нам досталась шина. Аппаратура в то время ещё не была параллельной, и процессоры имели только одно исполнительное устройство. Но сами процессоры уже могли работать параллельно друг с другом на общей памяти. Как раз для этого им и нужна была шина. Шина создавала строгую упорядоченность всех обращений к памяти со стороны всех процессоров. То, что сейчас называется strong ordering или memory model.

Программистам давалась такая система, и они понимали, что всё упорядочено во времени. Программисты, как всегда, просто пользовались тем, что им дают. А давали им вот что. Тогда синхронизация через семафоры и чтение данных из памяти занимали одно и то же время. Поэтому программистам, с точки зрения эффективности приложения, не было никакой разницы: использовать для синхронизации семафоры или же воспользоваться той упорядоченностью, которая задавалась memory model. В итоге, программы писались как попало.

А дальше ситуация только усугубилась. Появились кеши. И если кто-то раньше отрабатывал в своих программах честную синхронизацию через семафоры, то теперь он просто обязан был переписать программы так, чтобы они работали через memory model. Потому что доступ к данным стал гораздо быстрее, чем доступ к семафору. Ведь данные теперь лежат в кеше, а семафор – в общей памяти, доступ к которой гораздо медленнее, чем к кешу. Пользоваться семафорами стало очень не выгодно.

Отсюда пошли проблемы с совместимостью.

Сейчас уже давно нет шины. Тем не менее, во всех машинах моделируется та шина, которая была в самых первых машинах. Конечно, ее чуть-чуть изменили. Разработчики P6 посмотрели, что если строго выполнять memory ordering, то теряется 25% производительности. Поэтому они ввели одно облегчение: чтения из памяти могут обгонять записи в память. Но по-прежнему чтения не могут обгонять друг друга, записи не могут обгонять друг друга, а также записи не могут обгонять чтения.

А можно было бы все отменить и сделать по-новому. Мы в Эльбрусах никогда шинами не пользовались. У нас cross-bar-switch с самого начала был.
Cross-bar-switch
Прямая связь каждого процессора с каждым

Так вот: юмор заключается в том, что до сих пор моделируются первые машины. Причем не только в железе, но и в языках программирования. Все языки программирования испорчены. Они очень далеки от алгоритмов – от того, что я назвал параллельным временем и параллельным пространством. Они ближе к самым первым машинам, где все последовательно.

Мы видим, что совместимость взяла всё мертвой хваткой, и изменить это очень трудно.

Теперь давайте раздельно посмотрим на то, как прогрессировала временнАя компонента и как развивалась пространственная. Ну давайте начнем с пространственной компоненты. Это гораздо проще. Хотя более актуальна, может быть, временнАя компонента. Но это более трудно.

Итак, пространственная… С ней все очень просто. Это объекты. Значит, машина должна работать с объектами. Когда мы начинали первый Эльбрус, мы не думали о безопасности.
Безопасность...
Защита процессов друг от друга могла бы стать самостоятельной мотивацией для введения всех тех вещей, о которых говорится ниже. Именно поэтому здесь упоминается безопасность

Как я уже говорил, никаких проблем с безопасностью тогда не было. Мы занялись объектами, чтобы поддержать языки высокого уровня. Мы тогда задумались: что должен собой представлять язык высокого уровня? В то время, в 72-ом году, считалось, что программирование высокого уровня обеспечивалось такими языками как Algol и Fortran. Но мы быстро сообразили, что существующие языки ориентированы на существующие машины, где всё последовательно. Следовательно, пытаясь поддержать существующие языки в новой машине, мы бы фактически ориентировались косвенно, через языки, на существующие архитектуры. Это глупость!

Отмечу, что в то время уже существовали машины с поддержкой языков высокого уровня. Например, фирма Burroughs выпускала машину, которая исполняла Extended Algol. Типы данных там реализовывались через теги, которые хранились в памяти вместе с данными. Это была хорошая идея, и мы позаимствовали её у Burroughs. Но то, как они использовали эти теги, было просто недоразумением. С помощью тегов Burroughs поддержала на аппаратном уровне статические типы. Работало это так: каждой используемой ячейке памяти жестко приписывался некоторый тип. Эта информация применялась для автоматического преобразования данных во время их записи в память. Если, например, вещественное число сохранялось в область памяти, отмеченную тегом целого числа, то машина динамически превращала вещественное в целое перед тем, как осуществить запись.

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

Однако, справедливости ради, надо отметить, что динамическое приведение типов далось Burroughs почти бесплатно. Для такого преобразования необходимо было при каждой записи в память узнавать тип ячейки, в которую сохранялись данные. Это нужно было для того, чтобы узнать, каким образом данные должны быть преобразованы. Получается, что каждая запись в память требовала предварительного считывания. Такие лишние чтения выглядят ужасным расточительством. Но дело в том, что тогда использовалась ториковая память. Перед тем, как писать в такую память, её нужно было размагничивать. А размагничивание делалось посредством чтения. Поэтому считывание типа ячейки во время записи не приводило к дополнительным накладным расходам. Оно просто совмещалось к размагничиванием.

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

Вот как устроены алгоритмы? Представим, что исполняется некоторый алгоритм. Если он генерирует новый объект, ему не нужны никакие биты. Объект, ну, в пространстве появляется, что ли. К этому объекту, вновь сгенерированному, только текущий алгоритм может обращаться. Никто больше про него просто даже не знает. Потому что его сгенерировал конкретный алгоритм. Абстрактный алгоритм, а никакое не железо, понимаете? Такое должно быть и в железе поддержано как-то.

Далее, каждый объект имеет тип. Значит, мы должны и типы поддерживать. Сначала мы пытались очень экстремистский подход применить: целые, вещественные в тегах были написаны. Но потом мы увидели, что это совершенно не нужно. Не нужно любые типы поддерживать в тегах. И вот почему.
Немного о системе типов Эльбрус-1
рядом с пользовательскими данными в памяти хранилась информация об их типе. Эта же информация попадала в регистры при считывании данных из памяти. Знание типа позволяло контролировать операции, которые можно было производить над объектами. Например, попытка произвести целочисленное сложение вещественных чисел вызывала слом

Представьте, что вы берете вещественное число и хотите какие-то биты в нём изменить. Например, с экспонентой хотите что-то сделать. Если строго всё разнообразие типов поддерживается (битовый набор, вещественные, целые, …), то чтобы изменить какие-то биты в вещественном числе, вы должны сначала превратить его в набор битов, потом проделать нужные манипуляции, потом обратно превратить битовый набор в вещественное. Куча лишних преобразований! А если с вещественным можно литерально работать, – что, конечно же, обязательно надо уметь делать – ошибка может заключаться не в том, что программист, так сказать, в вещественном числе биты меняет, а в том, что он литерально неправильные значения пишет.
Работать литерально
Т.е. через битовый набор

Я хочу сказать, что внутри процедуры невозможно проверить её семантику. Аппаратура не может знать семантики. Ошибки внутри процедуры – это ответственность программиста. Внутри процедуры охранять программиста не нужно. Если он захочет, то всегда сможет сделать там ошибку. Другое дело – межпроцедурные взаимоотношения. Вот межпроцедурные взаимоотношения регулируются указателями. А указатели, вообще говоря, нельзя менять литерально. То есть, если какая-то процедура работает с неким набором указателей, она не должна иметь возможности их подделывать.

Таким образом, мы поняли, что проверять нужно только указатели и больше ничего. Это первое. Второе. Мы поняли, что язык высокого уровня должен быть динамическим. Это если мы хотим универсальный язык иметь. Для меня тогда – напомню, что это 72 год был – универсализм значил, что на языке можно эффективно писать операционную систему. Если операционная система не программируется, значит, подход не универсален. Для того чтобы можно было писать операционную систему, типы данных должны быть динамическими.
Динамические типы
Подход, при котором пересылка данных не сопровождается контролем типов. На уровне языка это проявляется, например, в том, что в любую переменную можно присвоить объект любого типа. Весь контроль типов переносится на этап выполнения операций

Почему это так? Допустим, вы определяете имя какое-то и к этому имени статически привязываете тип. В своей программе вы этот тип знаете, однако операционная система, имея дело с вашими данными, не знает, каким образом они описаны в исходном языке. Если в программе переменная статически описана как целое, операционная система об этом не узнает. Она только двоичные коды видит. Поэтому статический подход совершенно не приемлем. Кроме того он ещё и не удобен. Например, удобно иметь возможность передавать один и тот же параметр процедуры в виде прямого значения, ссылки на это значение либо даже вызова процедуры, которая вырабатывает нужное значение. Это абсолютно естественно. Но статический подход не позволяет этого делать, в отличие от динамического.

В итоге, мы пришли к тому, что язык высокого уровня – это динамический язык со строгим контролем указателей. Точно к такому выводу, фактически независимо – мы особо не контактировали и почти не читали друг друга – пришел Никлаус Вирт. Это человек номер один в языках. Он тоже осознал, что программирование высокого уровня строится на type safety и динамике типов.

Вирт создал динамический по типам язык Эйлер. Он был невероятно интересный. Все просто в восторге были от этого языка. Но ему недоставало эффективности. Потому что он не поддерживался аппаратурой. Была масса динамического контроля. Тогда Вирт сдал назад. Он сказал: да, типы должны быть, но пусть они будут статическими. И контроль должен быть… но, может быть, не очень сильный, потому что, например, контроль выхода за границу массива требует дополнительных команд.

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

И что в результате получилось? Мы сделали настоящий язык. У нас были теги. То есть ко всем данным добавлялись несколько разрядов, описывавших тип. Мы сделали контроль указателей. Одним словом, мы создали Эль-76. Это покойный Володя Пентковский сделал. Он тогда программистом был.

На Эль-76 была написана операционная система Эльбруса. Это уже Сережа Семенихин сделал. 26 человек в середине 70-х годов сделали операционную систему: мультипрограммную, мультипроцессорную, мультитерминальную. В то время в основном пакетный режим везде использовался. А у нас такая развитая операционная система!

К тому же наш типовый подход резко упрощал программирование. Он даже увеличивал производительность. Мы три поколения машины на этом подходе сделали: первый, второй, третий Эльбрус.

Наши машины использовались в очень ответственных системах. Противоракетная оборона Москвы, контроль космоса, атомные проекты в Арзамасе. При этом все наши пользователи говорили: отлаживать на этой машине – в 10 раз быстрее, чем на старых машинах. Впечатление было такое, будто работаешь с постоянно включенной отладочной системой. Причем без потери эффективности.

Когда наши ребята получили западные машины – в начале 90-х годов – они ко мне стали подходить и говорить: как на этих машинах можно работать? На них нельзя отлаживать программы. Ужасно!

Теперь посмотрите, что же стало с этим подходом! Исторически. Мы выпустили первую машину в 78 году. Тогда же прошел первый тест по операционной системе. До 82-83 года широко в нашей стране использовались Первые Эльбрусы. Примерно в это же время во многих университетах мира шли исследовательские работы в области type safety. И Интел тоже заинтересовался этим подходом. Они тоже сделали type-safety-машину, 432-ую. Спросите у любого интеловца, знает ли он, что Интел в истории имеет 432-ю машину. Ответ будет: нет, не знает. Об этом вспоминать-то стыдно! Просто позорная машина. Она обеспечивала type safety. Но там элементарные ошибки были.

В 432-ой была реализована защита укзателей, что конечно же, очень правильно. Однако все указатели хранились в отдельном сегменте. Назывался он program reference table. Машина контролировала, что находиться в этом сегменте могут только указатели. И нигде, помимо него, указателей больше не могло быть. Я почитал их бумаги. Они говорят, что всё это очень здорово, но очень неудобно указатели в отдельном сегменте держать.

Указатели должны рассылаться как обычные данные. Мы так и сделали. У нас указатели – просто данные. А 432-ая держала указатели в отдельном сегменте. Это приводило к ужасным результатам. Например, для индексации массива требовалась трёхадресная операция. Нужно было указать три операнда: положение указателя на массив в поинтерном сегменте, положение индекса в сегменте данных и снова смещение в поинтерном сегменте, по которому требовалось записать результат. Но самое ужасное даже не это, а то, что при входе в процедуру, у операционной системы запрашивалось четыре сегмента! Два сегмента для параметров: поинтерный и скалярный. И два сегмента для локальных данных: тоже поинтерный и скалярный.

ЦК и Совмин тогда копировали западные машины, и с появлением 432-ой распространили по учёным бумагу: вот, надо копировать эту машину. Так как я был защитник идеологии type-safety, меня включили в комиссию. Эрнст Фильцев возглавлял её. И я написал тогда большую телегу против Интела. Написал, что машина плохая и что через несколько месяцев она провалится. И она провалилась. Когда я пришел в Интел, то нашел статью Боба Колвелла, того гениального человека, который P6 создал. Он анализировал 432-ую машину и пришел к тому же выводу, что и я: идея колоссальная, но реализация никудышная. В статье Колвелла есть конкретные цифры. Например, вход в процедуру занимал до пятидесяти обращений к памяти. Как можно было на такой машине работать?

Как я уже сказал, 432-ая прожила недолго. Но что после этого стало с type safety? В каких направлениях стали развиваться языки и аппаратура?

Продолжение следует…


Автор благодарит Андрея Доброва, Александра Кима, Дмитрия Масленникова и Александра Останевича за помощь в подготовке материала
Andrey Nevolin @TechThink
карма
94,7
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое

Комментарии (138)

  • +3
    Бабаян — директор в Интел? Вот это новость — не знал.
    • +6
    • +1
      Я тоже не знал. В 2003-м читал его интервью в «Домашнем компьютере», в котором он говорил, мол, сами не лыком шиты, суперскаляры раньше Intel реализовали. Оказывается, буквально через год он сам перешёл в Intel.
  • +19
    прочитал с большим интересом, жду продолжения

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

    • +2
      Есть уже — Микрон в Зеленограде. Не Интел, конечно, но свою нишу имеет. Если будет расти спрос — предприятие сможет расширить предложение.
    • +4
      Очень хотелось бы. Уже есть люди и есть идеи. Проблема в том, что стоимость стартапа по разработке микропроцессора оценивается примерно в $1 млрд. Российские инвестиции пока до этого не дозрели.
      • –3
        Вам сумму в 1 млрд$ Бабаян сообщил? А как же тогда его бывшая команда сумела далеко не один процессор сделать за гораздо меньшие суммы? Более чем реальные процессоры, R500 и E3M называются, лично видел. Пробное производство обошлось, насколько я понимаю, менее чем в 1млн $, разработку вели, фактически, студенты. Естественно что это был не финальный продукт, но так это же стартап, от него и не требуется ничего продемонстрировать, кроме работоспособной идеи, под которую дальше уже можно получать инвестиции.
        • 0
          Видимо, имелась в виду не только разработка, но и производство.
          • +1
            Т.е. стоимость создания полноценной компании? Да, пожалуй. Но для того чтобы создать стартап такие деньги не нужны. А в России пока не могут даже начать.
          • +2
            Нет, видимо имелось в виду, что «мы хотели построить два маленьких домика»…
        • +3
          Цифра приблизительная, и я не готов за нее поручиться. Это просто моя прикидка (хотя я знаю, которые получили тот же результат).

          Это деньги, которые необходимо вложить в проект, чтобы получить продукт.

          Примерно столько привлек Дэйв Дицел, когда делал Трансмету.

          Цифра включает в себя стоимость производства тестового чипа с использованием современного технологического процесса.

          Хотя, конечно, тот, кто научится делать высокотехнологичные вещи быстрее и дешевле, выиграет гонку за место под солнцем. Будем надеяться, что найдутся люди, способные сделать процессор малой кровью :)
          • +3
            Примерно столько привлек Дэйв Дицел, когда делал Трансмету.


            Дэйв привлек на момент начала производства 376 млн $. Серийного производства готового продукта — речь уже не о стартапе, а о вполне себе рабочем бизнесе, который вышел на IPO. Остальные 600 млн $ — это затраты на уже, собственно, производство, развитие и т.д.

            Для стартапа, от которого требуется всего лишь показать реализуемую идею с хорошими перспективами, требуется куда меньше денег. 10-20 млн$, полагаю, для прототипа, демонстрирующего реализуемость идеи и вменяемость команды разработчиков более чем хватит. То есть миллиард для того чтобы создать стартап не нужен, миллиард — это уже инвестиции, нужные для выхода производства в сложившемся бизнесе на самоокупаемость.
            • +5
              Во времена Трансметы были намного меньшие NRE затраты для серийного производства (на порядок по меньшей мере), из-за намного более толстых норм и бОльшей конкуренции среди производителей.

              10-20 млн$, полагаю, для прототипа, демонстрирующего реализуемость идеи и вменяемость команды разработчиков более чем хватит.
              Да, демонстратор сделать можно. Но где бы еще найти инвестора, которые эти первые 20млн даст именно на демонстратор, а не серийный продукт? :-) Тут в России больше вкладывают по 1млн на первом раунде, и требуют по 40% компании за это :-)
              • 0
                Да, демонстратор сделать можно. Но где бы еще найти инвестора, которые эти первые 20млн даст именно на демонстратор, а не серийный продукт?


                А инвестора, который сразу даст 1 млрд $ на готовый продукт найти проще что-ли :D?

                Если вообще, в принципе, в России будет инвестор желающий вложиться в разработку микроэлектроники и располагающий необходимыми для этого финансами, то он начнет именно с закупки демонстраторов по 20 млн $, ибо гораздо выгоднее потратить 200 млн $ на десяток демонстраторов и выбрать сильный проект, чем сразу вбухать 1 млрд $ в «темную лошадку».

                При этом вполне возможна и бизнес-модель, в которой эти 200 млн $ на 10 демонстраторов будут вложены сугубо с целью перепродажи удачной идеи и команды западному инвестору. Это меньшие деньги и меньший риск, чем вбухивать 1 млрд $ в производство.

                Тут в России больше вкладывают по 1млн на первом раунде, и требуют по 40% компании за это :-)


                А разработчики микроэлектроники в России больше хотят 1 млрд $ и с сохранением контроля над компанией :)
                Вполне достойная пара к российским инвесторам.
                • 0
                  Полностью согласен с тем, что 10 демонстраторов по 20 для инвестора лучше чем 1 за 1000.

                  Многомиллиардные компании с видимой долей основателей ведь есть, что с ними не так?
              • –2
                Сейчас нет большого смысла делать своё производство кристалов, это очень жосткая индустрия с большим сроком окупаемости, большими капитальными инвестициями и низкой маржой. Большинство новых компаний fabless.
                • +5
                  Это и есть оценки для fabless. Современный фаб свой строить с нуля — в 10млрд$ можно не уложиться.
                  • 0
                    У вас очень завышеные оценки. Paralella на GlobalFoundries выпустила свой чип менее чем за милион.
                    А так насколько помню оценки, около 50000$ за один блин. С первой итерации не факт что всё выйдет конечно.
                    • +1
                      Как я писал ниже — Parallella не за миллион делалась + это намного более примитивный процессор, чем процессор общего назначения.

                      Пластина хоть и стоит действительно меньше 50тыс$, один полный комплект масок для 28нм стоит уже больше 1 млн $. +лицензии на софт — до 500тыс$ на 1 рабочее место в год. За миллион тут как ни крутись — ничего современного не сделать.
                      • 0
                        >лицензии на софт — до 500тыс$ на 1 рабочее место в год
                        Облезут буржуи. За 100к единовременно, наши хакеры проведут разведывательную операцию, стащят софт оттуда где он есть, взломают чтобы работало у заказчика, и зашифруют рабочие места от проверок. Никто вменяемый на первом этапе софт покупать не будет. Потратиться на лицензии можно тогда, когда денег станет куры не клюют.
          • +1
            Пятиядерный тестовый чип 40нм на TSMC-шном шаттле ~ $40k. Делали в этом году, правда у нас корпоративная скидка.
        • +4
          Взять стандартное MIPS ядро, автоматически синтезировать топологию на уже имеющимся софте и выпустить 25 кристаллов по устаревшей технологии (180нм) — это конечно и в миллион можно уложиться.

          Конкурентоспособный микроэлектронный проект по самым современным нормам производства (14-20-28нм) в крупной серии за 10 миллионов не сделать даже при использовании рабского труда.

          Так что реалистичный диапазон — 0.1-1млрд$.
          • +3
            Конкурентоспособный микроэлектронный проект «по самым современным нормам производства», если говорить о процессорах общего назначения, в России не сделают даже при вложении 10 млрд $. Нет ни людей ни технологий. В этом смысле я вообще не понимаю что эти Ваши «0.1-1 млрд $» значат. Что конкретно за эти деньги будет сделано?

            А для специализированных продуктов «самые современные нормы производства» сильно второстепенны, 90 нм для подавляющего большинства задач за глаза хватает.
          • +1
            Можна поинтересоваться что вы хотите по современнным нормам производить. Ещё один универсальный процесор? Боюсь вас разочаровать, но там никто кроме интела и возможно Самсунга не зарабатывает. Qualcomm по процесорам еле в ноль выходит, хорошо патентные платежи вытягивают, TI с мобильного рынка ушла, потому что маржа менее 5% и неуспех одного продукта ставил компанию на грань банкротства. А в нижнем сегменте от китайских производителей нет проходу. И что такого вы хотите предложить чтобы выжыть?

            Нужно искать нишу и умерить амбиции вроде паралелла они менее чем в милион вложились www.kickstarter.com/projects/adapteva/parallella-a-supercomputer-for-everyone
            www.adapteva.com/epiphanyiv/
            и выпускают очень достойный и интересный продукт. Смогут часть рынка Rasbery Pi отгрызть, да это не мировое господство, зато на собственные средства настоящий крутой и прибыльный процесор.
            • +3
              Тут речь шла о настольных процессорах с конкурентоспособной производительностью и стоимости его создания. С тем, что это дерьмовый бизнес (рынок заполнен, высокие требования к капиталу) — я полностью согласен.

              Естественно, в более узких нишах можно находить экономически более интересные новые продукты.

              Относительно Parallella/Adapteva — говорить «выпускают очень достойный и интересный продукт» пока преждевременно. Ну и миллион — это далеко не все деньги, на которые они проект делают. К моменту начала Kickstarter компании сам процессор уже был разработан.
    • 0
      Странно, во времена, описанные в статье, никаких компаний не требовалось, чтобы разрабатывать процессоры мирового уровня, а сейчас обязательно нужна какая-то компания.
    • +1
      МЦСТ неплохие аппараты проектирует. Собираются они, правда, на сановских заводах, обычно.
      Проблема-то в маштабах.
      В России самая большая проблема в моде на иностранное. Денег надо в разработку вкладывать много, а чтобы окупилось — необходимы большие обороты. На сегодняшний момент невозможно будет продать достаточное количество, чтобы окупить производство.
      Пару лет назад, тот же МЦСТ, захотел запустить массовое производство ноутбуков на Эльбрусе. Проводил исследования… и было решено приостановить этот проект до лучших времён, когда доверие населения к русским продуктам сдвинется в положительную сторону. Кто знает — быть может Ёфон сыграет в этом не последнюю роль.
      Ну и, опять же, предприятия, которые имею хорошие наработки и опыт в высоких технологиях — они все кормятся на госзаказах, на оборонке. Государство вливает в них нереальные деньги — им и развиваться-то не надо, по большому счёту, их заработок зависит не от этого и конкуренция их не интересует.
      • 0
        Пару лет назад, тот же МЦСТ, захотел запустить массовое производство ноутбуков на Эльбрусе. Проводил исследования… и было решено приостановить этот проект до лучших времён, когда доверие населения к русским продуктам сдвинется в положительную сторону.


        А Эльбрус уже достиг приличной производительности? Когда я его видел в последний раз это был откровенно тормозной по мировым стандартам продукт, способный вдобавок разумно работать только с *nix. Может доверие тут совершенно ни при чём :)?
        • +1
          Что касается VLIW'ных — то они очень даже хороши.
          Безусловно «родной» (допиленный *nix и самописный под винду) софт работает значительно качественнее.
          Но и транслированная винда ведёт себя вполне пристойно.

          Производительность… вам в попугаях или зайчиках? Я, вот даже, не знаю с чем сравнивать… учитывая, что VLIW'ов на попсовом рынке то и нет вовсе (если GPU не считать).

          За 90микро ни чего не скажу — не знаю.
          • 0
            Производительность… вам в попугаях или зайчиках? Я, вот даже, не знаю с чем сравнивать… учитывая, что VLIW'ов на попсовом рынке то и нет вовсе (если GPU не считать).


            Что значит «с чем сравнивать»? Вы же ноутбук предлагали на нем сделать? Вот с другими ноутбуками доступными на рынке и сравнивать. Когда я в последний раз видел Эльбрус (это было, правда, больше 5 лет назад), то его производительность в nix была на уровне примерно P2 @ 300 MHz. Win XP бы это чудо уже явно не потянуло. Если судить по сайту МЦСТ, то они с тех пор подняли частоту с 300 до 500 МГц и допилили таки двухядерный вариант. Если это так, то скорее всего по производительности лучший из Эльбрусов по меньшей мере раза эдак в четыре уступает младшим из нынешних Intel Atom (рекомендованная розничная стоимость: 32$, предназначение: установка в планшеты).
            • +1
              =) если взять Эльбрус-3М Кристалл 300МГц, то он вполне способен на операциях с плавающей точкой померяться с Pentium4 2ГГц. И WinXP на нём «летает».
              И да — с тех пор много воды утекло. С тех пор появился шестиядерный Эльбрус-2С+ с частотой 1ГГц и на подходе Эльбрус-4С.

              Это принципиально разные процессоры с абсолютно несопоставимой архитектурой. И сравнивать их частотами — в корне неверно. Конечно, сравнивать MIPS'ами (Meaningless Indicator of Processor Speed) но я, увы, не знаю значений ни для одних процессоров, ни для других.
              • –4
                Я тебе один умный вещь скажу, но только ты не обижайся: раз вы выпускаете ноут, то сравнивать нужно не плавучку и не MIPS'ы, а вовсе даже PCMarkи. Где, я боюсь, Эльбрус себя хорошо не покажет.
                • +5
                  Не обижусь, но попрошу пояснений.
                  Я знаю, что такое MIPS — это количество миллионов каких-либо операций в секунду.
                  Я знаю, что такое FLOPS — это количество операций с плавающей точкой в секунду.
                  Что такое PCMark я не знаю. А вы предоставили ссылку на сайт некой программы, которая работает исключительно в win7 и win8. Не знаю что она считает (надеюсь, что, вы напишите что она и как считает), но, есть подозрения, что для vliw архитектуры её работа не рассчитана.
              • +2
                С тех пор появился шестиядерный Эльбрус-2С+ с частотой 1ГГц


                Лезем на сайт: www.mcst.ru/elbrus_2c_plus. Читаем: 500 МГц и 2 ядра. «Шестиядерный» — это видимо если еще 4 ядра DSP посчитать, а 1 ГГц — если сложить по 500 МГц на ядро :). Ну давайте тогда и встроенную графику интеловскую посчитаем у Атома, там тоже ядер много :). Вообще, откуда Вы берете свои сведения, если не секрет?

                если взять Эльбрус-3М Кристалл 300МГц, то он вполне способен на операциях с плавающей точкой померяться с Pentium4 2ГГц.


                Только в очень специализированных и вручную вылизанных приложениях, плюс то что я видел тягалось, если не ошибаюсь, с P4 @ 1.6 ГГц, который вообще, прямо скажем, не особо блистал в FP-вычислениях в пересчете на его частоту :) — Atom на той же частоте заметно побыстрее будет.

                А для обычного софта, собранного компилятором, E3M выдавал при мне производительность P-2 @ 300 МГц.

                И WinXP на нём «летает».


                Сожалею, но в это я не поверю. Я WinXP там вообще вживую не видел и это совершенно неудивительно — по производительности E3M в целочисленке и тому что x86 там эмулируется, эта древняя ось там должна тихонько ползать, а отнюдь не летать.

                Это принципиально разные процессоры с абсолютно несопоставимой архитектурой. И сравнивать их частотами — в корне неверно


                Да я вообще-то в курсе, поэтому и ссылаюсь на известные мне тестовые данные, а не на частоту. Никакого особого прорыва E3M там, увы, не совершил: да в некоторых операциях он быстр на единицу частоты, да, но только очень в некоторых и даже в них не настолько, чтобы компенсировать колоссальный разрыв в тактовой частоте.
                • +3
                  Да, с количеством ядер я грубанул — извиняюсь. Частота — да на сайте написано 500МГц. Так оно и было поначалу. В апреле я работал на машинке с 1ГГц на ядро. Видимо модификация какая-то. Но она имеется.

                  Вообще, откуда Вы берете свои сведения, если не секрет?

                  Знаний у меня не много.
                  Я некоторое время проработал в МЦСТ. Но я к железу не особо близок — я Oracle PL\SQL программист.
                  Воочию видел их аппараты, работал за ними.
                  WinXP запускается без эмуляции — транслируется под архитектуру и, именно, «летает». Microsoft, в рамках каких-то договорённостей с оборонкой, для оптимизации работы на Эльбрусах выпускает различного рода патчи.
                  Имеются трансляторы, которые перелапачывают бинарники таким образом что они и без эмуляции начинают нативно работать. Не всегда это помогает. Иногда местные умельцы дизассемблируют код и сами «портируют» софт. С некоторыми производителями получается договорится и они этим занимаются сами, microsoft в их числе.

                  А если E3M запускается в режиме эмуляции, — то не удивительно что он столь прискорбные результаты показал.
                  • 0
                    Очень интересная инсайдерская конкретика. Спасибо!
                  • 0
                    В апреле я работал на машинке с 1ГГц на ядро. Видимо модификация какая-то. Но она имеется.


                    Вы с R1000 Эльбрус не путаете? www.mcst.ru/system-4x.shtml

                    С некоторыми производителями получается договорится и они этим занимаются сами, microsoft в их числе.


                    О. Интересный поворот сюжета. Ну тогда допускаю что XP может более-менее прилично работать. Все ж таки system requirements там как раз на P-2 @ 300 МГц изначально ориентировались.

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


                    Нет, E3M как раз я видел и тестировал в нативном режиме, просто тогда в нэйтиве тогда можно было только *nix гонять.
      • +1
        Пару лет назад, тот же МЦСТ, захотел запустить массовое производство ноутбуков на Эльбрусе.
        Я бы купил, да мне не продадут, да и цена там, с учётом защищённого индустриального дизайна, немаленькая.
        • 0
          Цена немалая, в первую очередь, из-за малых партий. Если стоимость исследований, составления ТЗ, дизайна и т.п. раскидывать не на 10 машин, а на, хотябы, тысячу — цена уменьшится в разы.
          Это предусматривалось при подготовке массового выпуска.
  • +4
    есть версия совсем другая
    fcenter.ru/online/hardarticles/processors/15730
    где правда?
    • +15
      Правду надо искать :)

      В данном случае предлагается не истина, а определенный взгляд. Очень весомый взгляд, т.к. принадлежит человеку, который занимается машинами со времен БЭСМа.

      У Бабаяна есть и противники (их не мало), и сторонники. У меня есть идея проинтервьюировать некоторых из противников (правда, не блоггеров, а людей, сделавших весомый вклад в развитие техники). Тогда будет более полная картина.

      Правда, пока даже противники (с которыми я успел пообщаться) сходятся в том, что Бабаян во многом опережает своими идеями время. По мнению одного из них, железо пока не дозрело (ну или было недозревшим) до того, чтобы идеи задышали в полную силу…
      • +9
        Я общался с г-ном Бабаяном в тот момент, когда он продавал интелу МЦСТ. Впечатление от общения осталось достаточно тягостное и я склонен согласиться со многим, что написано в статье на fcenter.ru. ИМХО г-н Бабаян достаточно успешный бизнесмен, но не ученый.
        • +3
          Напишите про! Будет интересно. Мне показалось наоборот: что Бабаян, скорее, чересчур увлеченный ученый, нежели ловец выгоды.
          • +1
            Потерял слово: «Напишите про это!»
          • +17
            Одно другому не противоречит. Бабаян — действительно «чересчур увлечённых учёный», но то как он «впаривает» свои идеи вызыввет у приличных учёных просто смех.

            Вопрос в подходе. Есть научный подход — когда мы описываем события по существу. А есть — грантопилительный, когда мы придумываем уловки, чтобы впарить свои идеи.

            Возьмите такую известную мульку как 23 инструкции за такт.

            Если вы сравните с «жалкими» 4мя инструкциями, которые выдаёт какой-нибудь Haswell, то вам покажется, что это просто-таки «прорыв тысячелетия».

            А вот если копнуть глубже… 4 инструкции за такт в Haswell'е не из воздуха берутся — это ограничение конвеера. Просто декодер «принимает» столько. А вот ALU'шек в нём аж десяток, причём 8 из них работают в параллель. И из них 3 могут работать с адресами памяти, то есть им «подносят снаряды» ещё три сумматора адресов (это отдальные устройства, не ALU!). А ещё есть устройства работы с памятью, которые могут считать из памяти (вернее из кеша) параллельно аж два разных слова. И записать столько же. Итого «бабаяновская» скорость — 15 "μ-инструкций" на такт. Не 23, конечно, но уже и не 4, согласитесь?

            Конечно на это Борисом Арташесович может заявить, что это мухлёж, так как в том самом «кривом и косом» Haswell'е при десяти ALU есть восемь запускачей и только четыре декодера (на самом деле больше, но это детали — декодируются максимум 4 инструкции за такт), а на три устройства, считающих адреса есть только два читателя/писателя и, соответственно, эти самые 15 "μ-инструкций" мы не сможем поддерживать… при этом он умолчит, конечно, о том, что 23 инструкции его поделие тоже в осмысленных программах удерживать не сможет. Только в специально написанных руками искусственных конструкциях: даже если писать всё ручками, то и в этом случае в осмысленных алгоритмах всё это хозяйство задействовать не удастся.

            Я думаю тот же Haswell вполне можно было изготовить так, чтобы в нём было не 23, а 33 «бабаяновских» "μ-инструкций" — но смысл? Скорость работы это не увеличит, а Intel всё-таки выпускает процессоры, чтобы продавать их заказчиками, которые на них реальные программы гоняют. А вот ради чего был создан Эльбрус 2000 — никто так до сих пор объяснить и не смог. Вообще. Единственное разумное объяснение — чтобы всё-таки доказать, что Эльбрус-3 таки мог быть сделан. Ну типа как современная реплика машины Бэббиджа, которая показала, что Бэббидж в своё время мог-таки сделать работающее изделие, хотя ему самому это и не удалось. Есть правда одна большая разница: энтузиасты делали реплику машины Бэббиджа осознавая, что именно они делают, а вот люди, которые разрабатывали Эльбрус-2000 всерьёз верили, что они делают что-то практически полезное.

            А про то, что он не бизнесмен — это точно, бизнесмен бы сначала решил зачем ему нужно что-то выпускать, а уж потом затеял многолетнюю возню с производством чего-либо. И давал бы интервью всех журналам когда бы потребовалось «подогреть интерес» перед запуском продукта, а не тогда, когда у него была только кучка предварительных расчётов.

            Рассказ про «главного архитектора вычислительных систем «Эльбрус-1», «Эльбрус-2» и «Эльбрус-3»» — это из той же серии. Эльбрус-1 и Эльбрус-2 вообще-то Бурцев разрабатывал и да, они реально существовали и работали. А вот «Эльбрус-3» — который, собственно, единственный и был разработан под руководством вашего «чересчур увлечённого учёного» был выпущен в одном экземпляре, да и тот, по слухам, толком не работал. Но послужной список состоящий только и исключительно из провалившихся проектов будет звучать не так убедительно, не так ли? Вот потому и изобретается эвфемизм «главного архитектора» (то есть типа Бурцев — да, он был главным конструктором, но архитектором он не был, да… так, воплощал в жизнь генеальнейшие идеи Борисом Арташесовича и только).

            P.S. Всё это, кстати не отменяет того факта, что многие идеи у Бабаяна — вполне себе интересные и они ещё могут «выстрелить». Но в каком-то смысла сама его личность — злобная антиреклама его идей.
            • +3
              > А вот ради чего был создан Эльбрус 2000 — никто так до сих пор объяснить и не смог. Вообще.

              Сама идея достигнуть производительности P4 на грубом техпроцессе и частоте 300MHz, чтобы иметь возможность выпуска кристалла на текущем доступном оборудовании внутри страны — это идея довольно здравая. VLIW, можно сказать, единственный путь, чтобы в текущих условиях выпустить микропроцессор общего назначения с хорошей производительностью. Китайцы свой MIPS до сих пор не могут сколько нибудь ускорить, ARM только недавно добрался до 1GHz, и он весь обложен патентами.

              > Единственное разумное объяснение — чтобы всё-таки доказать, что Эльбрус-3 таки мог быть сделан.

              Причина в другом. Когда Бабаян перебегал в Интел, он в срочном порядке регистрировал на себя все изобретения рабочей группы, ибо это было одним из условий его безбедного пребывания в Intel. И после его ухода, чтобы не попадать под патенты, и с целью доведения проекта до промышленного использования, стали пилить E2K. Благо что уже виновник торжества находился в другом месте и не мешал работать.
              • +2
                Сама идея достигнуть производительности P4 на грубом техпроцессе и частоте 300MHz, чтобы иметь возможность выпуска кристалла на текущем доступном оборудовании внутри страны — это идея довольно здравая.
                А зачем вам 300MHz? Что вы от этого получите? Зачем имея вот это разрабатывать ещё и вот это? Грубо говоря спалив кучу денег вы получили вместо процессора, выполняющего X инструкций за такт процессор выполняющий 2X инструкций за такт, но и имеющий при этом вдвое более низкую частоту при том же техпроцессе. Кому оно надо? Вас пример Itanic'а ничему не научил?

                VLIW, можно сказать, единственный путь, чтобы в текущих условиях выпустить микропроцессор общего назначения с хорошей производительностью.
                Поверю когда увижу, уж извините. Пока что все VLIW'ы выглядят очень и очень бледно и вообще не факт, что имеет смысл с ними связываться. Ах, да, есть исключение: видеокарты. Вот и подумайте на тему почему супергении под руководством Бабаяна сотворили процессор, который ничего (ну то есть совсем ничего) из себя не представляет в то время как «дураки» на Западе (в ATI и nVidia) сделали что-то, что реально продаётся и используется.

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


                Это-то понятно. Почему его таки доделали — понятно. Неясно зачем вообще весь сыр-бор затеяли изначально.
                • 0
                  Пока что все VLIW'ы выглядят очень и очень бледно и вообще не факт, что имеет смысл с ними связываться.

                  Я в этой области профан, но правильно ли понимаю, что подход «железо на службе у алгоритма» перспективен только для GPU и только потому, что для них легче создать оптимальную прослойку между высокоуровневыми алгоритмами (OpenGL, DirectX, и т.п.) и тем самым железом?

                  Я помню волну оптимизма вокруг RISC и других «хорошо забытых старых подходах» лет 15-20 назад. Как по Вашему, это все неоправдывано по техническим причинам, или потому, что трудно добраться до экономической целесообразности?
                  • 0
                    Грубо говоря какой бы CPU вы не выпустили на нём нужно будет гонять Linux или Windows, что автоматически очень сильно «подрежет крылья» вашему созданию. Угу, GPU «выстрелили» потому, что для них программы пишутся совсем по другому. И совместимость с существующих софтом и существующими OS была вообще не нужна.

                    Да, на них не запустить операционку и вообще они «ущербные». Но, как я уже говорил, GPU — продаются и используются, а Эльбрус — нет.

                    С RISC'ами, кстати, та же беда: у них тоже более «рыхлый» код, чем у x86 и им тоже нужен «большой прицеп». Нормально себя чуствует только ARM, но если вы на него взглянете… длина машинной инструкции 1, 2 или 4 байта, в режиме 2х байтов (Thumb) некоторые инструкции могут быть 4 байтовыми (Thumb2)… от «чистого» RICSа там одно название. Эльбрус, насколько я знаю, примерно подобные же приёмы применяет, но эффективность у них гораздо меньше (минимальная длина инструкции вроде как не 1-2 файла, как у x86-ARM'а, а скорее байт 8, хотя могу ошибаться — спеков они не публикуют).
                    • 0
                      спасибо.
                      куда пытаюсь увести разговор — раз я правильно понимаю, что первична экономическая проблема несовместимости кода, может быть у архитектуры (и уже потом у разработок местных ученых) все-таки есть еще шанс выстрелить в каких-нибудь новых направлениях? Очки там, или бортовые компьютеры?
                    • +1
                      длина машинной инструкции 1, 2 или 4 байта,

                      2 и 4

                      в режиме 2х байтов (Thumb) некоторые инструкции могут быть 4 байтовыми (Thumb2)

                      Thumb это урезаный 16-битный режим. Thumb2 позволяет совмещать 2х и 4х-байтовые команды.

                      от «чистого» RICSа там одно название

                      Спорно. К тому же v8 — чистый «академический» RISC.
                      Про рыхлый код тоже спорно. Сравнивал рандомно взятые куски (правда под AMD64) — на ARM получалось меньше инструкций и короче.
                • 0
                  Ах, да, есть исключение: видеокарты.

                  От VLIW уже все отказались — сложно писать эффективные компиляторы, обеспечивающие приемлимую загрузку юнитов.
                  • 0
                    Не согласен, в сегменте DSP как раз VLIW очень популярен в исполнении, например, TI, AD и тд.
                    • 0
                      Мне кажется там явно говорится про видеокарты

                      DSP, по крайней мере от TI — cкалярные, рассчитанные под ASM/С.
                      Фигурно выпиленные руками кернелы конечно могут раскрыть возможности VLIW, но ни о какой гибкости и универсальности речи не идёт.
                      Популярность — не признак хорошего.
                • 0
                  > А зачем вам 300MHz? Что вы от этого получите? Зачем имея вот это разрабатывать ещё и вот это? Грубо говоря спалив кучу денег вы получили вместо процессора, выполняющего X инструкций за такт процессор выполняющий 2X инструкций за такт, но и имеющий при этом вдвое более низкую частоту при том же техпроцессе. Кому оно надо?

                  1. Мы получим экстремально низкое энергопотребление. 5Вт на максимальной нагрузке — это прекрасно. Суперскалярам такое и не снилось.

                  2. В Эльбрусе E2K не только VLIW заложен, но и, например, поддержка изменяемого микрокода, что делает его совместимым с машинным кодом Intel. Это реально необходимо в некоторых областях промышленности. На спарках такое не прокатит, только виртуальные машины с эмуляцией инструкций городить, а это _очень_ медленно будет спарках выполняться.

                  3. Идея достигнуть произодительности за счет явного параллелизма, обеспеченного компилятором — тоже очень перспективна. С улучшением компилятора увеличивается средняя производительность системы, причем «рычаг воздействия» гораздо больше, чем у классических подходов.

                  4. Использование на аппаратном уровне защитного программирования вплоть до контроля типов — это реально жесткое обеспечение качества и безопасности кода. В операционках под Интель с их кольцами защиты постоянно находят дыры, микрософт уже SECURE BOOT продавило чтобы через три звезды колено решить эту проблему. А тут Эльбрус выступает прямо как статический анализатор кода, и делает все это на лету. Я где-то читал их отчет об обнаруженных ошибках в опенсорчном коде, цифры там заставляют задуматься.
                  • 0
                    Мы получим экстремально низкое энергопотребление. 5Вт на максимальной нагрузке — это прекрасно. Суперскалярам такое и не снилось.


                    5 Вт — это только у одноядерной версии на 300 МГц. Более шустрые варианты уже идут по 20-25 Вт, причем у 4-ядерного R1000 потребление меньше чем у 2-ядерных Эльбрусов и немногим больше чем у 1-ядерных, но на 500 МГц. Это только если по продуктам МЦСТ говорить. Если же включить в сравнение intel, то четырехядерный Z3740 потребляет менее 4 Вт (2 Вт типовых) при несопоставимой с 300-МГц Эльбрусом производительности

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


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

                    В операционках под Интель с их кольцами защиты постоянно находят дыры


                    Осталось только вспомнить какие дыры и подумать, как их можно было бы на аппаратном уровне закрыть :). «Кольца защиты» тут, кстати, вообще боком стоят, они не для этого предназначены и со своей функцией как раз справляются довольно неплохо (особенно если смотреть на nix где они используются более рационально чем в винде).
                  • –4
                    В Эльбрусе E2K не только VLIW заложен, но и, например, поддержка изменяемого микрокода, что делает его совместимым с машинным кодом Intel.

                    Программный двоичный транслятор теперь называется «микрокод»?
                    Ну так на спарках тоже самое можно сделать, хотя проблем будет больше конечно.
                    Но зачем прикидываться другой архитектурой? Вместо создания своей софтверной базы — прогиб под архитектуру потенциального врага.
                  • 0
                    Есть много суперскаляров, работающих на частоте порядка 1 ГГц и потребляющих гораздо меньше пяти ватт. ARM Cortex-A9, например.
              • 0
                ARM только недавно добрался до 1GHz, и он весь обложен патентами.

                И ARM и MIPS — лицензируемые архитектуры. Или вы предлагаете содрать и не платить?

                «недавно добрался» это когда?

                Например в Intel IOP 342 (Q1 2003г) стоит двух-ядерный 1.2GHz ARM
                То бишь почти 11 лет назад как
      • +12
        правда, не блоггеров, а людей, сделавших весомый вклад в развитие техники

        удививительно, как фантастически и здравомысленно звучит такая фраза в настоящее время…

        спасибо за интервью и ждем продолжений!
      • +1
        > принадлежит человеку, который занимается машинами со времен БЭСМа.
        «Насыщает не время, проведенное в столовой, а количество съеденных беляшей» (с) Лео Каганов
        • +2
          извините, я правильно понял, что по Вашему мнению он съел недостаточно?
          • +2
            Я не хочу быть ни сторонником, ни противником в данном вопросе, хотя 20 лет назад во время учебы был наслышан от научного руководителя о разработке Эльбрусов. Темой моей курсовой была одна из подсистем Электроники СС-БИС — это был «конкурирующий» с Эльбрусами проект. За давностью лет я уже все хвалебные слова и критику забыл. Много воды утекло. Да и технологии изменились.

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

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

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

              а это, извините, похоже на соревнования по громкости выхлопа газов. в столовой.

              комментарий не Вам лично. прячу в треде, не дождавшись интересного.
              • +4
                меня удивляет, что _никто_ не пытается обсуждать само содержание «эссе».


                А что там, простите, обсуждать? Полезной информации об архитектуре ЭВМ ноль, одно хвастовство. А так я бы с удовольствием прошелся по тезисам Бориса Арташесовича, но так нет их, этих тезисов. Есть тезис о полезности type safety, но без какой-либо конкретики о реализации или о том что полезного она дает. Неудивительно что в результате объектом критики стало хвастовство Бабаяна, причем, поскольку Бабаян этим хвастовством, увы, печально знаменит, то эта критика вышла за рамки конкретно данной статьи.
                • +1
                  И, все-таки, Вы избыточно агрессивны, согласитесь.
                  Монолог явственным образом не претендует на научную работу, а является чем-то вроде популярной лекции для самых маленьких:
                  В общем, тема моей беседы – это история развития нашего дела

                  Цель — объяснить, рассказать историю, как видит этот человек, который эту историю видел и (да-да) местами творил.
                  Зачем здесь требовать оправданий и доказательств?

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

                  В той статье, что приведена выше — слишком много истерики и банальных манипуляций (жонглирования словами и фактами), чтобы я ее воспринимал всерьез. И я не осуждаю человека, процитировавшего ссылку. Я удивляюсь, как «скандалы и интриги» изменили ход обсуждения и увели от главного (лекции).

                  Ну а половина, подобных Вашим, эмоциональных доводов построена на простой конструкции — «что же он такой умный, а Интел, значит, тупой, да?»
                  Более того, мне кажется и за Интел вступаться не нужно. Они свое отношение к этому человеку высказали более-менее внятно. Или же тут принято считать, что его должность — это попытка нейтрализации хвастуна, мешающего великой компании?

                  Но, еще раз хочу подчеркнуть — не интересно мне ничье личное отношение к этому человеку. Я сам построю свое личное отношение. На основании фактов, как раз, а не эмоций.

                  А эта неоконченная лекция, нам, молодым, — мне нравится и призываю такой же «глупый» материал множить, а не засорять. Тем более, что я верю, что лично Вы, благодаря своему опыту, вовлеченности и беспристрастности, более всех других в состоянии донести много интересного и полезного по схожей тематике.
                  • +3
                    Нет, простите, но я ведь здесь вроде как не пытаюсь тут никому затыкать рта и мешать монологу Бориса Арташесовича? Я разве где-то говорю что вторую (и последующие) части эссе не следует публиковать?

                    Вы задали вопрос почему никто не обсуждает содержание эссе. Я Вам на него ответил: потому что обсуждать там просто нечего. Вот совершенно безотносительно к личности Бабаяна — в его монологе нет ничего, что можно было бы обсудить в комментариях, кроме его безудержного хвастовства. Вам есть что на это возразить, предложив, например, конкретный тезис «из содержания эссе», который Вам бы хотелось обсудить? Или вопрос все же Вами ставится в разрезе не того, чтобы обсудить монолог Б.А., а в том чтобы помешать другим это делать?
                    • 0
                      Ок. Договорились.
                      На всякий случай повторюсь — лично мне (и автору топика, судя по нескольким комментариям) будет интересно почитать Ваши мысли на тему эволюции процессорных архитектур и дуализма софта и железа.
      • +9
        Странный тезис. Почему кто-то должен обладать весомым взглядом только потому что он чем-то занимался? Весомость человеку придает то что он что-то сделал, а с этим у Бориса Арташесовича, уж извините, большие проблемы — и цитируемая выше статья подробно рассказывает об этом.

        Далее. У описываемой статьи на самом деле есть продолжение. Примерно год спустя, когда Бабаян уже ушел в Intel, я общался с командой разработчиков, доделывавших процессор E3M.

        Так вот, насколько я могу судить, там была по сути заново набрана изрядная часть команды и пришел другой руководитель. И всего за год они сделали вменяемый «железный» прототип E3M, на котором крутилась работоспособная *nix, естественно с работающим компилятором. За весьма умеренные деньги, замечу. Практически студенты.

        Чудес там, естественно, не было — «суперидеи» Бабаяна на практике показывали довольно среднюю производительность, которая была неплохим для России, но отнюдь не прорывным по мировым стандартам результатом. Но, блин, люди там пришли и сделали работающую систему, тогда как Бабаян только языком трепал бог знает сколько лет.

        И я не очень знаю с кем Вы общались из «противников», но я удивлен слышать о идеях Бабаяна тезисы об «опережении времени». Бабаян генерирует много идей, но удачных из них ничтожное большинство. Он живет в оторванном от реальности мире, не проверяя то, насколько его идеи «ложатся» на реальное железо и реальные программы. Вот например во всем изложенном в статье тексте нет ни одной вменяемой идеи, которая бы способствовала повышению скорости или безопасности реальных программ. Зато там очень много хвастовства — присмотритесь сами. Мы везде там первые и гениальные, а Запад глупый и неработоспособный. Однако «почему-то» наши идеи никто заимствовать не спешит, тогда как удачные западные находки производители CPU расхватывают как горячие пирожки. Вам это не странно, нет? Мне кажется, что Вы исходя из ограничения «людей сделавших весомый вклад в развитие техники» пытаетесь общаться о Бабаяне с какими-то советскими бюрократами, имеющими весьма опосредованное представление об архитектуре CPU. Вам бы стоило вместо этого поспрашивать людей причастных к проектированию западных CPU — но они, полагаю, окажутся даже не в курсе идей Бориса Арташесовича :).
        • +2
          Все Эльбрусы были работающими системами. За ними работали реальные люди. Из разговоров с этими людьми я понял, что безопасность действительно была неплохо реализована. Точно так же некоторые указывали на то, что из-за этого падала производительность.

          Четких «за» или четких «против» мне найти в этой истории пока не удалось. Думаю, и не удастся. Мир, к счастью, не делится только на «белое» и «черное».

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

          В общем и целом я согласен, что в истории много всего спорных и белых пятен. Но это реальная история и реальные машины. Нужно просто продолжать «копать». Было бы здорово, если кто-нибудь присоединился и поработал с другими действующими лицами :)
          • +8
            Эльбрусы-1,2 действительно были работающими системами, но как выше было уже замечено, руководил их разработкой не Бабаян (он был заместителем главного конструктора). Эльбрус-3 которым руководил уже Бабаян работающей системой не стал. А ведь затем было еще 10 лет громких обещаний без какого-либо практического выхлопа.

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

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


            Так E3M же. Как раз отличная была проверка идей Бабаяна. Вполне себе современный уровень, 90 нм, 300 МГц когда я его видел (пишу по памяти, так что могу ошибиться, если хотите — потом уточню). Вполне себе были видны и идеи, и их потенциал, я даже тесты на нём гонял. Если коротко — то при глубокой оптимизации «вручную» там действительно получалась хорошая такая производительность, но «вручную» много софта так было не написать, гибрид CPU и DSP какой-то получался, но по производительности до DSP таки сильно не дотягивавший. А на компиляторе получался код равнявшийся на Pentium 2 @ 300 МГц. Что, замечу, тоже довольно неплохо — просто не так «революционно» и однозначно без каких-либо перспектив мирового господства.
    • 0
      есть версия совсем другая
      fcenter.ru/online/hardarticles/processors/15730
      где правда?

      Здесь…
    • –2
      «Абличение» пиарщика во «вранье» в стиле газеты «Московский Комсомолец», плюс страшилки про закладки в процессоре, плюс демонстрация непонимания причин неэффективности использования транзисторов в процессоре со спекулятивным исполнением (а там высокая «эффективность на один транзистор» и не нужна, нужна эффективность всего комплекса: удесятерение числа транзисторов ради утроения производительности процессора вполне приемлемо)… в общем, всё это снижает доверие к версии.
      • +2
        Страшилки про закладки — вообще-то как раз Бабаяновское изобретение и они, как бы, и являются основным доводом в пользу выкидывания денег на этот безумный проект. Это притом что ещё до его начала у МЦСТ уже были свои CPU, а «пеклось» (и «печётся») всё это в любом случае на Тайвене.

        Что касается транзисторного бюджета, то это вообще даже не смешно — достаточно сравнить Эльбрус-S с его одним ядром и 218 миллионами транзистров, R1000 с его четырьмя ядрами и 180 миллионами и, скажем, Pentium !!! с его 29 миллионами, чтобы понять, что не всё то золото, что блестит. Ну вот почему-то никак не получается вписаться во вменяемый бюджет у разработчиков VLIW-архитектур. И не получится никогда: код у VLIW'ов более «рыхлый», так что вся экономия на ядре легко пожирается необходимостью увеличения кешей, буферов и прочего. Грубо говоря попытка уменьшить седельный тягач приводит к тому, что вам приходится увеличивать размер полуприцепа в результате чего вся конструкция на дороге места занимает больше!

        Выйти из этого порочного круга не смогли ни Intel, ни Transmeta, ни МЦСТ. Однако его смогли сделать ATI и nVidia — полностью сменив программную парадигму, до чего последователи Бабаяна так и не додумлись. Так кто тут у нас время опережает?
    • 0
      Сначала он удивлялся зачем им нужно было сто миллионов, когда на тайваньском заводе можно было заказать партию за меньше миллиона, а потом сокрушается, что не получив большого финансирования опытный образец (даже не серийный экземпляр) сделали на тайваньском заводе, где могли добавить программных закладок. Интересно, сколько стоит поднять _у нас_ производство таких процессоров?
  • +2
    Спасибо вам большое, очень интересно, жду продолжения.
  • +5
    нет, дорогая редакция, на самом интересном месте… как в журнале Костёр… одно возмущение осталось от прочтения
  • +7
    «Эльбрус-1», «Эльбрус-2»

    Эльбрус-1/2 Главный конструктор — Всеволод Сергеевич Бурцев.
    Эльбрус-Б (или Эльбрус-1КБ) Главный конструктор — Г. Г. Рябов.

    тыц

    тыц

    Некоторые из его идей использованы в архитектуре Transmeta.

    По утверждению самого Бабаяна.
    • +1
      Эльбрус-1/2 Главный конструктор — Всеволод Сергеевич Бурцев.
      Эльбрус-Б (или Эльбрус-1КБ) Главный конструктор — Г. Г. Рябов.


      Архитектор и формальный руководитель проекта — разные вещи.

      По утверждению самого Бабаяна.


      По утверждению Дэвида Дицела
      • +1
        Архитектор и формальный руководитель проекта — разные вещи

        Однако вы мешаете всё в кучу.
        т.к. Бабаян был формальным руководителем Э3.

        По утверждению Дэвида Дицела

        А можете ткнуть пруфом?

        «The only thing I'm disappointed in is that David didn't tell directly to me that he has put to use so many things he learned here,» he [Boris Babaian] said.
        • –1
          Я и не говорю, что Бабаян был формальным руководителем первых двух Эльбрусов. Руководителей этих проектов вы совершенно верно указали выше.

          Тем не менее, Бабаян был архитектором всех трех систем.

          С Дицелом я беседовал лично. Письменного пруфа у меня нет.
          Но если вас так задел этот вопрос, можете проделать две вещи:

          1) написать Дицелу письмо. Думаю, он не будет отпираться
          2) можете изучить описание Трансметы
          • +2
            можете изучить описание Трансметы

            Уже, много лет назад как. Что там общего с E3?
      • +4
        «формальным руководителем» в кавычках.
        Мне кажется что всё же главный конструктор как раз в ответе за архитектуру.
        Почему вы приписываете Бабаяну все заслуги?
        • +4
          Я Бабаяну ничего не приписываю. Я говорил с людьми, которые принимали участие во всех трех проектах. Именно так они отозвались о роли Бабаяна.

          Внизу я выражаю благодарность Александру Киму, директору МЦСТ (сейчас за Эльбрусы отвечает он). Можете позвонить ему (его телефон есть на сайте МЦСТ) и обсудить роль Бабаяна с ним.
          • +5
            С руководителями МЦСТ на эту тему говорить бесполезно. Там замешана политика и советские бюрократы. Я общался и знаю о чем говорю — меня, например, просто угрожали засудить за публикацию сведений, где о E3M будет написано что он работает не фантастически быстро, а всего лишь на довольно среднем уровне. Там целая мифология выстроена, которая довольно жестко защищается. Общайтесь лучше с «технарями», желательно — ключевыми разработчиками (знающими о чем идет речь), но не руководителями (которые вынуждены соотноситься с политическими реалиями)
            • 0
              У руководителей я только визы получаю. Мои главные собеседники — инженеры.
              • +5
                Если честно — то не похоже. Вы бы хотя бы назвали этих инженеров и дали им слово.
                Говорю, повторюсь, как человек, который с этими инженерами тоже общался
                • +7
                  Не проблема. Некоторые из имен указаны в конце текста. Кроме Кима, там все инженеры и архитекторы.

                  «Дать им слово» — это то, что я мечтаю сделать. Но это очень большая работа.

                  Предложу вам то, что предлагал уже в комментах выше: раз вы знаете людей — присоединяйтесь! Поработайте с кем-нибудь и напишите текст.
  • +1
    Очень интересная тема, к сожалению, пока склоняюсь к мнению озвученному выше и в статье на формозе — Бабаян может и хороший бизнесмен, но не более того. Про характеристики, которые постоянно вдвое лучше самого быстрого процессора — в точку.
  • +1
    Увидел, что Борис Бабаян в Интеле и удивился (не знал). Сразу всплыла фраза: «Пентиум — Пентковского, Эльбрус — Бабаяна». Когда-то, году в 2000, читал об Эльбрусе 2k, и узнал, что один из разработчиков Эльбруса работает в Интел. По молодости лет воспринимал этот факт предательством. :)
  • 0
    Эти Эльбрусы вообще реально где-то используются? Или это всё vaporware?
    • +1
      Если вы почитаете что тут понаписали в комментариях, то обнаружите, что истина, как обычно, посередине:
      1. Эльбрусы в конце-концов таки довели до ума (правда уже без Бабаяна)
      2. Работать они, в принципе, работают — но нафиг их кто-то сотворил и куда их девать неясно до сих пор (в том числе ответа на этот вопрос не могут дать и сами работники МЦСТ)

      P.S. Думаю что, в конечном итоге, Эльбрусы всё-таки к делу приспособят, так как софта под Sparc — всё меньше, а под x86 (для которого под этот самый Эльбрус есть эмулятор) — всё больше. С почти тем же успехом можно было бы сделать эмулятор x86 под Sparc (пусть с некоторыми «добавками», чтобы его ускорить), но если рассуждать разумно и исходить из того, что Эльбрус и эмулятор под него уже есть, а под Sparc пока ничего нету… В общем воспринимайте Эльбрус как новомодное повторение славной истории с Бураном.
  • +4
    Зря хает iAPX-432.
    Хороший процессор был. Хотя с производительностью действительно были очень большие проблемы.
    Упоминаемая в статье проблема с разделением сегментов это лишь одна из минорных.
    Основные затыки были физические (техпроцесс / распиновка / отсутствие кэша), архитектурная платформа была очень гибкая, перестройка ISA занимала буквально день-два.
    Это не только мое мнение, но и самих разработчиков (с кем мне удалось пообщаться).
    Кстати статья Колвелла (на основе которой он построил диссертацию и PhD получил) отнюдь не такая односторонняя как показано в данной статье.
    • +2
      Очень интересно. А вы не помните, как статья называлась? Возникло желание почитать.

      Это очень здорово, что вы знакомы с разработчиками 432-ой. Можете рассказать что-нибудь об их впечатлениях о проекте? Почему-то в Интернете информации по 432-ой почти нет :( Сгинула совсем…
      • 0
        Я нашел его CV, там есть список публикаций
        Название диссертации:
        The Performance Effects of Function Migration and Architectural Complexity in Object-Oriented Systems, Robert P. Colwell, PhD thesis, Carnegie-Mellon University, Pittsburgh, PA, August 1985
        • 0
          Кстати, он как раз автор «печально знаменитой» архитектуры Pentium 4
      • +6
        > Очень интересно. А вы не помните, как статья называлась? Возникло желание почитать.
        Конкретно по iAPX 432:
        Robert P. Colwell / Edward F. Gehringer / Doug Jensen; «Performance Effects of Architectural Complexity in the Intel 432» ACM Transactions on Computer Systems, vol. 6, no. 3, August 1988, pp. 296-339.
        Диссертация немного более общая.
        > Можете рассказать что-нибудь об их впечатлениях о проекте?
        Много слишком текста.
        Разве что приведу отрывок одного письма.
        The 3 largest problems with the iAPX432 (in my opinion) were:
        — pincount limitations of then-current IC packaging (no more that 64-pins)
        — consequences of having no/minimal cache
        — design complexity vs. the 5 micron NMOS fabrication process limiting the # of transistors on a chip

        Some negatives:
        The ACLs had to be repeatedly picked up to be processed, and the resolution was not cached.
        The initial thought to have a large on-chip stack got trimmed to one word (so conditional branches could be fast)
        The load/store instruction set — no registers — was a problem with a narrow pipe of 64-pins to «drink» through
        — anything larger than 16 bits had to be multiplexed and/or serialized into and out of the chip
        The cost — both power and delay — of sending microcode and status information between the `01 and `02 was terrible
        The limitation of 32-bit addressing was horrible for the size of «commercial» problems the 432 was supposed to tackle
        — even with lots of available segment descriptors, it was still too small
        — segments can be OK, but must not be required
        — they are OK if they are 5x to 10x larger than the biggest data set you may want to manipulate in one «lump»
        Use of a new programming language of limited viability — Ada — was a serious problem
        — Simula or the object-oriented form of Algol would have been better
        — in fact, most of our simulators were written in Simula: easy instancing of repeated blocks, easy hook-up in the code interfaces
        — we later changed to use of MainSail (a portable, object-oriented language from a Stanford spin-off) — that was a wonderful language
        The original design — where data segments and Access segments were separate object was very, very in-efficient in hardware
        — the 2nd design rev — access and data segments together (negative and positive displacements, respectively) from the segment «base» was much better

        Some positives:
        The frequency-encoded, bit-length variable instruction set was surprisingly efficient
        — the ISA could — and did — change several times a week depending on statistical analysis of code generated «to date», and
        the compiler was updated in minutes to generate the new instruction set
        The iAPX432 was a very good learning exercise for subsequent work with object-oriented languages
        Very innovative structures were used on-chip: barrel shifters, bus-integrated ALU and address generation logic, folded PLAs, etc.
        It was one of the 1st implementations of IEEE conformant 32-, 64- and 80-bit floating point
        — we did LOTS of simulations of operations to minimize ULP (units-in-last-place) errors
        It was the 1st chip at Intel that was fully register-transfer-level simulated, and mixed-level logic+RTL simulated
        The IC layout design was fully connectivity extracted, and compared to the logic design for errors
        — this procedure/process was hand validated by crawling around on a 30m x 30m chip plot tracing circuits
        — we found the computer connectivity validation found many times more errors than the humans did
        — Intel changed to using the computer method almost exclusively — I wonder why :-)
        We (mostly) used my all-time favourite computer system — a dual processor DecSystem-10 / TOPS-10 to do all this work
        — I'm still mad that Digital Equipment corp. cancelled the «Jupiter» project; sigh…

        > Почему-то в Интернете информации по 432-ой почти нет
        Информации много, сэмплов не осталось совсем, вот что печально.
        • +2
          Спасибо! Очень круто!

          А вы в связи с чем разработчиков опрашивали? Что-нибудь публиковали на эту тему?
          • +3
            > А вы в связи с чем разработчиков опрашивали?
            Ищу рабочий процессор. Хочется в живую всё это пощупать.
            Надоел многим людям, но так и не нашёл пока.
            > Что-нибудь публиковали на эту тему?
            Еще нет, нет тела — нет дела :)
            Без сэмпла трудно проверить всё что написано в мануалах. Нет даже симулятора (говорят что был под VAX, машинки на которой использовали при разработке, но само собой копий нет).
        • +3
          Вообще, судя по по тем фрагментам, которые вы здесь выложили (еще раз большое спасибо!), думается, что Бабаян провел неплохой для условий того времени анализ.

          В письме тоже делается (как мне показалось) акцент на неэффективность разделения указателей и данных:
          «The original design — where data segments and Access segments were separate object was very, very in-efficient in hardware»

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

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

          В письме разработчик указывает лишь «административный» плюс: легко было вносить изменения в проект. В принципе, с хорошей ISA — это почти очевидно. Простая ISA — значит, можно посторить эффективный симулятор, который можно пределывать «на лету». Похоже, так у них и было.

          А вот в плане производительности, скорее всего, ожидались большие проблемы. Простая ISA — громоздкая ISA (условно). Значит, нужна хорошая подкачка, нужен большой кеш. А с этим у них было плохо…

          Видимо, еще нужно отметить, что в то время Бабаян вряд ли мог знать о проблемах с разводкой и ограничениях американского техпроцесса. Поэтому ему приходилось концентрироваться на логике. Что удивительно, он смог по косвенным признакам или из общих соображений вывести некоторые интересные вещи (например, очереди сегментов для переиспользования в процедурах и пр.) В беседе со мной он дал некоторый набросок того, как проводил анализ. Но я пока не могу об этом писать, т.к. совсем не знаю 432-ой машины. Боюсь неправильно что-то понять и налажать.
          • +1
            > В письме тоже делается (как мне показалось) акцент на неэффективность разделения указателей и данных:
            Это не акцент, это просто один из недостатков.
            Для сравнения, в том же списке есть гораздо более существенная проблема — разделение процессора (конвеера!) физически на 2 отдельных чипа, и огромные потери на их интеркоммуникациях.

            Список достоинств мал, просто потому что сама архитектура и ООП-заточенность процессора это фактически шаг в будущее. То есть все достоинства это by design, сами идеи и архитектура. Открываем мануал, и читаем, всё это и будут достоинства процессора :)
            Упоминать их не имеет смысла. Всё запоролось на хардварной реализации.
            К примеру, другой человек мне писал:
            «These were very long „systems level“ projects for a then small „component“ company like Intel. They were both „a bridge too far“. In the end, their most value to Intel was the staffs they hired/trained and the technologies developed which then became valuable contributions to future Intel products.»
            • +1
              С этой позиции Бабаян 432-ую не критикует. Он критикует именно реализацию. А высокоуровневые идеи у эльбрусовцев у самих те же самые (только возникли гораздо раньше).
        • +1
          В Интеловском музее можно запросить — они вполне дружественны.
          • 0
            Думаете не спрашивал?
            Кроме того мне сообщали что интел совсем не гордится данным процессором, и частенько о нём умалчивает.
            • 0
              Систему команд мне дали.
              Могу переслать.
              • 0
                С доками проблем нет.
                Их у меня довольно много.
                В том числе и отличная книжка Organick'a и reference manual интеловский.
  • –1
    Все это хорошо, только как показывает практика — алгоритмы, сложнее молотилок чисел или брутфорса, нихрена не распараллеливаются. Возьмем к примеру сортировку массива. Нет, распаралеллить принудительно ее можно, или сортировать всякими merge sort и т.д. Только время выполнения этого говнокода на 4ех (8,16,32,100500) ядрах будет либо больше, либо сравнимо с однопоточной версией. И так много с чем обыденным, типа тех же архиваторов.
    • +5
      Большинство научных задач распараллеливается очень хорошо.
      • +3
        Вот только Tesla / Phi для таких научных задач подходят гораздо больше Эльбруса
        • +3
          Кто же спорит, просто наезд выполняют на многопоточность в общем, а не на конкретную систему.
    • 0
      Вообще-то сортировка очень и очень хорошо парализуется. Существование Гугла это неплохо доказывает.
  • +2
    А где можно найти исходники ОС любого Эльбруса? Думаю, это был бы весьма интересный проект для нынешних студентов-программистов, да и в целом как уникальный экспонад для виртуального музея информационной археологии.
    • +4
      Когда сперли исходники Винды, народ тоже думал, что все сразу бросятся с красными глазами их копать. Но никто особо не стал влезать. Слишком много всего и слишком оно чужое…

      Много ли найдется студентов, желающих освоить Эль-76 и изучить операционную систему на нем?

      Хотя думаю, что у любого студента, работающего в МЦСТ, такая возможность есть.
      • 0
        Между тем (как подсказывают из зала) в MIT с удовольствием выдают студентам именно такие замшелые системы для практических работ. Это прекрасная возможность опробовать свои знания в программировании (а не в кодинге на каком-то одном языке) в необычной обстановке. В любом случае, вопрос остаётся открытым, складывается такое ощущение, что Эльбрус — это такой мифический зверь, существующий только в воспоминаниях отдельных людей. Кто-нибудь может убедительно доказать его существование?
        • 0
          Я думаю, вам надо обратиться в МЦСТ (контакты есть на их сайте). Там работают очень интересные и отзывчивые люди. Если вы сможете четко объяснить, что вам нужно и, главное, зачем, то они, вполне возможно, пойдут вам навстречу.

          С другой стороны, я не уверен, что они прямо бросятся шарить исходники. Все-таки это проприетарная вещь, которая (теоретически) может представлять коммерческий интерес. Так что не знаю… Но поговорить стоит.
          • 0
            Я просто оставлю эту ссылку здесь. А позже напишу письмо в МЦСТ и мы потом вместе либо посмеёмся над фразой "(теоретически) может представлять коммерческий интерес", либо всплакнём над ней.
          • 0
            Письмо написал, жду ответа.
          • 0
            Думаю, можно смело подвести итоги: на письмо в МЦСТ ответил Константин Трушкин, начальник отдела маркетинга и посоветовал обратиться в ИТМиВТ. В ИТМиВТ парни работают суровые, на почту не отвечают. Вот и вся история. Эльбрус опять ускользнул :)
            • +1
              Насколько вам интересна эта тема?

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

              На данный момент у меня есть такая информация:
              1) найден рабочий Эльбрус-2 (в Софрино)
              2) найден человек, который утверждает, что сохранил всю информацию по проекту (но есть неуверенность относительно кодов ОС). В любом случае есть бинарии ОС, поэтому можно поднять ее на симуляторе (который нужно будет разработать).

              Если вы настроены серьезно, могу свести вас с людьми.
              • 0
                Мне она интересна только с точки зрения «цифровой археологии». Посмотреть, почитать и поумиляться. Так что предложение свести с людьми не по адресу. Но почему бы найденному человеку не выложить «всю информацию по проекту» в свободный доступ? Я готов финансово по мере возможностей поддержать проект «Отсканируем всё про Эльбрус и выложим». Физически, учитывая мою удалённость от Софрино, помочь ничем не могу.
                • 0
                  Проблема в том, что разработчики первого и второго Эльбрусов сейчас довольно пожилые люди, причем все еще активно работающие. Сами заниматься обработкой и продвижением материалов они не будут. Так что нужны именно рабочие руки. Но есть надежда, что они найдутся. Вроде бы, у хороших людей назревает идея написать симулятор Эльбруса.
                  • 0
                    Значит, остаётся надеяться только на них.
    • 0
      Я искал (работая в Институте Точной Механики), найти не смог. В девяностые многое из архивов потерялось.
      Правда мне дали плохо напечатанное описание системы команд. Все ни как руки не дойдут эмулятор написать.
      • 0
        Можешь выложить скан этой системы команд?
        • 0
          Попробую в выходные сделать. Только там качество печати не очень.
          • +2
            Это не так важно, я comic sans bold italic underline видел, меня сложно качеством печати напугать.
  • –12
    «начинал работать. Кончал – снимал свою магнитную ленту, уходил, другой приходил»
    Лучше кажется использовать слово «Заканчивал» :)
  • +3
    В 80 лет, быть в такой неплохой умственной форме… впечатляет…
    Ну и кончено дай Бог здоровья и с грядущим юбилеем!
  • +1
    Жалко, что Intel недооценила свою 432. И Бабаян ее недооценивает. Решение отделить указатели от данных дешевле (в плане аппаратуры), чем вводить теги. И современные языки (кроме С++) на такую архитектуру неплохо отображаются.
    Теги только в редких случаях дают преимущество, позволяя писать более универсальный код.
    • 0
      А зачем эти тэги вообще нужны, для компилируемого кода? Я так идею и не понял. Смахивает больше на фичу, удобную для ассемблерщиков.
      • 0
        Переполнение буфера, ошибки компилятора, модифицирующие екзешники вирусы…
        Кроме того, может быть полезно, что один бинарный код обрабатывает и int, и float. Хотя редко.
        • +1
          Переполнение буфера


          Для этого достаточно разделять данные и код, что отлично реализуется NX-флагом

          ошибки компилятора


          Большинство ошибок компилятора таким подходом не найти. Какой смысл?

          модифицирующие екзешники вирусы


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

          Кроме того, может быть полезно, что один бинарный код обрабатывает и int, и float. Хотя редко.


          Полезно :-O? Для чего? На размере бинарника три копейки сэкономить?
          • 0
            Различие кода и данных весьма условно. Данные могут содержать код на интерпретируемом языке. Переполнение буфера на стеке может изменить адрес возврата, что приведет к несанкционированному исполнению кода, пусть даже из корректной программы.

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

            Теги ограничивают возможность исполняемого кода, в том числе и вирусного. Написать вредоносный код для такой архитектуры сложнее.
            • 0
              Различие кода и данных весьма условно. Данные могут содержать код на интерпретируемом языке.


              Тогда его и тэги не отловят :)

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


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

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


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

              Теги ограничивают возможность исполняемого кода, в том числе и вирусного. Написать вредоносный код для такой архитектуры сложнее.


              Вопрос в том, стоит ли овчинка выделки. Потенциально и правильный код для такой архитектуры написать сложнее, плюс однозначно страдает производительность.
              • 0
                В буфере будут строки, а интерпретируемый код в виде AST. Да и теги обычно позволяют ограничить буфер.

                Производительность может не пострадать, за счет увеличения количества аппаратуры. По моему опыту производительности большей части программ хватает с запасом, а вот с надежностью проблемы наблюдаются.
                • 0
                  Производительность может не пострадать, за счет увеличения количества аппаратуры. По моему опыту производительности большей части программ хватает с запасом, а вот с надежностью проблемы наблюдаются.


                  Там где с производительностью проблем нет проще сделать виртуальную машину а-ля Java.
                  • 0
                    Так ведь не делают :-).
                    • +1
                      Да нет, вполне себе делают — просто оно тормозит и все равно остается уязвимо для других популярных видов атак :)

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.