Comments 65
Исходя из Вашей статьи можно сделать вывод, что это очередной PR проект Сколоково\Нано\Чубайса?
Я так понимаю дальше стен лабораторий этот процессор не пойдет и будет лишь демострироваться на различных выставках как нечно волшебное
Я так понимаю дальше стен лабораторий этот процессор не пойдет и будет лишь демострироваться на различных выставках как нечно волшебное
Все не так плохо, этот проект не бумажный — получен реальный работающий продукт, который где-то может быть использован, особенно если нужен именно отечественный процессор.
Но заявления о «прорывной архитектуре», «мы сейчас всех порвем с их устаревшей Фон-неймановской архитектурой» — это некоторое преувеличение на мой взгляд.
Но заявления о «прорывной архитектуре», «мы сейчас всех порвем с их устаревшей Фон-неймановской архитектурой» — это некоторое преувеличение на мой взгляд.
UFO just landed and posted this here
Человек, который не понимает что такое FPGA, наверно и не дойдёт до этой части текста.
Автор постарался критически взглянуть, исходя из имеющейся информации, а его уже в американские шпионы записывают :)
Автор постарался критически взглянуть, исходя из имеющейся информации, а его уже в американские шпионы записывают :)
Понимаете в чем дело, я не против отечественной электроники. Более того, в России разработаны и производятся куча хороших и добротных процессоров, которые сделали безо всякого выпендрежа и загибаний пальцев: есть Элвис, есть Модуль, есть НИИСИ РАН, есть Миландр, есть МЦСТ (с натяжкой).
Но когда кричат «У нас крутая архитектура» и «Мы счас всех за пояс заткнем» и при этом не дают реальной информации о том что именно у них такого крутого, как именно они посчитали их производительность указанную в рекламных статьях и документации, как собираются обеспечивать разрекламированную отказоустойчивость, и как и почему они всех смогут заткнуть за пояс — у специалистов это вызывает вопросы.
По результатам прояснения вопросов и написана эта статья.
Но когда кричат «У нас крутая архитектура» и «Мы счас всех за пояс заткнем» и при этом не дают реальной информации о том что именно у них такого крутого, как именно они посчитали их производительность указанную в рекламных статьях и документации, как собираются обеспечивать разрекламированную отказоустойчивость, и как и почему они всех смогут заткнуть за пояс — у специалистов это вызывает вопросы.
По результатам прояснения вопросов и написана эта статья.
Да да, это все Американские спецслужбы.
на самом деле всё что тут перечислено дня массового внедрения значения не имеет. Тут гораздо важнее с какой он работает IDE, поддержка библиотек, стабильность работы (глюки), портирование ОС и тд. Понимаете после такого «Софт для разработки — на данный момент только ассемблер.» тут всё можно ставить крест, я уж не говорю о других недостатках. Сделать то сделали, а смысл.
Ну, защита от сбоев процессора всё же вещь хорошая. Если прозрачный перезапуск фрагмента кода (инструкции?) возможен, это откроет серьёзные двери в серьёзные решения.
В этом и проблема, как определить, что выполнение инструкции прошло со сбоем? Как откатить состояние?
В радиационно-стойких процессорах исключают саму возможность сбоя технологическими способами (8T SRAM, ECC во всех регистрах и памяти, кремний на изоляторе) и готовятся к ней с программной точки зрения.
В радиационно-стойких процессорах исключают саму возможность сбоя технологическими способами (8T SRAM, ECC во всех регистрах и памяти, кремний на изоляторе) и готовятся к ней с программной точки зрения.
Для схемы требующей надёжности можно исполнять один код на двух «клетках», и в случае различия, запустить тесты чтобы выявить сбойный.
Звучит просто, но в реальности очень много вариантов требующих проверки: Увидеть отличия в условном переходе? Во входе в прерывание? Запись правильного значения в неправильный регистр…
Но если бы это было реализовано — было бы полезно.
Но если бы это было реализовано — было бы полезно.
Отличия очень просто увидеть: берём и сравниваем. Проблема в том, как определить, какое из вариантов верный. Но, насколько мне известно, у нас традиционным решением проблемы является дублирование процессоров с предположением о том, что поломаться может меньше модулей, чем останется корректно работающими. Ну, и сбоящий определяется простым голосованием. MCp-шная фишка в том, что проверять корректную работу можно не всего процессора целиком, а каждой клетки отдельно, и при сбое в какой-то, отключать только её, а не весь процессор.
Да. Это требует и программной поддержки и прочего. Да, рекламные лозунги такие рекламные, но особенности у процессора действительно есть, которые облегчают задачу.
Да. Это требует и программной поддержки и прочего. Да, рекламные лозунги такие рекламные, но особенности у процессора действительно есть, которые облегчают задачу.
Ну для того, чтоб сравнить результаты и принять решение, на каком из модуле возникла ошибка, нужен некий брокер, который сам будет защещён от ошибок.
А здесь его не видно, и похоже предполлагается что это будет делатья програмно, на тех же процесорных модулях, на которых будут выполнятся алгоритмы, результаты которых будут сравниваться.
А кто гарантирует, что сам алгорим сравнения будет не выполняться на сбойном модуле.
А здесь его не видно, и похоже предполлагается что это будет делатья програмно, на тех же процесорных модулях, на которых будут выполнятся алгоритмы, результаты которых будут сравниваться.
А кто гарантирует, что сам алгорим сравнения будет не выполняться на сбойном модуле.
Насколько я понимаю в этом (а могу ошибаться), брокер не нужен. Схема сравнения — это куча простых компараторов, которых можно сделать множество, и за счёт количества обеспечить необходимую степень достоверности сравнения. И признаком того некий модуль вышел из строя служит просто набор 0 (false) на выходах этих схем. Вот. Тут не нужен сложный алгоритм сравнения и анализа: просто нужно, чтобы на определённых проводочках всегда шли одинаковые сигналы, как только где-то появляются различия, это признак ошибки.
Только не дублирование, а троирование. Если два выдали совпадающее значение, третий другое — он объявляется сбойным.
Похоже, на этой архитектуре троирование можно будет сделать довольно красиво.
Похоже, на этой архитектуре троирование можно будет сделать довольно красиво.
вообще-то на трех, если две согласны, то понятно что выбрать.
Я не эксперт по этому вопросу, но примерная схема понятна: выполняем на трёх ядрах, решаем (компаратором) у кого большинство. В принципе, можно даже и не трёх, а, например, 6, с требованием «не менее 5 согласных». Если несогласных больше, инструкция выполняется повторно.
Т.е. понятно что это вещь хорошая. Но судя по отсутствию каких-либо деталей об этом, и огромной сложности проблемы — никакой защиты от сбоев тут вероятно нет.
Чем то мне он пропеллер напомнил. Только у того 8 ядер.
Единый регистровый файл, но возможная разбивка по памяти.
Это эпично.
Вдвойне эпична разбивка исполняемой памяти.
Кэш насколько я вижу даже теоретически трудно пристроить, не говоря уже о железе.
Чем-то мне cell напомнили:
Одна шина, у ядер local storage, разве что вместо общего файла, общие регистры.
Имхо, на бумаге это неплохая дипломная работа, особенно на уровне сегодняшнего образования — очень неплохая.
А кому она нужна в железе — хз, разве что PoC, испытание сил перед нормальным проектом, но у нас уже есть парочка классных процессорных лаб.
Это эпично.
Вдвойне эпична разбивка исполняемой памяти.
Кэш насколько я вижу даже теоретически трудно пристроить, не говоря уже о железе.
Чем-то мне cell напомнили:
Одна шина, у ядер local storage, разве что вместо общего файла, общие регистры.
Имхо, на бумаге это неплохая дипломная работа, особенно на уровне сегодняшнего образования — очень неплохая.
А кому она нужна в железе — хз, разве что PoC, испытание сил перед нормальным проектом, но у нас уже есть парочка классных процессорных лаб.
А какие проблемы с кэшем вы видете? Эмс. Там вполне возможен обычный контроллер памяти. То, что на картинке обозначено Память ПРограмм — это фактически и есть кэши IL1. Оно уже реализовано и работает. Никаких проблем.
> Там вполне возможен обычный контроллер памяти.
Обычно когда отделяют память на схеме (здесь ПД), то на каждый блок вешается свой контроллер памяти.
Организация работы кэша с N контроллерами памяти является непростой задачей.
> Память ПРограмм — это фактически и есть кэши IL1
Ну хорошо если так, но я пока в этом сильно сомневаюсь.
Обычно когда отделяют память на схеме (здесь ПД), то на каждый блок вешается свой контроллер памяти.
Организация работы кэша с N контроллерами памяти является непростой задачей.
> Память ПРограмм — это фактически и есть кэши IL1
Ну хорошо если так, но я пока в этом сильно сомневаюсь.
Эмс… Вы ошибаетесь в нескольких оценках.
1. Общий регистровый файл и коммутатор. Они могут быть легко продублированы. Более того, регистры, фактически, не требуются для выполнения программы, они позволяют кое-что упростить, но не более того. На самом деле, самой большой проблемой является доступ к памяти.
2. Не понятно, откуда у Вас информация о размерах float/double. В текущей версии double не поддерживается, а float — стандартный 32-битовый IEEE.
3. Устойчивость к сбою ядра сейчас реализована в виде устойчивости к браку при производстве. Но архитектура позволяет процессору выдерживать сбои, именно отказы вычислительных блоков, в runtime.
4. Про пузырьковую сортировку tweet довольно старый :) Теперь уже работают факториалы, ну и куча прочих тестов.
5. Вы неверно оцениваете сложность коммутатора. Он не обязательно должен быть точка-точка в данной архитектуре. Это просто широковещательная шина. Скорость доступа к регистрам не особо важна, поэтому регистровый файл тоже гораздо проще, чем Вы думаете. У него нет доступа на 4 одновременных записи и на 4 одновременных чтения. И они не нужны.
6. Память программ действительно для каждого ядра своя, но ничто не мешает её перезаписывать при сбое одного из ядер.
Ну, и так далее. Вероятно, Вам стоило бы дождаться более полного описания архитектуры, прежде чем критиковать. Нет? А то, как-то выходит, что «Пастернака не читал, но осуждаю!». Единственное, за что можно действительно критиковать разработчиков, так это за то, что с документацией у них хаос. Но… Понять это можно, они загружены другой работой. И партия процессоров — опытно-промышленна. Это не release-версия для публики, когда всё готово. Это ранняя альфа-версия для отладки с партнёрами. Как бы, нужно учитывать.
1. Общий регистровый файл и коммутатор. Они могут быть легко продублированы. Более того, регистры, фактически, не требуются для выполнения программы, они позволяют кое-что упростить, но не более того. На самом деле, самой большой проблемой является доступ к памяти.
2. Не понятно, откуда у Вас информация о размерах float/double. В текущей версии double не поддерживается, а float — стандартный 32-битовый IEEE.
3. Устойчивость к сбою ядра сейчас реализована в виде устойчивости к браку при производстве. Но архитектура позволяет процессору выдерживать сбои, именно отказы вычислительных блоков, в runtime.
4. Про пузырьковую сортировку tweet довольно старый :) Теперь уже работают факториалы, ну и куча прочих тестов.
5. Вы неверно оцениваете сложность коммутатора. Он не обязательно должен быть точка-точка в данной архитектуре. Это просто широковещательная шина. Скорость доступа к регистрам не особо важна, поэтому регистровый файл тоже гораздо проще, чем Вы думаете. У него нет доступа на 4 одновременных записи и на 4 одновременных чтения. И они не нужны.
6. Память программ действительно для каждого ядра своя, но ничто не мешает её перезаписывать при сбое одного из ядер.
Ну, и так далее. Вероятно, Вам стоило бы дождаться более полного описания архитектуры, прежде чем критиковать. Нет? А то, как-то выходит, что «Пастернака не читал, но осуждаю!». Единственное, за что можно действительно критиковать разработчиков, так это за то, что с документацией у них хаос. Но… Понять это можно, они загружены другой работой. И партия процессоров — опытно-промышленна. Это не release-версия для публики, когда всё готово. Это ранняя альфа-версия для отладки с партнёрами. Как бы, нужно учитывать.
Опс, чуть ниже ответ получился )
1. Для чтения из памяти нужны регистры для хранения адресов как минимум.
Почитал документацию по ассемблеру более подробно, убрал упоминания о 24-бит числах. Похоже комплексные числа — 2 по 32бит.
А с упакованными числами с плавающей точкой (2 по 32бит) какие операции могут выполнятся?
А с упакованными числами с плавающей точкой (2 по 32бит) какие операции могут выполнятся?
1. С управляющими регистрами-то ладно, но РОН (в документации написано что используются в качестве «сверхбыстрой памяти») — так просто не продублировать, ведь данные из них могут понадобится в любом из ядер. С тем, что проблема с вычитыванием из памяти результатов, которые могли быть получены на любых ядрах я согласен, и эту проблему так просто не решить.
2. multiclet.com/index.php?option=com_content&view=article&id=112&Itemid=74&lang=ru
Если эта информация не соответствует действительности — надо выяснить, есть ли упаковка комплексных чисел и какая там точность получается тогда (или каким другим способом получается 2.4GFLOP).
3. Про устойчивость к браку на производстве я промолчу, в рекламной статье писали не про это: sdelanounas.ru/blogs/17220/
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. Ну вот особенность архитектуры в том, что регистры не должны быть такими же быстрыми, как у современных суперскаляров. Но они действительно быстрее памяти, но в архитектуре, это именно более быстрая память, а не основной метод передачи аргументов. Из-за того, что требования к скорости помягче, регистровых файлов можно сделать несколько, и дублировать в них результаты.
2. Это написано про модель MCc — это предыдущий проект. В MCp есть float-ы. Их можно упаковать в 2-вектор, с которым можно осуществлять операции по правилам комплексной арифметики.
3. Реклама — это такая реклама, к сожалению. Но у западных коллег, в принципе, такого же рода рекламные памфлеты издаются. Чего уж там… Маркетинг. Но потенциал к устойчивости к сбоям есть. И авторы действительно пишут некие два патента на эту тему. Надеюсь, из более подробного описани архитектуры станет понятно, что потенциал для этой устойчивости у неё есть.
4. Ну тык… «Ваш КО». Но программы уже компилируются и корректно (ну, тесты, по крайней мере) исполняются. Естественно, предстоит ещё куча работы.
5. Как раз верно. Это именно память, а не средство распространения данных по потоку исполнения, как в традиционных архитектурах, и работают они быстрее, чем RAM. Да, они медленней, чем регистровые файлы у VLIW, допустим, но в том и достоинство MCp, что они могут быть медленней.
6. Скорее нужно, чтобы в коде программы встречались тестирующие участки. Которые в случае успешного теста всех клеток, подтверждали бы корректность предыдущих вычислений, а в случае обнаружения сбоев, вырубали бы сбоящую клетку, и перезапускали бы предыдущий этап вычисления. Архитектура вполне позволяет такой сценарий. Наверняка, разработчики изобрели нечто более продвинутое, потому что это не realtime вариант, но вот хотя бы такой вариант возможен. Уже плюсик для архитектуры, как мне кажется.
Ну, к сожалению, пока дела с документацией именно так обстоят… Это реальная печалька, и вот за это можно проехаться по руководству.
1. Ну вот особенность архитектуры в том, что регистры не должны быть такими же быстрыми, как у современных суперскаляров. Но они действительно быстрее памяти, но в архитектуре, это именно более быстрая память, а не основной метод передачи аргументов. Из-за того, что требования к скорости помягче, регистровых файлов можно сделать несколько, и дублировать в них результаты.
2. Это написано про модель MCc — это предыдущий проект. В MCp есть float-ы. Их можно упаковать в 2-вектор, с которым можно осуществлять операции по правилам комплексной арифметики.
3. Реклама — это такая реклама, к сожалению. Но у западных коллег, в принципе, такого же рода рекламные памфлеты издаются. Чего уж там… Маркетинг. Но потенциал к устойчивости к сбоям есть. И авторы действительно пишут некие два патента на эту тему. Надеюсь, из более подробного описани архитектуры станет понятно, что потенциал для этой устойчивости у неё есть.
4. Ну тык… «Ваш КО». Но программы уже компилируются и корректно (ну, тесты, по крайней мере) исполняются. Естественно, предстоит ещё куча работы.
5. Как раз верно. Это именно память, а не средство распространения данных по потоку исполнения, как в традиционных архитектурах, и работают они быстрее, чем RAM. Да, они медленней, чем регистровые файлы у VLIW, допустим, но в том и достоинство MCp, что они могут быть медленней.
6. Скорее нужно, чтобы в коде программы встречались тестирующие участки. Которые в случае успешного теста всех клеток, подтверждали бы корректность предыдущих вычислений, а в случае обнаружения сбоев, вырубали бы сбоящую клетку, и перезапускали бы предыдущий этап вычисления. Архитектура вполне позволяет такой сценарий. Наверняка, разработчики изобрели нечто более продвинутое, потому что это не realtime вариант, но вот хотя бы такой вариант возможен. Уже плюсик для архитектуры, как мне кажется.
Ну, к сожалению, пока дела с документацией именно так обстоят… Это реальная печалька, и вот за это можно проехаться по руководству.
1. Дублирование регистров с записью результатов во все копии — это один из способов реализации многопортовой памяти, он не снижает сложность схемы и имеет те же проблемы со скорость.
Т.е. общая проблема на мой взгляд — когда ядра имеют доступ все во все — это в принципе не масштабируется: много ядер — медленный доступ к общим ресурсам.
2. Ага, понятно. А в 2-векторе куски — 16-и битные float-ы? Соответственно, 2.4GFLOP получаются при их перемножении?
Т.е. общая проблема на мой взгляд — когда ядра имеют доступ все во все — это в принципе не масштабируется: много ядер — медленный доступ к общим ресурсам.
2. Ага, понятно. А в 2-векторе куски — 16-и битные float-ы? Соответственно, 2.4GFLOP получаются при их перемножении?
Непонятно зачем городить устойчивость к сбоям в рамках одного процессора. Если нужна отказоустойчивая система — одного этого не достаточно (и бесполезно). Если не нужна, то это только лишнее усложнение логики (и скорее увеличение вероятности отказа).
Для надежности, гораздо лучше оптимизировать энергопотребление, чтобы при той же мощности влезло 2 (три, пять, сколько надо) отдельных параллельно работающих процессоров, выполняющих одну и ту же программу.
Для надежности, гораздо лучше оптимизировать энергопотребление, чтобы при той же мощности влезло 2 (три, пять, сколько надо) отдельных параллельно работающих процессоров, выполняющих одну и ту же программу.
Хм… Специфическое архитектурное решение.
Исходя из структурной схемы получается, что блок процессора должен сначала загрузить код приложения в память программ через коммутатор, ПБ и только потом приступить к выполнению. А что будет если код программы не поместился в ПП?
Причем память данных доступна через коммутаторы минуя БП. То есть какой-никакой прямой доступ к памяти таки возможен.
Похоже это скорее специализированный микроконтроллер с развитым функционалом DSP, чем процессор общего назначения. Очевидно код будет загружаться в ПП на этапе инициализации, а данные на обработку должны в непрерывном режиме поступать со стороны внешних устройств.
Файл регистров по сути тот же коммутатор и ПД, но без возможности доступа периферии к ней. Видимо коммутатор достаточно тормозной, раз решили его продублировать и назвать файлом регистров…
Подозреваю тормоза вызваны тем, что архитектура предусматривает возможность объединения коммутаторов нескольких камней в единое коммутационное поле. Видимо в этом и зарыт потенциал устойчивости к сбоям… Других объяснений таким особенностям архитектуры не вижу…
Исходя из структурной схемы получается, что блок процессора должен сначала загрузить код приложения в память программ через коммутатор, ПБ и только потом приступить к выполнению. А что будет если код программы не поместился в ПП?
Причем память данных доступна через коммутаторы минуя БП. То есть какой-никакой прямой доступ к памяти таки возможен.
Похоже это скорее специализированный микроконтроллер с развитым функционалом DSP, чем процессор общего назначения. Очевидно код будет загружаться в ПП на этапе инициализации, а данные на обработку должны в непрерывном режиме поступать со стороны внешних устройств.
Файл регистров по сути тот же коммутатор и ПД, но без возможности доступа периферии к ней. Видимо коммутатор достаточно тормозной, раз решили его продублировать и назвать файлом регистров…
Подозреваю тормоза вызваны тем, что архитектура предусматривает возможность объединения коммутаторов нескольких камней в единое коммутационное поле. Видимо в этом и зарыт потенциал устойчивости к сбоям… Других объяснений таким особенностям архитектуры не вижу…
То что это специализированный около-DSP процессор — это да.
Код к ПП загружается — именно во время инициализации после reset-а из внешней последовательной флешки.
Возможностей объединять камни тут нет.
Код к ПП загружается — именно во время инициализации после reset-а из внешней последовательной флешки.
Возможностей объединять камни тут нет.
Тогда не очень понятно зачем нужен «не очень быстрый» файл регистров…
И кстати Linux в нынешнем виде на этом процессоре просто не заживет. С трудом представляю себе операционную систему под такую архитектуру процессора. Разве что-то на базе микроядра, которое будет эмулировать VM, по верх которой может быть linux и запустится…
Ведь аппаратного диспетчера задач как на x86 платформе там судя по всему нет. Соответственно многозадачность может быть только кооперативной. А еще виртуальная память и всё такое прочее…
Ведь аппаратного диспетчера задач как на x86 платформе там судя по всему нет. Соответственно многозадачность может быть только кооперативной. А еще виртуальная память и всё такое прочее…
> в настольных процессорах принято производительность измерять на 64-х битных вещественных числах
С чего это вдруг???? Всегда счет был во флопсах одинарной точности, т.е. 32-х битных вещественных.
С чего это вдруг???? Всегда счет был во флопсах одинарной точности, т.е. 32-х битных вещественных.
Я говорю именно о сравнении с настольниками, вот первые 3 ссылки из гугля — там цифры с 64-х бит:
www.koshcheev.ru/2012/02/11/mcst-r1000-elbrus/
sdelanounas.ru/blogs/17220/ (тут в комментах Мультиклет сравнивают с Intel)
ru.wikipedia.org/wiki/%D0%AD%D0%BB%D1%8C%D0%B1%D1%80%D1%83%D1%81_%28%D0%BA%D0%BE%D0%BC%D0%BF%D1%8C%D1%8E%D1%82%D0%B5%D1%80%29
Понятно, что этот проц — не конкурент настольным процессорам, и пытаться сравнивать его с ними нельзя.
DSP же GFLOPы меряют как хотят (но обычно указывают как они это делают, и разделают производительность на MAC и FLOP).
www.koshcheev.ru/2012/02/11/mcst-r1000-elbrus/
sdelanounas.ru/blogs/17220/ (тут в комментах Мультиклет сравнивают с Intel)
ru.wikipedia.org/wiki/%D0%AD%D0%BB%D1%8C%D0%B1%D1%80%D1%83%D1%81_%28%D0%BA%D0%BE%D0%BC%D0%BF%D1%8C%D1%8E%D1%82%D0%B5%D1%80%29
Понятно, что этот проц — не конкурент настольным процессорам, и пытаться сравнивать его с ними нельзя.
DSP же GFLOPы меряют как хотят (но обычно указывают как они это делают, и разделают производительность на MAC и FLOP).
В этом процессоре интересна в первую очередь реализация паралеллизма через команды-триады, в которых в явном виде указывается потребитель результата операции. Это действительно новизна, даже если схемотехника регистровых файлов и т.п. вам кажется неоптимальной.
Есть английская фирма Xmos выпускает процессоры Xcore. Эти процы вроде обычные ядра, компилятор стандартный С, но есть хитрые схемы синхронизации, которые фактически аппаратно реализуют функции поддержки многозадачности, которые обычно делает операционная система. За счет этого разработка параллельных программ становится почти тривиальной задачей, процы выпускаются серийно и отзывы самые положительные. Фактически этот проц представляет собой микроконтроллер с производительностью DSP и возможностью программного задания временных интервалов с наносекундной точностью. Такая замена средненькому DSP, микроконтроллеру и FPGA с циклом разработки на чистом С.
Поэтому есть, есть смысл искать новые архитектуры многоядерных процессоров. У мультиклета другой подход, но сам факт поиска очень радует. Если проц пойдет в серию, ребятам надо продвигать свою концепцию, организовывать конкурсы для разработчиков приложений, давать бесплатные библиотеки и вообще не жадничать. А то с патентованием все увязнут в мелких дрязгах, все-равно ничего не защитят, а время уйдет.
Есть английская фирма Xmos выпускает процессоры Xcore. Эти процы вроде обычные ядра, компилятор стандартный С, но есть хитрые схемы синхронизации, которые фактически аппаратно реализуют функции поддержки многозадачности, которые обычно делает операционная система. За счет этого разработка параллельных программ становится почти тривиальной задачей, процы выпускаются серийно и отзывы самые положительные. Фактически этот проц представляет собой микроконтроллер с производительностью DSP и возможностью программного задания временных интервалов с наносекундной точностью. Такая замена средненькому DSP, микроконтроллеру и FPGA с циклом разработки на чистом С.
Поэтому есть, есть смысл искать новые архитектуры многоядерных процессоров. У мультиклета другой подход, но сам факт поиска очень радует. Если проц пойдет в серию, ребятам надо продвигать свою концепцию, организовывать конкурсы для разработчиков приложений, давать бесплатные библиотеки и вообще не жадничать. А то с патентованием все увязнут в мелких дрязгах, все-равно ничего не защитят, а время уйдет.
С тем что она новая никто не спорит, новых архитектур полно в студенческих поделках на FPGA.
Сомнения вызывают практические преимущества новой архитектуры, разрекламированные на сайте:
По вашему же примеру — этот XS1-G4 выпущенный 4 года назад в 4 раза быстрее Мультиклета (1600MIPS vs 400MIPS), и его архитектура позволяет наращивать производительность без видимых ограничений как по частоте так и кол-ву ядер. Мультиклет в рамках текущей архитектуры не сможет иметь 64 ядра, или работать на 1ГГц. Именно потому я и говорю о том, что практическая ценность новшества мультиклета ограничена.
Сомнения вызывают практические преимущества новой архитектуры, разрекламированные на сайте:
Преимущества мультиклеточной архитектуры
* Увеличение производительности при одновременном снижении энергопотребления
* Уменьшение площади кристалла
* Эффективная реализация любого класса задач (коммутационная среда не вносит каких-либо ограничений в межклеточный обмен данными)
* Выполнение задачи без перекомпиляции на любом количестве клеток
* Непрерывное выполнение программы при деградации аппаратной среды (отказ клеток)
По вашему же примеру — этот XS1-G4 выпущенный 4 года назад в 4 раза быстрее Мультиклета (1600MIPS vs 400MIPS), и его архитектура позволяет наращивать производительность без видимых ограничений как по частоте так и кол-ву ядер. Мультиклет в рамках текущей архитектуры не сможет иметь 64 ядра, или работать на 1ГГц. Именно потому я и говорю о том, что практическая ценность новшества мультиклета ограничена.
Увеличение производительности при снижении энергопотребления: фрагмент кода
x = a + b
y = b + c
z = x + y
Мультиклеточный процессор (точнее компилятор) автоматически распараллелит на два ядра вычисление x и y, строка z будет ждать пока x и y не вычислятся, и не потреблять энергии. Почему это вызывает сомнения?
Насчет «студенческих поделок на FPGA» — это некорректно. Вас раздражает, что коллектив привлек внимание к себе? Сделайте что-нибудь и займитесь тоже пеаром, будет приятно.
x = a + b
y = b + c
z = x + y
Мультиклеточный процессор (точнее компилятор) автоматически распараллелит на два ядра вычисление x и y, строка z будет ждать пока x и y не вычислятся, и не потреблять энергии. Почему это вызывает сомнения?
Насчет «студенческих поделок на FPGA» — это некорректно. Вас раздражает, что коллектив привлек внимание к себе? Сделайте что-нибудь и займитесь тоже пеаром, будет приятно.
Сомнения возможность распараллелить вычисления не вызывает.
Мультиклет сейчас выполняет 4 операции параллельно, классические процессоры — 2-3.
Из-за тяжести своей архитектуры эти 4 параллельные операции он делает очень медленно (100Мгц против 500 и выше), так медленно что даже обычные Российские «последовательные» процессоры оказываются быстрее.
Мультиклет говорит что их архитектура очень крутая, и они могут наращивать количество клеток и достичь невероятных результатов. Я утверждаю что не смогут. Больше клеток — ниже рабочая частота. Или выкидывать архитектуру и придумывать что-то другое.
Мультиклет сейчас выполняет 4 операции параллельно, классические процессоры — 2-3.
Из-за тяжести своей архитектуры эти 4 параллельные операции он делает очень медленно (100Мгц против 500 и выше), так медленно что даже обычные Российские «последовательные» процессоры оказываются быстрее.
Мультиклет говорит что их архитектура очень крутая, и они могут наращивать количество клеток и достичь невероятных результатов. Я утверждаю что не смогут. Больше клеток — ниже рабочая частота. Или выкидывать архитектуру и придумывать что-то другое.
>>С тем что она новая никто не спорит
Есть подобная штука и в Америце — 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.
Есть подобная штука и в Америце — 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.
В общем, подводя итог, можно сказать, что у нас теперь есть еще одна своя самобытная архитектура (помимо E2K).
По производительности она сравнима, а по потенциалу превосходит, китайскую народную архитектуру MIPS. Ежели появится нормальный C/C++ компилятор и Linux, и платы будут в свободной продаже по разумным ценам, будущее у платформы однозначно будет.
По производительности она сравнима, а по потенциалу превосходит, китайскую народную архитектуру MIPS. Ежели появится нормальный C/C++ компилятор и Linux, и платы будут в свободной продаже по разумным ценам, будущее у платформы однозначно будет.
Нет, она не сравнима по производительности с китайскими MIPS-ами на задачах общего назначения.
Мультиклет медленнее даже Российских процессоров (вроде МЦСТ-R500).
И как я уже писал, Linux-а тут не будет в обозримом будующем — это DSP а не процессор общего назначения. У него пока нет даже внешней памяти.
Потенциал же тут как раз низкий, архитектура обещает плохо масштабироваться — не выйдет просто взять и воткнуть 256 клеток или сделать частоту 3ГГц.
Мультиклет медленнее даже Российских процессоров (вроде МЦСТ-R500).
И как я уже писал, Linux-а тут не будет в обозримом будующем — это DSP а не процессор общего назначения. У него пока нет даже внешней памяти.
Потенциал же тут как раз низкий, архитектура обещает плохо масштабироваться — не выйдет просто взять и воткнуть 256 клеток или сделать частоту 3ГГц.
> Нет, она не сравнима по производительности с китайскими MIPS-ами на задачах общего назначения.
Но вы же сами написали, что сравнимо с 400MHz Arm и Комдив-64, который MIPS и есть.
Но я прочитал документацию на официальном сайте, там четко указано, что «Предназначено для решения задач управления и цифровой обработки сигналов» — то есть DSP и есть. Однако, чистые DSP не могут выполнять задачи общего назначения, они могут по большей части только управляться с потоком данных, преобразуя его, не более того. А мультиклет, судя по составу команд и регистров может работать как микропроцессор общего назначения, да еще и распараллеливая вычисления.
По поводу масштабируемости — вы не можете поручиться, что завтра не появится технология/алгоритм/архитектурное решение, которое успешно и дёшево решит так страшащую вас проблему «все имеет доступ ко всему», на которой и строятся ваши размышления о ограниченности масштабируемости.
Но вы же сами написали, что сравнимо с 400MHz Arm и Комдив-64, который MIPS и есть.
Но я прочитал документацию на официальном сайте, там четко указано, что «Предназначено для решения задач управления и цифровой обработки сигналов» — то есть DSP и есть. Однако, чистые DSP не могут выполнять задачи общего назначения, они могут по большей части только управляться с потоком данных, преобразуя его, не более того. А мультиклет, судя по составу команд и регистров может работать как микропроцессор общего назначения, да еще и распараллеливая вычисления.
По поводу масштабируемости — вы не можете поручиться, что завтра не появится технология/алгоритм/архитектурное решение, которое успешно и дёшево решит так страшащую вас проблему «все имеет доступ ко всему», на которой и строятся ваши размышления о ограниченности масштабируемости.
Настоящий Китайский MIPS — Godson-3b имеет производительность 128 64-х битных GFLOP.
Если говорить о DSP — то и более быстрые отечественные DSP давно производятся (NVCom-1 и другие), и у них никто не заявлял прорыв в архитектуре.
Проблемы с маштабируемостью «все имеет доступ ко всему» фундаментальны, тут без изменения архитектуры ничего не сделать.
Если говорить о DSP — то и более быстрые отечественные DSP давно производятся (NVCom-1 и другие), и у них никто не заявлял прорыв в архитектуре.
Проблемы с маштабируемостью «все имеет доступ ко всему» фундаментальны, тут без изменения архитектуры ничего не сделать.
Вам уже писали, что коммутатор там не «точка-точка», а шинный, значит, если и не «хорошо масштабироваться», то хоть как-нибудь оно сможет :-)
Это-то да, но кроме коммутатора есть еще регистры общего назначения и память (где все ядра одновременно пишут и читают). Их «шиной» не сделать.
Их можно сделать шинами — вот именно так, в множественном числе. Шины адреса, шины данных по количеству ядер. Тогда и параллельное запись/чтение возможны. Ну как минимум, это реализуемо если память будет на том же кристалле. Или еще можно поднять частотку коммутатора в четыре раза, чтобы работа с памятью четырех ядер укладывалась в такт процессора. Еще можно новоротить какие-нибудь транзакционные механизмы как в современных SQL, чтоб на момент R/W блокировалась не вся таблица (вся A и D шина) а только участок. Вариантов много.
У вас какой-то зашореный взгляд на предметную область. Мыслить надо шире.
У вас какой-то зашореный взгляд на предметную область. Мыслить надо шире.
Сделать возможность из памяти читать и писать одновременно по 16-32 адресам конечно возможно. Но каждый такой «порт доступа» — это огромное количество декодеров адреса и шин передачи данных => большая емкость соединений => снижение скорости работы.
В общем, не от скудоумия зарубежные коллеги не пошли по этому пути :-)
В общем, не от скудоумия зарубежные коллеги не пошли по этому пути :-)
Меня больше интересует вот что.
Смысл нескольких ядер появляется тогда, когда «предложение» распаралеливается на них. Посему хотелось бы взглянуть на статистику по другим архитектурам, чтобы была известна оценка, какая средняя длина у предложений с элементарными операциями. Если около десятка, то смысл есть максимум в 8 мультиклеточных ядрах, и это с учетом того что все операции в предложении будут независимые (способны выполняться в параллель). Но походу в предложении более 50% операций зависят от предыдущих операций, так что будут выполняться на следующем такте (в мультиклете не важно на каком ядре). Таким образом, средняя длина предложения должна быть 20-25 операций чтобы оправдать наличие 8 ядер.
Кто-нибудь обладает хоть какой-нибудь статистикой по неделимым блокам элементарных операций, хоть для какой-нибудь платформы чтоб с натяжкой сравнить?
Смысл нескольких ядер появляется тогда, когда «предложение» распаралеливается на них. Посему хотелось бы взглянуть на статистику по другим архитектурам, чтобы была известна оценка, какая средняя длина у предложений с элементарными операциями. Если около десятка, то смысл есть максимум в 8 мультиклеточных ядрах, и это с учетом того что все операции в предложении будут независимые (способны выполняться в параллель). Но походу в предложении более 50% операций зависят от предыдущих операций, так что будут выполняться на следующем такте (в мультиклете не важно на каком ядре). Таким образом, средняя длина предложения должна быть 20-25 операций чтобы оправдать наличие 8 ядер.
Кто-нибудь обладает хоть какой-нибудь статистикой по неделимым блокам элементарных операций, хоть для какой-нибудь платформы чтоб с натяжкой сравнить?
Статистика известна — в обычном коде (прикладные приложения и проч) — обычно не больше 3. Именно поэтому x86 процессоры выполняют столько операций за такт. Если бы был смысл делать 4 и выше — сделали бы.
Но в DSP приложениях — там есть задачи, где можно обеспечить хоть 1024 ALU.
Но в DSP приложениях — там есть задачи, где можно обеспечить хоть 1024 ALU.
> Статистика известна — в обычном коде (прикладные приложения и проч) — обычно не больше 3.
ХМ, сколько не прогал на ассемблерах К580ВМ80, на Z80, на Intel8086, на 386 в защищенном режиме, на AVR, всегда казалось что предложения обычно гораздо длиннее, никак не три. Может быть я ошибаюсь, и современные компилеры генерят именно такой код, но когда дизассемблил некоторые проги, такого не наблюдал. Обычно идут большие куски пересылок и арифметическо-логических операций, которые должны параллелиться за милое дело.
ХМ, сколько не прогал на ассемблерах К580ВМ80, на Z80, на Intel8086, на 386 в защищенном режиме, на AVR, всегда казалось что предложения обычно гораздо длиннее, никак не три. Может быть я ошибаюсь, и современные компилеры генерят именно такой код, но когда дизассемблил некоторые проги, такого не наблюдал. Обычно идут большие куски пересылок и арифметическо-логических операций, которые должны параллелиться за милое дело.
>>обычно не больше 3. Именно поэтому x86 процессоры выполняют столько операций за такт.
Давно уже 4 и даже 5 инструкций (в случае cmp+branch)
Давно уже 4 и даже 5 инструкций (в случае cmp+branch)
Если костыли всякие считать, то можно много насчитать )
Вроде 3xSSE2 = 12 операций.
Вроде 3xSSE2 = 12 операций.
Какие костыли? 4 инструкции декодируются и «отправляются в отставку» (retire) за такт.
Планировщик может запускать 6 инструкций каждый такт.
микроархитектура Core2
>>Вроде 3xSSE2 = 12 операций.
SSE инструкция так и остаётся одной инструкцией (двумя в случае 64-битного ALU), вне зависимости от количества обрабатываемых ею данных.
Давайте тогда посчитаем 3х128 битных операции — 384 операции за такт :-)
Да и нынче актуален уже 256-битный AVX
Планировщик может запускать 6 инструкций каждый такт.
микроархитектура Core2
>>Вроде 3xSSE2 = 12 операций.
SSE инструкция так и остаётся одной инструкцией (двумя в случае 64-битного ALU), вне зависимости от количества обрабатываемых ею данных.
Давайте тогда посчитаем 3х128 битных операции — 384 операции за такт :-)
Да и нынче актуален уже 256-битный AVX
а не потому ли их в среднем три, что код оптимизирован для малого количества регистров? А их в x86 мало.
> Если говорить о DSP — то и более быстрые отечественные DSP давно производятся (NVCom-1 и другие), и у них никто не заявлял прорыв в архитектуре.
Эти DSP не могут выступать в качестве процессоров общего назначения. А мультиклет может, и это уникальное свойство именно данной архитектуры.
Эти DSP не могут выступать в качестве процессоров общего назначения. А мультиклет может, и это уникальное свойство именно данной архитектуры.
Вот также интересные комментарии по теме от Сергея Вакуленко:
ramlamyammambam.livejournal.com/193032.html
ramlamyammambam.livejournal.com/193032.html
Only those users with full accounts are able to leave comments. Log in, please.
Критический взгляд со стороны на процессоры Мультиклет / Multiclet