0,0
рейтинг
2 июля 2012 в 18:09

Разработка → Критический взгляд со стороны на процессоры Мультиклет / Multiclet

В последние пару недель на многих сайтах были заметки о начале производства (на азиатских заводах) отечественных процессоров Multiclet с «прорывной архитектурой и фантастической производительностью», в том числе и на Хабре: Первая опытно-промышленная партия отечественных мультиклеточных процессоров MCp. Все эти заметки в целом рассматривали разработку с позитивной стороны, основываясь на преимуществах в изложении разработчиков. Я всегда интересовался отечественными разработками, и попробую рассказать об этом процессоре чуть более критически, и описать в меру своих возможностей суть этой новой архитектуры.

Источники информации — ограниченная документация доступная на сайте разработчика, и ответы сотрудников компании на вопросы.

Архитектура


Если отбросить всю словесную шелуху (а её особенно много в данном случае), мультиклет — это в первом приближении любимый в России и СССР EPIC: архитектура с явным параллелизмом. В отличии от VLIW, где компилятор указывает какой блок что должен делать, тут указываются только зависимости инструкций, а по ядрам они растаскиваются уже в процессе выполнения (таких ядер в MCp0411100101 — 4 штуки).

За рубежем эта архитектура известна, и с 2006-года работает в кремнии (Explicit Data Graph Execution / TRIPS), но массового коммерческого успеха за прошедшие 6 лет не видно.

Преимуществ по сравнения с VLIW тут 2: гипотетическая возможность запускать код на процессоре c другим количеством «ядер» и возможность продолжить работу при выходе из строя одного из ядер. Оба преимущества, на мой взгляд, весьма сомнительны:

1) Запуск без перекомпиляции на процессоре бóльшего размера — для embedded применений обычно нет проблемы в перекомпиляции. Помимо этого, оптимальный код для 4 и 16 ядер разный — и запуск без перекомпиляции снижает эффективность (конечно если мы делаем что-то сложнее чем перемножение массивов).

2) Устойчивость к сбою любого ядра — эта «фишка» появилась недавно.
По последней информации, в выпущенной микросхеме устойчивости нет, она может появится в будущем при необходимых изменениях.
И нет никакой информации о том, как это работает, и в виду чрезвычайной сложности задачи продолжения работы при сбое ядра — я подозреваю, что это голый маркетинг и это не работает вообще, в том виде как это нам представляется. Разработчики объясняют отсутствие какой-либо информации об этой фиче тем, что она еще «не запатентована» (ну и нужно помнить, что сбой в разделяемых ресурсах — памяти, коммутаторе, регистрах — это гарантированный труп).

Теперь посмотрим на картинку из описания процессора (ПП — память программ, ПД — память данных, ПБ — процессорный блок):


Сразу бросается в глаза — общий регистровый файл и коммутатор, совместный доступ к памяти (когда все ядра могут читать и писать практически что угодно). Обычно такого рода архитектуры работают медленно (из-за чисто физических ограничений), и возможно это причина, почему Мультиклет работает всего на 100Мгц при изготовлении на зарубежной фабрике (т.е. вряд ли там техпроцесс толще 130-180нмна 180нм).

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

Производительность


Казалось бы, 2.4GFLOP декларируемые производителем — весьма существенная производительность. Однако, в компании-разработчике процессора отказались пояснить, каким образом была получена такая производительность при тактовой частоте 100МГц, и не подтвердили, что madd (multiply+add) выполняется за 1 такт. Тем не менее, похоже, мне удалось понять откуда взялась такая цифра.

Мультиклет работает с числами одинарной точности — «single» (32-бит) и есть возможность упаковать комплексное число single-точности в 64 бит (т.е. действительная и мнимая часть по 32 бит). Тогда и получается, что если умножение двух комплексных чисел выполняется за 1 такт, то это дает 6 FLOP за такт: (a + bi)(c + di) = (aс + bd) + (ad + bc)i., и соответственно, 6*4*100Mhz = 2.4GLOP.

Таким образом, сравнивать эту производительность с настольными Pentium-ами всякими конечно нельзя (это любят делать в обсуждении: «вот, почти достали Intel»): в настольных процессорах принято производительность измерять на 64-х битных вещественных числах, а тут озвученные цифры производительности получаются только на 32-бит и только в специфических условиях.

На обычных операциях с неупакованными данными производительность составляет 400 млн. операций в секунду, и нужно иметь ввиду что набор инструкций тут существенно более простой чем в том же арме, т.е. скорость на обычных задачах будет ниже, чем у 400Mhz арма (или Комдива-64).

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

Энергопотребление


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

Периферия и прочий фарш


Во первых, обращаем внимание на количество памяти — по 16кб памяти программ и данных.
Контроллера внешней памяти нет, соответственно все разговоры о портировании Linux — это дело далекого и туманного будущего, перед которым нужно еще сделать бакенд к GNUC для этого процессора.

Флеш-памяти для хранения программы нет, и загрузка производится с внешней флешки (в данный момент это Xilinx XCF04S). Естественно это вызвало подозрения, что процессор — перемаркированная FPGA, но на прямой мой вопрос об этом мне ответили:
Вместо Xilinx можно было бы поставить любую флэшку, а кристалл есть кристалл (внимательно посмотрите сайт), на FPGA мы сейчас ничего не делаем. Делали на этапе ОКР, для подтверждения расчётных параметров.
Кристалл сделан по 180нм.

Периферия — более-менее понятная для тех, кто работал с микроконтроллерами, за исключением Ethernet и USB — на кристалле нет «физической» части интерфейса, и их нужно ставить на плате отдельными микросхемами.

Софт для разработки — на данный момент только ассемблер. Компилятор С находится на стадии «пузырьковая сортировка работает» (Update: и факториалы). Подробное описание архитектуры, необходимое для разработчиков — не доступно на данный момент.

Резюме


Архитектура Мультиклета — да, действительно новая и действительно разработана в России на западе малоизвестна, но с 2006-го года работающая в кремнии (у буржуйского первого процессора производительность была 15.6 GFLOP). За бугром оно за 6 лет «не взлетело», и очевидно не спроста.

Достигнутая практическая производительность первого процессора в 400 млн операцией в секунду сравнима, а местами и меньше чем производительность серийных одноядерных процессоров классической архитектуры производимых в России (про зарубежные процессоры и DSP я конечно молчу) — за счет более высокой тактовой частоты и более «мясистого» набора инструкций последних.

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

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

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

Буду рад услышать ваши дополнения и корректировки — доступная информация по Мультиклету весьма ограничена, и я вполне могу где-то ошибаться.

Update: Обновлены данные по точности вещественных чисел, 24->32бит, 48бит убрано, переписал в свете этого резюме в более позитивном ключе.
Update: Более явно отделил свои домыслы от фактов.
Update: Благодаря beeruser обнаружили, что эта архитектура (Explicit Data Graph Execution / TRIPS) известна на западе достаточно давно, и назвать её новой нельзя. Т.к. у них она УЖЕ не взлетела, вероятность взлететь у нас — крайне мала.
Update: Получены дополнения от разработчиков — кристалл сделан на 180нм, отказоустойчивость — в текущем процессоре её нет, она может появится в будущем.
Михаил Сваричевский @BarsMonster
карма
966,7
рейтинг 0,0
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

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

Самое читаемое Разработка

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

  • +5
    Исходя из Вашей статьи можно сделать вывод, что это очередной PR проект Сколоково\Нано\Чубайса?
    Я так понимаю дальше стен лабораторий этот процессор не пойдет и будет лишь демострироваться на различных выставках как нечно волшебное
    • +19
      Все не так плохо, этот проект не бумажный — получен реальный работающий продукт, который где-то может быть использован, особенно если нужен именно отечественный процессор.

      Но заявления о «прорывной архитектуре», «мы сейчас всех порвем с их устаревшей Фон-неймановской архитектурой» — это некоторое преувеличение на мой взгляд.
      • НЛО прилетело и опубликовало эту надпись здесь
        • +1
          Человек, который не понимает что такое FPGA, наверно и не дойдёт до этой части текста.
          Автор постарался критически взглянуть, исходя из имеющейся информации, а его уже в американские шпионы записывают :)
        • +3
          Понимаете в чем дело, я не против отечественной электроники. Более того, в России разработаны и производятся куча хороших и добротных процессоров, которые сделали безо всякого выпендрежа и загибаний пальцев: есть Элвис, есть Модуль, есть НИИСИ РАН, есть Миландр, есть МЦСТ (с натяжкой).

          Но когда кричат «У нас крутая архитектура» и «Мы счас всех за пояс заткнем» и при этом не дают реальной информации о том что именно у них такого крутого, как именно они посчитали их производительность указанную в рекламных статьях и документации, как собираются обеспечивать разрекламированную отказоустойчивость, и как и почему они всех смогут заткнуть за пояс — у специалистов это вызывает вопросы.

          По результатам прояснения вопросов и написана эта статья.
        • –2
          Да да, это все Американские спецслужбы.
        • +1
          на самом деле всё что тут перечислено дня массового внедрения значения не имеет. Тут гораздо важнее с какой он работает IDE, поддержка библиотек, стабильность работы (глюки), портирование ОС и тд. Понимаете после такого «Софт для разработки — на данный момент только ассемблер.» тут всё можно ставить крест, я уж не говорю о других недостатках. Сделать то сделали, а смысл.
          • НЛО прилетело и опубликовало эту надпись здесь
  • +2
    Ну, защита от сбоев процессора всё же вещь хорошая. Если прозрачный перезапуск фрагмента кода (инструкции?) возможен, это откроет серьёзные двери в серьёзные решения.
    • +5
      В этом и проблема, как определить, что выполнение инструкции прошло со сбоем? Как откатить состояние?

      В радиационно-стойких процессорах исключают саму возможность сбоя технологическими способами (8T SRAM, ECC во всех регистрах и памяти, кремний на изоляторе) и готовятся к ней с программной точки зрения.
      • 0
        Для схемы требующей надёжности можно исполнять один код на двух «клетках», и в случае различия, запустить тесты чтобы выявить сбойный.
        • +2
          Звучит просто, но в реальности очень много вариантов требующих проверки: Увидеть отличия в условном переходе? Во входе в прерывание? Запись правильного значения в неправильный регистр…

          Но если бы это было реализовано — было бы полезно.

          • 0
            Отличия очень просто увидеть: берём и сравниваем. Проблема в том, как определить, какое из вариантов верный. Но, насколько мне известно, у нас традиционным решением проблемы является дублирование процессоров с предположением о том, что поломаться может меньше модулей, чем останется корректно работающими. Ну, и сбоящий определяется простым голосованием. MCp-шная фишка в том, что проверять корректную работу можно не всего процессора целиком, а каждой клетки отдельно, и при сбое в какой-то, отключать только её, а не весь процессор.

            Да. Это требует и программной поддержки и прочего. Да, рекламные лозунги такие рекламные, но особенности у процессора действительно есть, которые облегчают задачу.
            • +2
              Ну для того, чтоб сравнить результаты и принять решение, на каком из модуле возникла ошибка, нужен некий брокер, который сам будет защещён от ошибок.
              А здесь его не видно, и похоже предполлагается что это будет делатья програмно, на тех же процесорных модулях, на которых будут выполнятся алгоритмы, результаты которых будут сравниваться.
              А кто гарантирует, что сам алгорим сравнения будет не выполняться на сбойном модуле.
              • +1
                Насколько я понимаю в этом (а могу ошибаться), брокер не нужен. Схема сравнения — это куча простых компараторов, которых можно сделать множество, и за счёт количества обеспечить необходимую степень достоверности сравнения. И признаком того некий модуль вышел из строя служит просто набор 0 (false) на выходах этих схем. Вот. Тут не нужен сложный алгоритм сравнения и анализа: просто нужно, чтобы на определённых проводочках всегда шли одинаковые сигналы, как только где-то появляются различия, это признак ошибки.
                • +1
                  Ну дык вы сами написали, что некое аппаратное решение всё же необходимо, чтобы от этого дела был реальный толк.
                  И тут два варианта — или его нет или его просто не указали в сехме.
                  • 0
                    А пока три модуля выясняют, кто из них сбойный, четвертый исполняет программу.
            • +1
              Только не дублирование, а троирование. Если два выдали совпадающее значение, третий другое — он объявляется сбойным.
              Похоже, на этой архитектуре троирование можно будет сделать довольно красиво.
        • +2
          вообще-то на трех, если две согласны, то понятно что выбрать.
      • 0
        Я не эксперт по этому вопросу, но примерная схема понятна: выполняем на трёх ядрах, решаем (компаратором) у кого большинство. В принципе, можно даже и не трёх, а, например, 6, с требованием «не менее 5 согласных». Если несогласных больше, инструкция выполняется повторно.
        • 0
          При этом производительность относительно тех процессоров, у которых ядра работают параллельно, вместо того, чтобы сбоить и проверять друг друга, сразу уменьшается пропорционально количеству ядер?
    • +1
      Т.е. понятно что это вещь хорошая. Но судя по отсутствию каких-либо деталей об этом, и огромной сложности проблемы — никакой защиты от сбоев тут вероятно нет.
  • +3
    Чем то мне он пропеллер напомнил. Только у того 8 ядер.
    • +1
      Пропеллер гораздо ближе к реальности — у него память и регистры отдельные у каждого ядра, соответственно проблем с масштабированием намного меньше.
  • 0
    Единый регистровый файл, но возможная разбивка по памяти.
    Это эпично.
    Вдвойне эпична разбивка исполняемой памяти.
    Кэш насколько я вижу даже теоретически трудно пристроить, не говоря уже о железе.
    Чем-то мне cell напомнили:
    image
    Одна шина, у ядер local storage, разве что вместо общего файла, общие регистры.
    Имхо, на бумаге это неплохая дипломная работа, особенно на уровне сегодняшнего образования — очень неплохая.
    А кому она нужна в железе — хз, разве что PoC, испытание сил перед нормальным проектом, но у нас уже есть парочка классных процессорных лаб.
    • +1
      А какие проблемы с кэшем вы видете? Эмс. Там вполне возможен обычный контроллер памяти. То, что на картинке обозначено Память ПРограмм — это фактически и есть кэши IL1. Оно уже реализовано и работает. Никаких проблем.
      • 0
        > Там вполне возможен обычный контроллер памяти.
        Обычно когда отделяют память на схеме (здесь ПД), то на каждый блок вешается свой контроллер памяти.
        Организация работы кэша с N контроллерами памяти является непростой задачей.
        > Память ПРограмм — это фактически и есть кэши IL1
        Ну хорошо если так, но я пока в этом сильно сомневаюсь.
  • +11
    Эмс… Вы ошибаетесь в нескольких оценках.

    1. Общий регистровый файл и коммутатор. Они могут быть легко продублированы. Более того, регистры, фактически, не требуются для выполнения программы, они позволяют кое-что упростить, но не более того. На самом деле, самой большой проблемой является доступ к памяти.

    2. Не понятно, откуда у Вас информация о размерах float/double. В текущей версии double не поддерживается, а float — стандартный 32-битовый IEEE.

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

    4. Про пузырьковую сортировку tweet довольно старый :) Теперь уже работают факториалы, ну и куча прочих тестов.

    5. Вы неверно оцениваете сложность коммутатора. Он не обязательно должен быть точка-точка в данной архитектуре. Это просто широковещательная шина. Скорость доступа к регистрам не особо важна, поэтому регистровый файл тоже гораздо проще, чем Вы думаете. У него нет доступа на 4 одновременных записи и на 4 одновременных чтения. И они не нужны.

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

    Ну, и так далее. Вероятно, Вам стоило бы дождаться более полного описания архитектуры, прежде чем критиковать. Нет? А то, как-то выходит, что «Пастернака не читал, но осуждаю!». Единственное, за что можно действительно критиковать разработчиков, так это за то, что с документацией у них хаос. Но… Понять это можно, они загружены другой работой. И партия процессоров — опытно-промышленна. Это не release-версия для публики, когда всё готово. Это ранняя альфа-версия для отладки с партнёрами. Как бы, нужно учитывать.
    • 0
      Опс, чуть ниже ответ получился )
    • 0
      1. Для чтения из памяти нужны регистры для хранения адресов как минимум.
    • 0
      Почитал документацию по ассемблеру более подробно, убрал упоминания о 24-бит числах. Похоже комплексные числа — 2 по 32бит.

      А с упакованными числами с плавающей точкой (2 по 32бит) какие операции могут выполнятся?
  • +1
    1. С управляющими регистрами-то ладно, но РОН (в документации написано что используются в качестве «сверхбыстрой памяти») — так просто не продублировать, ведь данные из них могут понадобится в любом из ядер. С тем, что проблема с вычитыванием из памяти результатов, которые могли быть получены на любых ядрах я согласен, и эту проблему так просто не решить.

    2. multiclet.com/index.php?option=com_content&view=article&id=112&Itemid=74&lang=ru
    Если эта информация не соответствует действительности — надо выяснить, есть ли упаковка комплексных чисел и какая там точность получается тогда (или каким другим способом получается 2.4GFLOP).

    3. Про устойчивость к браку на производстве я промолчу, в рекламной статье писали не про это: sdelanounas.ru/blogs/17220/

    Сложно переоценить важность разработки отказоустойчивого процессора для современных космических, спутниковых и навигационных технологий. Зарубежные производители микрочипов, безусловно, предлагают варианты отказоустойчивых процессоров, но в них отказоустойчивость достигается путем дополнительных решений. В наших разработках отказоустойчивость является врожденной характеристикой, обусловленной особенностями архитектуры процессора. Под отказоустойчивостью мы в большей степени понимаем живучесть процессора – его способность продолжать работу даже при выходе из строя одного из вычислителей. К сожалению, мы не можем дать более подробных технических комментариев, пока технология еще не запатентована
    4. Понятно, но по факту от факториала до компилятора в коробке — долгий путь :-)

    5. Если там нет 4 чтения и записи, то получается утверждение в документации ассемблера о том, что это «Сверхбыстрая память» неверно. В любом случае, каждому ядру каждый такт нужно вычитывать по 2 операнда, которые могли быть записаны где угодно — это очень сложная проблема с ростом кол-ва ядер.

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

    Я не считаю, что нужно было ждать пол года-год пока будет доступна подробная информация. Это не случай «не читал, но критикую» — я прочитал все что доступно, по УЖЕ ПРОДАЮЩЕМУСЯ процессору и пишу что вижу.
    • +1
      Давайте я напишу развёрнутое описание, а Вы тогда его уж и покритикуете. Там есть место для этого, уверяю :).

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

      2. Это написано про модель MCc — это предыдущий проект. В MCp есть float-ы. Их можно упаковать в 2-вектор, с которым можно осуществлять операции по правилам комплексной арифметики.

      3. Реклама — это такая реклама, к сожалению. Но у западных коллег, в принципе, такого же рода рекламные памфлеты издаются. Чего уж там… Маркетинг. Но потенциал к устойчивости к сбоям есть. И авторы действительно пишут некие два патента на эту тему. Надеюсь, из более подробного описани архитектуры станет понятно, что потенциал для этой устойчивости у неё есть.

      4. Ну тык… «Ваш КО». Но программы уже компилируются и корректно (ну, тесты, по крайней мере) исполняются. Естественно, предстоит ещё куча работы.

      5. Как раз верно. Это именно память, а не средство распространения данных по потоку исполнения, как в традиционных архитектурах, и работают они быстрее, чем RAM. Да, они медленней, чем регистровые файлы у VLIW, допустим, но в том и достоинство MCp, что они могут быть медленней.

      6. Скорее нужно, чтобы в коде программы встречались тестирующие участки. Которые в случае успешного теста всех клеток, подтверждали бы корректность предыдущих вычислений, а в случае обнаружения сбоев, вырубали бы сбоящую клетку, и перезапускали бы предыдущий этап вычисления. Архитектура вполне позволяет такой сценарий. Наверняка, разработчики изобрели нечто более продвинутое, потому что это не realtime вариант, но вот хотя бы такой вариант возможен. Уже плюсик для архитектуры, как мне кажется.

      Ну, к сожалению, пока дела с документацией именно так обстоят… Это реальная печалька, и вот за это можно проехаться по руководству.
      • 0
        1. Дублирование регистров с записью результатов во все копии — это один из способов реализации многопортовой памяти, он не снижает сложность схемы и имеет те же проблемы со скорость.

        Т.е. общая проблема на мой взгляд — когда ядра имеют доступ все во все — это в принципе не масштабируется: много ядер — медленный доступ к общим ресурсам.

        2. Ага, понятно. А в 2-векторе куски — 16-и битные float-ы? Соответственно, 2.4GFLOP получаются при их перемножении?
      • 0
        Непонятно зачем городить устойчивость к сбоям в рамках одного процессора. Если нужна отказоустойчивая система — одного этого не достаточно (и бесполезно). Если не нужна, то это только лишнее усложнение логики (и скорее увеличение вероятности отказа).

        Для надежности, гораздо лучше оптимизировать энергопотребление, чтобы при той же мощности влезло 2 (три, пять, сколько надо) отдельных параллельно работающих процессоров, выполняющих одну и ту же программу.
  • 0
    Хм… Специфическое архитектурное решение.

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

    Причем память данных доступна через коммутаторы минуя БП. То есть какой-никакой прямой доступ к памяти таки возможен.

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

    Файл регистров по сути тот же коммутатор и ПД, но без возможности доступа периферии к ней. Видимо коммутатор достаточно тормозной, раз решили его продублировать и назвать файлом регистров…

    Подозреваю тормоза вызваны тем, что архитектура предусматривает возможность объединения коммутаторов нескольких камней в единое коммутационное поле. Видимо в этом и зарыт потенциал устойчивости к сбоям… Других объяснений таким особенностям архитектуры не вижу…
    • 0
      То что это специализированный около-DSP процессор — это да.
      Код к ПП загружается — именно во время инициализации после reset-а из внешней последовательной флешки.

      Возможностей объединять камни тут нет.
      • 0
        Тогда не очень понятно зачем нужен «не очень быстрый» файл регистров…
      • +1
        И кстати Linux в нынешнем виде на этом процессоре просто не заживет. С трудом представляю себе операционную систему под такую архитектуру процессора. Разве что-то на базе микроядра, которое будет эмулировать VM, по верх которой может быть linux и запустится…

        Ведь аппаратного диспетчера задач как на x86 платформе там судя по всему нет. Соответственно многозадачность может быть только кооперативной. А еще виртуальная память и всё такое прочее…
        • +2
          Какой диспетчер задач. Тут память внешнюю цеплять пока некуда, 16кБ и все
  • +1
    > в настольных процессорах принято производительность измерять на 64-х битных вещественных числах

    С чего это вдруг???? Всегда счет был во флопсах одинарной точности, т.е. 32-х битных вещественных.
  • +2
    В этом процессоре интересна в первую очередь реализация паралеллизма через команды-триады, в которых в явном виде указывается потребитель результата операции. Это действительно новизна, даже если схемотехника регистровых файлов и т.п. вам кажется неоптимальной.

    Есть английская фирма Xmos выпускает процессоры Xcore. Эти процы вроде обычные ядра, компилятор стандартный С, но есть хитрые схемы синхронизации, которые фактически аппаратно реализуют функции поддержки многозадачности, которые обычно делает операционная система. За счет этого разработка параллельных программ становится почти тривиальной задачей, процы выпускаются серийно и отзывы самые положительные. Фактически этот проц представляет собой микроконтроллер с производительностью DSP и возможностью программного задания временных интервалов с наносекундной точностью. Такая замена средненькому DSP, микроконтроллеру и FPGA с циклом разработки на чистом С.

    Поэтому есть, есть смысл искать новые архитектуры многоядерных процессоров. У мультиклета другой подход, но сам факт поиска очень радует. Если проц пойдет в серию, ребятам надо продвигать свою концепцию, организовывать конкурсы для разработчиков приложений, давать бесплатные библиотеки и вообще не жадничать. А то с патентованием все увязнут в мелких дрязгах, все-равно ничего не защитят, а время уйдет.
    • 0
      С тем что она новая никто не спорит, новых архитектур полно в студенческих поделках на FPGA.

      Сомнения вызывают практические преимущества новой архитектуры, разрекламированные на сайте:

      Преимущества мультиклеточной архитектуры

      * Увеличение производительности при одновременном снижении энергопотребления
      * Уменьшение площади кристалла
      * Эффективная реализация любого класса задач (коммутационная среда не вносит каких-либо ограничений в межклеточный обмен данными)
      * Выполнение задачи без перекомпиляции на любом количестве клеток
      * Непрерывное выполнение программы при деградации аппаратной среды (отказ клеток)


      По вашему же примеру — этот XS1-G4 выпущенный 4 года назад в 4 раза быстрее Мультиклета (1600MIPS vs 400MIPS), и его архитектура позволяет наращивать производительность без видимых ограничений как по частоте так и кол-ву ядер. Мультиклет в рамках текущей архитектуры не сможет иметь 64 ядра, или работать на 1ГГц. Именно потому я и говорю о том, что практическая ценность новшества мультиклета ограничена.
      • 0
        Увеличение производительности при снижении энергопотребления: фрагмент кода

        x = a + b
        y = b + c
        z = x + y

        Мультиклеточный процессор (точнее компилятор) автоматически распараллелит на два ядра вычисление x и y, строка z будет ждать пока x и y не вычислятся, и не потреблять энергии. Почему это вызывает сомнения?

        Насчет «студенческих поделок на FPGA» — это некорректно. Вас раздражает, что коллектив привлек внимание к себе? Сделайте что-нибудь и займитесь тоже пеаром, будет приятно.
        • 0
          Сомнения возможность распараллелить вычисления не вызывает.
          Мультиклет сейчас выполняет 4 операции параллельно, классические процессоры — 2-3.

          Из-за тяжести своей архитектуры эти 4 параллельные операции он делает очень медленно (100Мгц против 500 и выше), так медленно что даже обычные Российские «последовательные» процессоры оказываются быстрее.

          Мультиклет говорит что их архитектура очень крутая, и они могут наращивать количество клеток и достичь невероятных результатов. Я утверждаю что не смогут. Больше клеток — ниже рабочая частота. Или выкидывать архитектуру и придумывать что-то другое.

      • 0
        >>С тем что она новая никто не спорит

        Есть подобная штука и в Америце — TRIPS

        Explicit Data Graph Execution (EDGE) instruction set architecture
        www.cs.utexas.edu/~trips/overview.html

        In 2003, the TRIPS team began the implementation of a prototype system including a custom ASIC, custom system boards, and custom software tools. First silicon was delivered on September 27, 2006. Each TRIPS chip contains two scalable processor cores, each of which can execute up to 16 instructions per cycle. The prototype system can be scaled up to 32 processor chips for a peak performance approaching 500 gigaflops.
  • 0
    В общем, подводя итог, можно сказать, что у нас теперь есть еще одна своя самобытная архитектура (помимо E2K).

    По производительности она сравнима, а по потенциалу превосходит, китайскую народную архитектуру MIPS. Ежели появится нормальный C/C++ компилятор и Linux, и платы будут в свободной продаже по разумным ценам, будущее у платформы однозначно будет.
    • –1
      Нет, она не сравнима по производительности с китайскими MIPS-ами на задачах общего назначения.
      Мультиклет медленнее даже Российских процессоров (вроде МЦСТ-R500).
      И как я уже писал, Linux-а тут не будет в обозримом будующем — это DSP а не процессор общего назначения. У него пока нет даже внешней памяти.

      Потенциал же тут как раз низкий, архитектура обещает плохо масштабироваться — не выйдет просто взять и воткнуть 256 клеток или сделать частоту 3ГГц.
      • 0
        > Нет, она не сравнима по производительности с китайскими MIPS-ами на задачах общего назначения.

        Но вы же сами написали, что сравнимо с 400MHz Arm и Комдив-64, который MIPS и есть.

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

        По поводу масштабируемости — вы не можете поручиться, что завтра не появится технология/алгоритм/архитектурное решение, которое успешно и дёшево решит так страшащую вас проблему «все имеет доступ ко всему», на которой и строятся ваши размышления о ограниченности масштабируемости.
        • 0
          Настоящий Китайский MIPS — Godson-3b имеет производительность 128 64-х битных GFLOP.

          Если говорить о DSP — то и более быстрые отечественные DSP давно производятся (NVCom-1 и другие), и у них никто не заявлял прорыв в архитектуре.

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

      • +1
        Вам уже писали, что коммутатор там не «точка-точка», а шинный, значит, если и не «хорошо масштабироваться», то хоть как-нибудь оно сможет :-)
        • –1
          Это-то да, но кроме коммутатора есть еще регистры общего назначения и память (где все ядра одновременно пишут и читают). Их «шиной» не сделать.
          • +1
            Их можно сделать шинами — вот именно так, в множественном числе. Шины адреса, шины данных по количеству ядер. Тогда и параллельное запись/чтение возможны. Ну как минимум, это реализуемо если память будет на том же кристалле. Или еще можно поднять частотку коммутатора в четыре раза, чтобы работа с памятью четырех ядер укладывалась в такт процессора. Еще можно новоротить какие-нибудь транзакционные механизмы как в современных SQL, чтоб на момент R/W блокировалась не вся таблица (вся A и D шина) а только участок. Вариантов много.

            У вас какой-то зашореный взгляд на предметную область. Мыслить надо шире.
            • 0
              Сделать возможность из памяти читать и писать одновременно по 16-32 адресам конечно возможно. Но каждый такой «порт доступа» — это огромное количество декодеров адреса и шин передачи данных => большая емкость соединений => снижение скорости работы.

              В общем, не от скудоумия зарубежные коллеги не пошли по этому пути :-)
              • 0
                Меня больше интересует вот что.

                Смысл нескольких ядер появляется тогда, когда «предложение» распаралеливается на них. Посему хотелось бы взглянуть на статистику по другим архитектурам, чтобы была известна оценка, какая средняя длина у предложений с элементарными операциями. Если около десятка, то смысл есть максимум в 8 мультиклеточных ядрах, и это с учетом того что все операции в предложении будут независимые (способны выполняться в параллель). Но походу в предложении более 50% операций зависят от предыдущих операций, так что будут выполняться на следующем такте (в мультиклете не важно на каком ядре). Таким образом, средняя длина предложения должна быть 20-25 операций чтобы оправдать наличие 8 ядер.

                Кто-нибудь обладает хоть какой-нибудь статистикой по неделимым блокам элементарных операций, хоть для какой-нибудь платформы чтоб с натяжкой сравнить?
                • 0
                  Статистика известна — в обычном коде (прикладные приложения и проч) — обычно не больше 3. Именно поэтому x86 процессоры выполняют столько операций за такт. Если бы был смысл делать 4 и выше — сделали бы.

                  Но в DSP приложениях — там есть задачи, где можно обеспечить хоть 1024 ALU.

                  • 0
                    > Статистика известна — в обычном коде (прикладные приложения и проч) — обычно не больше 3.

                    ХМ, сколько не прогал на ассемблерах К580ВМ80, на Z80, на Intel8086, на 386 в защищенном режиме, на AVR, всегда казалось что предложения обычно гораздо длиннее, никак не три. Может быть я ошибаюсь, и современные компилеры генерят именно такой код, но когда дизассемблил некоторые проги, такого не наблюдал. Обычно идут большие куски пересылок и арифметическо-логических операций, которые должны параллелиться за милое дело.
                    • 0
                      Пересылки от недостатка регистров, а вот куски арифметики — там обычно зависимости как раз большие следующих инструкций от предыдущих, и параллельно считать мало что можно…

                      Но тут конечно надо смотреть результаты исследований, на вскидку не нашел.
                  • 0
                    >>обычно не больше 3. Именно поэтому x86 процессоры выполняют столько операций за такт.

                    Давно уже 4 и даже 5 инструкций (в случае cmp+branch)
                    • 0
                      Если костыли всякие считать, то можно много насчитать )
                      Вроде 3xSSE2 = 12 операций.
                      • 0
                        Какие костыли? 4 инструкции декодируются и «отправляются в отставку» (retire) за такт.
                        Планировщик может запускать 6 инструкций каждый такт.
                        микроархитектура Core2

                        >>Вроде 3xSSE2 = 12 операций.
                        SSE инструкция так и остаётся одной инструкцией (двумя в случае 64-битного ALU), вне зависимости от количества обрабатываемых ею данных.
                        Давайте тогда посчитаем 3х128 битных операции — 384 операции за такт :-)
                        Да и нынче актуален уже 256-битный AVX
                  • 0
                    а не потому ли их в среднем три, что код оптимизирован для малого количества регистров? А их в x86 мало.
  • +1
    > Если говорить о DSP — то и более быстрые отечественные DSP давно производятся (NVCom-1 и другие), и у них никто не заявлял прорыв в архитектуре.

    Эти DSP не могут выступать в качестве процессоров общего назначения. А мультиклет может, и это уникальное свойство именно данной архитектуры.
  • 0
    Вот также интересные комментарии по теме от Сергея Вакуленко:
    ramlamyammambam.livejournal.com/193032.html

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