Comments 180
А как резервируется и проверяется правильность работы коммутатора? Как он устроен, какие лимиты накладывает? Почему «коммутатор» а не шина, как у Intel'а?
У Intel'a кольцо (ring).
Хотя меня тоже интересует отказоустойчивость системы заведенной на 1 важный блок.
Хотя меня тоже интересует отказоустойчивость системы заведенной на 1 важный блок.
Коммутатор в данном случае — это понятие из архитектуры, а не из реализации. Как реализовано сейчас, и как будет в будущем — это опять надо спрашивать у инженеров. От него требуется только умение шириоковещательно передавать вопросы. Поэтому, наверное, и реализация в виде шины, и в виде кольцевой шины, подошла бы.
Речь о том, что будет, если коммутатор даст сбой. Каким образом будет осуществляться «мягкая деградация» по мере выхода из строя отдельных клеток? Я тут вижу вполне себе единую точку отказа.
Коммутатор может быть зарезервирован. То есть, физически, это может быть несколько устройств, которые дублируют друг друга. Он должен выполнять достаточно простую функцию: выбирать значения со своих входных портов и рассылать на все выходные. Это достаточно дешёвое устройство. Кроме того, можно использовать коды с обнаружением и коррекцией ошибок на его datapath-ах. Поэтому, допустим, не нужно трёх коммутаторов для перекрёстной проверки ошибок.
В общем, это некая широковещательная сеть внутри чипа, а такие сети устойчивыми к сбоям человечество умеет делать. Можно даже сделать модным (Parallela или Single Chip Cloud от Intel) сейчас методом: вставить в каждую клетку микромаршрутизатор и построить полносвязную сеть между ними.
В общем, это некая широковещательная сеть внутри чипа, а такие сети устойчивыми к сбоям человечество умеет делать. Можно даже сделать модным (Parallela или Single Chip Cloud от Intel) сейчас методом: вставить в каждую клетку микромаршрутизатор и построить полносвязную сеть между ними.
круто!
Эх, на середине, в час ночи, я сдался. Второй подход завтра.
Спасибо, очень полезная статья, постараюсь вникнуть.
Спасибо, очень полезная статья, постараюсь вникнуть.
Хабр торт!
Спасибо, очень интересно, ряд идей в этом процессоре просто замечательный! Напоминает анекдот про то, как американцы изобретали специальную ручку для невесомости, а русские использовали карандаши. Отвергая догмы процессоростроения, но находя другие решения тем же самым проблемам, вы тем самым производите в отрасли революцию!
Единственная претензия будет к си-программе, которую вы используете в качестве примера. Вы ее случайно не с конкурса Obfuscated code взяли?
Единственная претензия будет к си-программе, которую вы используете в качестве примера. Вы ее случайно не с конкурса Obfuscated code взяли?
анекдот про то, как американцы изобретали специальную ручку для невесомости, а русские использовали карандаши
Надеюсь, вы знаете продолжение этой истории, а именно что «русские» потом закупили 100 таких ручек и тысячу картриджей с чернилами к ним для использования в дальнейшем вместо карандашей, которые представляли опасность из-за горючести и графитовой пыли?
За статью же спасибо! Особенно интересна именно dataflow архитектура, мне как интересующемуся визуальными dataflow языками программирования было познавательно прочесть о железной реализации данной парадигмы.
Нет. Этот код возник в результате отладки компилятора. Там всякий разный пересчёт ссылок осуществляется, нам было полезно. Ну… Эмс. Да, может быть, надо было что-нибудь осмысленное брать. Кстати, на процессор этот были потрачено очень много времени. Он историю свою ведёт из нашей космической программы, и эта простота и красота, к которой изобретатель процессора пришёл в итоге далась долгими усилиями, и ресурсы на неё были затрачены приличные.
Спасибо за статью, вы просто герой, такое написать, но кажется мне вы немножечко заангажированны =)
А я отношусь к проекту с некоторой долей скептицизма, хотя конечно в душе всё равно болею за разработчиков.
Первый вопрос на который я не увидел ответа в статье (хотя т.к. читал быстро, текста же много, мог пропустить. поправьте если что.), это собственно цели создания данного процессора, область применения, и для полного счастья ещё бы модель выхода на рынок.
Вы сравниваете мультиклет в основном с архитектурами центральных процессоров x86-64, arm, Itanium… То есть с CPU привычных нам девайсов. Все эти CPU разрабатывались как процессоры общего назначения. Это значит что процессор должен уметь эффективно выполнять любую программу. А любая программа — это обычно крайне малый параллелизм инструкций. Мы не можем знать какие программисты будут использовать процессор. А зачем заморачиваться по поводу потоков или тем более обеспечения возможности параллельного выполнения инструкций, если можно написать просто, и на процессорах х86/arm это будет работать более чем сносно.
В этом плане современные массовые архитектуры как-раз очень хороши. Предсказание переходов в данном случае очень полезно, или даже как это было сделано в Itanium — считать обе ветки сразу.
Другое дело если этот процессор всё же специализирован для каких-то вычислений. Тогда вопрос — для каких? Судя по простым ядрам и их предполагаемому большому количеству, процессор нужно сравнивать не с x86/arm/etc… А с видеокартами, или подобными многоядерными системами. Вот вспомним, ещё не так давно, было много разговоров про intel larrabee. И где этот ларраби? Почему интел не выкатила свою супер-многоядерную архитектуру? Я думаю потому что в интел понимают что это бесполезно. Высокий параллелизм инструкция можно обеспечить только в узком классе задач. А почему интел стала делать этот ларраби — скорее всего по моде. Если бы cuda выстрелила, то у интел был бы готов конкурент.
Так что кому нужна такая штука, да ещё и с учётом того, что техпроцесс скорее всего будет не самый современный — мне не понять. Хотя конечно не отказался бы пощупать такой процессор в живую =)
Ещё вопрос, правильно я понял что конвейера в процессоре тоже нет?
P.S. Не считаю себе гуру в процессорах, и ассемблере, я занимаюсь высокоуровневым девелопментом, но в моих глазах ситуация именно такая, какой я её описал.
А я отношусь к проекту с некоторой долей скептицизма, хотя конечно в душе всё равно болею за разработчиков.
Первый вопрос на который я не увидел ответа в статье (хотя т.к. читал быстро, текста же много, мог пропустить. поправьте если что.), это собственно цели создания данного процессора, область применения, и для полного счастья ещё бы модель выхода на рынок.
Вы сравниваете мультиклет в основном с архитектурами центральных процессоров x86-64, arm, Itanium… То есть с CPU привычных нам девайсов. Все эти CPU разрабатывались как процессоры общего назначения. Это значит что процессор должен уметь эффективно выполнять любую программу. А любая программа — это обычно крайне малый параллелизм инструкций. Мы не можем знать какие программисты будут использовать процессор. А зачем заморачиваться по поводу потоков или тем более обеспечения возможности параллельного выполнения инструкций, если можно написать просто, и на процессорах х86/arm это будет работать более чем сносно.
В этом плане современные массовые архитектуры как-раз очень хороши. Предсказание переходов в данном случае очень полезно, или даже как это было сделано в Itanium — считать обе ветки сразу.
Другое дело если этот процессор всё же специализирован для каких-то вычислений. Тогда вопрос — для каких? Судя по простым ядрам и их предполагаемому большому количеству, процессор нужно сравнивать не с x86/arm/etc… А с видеокартами, или подобными многоядерными системами. Вот вспомним, ещё не так давно, было много разговоров про intel larrabee. И где этот ларраби? Почему интел не выкатила свою супер-многоядерную архитектуру? Я думаю потому что в интел понимают что это бесполезно. Высокий параллелизм инструкция можно обеспечить только в узком классе задач. А почему интел стала делать этот ларраби — скорее всего по моде. Если бы cuda выстрелила, то у интел был бы готов конкурент.
Так что кому нужна такая штука, да ещё и с учётом того, что техпроцесс скорее всего будет не самый современный — мне не понять. Хотя конечно не отказался бы пощупать такой процессор в живую =)
Ещё вопрос, правильно я понял что конвейера в процессоре тоже нет?
P.S. Не считаю себе гуру в процессорах, и ассемблере, я занимаюсь высокоуровневым девелопментом, но в моих глазах ситуация именно такая, какой я её описал.
Спасибо за статью, вы просто герой, такое написать, но кажется мне вы немножечко заангажированны =)
Гы-гы-гы! :) Надо НЛО предложить: человеку, которого 10 раз назовут героем в письменной форме выдавать соответствующую медальку в профиль :) после всенародного голосования. Кстати, ангажирован я не немножечко, а на целые поставки. То есть, если Вам показалось, что немножечко, значит, архитектура объективно неплохая. Что приятно. Ок. Далее постараюсь быть серьёзным.
Первый вопрос на который я не увидел ответа в статье (хотя т.к. читал быстро, текста же много, мог пропустить. поправьте если что.), это собственно цели создания данного процессора, область применения, и для полного счастья ещё бы модель выхода на рынок.
Мне об этом ничего не известно. То есть, процессор создавался не как коммерческий проект, он разрабатывался как нечто такое этакое интересное. Оказалось, что эта интересная штука получилась производительной и экономичной (по энергии и транзисторному бюджету). И в 2010 ей заинтересовался бизнес. Те приложения, на которые нацелен процессор перечислены тут: ru.wikipedia.org/wiki/Multiclet
Моё же личное мнение в том, что это хорошая высокопроизводительная архитектура для процессоров общего назначения.
Вы сравниваете мультиклет в основном с архитектурами центральных процессоров x86-64, arm, Itanium… То есть с CPU привычных нам девайсов. Все эти CPU разрабатывались как процессоры общего назначения. Это значит что процессор должен уметь эффективно выполнять любую программу. А любая программа — это обычно крайне малый параллелизм инструкций. Мы не можем знать какие программисты будут использовать процессор. А зачем заморачиваться по поводу потоков или тем более обеспечения возможности параллельного выполнения инструкций, если можно написать просто, и на процессорах х86/arm это будет работать более чем сносно.
В этом плане современные массовые архитектуры как-раз очень хороши. Предсказание переходов в данном случае очень полезно, или даже как это было сделано в Itanium — считать обе ветки сразу.
А MCp тоже разрабатывался как процессор общего назначения. Степень его ILP примерно такая же, как у современных процессоров общего назначения с внеочередным исполнением (без учёта векторных блоков, конечно). Особенностью же MCp является то, что если становится понятно, что программе не нужна высокая степень параллелизма, то можно отключать клетки и экономить электричество. Наверное Core от Intel теперь тоже так умеют делать, но в MCp это достигается более простыми средствами.
При этом программистов заморачивать никак не нужно. Код параллелить должен сам компилятор, и для MCp это относительно простая задача из-за его потоковой архитектуры. Нити же я упомянул просто по той причине, что в некоторых приложениях без них никак: нужна независимая обработка событий.
Кроме того, я же не говорю, что современные массовые архитектуры плохи (я даже назвал их шедевральными). Я говорю, что они требуют много транзисторов для своей реализации и потребляют много энергии в своей работе. MCp по возможностям асинхронного исполнения инструкций этим архитектурам не уступает, но при этом требует гораздо меньше транзисторов на реализацию и потребляет меньше энергии. В этом преимущество. Вот, например, упомянутые Вами предсказатели перехода ему не нужны. Потому что архитектура MCp позволяет сообщить процессору примерно следующее: «знаешь, ты пока начинай выбирать инструкции вооОон по тому адресу, а я тут кое-что ещё досчитаю». В традиционных процессорах такой возможности нет, поэтому им нужно спекулятивное исполнение и предсказание переходов.
Другое дело если этот процессор всё же специализирован для каких-то вычислений. Тогда вопрос — для каких? Судя по простым ядрам и их предполагаемому большому количеству, процессор нужно сравнивать не с x86/arm/etc… А с видеокартами, или подобными многоядерными системами. Вот вспомним, ещё не так давно, было много разговоров про intel larrabee. И где этот ларраби? Почему интел не выкатила свою супер-многоядерную архитектуру? Я думаю потому что в интел понимают что это бесполезно. Высокий параллелизм инструкция можно обеспечить только в узком классе задач. А почему интел стала делать этот ларраби — скорее всего по моде. Если бы cuda выстрелила, то у интел был бы готов конкурент.
Не. С видеокартами сравнивать совсем не нужно. У видеокарт проблемы с выполнением ветвящихся вычислений, а у MCp таких проблем нет, даже если клеток в чипе будет много. В следующей версии архитектуры будет для этого ещё одна фишечка. MCp — процессор общего назначения.
CUDA, вообще-то, очень даже выстрелила. Сейчас очень много научных вычислений делается на CUDA. И NVIDIA — это один из главных конкурентов Intel за кошельки заказчиков на рынке суперкомпьютеров. А Microsoft даже разработала расширения для компиляторов OpenACC, чтобы потоковые (stream на сей раз) вычисления продвигать в массы. Larrabe тоже пошёл на этот рынок и сейчас поставляется в виде Xeon Phi. В Челябинске даже уже стоит компьютер с ними. Другое дело, что Intel, скорее всего, не победит NVIDIA в этом деле. Потому что они пытаются использовать универсальные традиционные ядра с общими кэшами (которые надо синхронизировать), да ещё и с тяжёлым набором инструкций. По энергоэффективности пресловутой они сильно проигрывают NVIDIA, и по производительности тоже. MCp тоже, вряд ли победит CUDA в stream-вычислениях. А вот x86 или ARM в вычислениях универсальных он вполне уделать может, архитектура позволяет.
Так что кому нужна такая штука, да ещё и с учётом того, что техпроцесс скорее всего будет не самый современный — мне не понять. Хотя конечно не отказался бы пощупать такой процессор в живую =)
Военным она нужна — это точно. И нужна инженерам, которые занимаются секретными вычислениями. Им очень хочется иметь отечественный высокопроизводительный микропроцессор. Проверять каждую партию зарубежной продукции на наличе закладок — удовольствие дорогое. А проверять надо, и это не паранойя, а вопрос безопасности.
Техпроцесс же да. Но, например, для военных применений грубый техпроцесс даже лучше, более устойчиво всё к излучениям и температурам. А тут проявляется ещё одно достоинство MCp. Даже на грубом техпроцессе и, соответственно, небольшом числе транзисторов, архитектура позволяет достичь 4-х инструкций за такт при асинхронном их исполнении. Что очень-очень не плохо.
Ещё вопрос, правильно я понял что конвейера в процессоре тоже нет?
Почему нет? Общей конвейер тут не нужен, но каждая клетка параллельно может выбирать, планировать и исполнять инструкции. То есть, три стадии точно есть. Про детали ALU надо уточнять у инженеров (они его сейчас переделывают, поэтому пока документации нет, к сожалению).
P.S. Не считаю себе гуру в процессорах, и ассемблере, я занимаюсь высокоуровневым девелопментом, но в моих глазах ситуация именно такая, какой я её описал.
Спасибо за мнение :) PR-отделу будет, чем заняться :)
Гы-гы-гы! :) Надо НЛО предложить: человеку, которого 10 раз назовут героем в письменной форме выдавать соответствующую медальку в профиль :) после всенародного голосования. Кстати, ангажирован я не немножечко, а на целые поставки. То есть, если Вам показалось, что немножечко, значит, архитектура объективно неплохая. Что приятно. Ок. Далее постараюсь быть серьёзным.
Первый вопрос на который я не увидел ответа в статье (хотя т.к. читал быстро, текста же много, мог пропустить. поправьте если что.), это собственно цели создания данного процессора, область применения, и для полного счастья ещё бы модель выхода на рынок.
Мне об этом ничего не известно. То есть, процессор создавался не как коммерческий проект, он разрабатывался как нечто такое этакое интересное. Оказалось, что эта интересная штука получилась производительной и экономичной (по энергии и транзисторному бюджету). И в 2010 ей заинтересовался бизнес. Те приложения, на которые нацелен процессор перечислены тут: ru.wikipedia.org/wiki/Multiclet
Моё же личное мнение в том, что это хорошая высокопроизводительная архитектура для процессоров общего назначения.
Вы сравниваете мультиклет в основном с архитектурами центральных процессоров x86-64, arm, Itanium… То есть с CPU привычных нам девайсов. Все эти CPU разрабатывались как процессоры общего назначения. Это значит что процессор должен уметь эффективно выполнять любую программу. А любая программа — это обычно крайне малый параллелизм инструкций. Мы не можем знать какие программисты будут использовать процессор. А зачем заморачиваться по поводу потоков или тем более обеспечения возможности параллельного выполнения инструкций, если можно написать просто, и на процессорах х86/arm это будет работать более чем сносно.
В этом плане современные массовые архитектуры как-раз очень хороши. Предсказание переходов в данном случае очень полезно, или даже как это было сделано в Itanium — считать обе ветки сразу.
А MCp тоже разрабатывался как процессор общего назначения. Степень его ILP примерно такая же, как у современных процессоров общего назначения с внеочередным исполнением (без учёта векторных блоков, конечно). Особенностью же MCp является то, что если становится понятно, что программе не нужна высокая степень параллелизма, то можно отключать клетки и экономить электричество. Наверное Core от Intel теперь тоже так умеют делать, но в MCp это достигается более простыми средствами.
При этом программистов заморачивать никак не нужно. Код параллелить должен сам компилятор, и для MCp это относительно простая задача из-за его потоковой архитектуры. Нити же я упомянул просто по той причине, что в некоторых приложениях без них никак: нужна независимая обработка событий.
Кроме того, я же не говорю, что современные массовые архитектуры плохи (я даже назвал их шедевральными). Я говорю, что они требуют много транзисторов для своей реализации и потребляют много энергии в своей работе. MCp по возможностям асинхронного исполнения инструкций этим архитектурам не уступает, но при этом требует гораздо меньше транзисторов на реализацию и потребляет меньше энергии. В этом преимущество. Вот, например, упомянутые Вами предсказатели перехода ему не нужны. Потому что архитектура MCp позволяет сообщить процессору примерно следующее: «знаешь, ты пока начинай выбирать инструкции вооОон по тому адресу, а я тут кое-что ещё досчитаю». В традиционных процессорах такой возможности нет, поэтому им нужно спекулятивное исполнение и предсказание переходов.
Другое дело если этот процессор всё же специализирован для каких-то вычислений. Тогда вопрос — для каких? Судя по простым ядрам и их предполагаемому большому количеству, процессор нужно сравнивать не с x86/arm/etc… А с видеокартами, или подобными многоядерными системами. Вот вспомним, ещё не так давно, было много разговоров про intel larrabee. И где этот ларраби? Почему интел не выкатила свою супер-многоядерную архитектуру? Я думаю потому что в интел понимают что это бесполезно. Высокий параллелизм инструкция можно обеспечить только в узком классе задач. А почему интел стала делать этот ларраби — скорее всего по моде. Если бы cuda выстрелила, то у интел был бы готов конкурент.
Не. С видеокартами сравнивать совсем не нужно. У видеокарт проблемы с выполнением ветвящихся вычислений, а у MCp таких проблем нет, даже если клеток в чипе будет много. В следующей версии архитектуры будет для этого ещё одна фишечка. MCp — процессор общего назначения.
CUDA, вообще-то, очень даже выстрелила. Сейчас очень много научных вычислений делается на CUDA. И NVIDIA — это один из главных конкурентов Intel за кошельки заказчиков на рынке суперкомпьютеров. А Microsoft даже разработала расширения для компиляторов OpenACC, чтобы потоковые (stream на сей раз) вычисления продвигать в массы. Larrabe тоже пошёл на этот рынок и сейчас поставляется в виде Xeon Phi. В Челябинске даже уже стоит компьютер с ними. Другое дело, что Intel, скорее всего, не победит NVIDIA в этом деле. Потому что они пытаются использовать универсальные традиционные ядра с общими кэшами (которые надо синхронизировать), да ещё и с тяжёлым набором инструкций. По энергоэффективности пресловутой они сильно проигрывают NVIDIA, и по производительности тоже. MCp тоже, вряд ли победит CUDA в stream-вычислениях. А вот x86 или ARM в вычислениях универсальных он вполне уделать может, архитектура позволяет.
Так что кому нужна такая штука, да ещё и с учётом того, что техпроцесс скорее всего будет не самый современный — мне не понять. Хотя конечно не отказался бы пощупать такой процессор в живую =)
Военным она нужна — это точно. И нужна инженерам, которые занимаются секретными вычислениями. Им очень хочется иметь отечественный высокопроизводительный микропроцессор. Проверять каждую партию зарубежной продукции на наличе закладок — удовольствие дорогое. А проверять надо, и это не паранойя, а вопрос безопасности.
Техпроцесс же да. Но, например, для военных применений грубый техпроцесс даже лучше, более устойчиво всё к излучениям и температурам. А тут проявляется ещё одно достоинство MCp. Даже на грубом техпроцессе и, соответственно, небольшом числе транзисторов, архитектура позволяет достичь 4-х инструкций за такт при асинхронном их исполнении. Что очень-очень не плохо.
Ещё вопрос, правильно я понял что конвейера в процессоре тоже нет?
Почему нет? Общей конвейер тут не нужен, но каждая клетка параллельно может выбирать, планировать и исполнять инструкции. То есть, три стадии точно есть. Про детали ALU надо уточнять у инженеров (они его сейчас переделывают, поэтому пока документации нет, к сожалению).
P.S. Не считаю себе гуру в процессорах, и ассемблере, я занимаюсь высокоуровневым девелопментом, но в моих глазах ситуация именно такая, какой я её описал.
Спасибо за мнение :) PR-отделу будет, чем заняться :)
PR-отдел должен делать бенчмарки. Нужно сравнивать себя с потенциальными конкурентами в разных нишах. С процессорами общего назначения корректно сравнивать себя только после того как запустили linux :)
А вот для эмбеддеров можно себя попиарить через разные dsp-бенчмарки, коммуникационные или мультимедийные.
Ну и хорошо бы выложить симуляторы, особенно архитектурный симулятор с профайлером. Чтобы можно было на своем коде померить производительность.
Для сравнения, похожая архитектура (бенчмарки и симулятор кстати в наличии):
cseweb.ucsd.edu/users/swanson/papers/TOCSWaveScalarArch.pdf
wavescalar.cs.washington.edu/wavescalar.pdf
А вот для эмбеддеров можно себя попиарить через разные dsp-бенчмарки, коммуникационные или мультимедийные.
Ну и хорошо бы выложить симуляторы, особенно архитектурный симулятор с профайлером. Чтобы можно было на своем коде померить производительность.
Для сравнения, похожая архитектура (бенчмарки и симулятор кстати в наличии):
cseweb.ucsd.edu/users/swanson/papers/TOCSWaveScalarArch.pdf
wavescalar.cs.washington.edu/wavescalar.pdf
Да, должен. Но для этого надо допиливать компилятор. Работа ведётся. Наверное, о результатах бенчмарков тоже будут сообщать. За ссылки большое спасибо!
Думаю печь кремений без софтверной поддержки несколько преждевременно. Такое могут себе позволить только университеты работающие на гранты, и организации занимающиеся распилом госбюджета :( Большинство электронных стартапов backend вообще отдают на аутсорсинг, дешевле чем держать backend команду в штате. Адекватным инвесторам достаточно показать FPGA-прототип.
Лучше тратить ресурсы именно на энэйблинг разного софта. Если посмотреть на ваших конкурентов, то все они предлагают хард вместе с софтверным стеком: ОС, мультимедиа кодеки, коммуникационные протоколы, криптографические либы и.т.д. Думаю что 80% софременного хардверного IP это софт.
Лучше тратить ресурсы именно на энэйблинг разного софта. Если посмотреть на ваших конкурентов, то все они предлагают хард вместе с софтверным стеком: ОС, мультимедиа кодеки, коммуникационные протоколы, криптографические либы и.т.д. Думаю что 80% софременного хардверного IP это софт.
Опять же это зависит от многих факторов. В данном случае, компании нужен контроль над разработкой компилятора. Возможно, это требование военных. Возможно, потому что архитектура новая и просто формально её непонятно как передавать сторонним разработчикам. Я не знаю, конечно, наверняка. Вполне возможно и то, что требованием инвесторов было нечто вроде: а вы вообще сможете свою идею до кристалла довести, с технологиями знакомы? Ну и т.д. Это новое всё, к сожалению, для нашей индустрии дело… Поэтому, наверное, компания и идёт таким путём. Да и потом, ассемблер же уже есть. И Си есть, который стыкуется с ассемблером. То есть, для тех, кому нужно выжимать максимум из процессора любой ценой (а в этом случае вычислительный код всё-равно надо писать на ассемблере), софт уже есть: ассемблер для выжимки производительности, Си для управления вычислением.
Мм, я имел в виду не компиляторный бэкэнд (понятно что ваше IP именно компилятор и архитектура), а электронный: place&route, physical verification, BIST всякий, оживление чипов пришедших с фабрики. Плюс к этому составление документации, создание прототипных плат. Всё это кажется несколько преждевременной работой.
Не, обычно инвесторов интересует вопорос, а зачем оно нужно, чем оно лучше чем у конкурентов, как вы будете это продавать. И, разумеется, ответы на такие вопросы нужно подтверждать на работающих примерах.
Да нет на свете этих людей. Этому описанию соответсвуют энтузиасты, а их единицы, и денег у них нет.
Реальные покупатели решают какие-то свои задачи, и будут выбирать компоненты исходя из того, насколько эти компоненты их приближают к решению.
Какой (в общих чертах) бизнес-план у multiclet? По-моему это больше университетский проект, и на выходе, в идеале, должны быть диссертации и IEEE-шные статьи :)
Вполне возможно и то, что требованием инвесторов было нечто вроде: а вы вообще сможете свою идею до кристалла довести, с технологиями знакомы?
Не, обычно инвесторов интересует вопорос, а зачем оно нужно, чем оно лучше чем у конкурентов, как вы будете это продавать. И, разумеется, ответы на такие вопросы нужно подтверждать на работающих примерах.
То есть, для тех, кому нужно выжимать максимум из процессора любой ценой (а в этом случае вычислительный код всё-равно надо писать на ассемблере), софт уже есть
Да нет на свете этих людей. Этому описанию соответсвуют энтузиасты, а их единицы, и денег у них нет.
Реальные покупатели решают какие-то свои задачи, и будут выбирать компоненты исходя из того, насколько эти компоненты их приближают к решению.
Какой (в общих чертах) бизнес-план у multiclet? По-моему это больше университетский проект, и на выходе, в идеале, должны быть диссертации и IEEE-шные статьи :)
Да есть на свете такие люди, отличные от энтузиастов. Они даже готовы на то, чтобы время тратить на разработку функциональных процессоров, а не только на то, чтобы на ассемблере код вылизывать. Называются такие люди: спецслужбы и вооружённые силы. Про бизнес-план не знаю, это надо у директора спрашивать. Но почему-то мне кажется, что этот бизнес-план связан именно с такими потребителями. Тем более, что компания входит в аэрокосмический кластер Сколково.
К слову о Plan9 — не уверен насчёт него, но вот OS Inferno насколько я знаю не требует MMU.
В принципе, есть много систем, которые не требуют MMU. Inferno, JNode, даже ранние Android. У MS ведётся проект Midori (бывшая Singularity). Есть ещё всякие Contiki или Barrelfish. Даже у нас (в смысле, в РАН) есть нечто такое этакое. Вопрос в том: выстрелит ли?
Так и линукс бывает nommu.
UFO just landed and posted this here
Ох, круто. Вечером обязательно почитаю. Наверное это все-таки EDGE архитектура, а не EPIC (VLIW)?
Не знаю. То есть, про EDGE-то я знаю, и даже пытался разобраться с TRIPS-ом. Но вот MCp никак у меня с этим не проассоциировался. А вот с VLIW-ами и EPIC-ами да. Потому что тоже есть некая последовательность инструкций, параллелизм которой задан компилятором или программистом. В EDGE, насколько я помню, всё намного суровее. Хотя, может и EDGE. В общем, пусть начальство определяется :)
Я так понимаю windows/linux не взлетят на этой архитектуре? Как вообще быть с существующим софтом?
Софт же бывает разным. Какой-то уже взлетает, клиенты что-то пытаются запускать. С Windows/Linux не понятно. А Java, например, очень даже неплохо взлететь может.
Офис /1С /почтовый сервер/ сервер БД (MSSQL, mysql, oracle) /php+apache+nginx / браузер + почтовый клиент +… — что из этого списка работает?
Или может какой-то научный софт, типа mathcad, mathlab, hyperchem?
Или может какой-то научный софт, типа mathcad, mathlab, hyperchem?
Из этого списка нет… Но это пока не десктопный процессор же.
Бизнесу значит не подходит, ученым тоже, домой не установишь. Остаются военные и энтузиасты, любящие ковыряться в железе.
Удачи, но я, мягко говоря, немного скептически отношусь к этой разработке.
Удачи, но я, мягко говоря, немного скептически отношусь к этой разработке.
Военные — это хороший рынок. И энтузиасты тоже. И ещё есть промышленные контроллеры. А скоро будут и учёные, когда пойдёт тема с суперкомпьютерами. Выйти на рынок десктопов сразу же просто офигительно сложно. Посмотрите на опыт ARM. Адекватные люди не воюют с Wintel, не имея за спиной хорошей поддержки. В МультиКлете работают адекватные люди :)
Да и вообще. Бизнес тоже бывает разный. Вот подошёл ко мне бизнесмен и спросил: а можно ли при помощи этого процессора перетранслировать на лету один сигнал в другой. Как бы вот он Вам интерес бизнеса :) Не весь же у нас бизнес в стране связан с офисной работой.
Да и вообще. Бизнес тоже бывает разный. Вот подошёл ко мне бизнесмен и спросил: а можно ли при помощи этого процессора перетранслировать на лету один сигнал в другой. Как бы вот он Вам интерес бизнеса :) Не весь же у нас бизнес в стране связан с офисной работой.
>>Вот подошёл ко мне бизнесмен и спросил: а можно ли при помощи этого процессора перетранслировать на лету один сигнал в другой.
Завтра этот же бизнесмен подойдет к программисту Си-шнику, спросит сможет ли он с помощью процессора intel и линукса/windows перетранслировать тот же сигнал в другой. Потом подойдет к другому железячнику и спросит у него может ли он с помощью китайского микроконтроллера, продающегося по 3 копейки за кило сделать то же самое. Потом сравнит стоимость и доступность на рынке Сишников, железячников знающих китайские микроконтроллеры и спецов знающих вашу архитектуру, а также риски от внедрения новой архитектуры и возможность её интеграции с имеющимися системами.
В общем путь предстоит нелегкий.
Завтра этот же бизнесмен подойдет к программисту Си-шнику, спросит сможет ли он с помощью процессора intel и линукса/windows перетранслировать тот же сигнал в другой. Потом подойдет к другому железячнику и спросит у него может ли он с помощью китайского микроконтроллера, продающегося по 3 копейки за кило сделать то же самое. Потом сравнит стоимость и доступность на рынке Сишников, железячников знающих китайские микроконтроллеры и спецов знающих вашу архитектуру, а также риски от внедрения новой архитектуры и возможность её интеграции с имеющимися системами.
В общем путь предстоит нелегкий.
Фишечка в том, что он уже ходил :) У аналогов по потребляемой мощности не хватает производительности. Вы не думайте, что наш бизнес неадекватный. Естественно, все сначала ищут распространённые решения, и только потом ищут среди новых решений, если существующие не удовлетворяют требованиям.
Можно подробнее про алгоритм обработки сигнала, на котором вы рвете конкурентов? И о каких требованиях идет речь?
Эмс. Ну, например, MCp рвёт конкурентов на БПФ. А про этот конкретный запрос бизнесмена, я не знаю, рвёт или не рвёт. Надо пробовать. Я же высказывался относительно того, что бизнесу вот тоже интересен этот процессор.
У вас есть сравнительный анализ производительности и энергопотребления для каких-нибудь прикладных задач или хотя бы синтетических тестов?
Ну об этом собственно и была речь в комментариях к тому топику, что ныне скрыт в черновиках. Правда более более обстоятельно и с конкретными примерами.
Ну и ещё вопрос цены, делает эти камушки бессмысленными не только для энтузиастов…
Ну и ещё вопрос цены, делает эти камушки бессмысленными не только для энтузиастов…
Да — вот, вполне подходящая ниша — преобразование сигналов: слишком «параллельное» для традиционных процессоров и слишком ветвящееся для GPU.
Вам лишьбы LAMPы на все устанавливать, не вокруг них весь мир крутится, ежели он всех будет рвать в отношении производительность/энергопотребление, то займет свою нишу среди устройств, где это критично, какие нибудь там автономные метеостанции, спутники, роботы, воякам полюбэ нужен будет. Я, если что, тоже скептически отношусь к этой разраотке, в первую очередь из-за того, что все предыдущие громкие заявления о всяких там русских ойфонах, читалках, осях окахывались на поверку пшиком, но хотелось бы чтобы тут было не так.
Чего бизнесу не подходит? Бизнес разный бывает. Если на этом мультиклете будет эффективнее выполнять как-то ресурсоемкие операции (от сложной обработки видео, но BI), то софт портируют достаточно быстро. Естественно, Офис и бухлгалтерию пока вряд ли портировать будут, но это далеко не самые требовательные задачи, с ними и текущие решения справляются лучше, чем необходимо.
Ещё один товарищ, который не понимает и не знает что существуют процессоры других архитектур и зачем они существуют.
Еще один товарищ считает уточняющие вопросы чуть ли не личным оскорблением)))
Не путайте уточняющие вопросы при полном понимании сути дела, с проявлением собственной неграмотности.
Интересно в каком месте вы нашли мое утверждение о полном понимании сути дела?
Я правда не особо понимаю конкретные сферы применения данного мощного микроконтроллера.
Тут даже их представитель в качестве примера практического применения смог назвать только абстрактное преобразование каких-то сигналов в какие-то другие сигналы, без сравнительного анализа с другими архитектурами по мощности, надежности, энергопотреблению и цене.
Я тем более не могу за них гадать куда засунуть их процессоры, тем более моя работа никак не связана с железом
Я правда не особо понимаю конкретные сферы применения данного мощного микроконтроллера.
Тут даже их представитель в качестве примера практического применения смог назвать только абстрактное преобразование каких-то сигналов в какие-то другие сигналы, без сравнительного анализа с другими архитектурами по мощности, надежности, энергопотреблению и цене.
Я тем более не могу за них гадать куда засунуть их процессоры, тем более моя работа никак не связана с железом
Я утверждаю, что вы просто проявляете свою неграмотность.
Ну как минимум вы говорите ересь о запуске винды и виндовских приложений на архитектуре для этого не предназначенной. Винда работает ТОЛЬКО на х86 процессорах.
А вам для справки, архитектура процессора не ограничивается только х86. Существуют ARM (их тоже море видов), MIPS (аналогично), PowerPC, туева хуча различных прикладных процессоров и контроллеров. Их такое множество и каждый хорош для своей задачи.
Вы знаете только пару задачек, и ими пытаетесь мерять. Вам тонко намекают, что ваш кругозор узок, а вы настойчиво со своей линейкой пытаетесь измерять напряжение. Это глупо
Ну как минимум вы говорите ересь о запуске винды и виндовских приложений на архитектуре для этого не предназначенной. Винда работает ТОЛЬКО на х86 процессорах.
А вам для справки, архитектура процессора не ограничивается только х86. Существуют ARM (их тоже море видов), MIPS (аналогично), PowerPC, туева хуча различных прикладных процессоров и контроллеров. Их такое множество и каждый хорош для своей задачи.
Вы знаете только пару задачек, и ими пытаетесь мерять. Вам тонко намекают, что ваш кругозор узок, а вы настойчиво со своей линейкой пытаетесь измерять напряжение. Это глупо
Винда работает ТОЛЬКО на х86 процессорах.Вроде есть эмулятор для гиков, можно на армо-андро-офоне запустить 98-ю…
>>Я утверждаю, что вы просто проявляете свою неграмотность.
У вас очень интересный и оригинальный способ определения грамотности населения. Пожалуй я даже напишу в росстат письмо с просьбой изменения методики измерения уровня грамотности, поскольку неграмотными следует считать тех, кто не разбирается в архитектурах процессора.
>>>А вам для справки, архитектура процессора не ограничивается только х86.
Вы прям как в анекдоте — выдали абсолютно точный и абсолютно бесполезный ответ. Спасибо, но я и так знал, что бывают процессоры с различной архитектурой. Видимо я слишком непонятно выражаюсь, но попробую переформулировать сказанное. Мне не интересно можно ли на нем запустить какую-либо определенную программу или набор программ, будет ли на нем работать мой любимый калькулятор, и игра крестики нолики 3D. Мне интересно что вообще на нем сейчас может работать, портированно ли хоть что-нибудь из существующего софта, какие прикладные задачи можно решать сейчас, какие через год, какие через 5 лет.
>>Винда работает ТОЛЬКО на х86 процессорах.
Это не совсем соответствует действительности. Если уж так любите точность, то windows работает на x86 и на x86-64, существует версия на AI-64, WindowsRT работает на ARM.
Совсем старые версии есть и для других архитектур.
Используя виртуализацию можно поставить её можно и на других платформах запустить, на том же ARM, или PowerPC, например habrahabr.ru/sandbox/48005/
У вас очень интересный и оригинальный способ определения грамотности населения. Пожалуй я даже напишу в росстат письмо с просьбой изменения методики измерения уровня грамотности, поскольку неграмотными следует считать тех, кто не разбирается в архитектурах процессора.
>>>А вам для справки, архитектура процессора не ограничивается только х86.
Вы прям как в анекдоте — выдали абсолютно точный и абсолютно бесполезный ответ. Спасибо, но я и так знал, что бывают процессоры с различной архитектурой. Видимо я слишком непонятно выражаюсь, но попробую переформулировать сказанное. Мне не интересно можно ли на нем запустить какую-либо определенную программу или набор программ, будет ли на нем работать мой любимый калькулятор, и игра крестики нолики 3D. Мне интересно что вообще на нем сейчас может работать, портированно ли хоть что-нибудь из существующего софта, какие прикладные задачи можно решать сейчас, какие через год, какие через 5 лет.
>>Винда работает ТОЛЬКО на х86 процессорах.
Это не совсем соответствует действительности. Если уж так любите точность, то windows работает на x86 и на x86-64, существует версия на AI-64, WindowsRT работает на ARM.
Совсем старые версии есть и для других архитектур.
Используя виртуализацию можно поставить её можно и на других платформах запустить, на том же ARM, или PowerPC, например habrahabr.ru/sandbox/48005/
1С — особенно шикарно… он хотя бы под ARM есть?
>>1С — особенно шикарно
Почему?
>>он хотя бы под ARM есть?
Толстый клиент запустить нельзя. Но на 1С можно писать приложения для андроид и iOs.
Статья по теме: habrahabr.ru/post/153809/
Еще можно использовать web клиент для работы с 1С. Для андроида не пробовал, а на айпаде работает.
Почему?
>>он хотя бы под ARM есть?
Толстый клиент запустить нельзя. Но на 1С можно писать приложения для андроид и iOs.
Статья по теме: habrahabr.ru/post/153809/
Еще можно использовать web клиент для работы с 1С. Для андроида не пробовал, а на айпаде работает.
Вот сделают под него Java — и запустится Mathlab…
MMU конечно же нужен, но можно реализовать лишь самый необходимый минимум, тоже и сложность будет не большой и затраты ресурсов.
Но я вот чего не понял, а если в пределах параграфа будет две операции перехода? И что если оба перехода произойдут (два условных перехода и оба условия выполнятся)?
Но я вот чего не понял, а если в пределах параграфа будет две операции перехода? И что если оба перехода произойдут (два условных перехода и оба условия выполнятся)?
Это забота компилятора/программиста, чтобы такого не было. Если могут сработать два, то будет взять адрес того, что сработает первым.
Лучше бы исключение выдавали — это явный сбой. Хотя компилятор, конечно не должен такого допускать
В принципе, это легко отслеживается статическим анализом. Даже по бинарной программе (особенность кодирования инструкций). Но, может быть, конечно, имеет смысл и исключение генерировать. Тут опять же вопрос tradeoff-ов. Насколько это будет дорого в железе, и насколько это востребовано. Вряд ли много людей будет писать прямо на ассемблере. А в компиляторе проверки таких условий и так проводятся.
Compiler error, и хватит.
Думаю, на случай прерывания можно сделать «сериализацию» внутреннего состояния CPU в память и потом «десериализацию» оттуда. И сделать возможность расширения на память внутреннего «пула промежуточных результатов».
Я правильно понял, что основная фишка в том, что задачу разбиения кода на паралелизуемые блоки переложили с CU на компилятор? И что все остальные бонусы — следствия этого подхода?
Неа. На самом деле эта задача возлагается на компилятор во всех архитектурах. В RISC надо так инструкции выставить, чтобы они параллельно исполнялись на конвейере. В VLIW, чтобы их можно было выполнить на нескольких устройствах. В OoOE-процессорах нужно назначить регистры так, чтобы не было Write-To-Read зависимостей. В MCp компилятор тоже участвует в распараллеливании кода, но основная фишка в том, что CU удалось сделать распределённым. Нет необходимости весь поток инструкций пропускать через одно место, и остальные бонусы и особенности — следствие этого.
Какую-то вы гермафродитную штуковину делаете между «нормальными» императивными процессорами типа x86|ARM и графическими процессорами для видеокарт… С нормальной многопоточностью/многопроцессностью и MMU нерешаемые проблемы… боюсь, придется к этим платам в итоге делать хотя бы маломощную «plain old» императивную «обвязку»…
При том, что, я слышал, практика выполнения сложных вычислений на видеокартах уже имеется…
При том, что, я слышал, практика выполнения сложных вычислений на видеокартах уже имеется…
Если Вы так думаете, значит, ничего не поняли. Какие проблемы Вы видите с нормальной многопоточностью и многопроцессорностью? В этом-то как раз проблем нет. Нет и нерешаемых проблем с MMU. Там главный сложный вопрос: стоит ли их вообще решать. К видеокартам эта архитектура вообще никакого отношения не имеет, потому что GPU устроены, можно сказать, диаметрально противоположным образом. И практика использования GPU, конечно есть. И даже положительная. Но алгоритмы, которые требуют ветвлений, на них выполняются крайне плохо.
А есть очень много методов вычислений, когда на каждом шаге итерационного процесса нужно анализировать кучу условий (if-ов), чтобы оптимальнее выбрать следующий шаг. GPU может «взять» такие вычисления грубой силой, типа: а будем делать всегда однообразно, и не важно, что для алгоритм сойдётся за 1000 шагов, а не за 10. Иногда это даёт выигрыш по времени вычисления, иногда нет. Знаю таких физиков, в расчётах которых GPU крайне неэффективны. То есть, если сравнивать тупой алгоритм на CPU и тупой на GPU, то GPU всех рвёт, как тузик грелку. Но если на CPU запускать «умный» алгоритм, то он сходится в 100 раз быстрее.
А есть очень много методов вычислений, когда на каждом шаге итерационного процесса нужно анализировать кучу условий (if-ов), чтобы оптимальнее выбрать следующий шаг. GPU может «взять» такие вычисления грубой силой, типа: а будем делать всегда однообразно, и не важно, что для алгоритм сойдётся за 1000 шагов, а не за 10. Иногда это даёт выигрыш по времени вычисления, иногда нет. Знаю таких физиков, в расчётах которых GPU крайне неэффективны. То есть, если сравнивать тупой алгоритм на CPU и тупой на GPU, то GPU всех рвёт, как тузик грелку. Но если на CPU запускать «умный» алгоритм, то он сходится в 100 раз быстрее.
А, я понял: каждый параграф — это аналог большшой многооперандной команды (~= подпрограммы на внутреннем языке микропрограмм), и критерием разбиения на параграфы является отсутствие между параграфами «промежуточных» результатов, передаваемых мимо регистров или памяти. Ну, тогда что — получается, в отношении арихитектуры, «растащили уровень между соседними», как это делается при рефакторинге кода с избыточными промежуточными уровнями абстракций. И «атомом» выполнения является не команда, как у нормальных процессоров, а параграф, между параграфами содержимое коммутатора считай что стирается.
Ну тогда на межпараграфном уровне возможны и многопоточность и многопроцессность, правда цена прерывания будет очевидно высокой, но, если считать с точки зрения уровня микропрограмм, всё равно несколько ниже, чем у традиционных процессоров, просто тут она не скрыта, а очевидна.
Ну тогда на межпараграфном уровне возможны и многопоточность и многопроцессность, правда цена прерывания будет очевидно высокой, но, если считать с точки зрения уровня микропрограмм, всё равно несколько ниже, чем у традиционных процессоров, просто тут она не скрыта, а очевидна.
В общем, в качестве специализированного немногопоточного сопроцессора (для спецустройств) покатит…
CUDA тоже не многопроцессная и не многопоточная ;-)
Спасибо за достаточно развернутый и популярный комментарий начинки этого мультиклета. Осталось непонятным: у него один коммутатор (тогда никакой надежности, увы) или одноранговое кольцо коммутаторов?
И еще, раз у вас есть компиллятор C, вы уже дошли до стадии, когда можно запустить Atlas и проверить производительность матричных умножений?
И еще, раз у вас есть компиллятор C, вы уже дошли до стадии, когда можно запустить Atlas и проверить производительность матричных умножений?
Ну. Теоретически дошли. Но практически, надо как-то так собрать этот Atlas, чтобы он влез в небольшую память. Да ещё и умножать придётся матрицы размером в несколько килобайт. Насколько это актуально?
Да, есть класс вычислительных задач (например, методы конечных элементов, у химиков DFT) где плотные матрицы небольшого размера. Для универсальности представьте себе разреженно-блочную матрицу с относительно небольшими плотными блоками. Разреженная матрица будет большая, но очередь умножений ее плотных блоков можно разрезать на куски небольшого размера. Если есть техническая возможность такой кусок данных быстро закачать в память мультиклета, там быстро умножить и быстро же вернуть обратно, то да, может быть актуально. Еще лучше, если мультиклет будет жить в одном адресном пространстве с основной памятью, тогда не придется копировать данные туда-сюда, как в современных GPU.
А вот пример реального кода, где используют маленькие матрицы, даже специальный аналог атласа написали для очень маленьких матриц:
www.hector.ac.uk/cse/distributedcse/reports/cp2k03/cp2k03/node9.html
Фактически этот код — месиво из bash'евских скриптов и фортранного кода. Они автоматически генерят кучу версий фортранных матричных умножателей для всех комбинаций размеров двух матриц с разными способами развернуть циклы — и проверяют, какая версия работает быстрее. В конечном итоге их аналог dgemm'а выглядит так:
— если надо умножить матрицы [1 x 3] * [3 x 4], вызываем multiply1x3x3x4
— если надо умножить матрицы [2 x 3] * [3 x 4], вызываем multiply2x3x3x4
…
В моем текущем проекте (Nektar++) маленькие матрицы тоже актуальны.
А вот пример реального кода, где используют маленькие матрицы, даже специальный аналог атласа написали для очень маленьких матриц:
www.hector.ac.uk/cse/distributedcse/reports/cp2k03/cp2k03/node9.html
Фактически этот код — месиво из bash'евских скриптов и фортранного кода. Они автоматически генерят кучу версий фортранных матричных умножателей для всех комбинаций размеров двух матриц с разными способами развернуть циклы — и проверяют, какая версия работает быстрее. В конечном итоге их аналог dgemm'а выглядит так:
— если надо умножить матрицы [1 x 3] * [3 x 4], вызываем multiply1x3x3x4
— если надо умножить матрицы [2 x 3] * [3 x 4], вызываем multiply2x3x3x4
…
В моем текущем проекте (Nektar++) маленькие матрицы тоже актуальны.
Спасибо за информацию. Сейчас как раз стоит вопрос о тестировании и отладке производительности и нужно понять, на каких алгоритмах это нужно делать. Ваша информация очень полезна.
Ну вот я бы на этот процессор стал бы смотреть, если доступны тесты следующего (в порядке важности):
— плотные матричные умножения, выполненные в технике Libsmm по ссылке выше (классический Atlas, OpenBLAS etc чхать на малые матрицы хотели, а Libsmm дает до 50-кратного прироста против OpenBLAS). Интересуют матрично-матричные и матрично-векторные.
— разреженные матричные умножения (CSR), блочно-разреженные форматы (посмотрите, например OSKI) — последние часто сводят к очереди умножений плотных блоков, а их можно выполнять вызовами к аналогу Libsmm.
— preconditioned conjugate gradient: достаточно хотя бы диагонального прекондишинера. Интересуют матрицы (в порядке приоритета): плотные, разреженные, блочно-диагональные с плотными и разреженными блоками.
— Lanczos algorithm
— факторизация холеского для плотных и разреженных матриц.
— решение треугольных систем (результат матричной факторизации): плотные, разреженные.
— очень хорошо, если оказывается, что железяка быстро в железе вычисляет корни, синусы и прочее трансцендентное (будут очень рады спец-функциям). Без хотя бы корня в железе вас сразу классифицируют в общий ряд с arduino. Вот еще типичное обсуждение (http://software.intel.com/en-us/forums/topic/277543).
— очень хорошо, если понятно как процессор справляется с относительно случайным доступом в память, например когда бежит по графу. Непрямо на это будет указывать производительность в разреженной алгебре, но спецов по графам это не очень устроит. Если у вас получится скомпиллировать Metis, это будет прорыв.
— ньютоновский градиентный спуск, с разреженной и плотной матрицей. Тот же interior point method формирует блочную матрицу, где есть много нулевых блоков, просто плотной матрицей не обойдетесь.
Для всего этого зоопарка — шкалируемость производительности с числом клеток, оценка GFLOPS и memory bandwidth как функция размера задачи. Ведь ваша главная продажная ценность — «оно само распараллеливает, программисту на С ничего делать не надо». Никакого OpenMP, MPI… Так же очень хорошо, если доступна статистика внутренних счетчиков по классификации PAPI.
Разреженный BLAS нельзя тестировать на случайных матрицах, все на этом обжигаются. Разница в производительности (!) простого матрично-векторного умножения может отличаться в разы в зависимости от структуры разреженности. Всегда берите несколько матриц из реальных задач, часто берут из matrixmarket'а.
— плотные матричные умножения, выполненные в технике Libsmm по ссылке выше (классический Atlas, OpenBLAS etc чхать на малые матрицы хотели, а Libsmm дает до 50-кратного прироста против OpenBLAS). Интересуют матрично-матричные и матрично-векторные.
— разреженные матричные умножения (CSR), блочно-разреженные форматы (посмотрите, например OSKI) — последние часто сводят к очереди умножений плотных блоков, а их можно выполнять вызовами к аналогу Libsmm.
— preconditioned conjugate gradient: достаточно хотя бы диагонального прекондишинера. Интересуют матрицы (в порядке приоритета): плотные, разреженные, блочно-диагональные с плотными и разреженными блоками.
— Lanczos algorithm
— факторизация холеского для плотных и разреженных матриц.
— решение треугольных систем (результат матричной факторизации): плотные, разреженные.
— очень хорошо, если оказывается, что железяка быстро в железе вычисляет корни, синусы и прочее трансцендентное (будут очень рады спец-функциям). Без хотя бы корня в железе вас сразу классифицируют в общий ряд с arduino. Вот еще типичное обсуждение (http://software.intel.com/en-us/forums/topic/277543).
— очень хорошо, если понятно как процессор справляется с относительно случайным доступом в память, например когда бежит по графу. Непрямо на это будет указывать производительность в разреженной алгебре, но спецов по графам это не очень устроит. Если у вас получится скомпиллировать Metis, это будет прорыв.
— ньютоновский градиентный спуск, с разреженной и плотной матрицей. Тот же interior point method формирует блочную матрицу, где есть много нулевых блоков, просто плотной матрицей не обойдетесь.
Для всего этого зоопарка — шкалируемость производительности с числом клеток, оценка GFLOPS и memory bandwidth как функция размера задачи. Ведь ваша главная продажная ценность — «оно само распараллеливает, программисту на С ничего делать не надо». Никакого OpenMP, MPI… Так же очень хорошо, если доступна статистика внутренних счетчиков по классификации PAPI.
Разреженный BLAS нельзя тестировать на случайных матрицах, все на этом обжигаются. Разница в производительности (!) простого матрично-векторного умножения может отличаться в разы в зависимости от структуры разреженности. Всегда берите несколько матриц из реальных задач, часто берут из matrixmarket'а.
Предложенные тесты с матричными умножениями постараемся реализовать, ну и остальные посмотрим, корень в железе имеется.
Раз уже вы в теме бенчмарков, то не подскажете что использовать для теста самого разного железа.
От простеньких risc, до топовых x86-процов и powerX?
Dhrystone сильно привязан к компиляторам, точнее к оптимизациям.
Linpack не пойдет — не везде даже есть FPU, не говоря уже у flops'ах с double.
Памяти в принципе можно подцепить много через прокси, но не все процы могут её полностью адресовать, поэтому тоже разумные лимиты нужны.
От простеньких risc, до топовых x86-процов и powerX?
Dhrystone сильно привязан к компиляторам, точнее к оптимизациям.
Linpack не пойдет — не везде даже есть FPU, не говоря уже у flops'ах с double.
Памяти в принципе можно подцепить много через прокси, но не все процы могут её полностью адресовать, поэтому тоже разумные лимиты нужны.
Ну дык зависит от того, производительность чего вы хотите узнать. Какая у вас задача?
Возможно я не умею такие бенчмаркинги готовить (да и никогда не пытался, пока), но доверия им априори никакого. Вот скажет мне Linpack конкретную циферку в гигафлопсах — и как мне ее натягивать на мою задачу? Только если бенчмаркинг указывает на производительность того самого вычислительного фрагмента, на который моя задача села.
К тому же, железо без компиллятора вы все-равно ж не протестируете? Так что увы, в общем случае мой ответ — магия поиска оптимальных настроек у наилучших компилляторов для каждой платформы для конкретного микробенчмаркинга.
Возможно я не умею такие бенчмаркинги готовить (да и никогда не пытался, пока), но доверия им априори никакого. Вот скажет мне Linpack конкретную циферку в гигафлопсах — и как мне ее натягивать на мою задачу? Только если бенчмаркинг указывает на производительность того самого вычислительного фрагмента, на который моя задача села.
К тому же, железо без компиллятора вы все-равно ж не протестируете? Так что увы, в общем случае мой ответ — магия поиска оптимальных настроек у наилучших компилляторов для каждой платформы для конкретного микробенчмаркинга.
Просто для информации.
Типа вот этот проц настолько крут, а вот этот — крут в 2 раза меньше.
Тупо синтетика, поэтому условные «гигафлопсы» вполне интересны.
> К тому же, железо без компиллятора вы все-равно ж не протестируете?
Ну в принципе да, поэтому Dhrystone пока впереди в моём чарте.
Типа вот этот проц настолько крут, а вот этот — крут в 2 раза меньше.
Тупо синтетика, поэтому условные «гигафлопсы» вполне интересны.
> К тому же, железо без компиллятора вы все-равно ж не протестируете?
Ну в принципе да, поэтому Dhrystone пока впереди в моём чарте.
Судя по беседе, вам приходится работать с большим зоопарком железа? Значит, скорее всего у вас не расчеты. Скажите хоть ваш класс задач.
Дык и крутизна ведь разная в разных задачах. Возьмете задачи, где данные лежат плотно и подряд (плотная линейная алгебра, dgemm-constraint), там нужно чтоб числомолотилка побыстрее. Возьмете задачи, где данные разреженные (разреженная алгебра, графы etc), там доступ к памяти и производительность подсистемы кэша становится важнее.
Вот например мой лаптоп на i7 выдает в максимуме на dgemm (OpenBLAS, одна нить) около 20 гигафлоп, но производительность аналога dgemv от Libsmm (выше упоминал) на маленьких матрицах от 2 до 6-7 гигафлоп в зависимости от размера. Отсюда, производительность разреженной алгебры этими 2-7 гигафлопами и ограничена. Мультиклет вон там в каких-то задачах в одинарной точности выдает чуть больше 2 гигафлопов. Получается, мультиклет сравним с i7? Если окажется, что разреженная алгебра на нем считается на полной скорости, то да, сравним (что вряд ли, но кто знает). А учитывая проблемы распараллеливания, OpenMP, false sharing etc на всех нынешних CPU, может быть и круче (что опять же вряд ли, но кто знает).
Так что линпак прекрасен, но только для плотной алгебры, а это очень узкая ниша. В Dhrystone не вглядывался, надо будет посмотреть что там.
Дык и крутизна ведь разная в разных задачах. Возьмете задачи, где данные лежат плотно и подряд (плотная линейная алгебра, dgemm-constraint), там нужно чтоб числомолотилка побыстрее. Возьмете задачи, где данные разреженные (разреженная алгебра, графы etc), там доступ к памяти и производительность подсистемы кэша становится важнее.
Вот например мой лаптоп на i7 выдает в максимуме на dgemm (OpenBLAS, одна нить) около 20 гигафлоп, но производительность аналога dgemv от Libsmm (выше упоминал) на маленьких матрицах от 2 до 6-7 гигафлоп в зависимости от размера. Отсюда, производительность разреженной алгебры этими 2-7 гигафлопами и ограничена. Мультиклет вон там в каких-то задачах в одинарной точности выдает чуть больше 2 гигафлопов. Получается, мультиклет сравним с i7? Если окажется, что разреженная алгебра на нем считается на полной скорости, то да, сравним (что вряд ли, но кто знает). А учитывая проблемы распараллеливания, OpenMP, false sharing etc на всех нынешних CPU, может быть и круче (что опять же вряд ли, но кто знает).
Так что линпак прекрасен, но только для плотной алгебры, а это очень узкая ниша. В Dhrystone не вглядывался, надо будет посмотреть что там.
На самом деле всё проще.
Если найду одну очень редкую железку, то напишу цикл статей про развитие архитектуры.
И собственно для наглядности было бы здорово отслеживать рост производительности со временем. Хотя бы синтетическую.
Причём архитектура металась по разным направлениям, в том числе и очень экзотичным (конвейер процессора разделенный физически на 2 чипа, к примеру).
Это больше хобби чем работа.
Если найду одну очень редкую железку, то напишу цикл статей про развитие архитектуры.
И собственно для наглядности было бы здорово отслеживать рост производительности со временем. Хотя бы синтетическую.
Причём архитектура металась по разным направлениям, в том числе и очень экзотичным (конвейер процессора разделенный физически на 2 чипа, к примеру).
Это больше хобби чем работа.
А вы SPEC щупали?
Да. Есть 2 проблемы.
1. Не всегда есть Си-компилятор под платформу! Например, присутствует только Ada, да и то на VAX-машине под каким-нибудь VAX/VMS. Я, наверно, буду год только адаптировать код SPEC'a к ассемблеру целевой машины.
2. Время работы CINT2000 (даже не CINT2006) даже у меня на современном железе занимает пару десятков минут. Сколько месяцев я буду ждать на железе 20-летней давности? :)
Dhrystone довольно прост, поэтому портировать его можно за 2-3 дня, плюс столько же на архитектурные оптимизации. Выполняется тоже быстро. В общем, пока аналога не вижу.
1. Не всегда есть Си-компилятор под платформу! Например, присутствует только Ada, да и то на VAX-машине под каким-нибудь VAX/VMS. Я, наверно, буду год только адаптировать код SPEC'a к ассемблеру целевой машины.
2. Время работы CINT2000 (даже не CINT2006) даже у меня на современном железе занимает пару десятков минут. Сколько месяцев я буду ждать на железе 20-летней давности? :)
Dhrystone довольно прост, поэтому портировать его можно за 2-3 дня, плюс столько же на архитектурные оптимизации. Выполняется тоже быстро. В общем, пока аналога не вижу.
снимаю шляпу перед мастером. И часто вам попадаются машины на VAX? Во время своего студенчества на кафедре теории функций стоял к тому времени уже устаревший сановский спарк, уже не помню какой номер. Все хотелось его попробовать, но не дали доступа. А сейчас его уже наверное и нет там.
Несколько десятков минут на современном железе? Это быстро :)
Как вы на старом железе решаете проблему тестов, кушающих память не в себя?
Несколько десятков минут на современном железе? Это быстро :)
Как вы на старом железе решаете проблему тестов, кушающих память не в себя?
> И часто вам попадаются машины на VAX?
Не особо, VAX меня не очень интересовал, но пару раз доводилось поиграться с ним.
> устаревший сановский спарк, уже не помню какой номер.
Я помню лет 7 назад у нас в городе распродавали как раз спарки, причём по ценам чуть ли не новых. Потом связывался с человеком, оказалось что никто не купил и они их тупо выбросили.
> Как вы на старом железе решаете проблему тестов, кушающих память не в себя?
ээ, а куда?
Тесты всё равно приходится адаптировать, поэтому часть проблем решается, а-ля доступ к ф/c, чего часто может и не быть.
RAM иногда бывает маловато. но минимум 4Kb. (Для Dhrystone хватает, кстати).
Не особо, VAX меня не очень интересовал, но пару раз доводилось поиграться с ним.
> устаревший сановский спарк, уже не помню какой номер.
Я помню лет 7 назад у нас в городе распродавали как раз спарки, причём по ценам чуть ли не новых. Потом связывался с человеком, оказалось что никто не купил и они их тупо выбросили.
> Как вы на старом железе решаете проблему тестов, кушающих память не в себя?
ээ, а куда?
Тесты всё равно приходится адаптировать, поэтому часть проблем решается, а-ля доступ к ф/c, чего часто может и не быть.
RAM иногда бывает маловато. но минимум 4Kb. (Для Dhrystone хватает, кстати).
В своей статье я писал почему мультиклет не сравним с i7.
Ваши бенчмарки меряют реальную производительность на 64-х битных вещественных числах, с учетом потерь от скорости доступа к медленной большой памяти.
А у мультиклета только 32-х битная арифметика (0.4-0.8GLOPS, 2.4 на редкой экзотике), и никакой внешней памяти нет.
Ваши бенчмарки меряют реальную производительность на 64-х битных вещественных числах, с учетом потерь от скорости доступа к медленной большой памяти.
А у мультиклета только 32-х битная арифметика (0.4-0.8GLOPS, 2.4 на редкой экзотике), и никакой внешней памяти нет.
как раз поэтому я говорил «что вряд ли, но кто знает» :)
насчет памяти не совсем так. На небольших размерах матриц (например: 4х4) все укладывается в кэш и значит мы сравниваем чистую производительность i7 с его кэшем (а то и регистровым файлом) против мультиклета и его кэшем. Или что у него там — я не очень понял, есть ли кэш, как далеко расположена внешняя память (см. задержку) и какая разница в частотах между памятью и процессором.
В предыдущем каменте я скорее ставил задачу рассказать, что на разреженной (разреженно-блочной) алгебре и маленьких матрицах пиковая достижимая производительность в разы ниже таковой для плотной алгебры, по крайней мере для i7. Который не может взять и на ходу распараллелить вычисление. Ну и «сравним» для меня это разница в один порядок: 0.4 GFLOPS (multiclet, float32) vs 4 GFLOPS (i7, float64) — ну, по крайней мере есть что сравнивать, особенно учитывая разницу в частотах и несравнимый уровень вылизанности технологии у Intel.
насчет памяти не совсем так. На небольших размерах матриц (например: 4х4) все укладывается в кэш и значит мы сравниваем чистую производительность i7 с его кэшем (а то и регистровым файлом) против мультиклета и его кэшем. Или что у него там — я не очень понял, есть ли кэш, как далеко расположена внешняя память (см. задержку) и какая разница в частотах между памятью и процессором.
В предыдущем каменте я скорее ставил задачу рассказать, что на разреженной (разреженно-блочной) алгебре и маленьких матрицах пиковая достижимая производительность в разы ниже таковой для плотной алгебры, по крайней мере для i7. Который не может взять и на ходу распараллелить вычисление. Ну и «сравним» для меня это разница в один порядок: 0.4 GFLOPS (multiclet, float32) vs 4 GFLOPS (i7, float64) — ну, по крайней мере есть что сравнивать, особенно учитывая разницу в частотах и несравнимый уровень вылизанности технологии у Intel.
Не. Ну как 100MHz процессор может быть сравним с 1.7GHz-овым? Нет, конечно, не будет такого. В лучшем случае можно будет говорить об удельной производительности на MHz, как о показателе эффективности архитектуры, а не конкретной модели процессора.
из вот этого комментария: "«сравним» для меня это разница в один порядок: 0.4 GFLOPS (multiclet, float32) vs 4 GFLOPS (i7, float64) — ну, по крайней мере есть что сравнивать, особенно учитывая разницу в частотах и несравнимый уровень вылизанности технологии у Intel."
Собственно, ради подобного сравнения, но с реальными чиселками, я исходный вопрос и задавал. Надежду, кроме разницы в частотах, питает то, что у мультиклета (точнее, качества вашего компиллятора) может оказаться лучшая шкалируемость на клетки по сравнению со шкалируемостью на различные x86 ядра. Тут для оценок вообще никаких данных не хватает: что с кэшем, насколько эффективно клетки обращаются к близко расположенным данным и так далее. Так что пока — гадание на кофейной гуще. Пока вы с коллегой тесты не прогоните ну или хотя бы детально модель внутренностей не расскажете, в терминах задержек каждой операции в числе тактов, длинне конвейеров и т.п.
Собственно, ради подобного сравнения, но с реальными чиселками, я исходный вопрос и задавал. Надежду, кроме разницы в частотах, питает то, что у мультиклета (точнее, качества вашего компиллятора) может оказаться лучшая шкалируемость на клетки по сравнению со шкалируемостью на различные x86 ядра. Тут для оценок вообще никаких данных не хватает: что с кэшем, насколько эффективно клетки обращаются к близко расположенным данным и так далее. Так что пока — гадание на кофейной гуще. Пока вы с коллегой тесты не прогоните ну или хотя бы детально модель внутренностей не расскажете, в терминах задержек каждой операции в числе тактов, длинне конвейеров и т.п.
С памятью и кэшами в MCp, скорее всего, тоже всё будет необычно. В текущих моделях для встраиваемых применений, вся память на борту, работает за один такт, позволяет, при удачном раскладе, 4 операции одновременно. Собственно и все другие операции однотактовые. Частота позволяет. Но это сейчас. Дальнейшая архитектура обсуждается.
а сколько тактов занимает одна операция умножения? Fused multiply-add есть? Как себя ведут клетки, когда пытаются читать/записать в одну ячейку памяти?
Тоже один такт (частота-то небольшая и «всего» 32-бита). FMA есть в виде команды madd, которая считает скалярное произведение двух 2-компонентных векторов: madd A, B. Если A = (a1, a2), B = (b1, b2), то выдаётся a1 * b1 + a2 * b2. При помощи команды patch можно достаточно свободно управлять содержимым вторых компонент.
ПРо ячейку памяти забыл! Что ж такое-то!? Прошу прощения. Итак. Сама ISA процессора предполагает. что в этой ситуации будет исполнена только одна операция, которой повезёт больше. И так можно поступать, потому что существует способ явно выразить упорядоченность записей в одну и ту же ячейку через разбиение на параграфы.
честно говоря, я мало что понял. Не могли бы вы чуть подробнее рассказать, что происходит с разделением доступа к ячейкам памяти одной команды скалярного произведения между параграфами?
Если не ошибаюсь, код там пока что без многопоточности.
Поскольку очередь команд одна, конфликтов доступа нет.
А распараллеливание происходит самим процессором при выполнении, по зависимостям входных данных инструкций.
Поскольку очередь команд одна, конфликтов доступа нет.
А распараллеливание происходит самим процессором при выполнении, по зависимостям входных данных инструкций.
Эмс… Вопрос не очень понятен. Команда скалярного произведения, она одна. То есть, она целиком выполняется в рамках одного параграфа. И она не работает непосредственно с памятью.
Для инструкций работы с памятью (и регистрами) действует такое правило: внутри параграфа они никак не упорядочиваются, а исполняют по готовности. Если, например, будет две таких команды:
То их упорядоченность никак не гарантируется. Сработают обе, но в неизвестном заранее порядке (он известен, конечно, на уровне аппаратуры, но не программисту).
Гарантируется только то, что все операции доступа к памяти и RF в следующем параграфе начнут выполнятся после завершения всех операций с памятью и RF в параграфе предыдущем.
Для инструкций работы с памятью (и регистрами) действует такое правило: внутри параграфа они никак не упорядочиваются, а исполняют по готовности. Если, например, будет две таких команды:
...
wrf @1, A
wrf @2, A
...
То их упорядоченность никак не гарантируется. Сработают обе, но в неизвестном заранее порядке (он известен, конечно, на уровне аппаратуры, но не программисту).
Гарантируется только то, что все операции доступа к памяти и RF в следующем параграфе начнут выполнятся после завершения всех операций с памятью и RF в параграфе предыдущем.
В описании вроде ещё есть бит RW в регистре управления PSW — он гарантирует выполнение команд записи только после команд чтения. Т. е. очерёдность с зависимыми данными будет соблюдаться.
В моем предыдущем комментарии я пытался суммировать свое понимание вашего же описания работы с ячейкой памяти и скалярным умножением. Как вы можете увидеть, получилась полная лажа, я ничего не понял. И по прежнему не понимаю. Но вы лучше сейчас не тратьте время в каментах, а напишите еще хотя бы одну статью, взяв некоторый вычислительный алгоритм и разложив процесс его выполнения на мультиклетный ассемблер и пару возможных сценариев выполнения (у вас же не гарантируется определенный порядок выполнения? Значит возможны по крайней мере два).
О, забавно, я тоже исходно из Кр-ска — посмотрел к вам в профиль.
Недавно наткнулся на STREAM benchmark, писан на фортране и С, и подумал, может вы тоже не встречали. Или?
Про коммутатор забыл сказать. Коммутатор может быть тоже дублированный или троированный. Это простая схема без своих внутренних состояний, которая расслылает результаты вычислений. Такие рассылатели могут быть продублированы, собраны в кольцо, или из них можно построить fat-tree сеть. Для самих клеток и для ABI это не важно. Будут лишь разные показатели у этих решений по производительности, надёжности и стоимости.
Непонятно что делать с этим процессором. Памяти мало. Периферия микроконтроллерная.
Сильно не разпрограммируешься.
Пока дешевле использовать Atmel.
Сильно не разпрограммируешься.
Пока дешевле использовать Atmel.
UFO just landed and posted this here
Спасибо за шикарный и развёрнутый пост. Он наконец-то расставил все точки над i!
А то холивар в прошлом посте был просто чудовищный, и самое ужасное что люди спорят и ничего не понимают.
А то холивар в прошлом посте был просто чудовищный, и самое ужасное что люди спорят и ничего не понимают.
И Firefox OS на него портировать…
Будет здорово, если MCp выйдет на рынок и составит конкуренцию Cortex'у. Может быть, даже имеет смысл не только выпускать свои процессоры самостоятельно, но и лицензировать, чтобы другие могли делать свои процессоры на базе вашей архитектуры.
Жду вскоре поста про реальные применения, как варианты: контроллер квадрокоптера, умный дом с веб-сервером, контроллер WiFi роутера и т.п.
Кстати, если говорить о встроенных применениях — как осуществлять дебаг этого устройства, есть какие-то тонкости, учитывая многоклеточность, относительно традиционных микроконтроллеров?
Всё-таки не хотелось бы, чтобы процессор так и почил в закрытых военных применениях. Удачи вам!
Жду вскоре поста про реальные применения, как варианты: контроллер квадрокоптера, умный дом с веб-сервером, контроллер WiFi роутера и т.п.
Кстати, если говорить о встроенных применениях — как осуществлять дебаг этого устройства, есть какие-то тонкости, учитывая многоклеточность, относительно традиционных микроконтроллеров?
Всё-таки не хотелось бы, чтобы процессор так и почил в закрытых военных применениях. Удачи вам!
Круто!
Не ожидал от себя, что пойму: ассемблер последний раз видел много лет назад.
Многоклеточный, говорите? :)
Вообще распределенные системы меня удивляют очень сильно. Как из набора довольно простых звеньев в результате получается сложнофункциональная система. Очень интересный тренд. И, думаю, многообещающий.
Не ожидал от себя, что пойму: ассемблер последний раз видел много лет назад.
Многоклеточный, говорите? :)
Вообще распределенные системы меня удивляют очень сильно. Как из набора довольно простых звеньев в результате получается сложнофункциональная система. Очень интересный тренд. И, думаю, многообещающий.
На днях я тут был на симпозиуме техническом организованном ARM. Там были практически все представители экосистемы ARM, все основные игроки кто что-то на их основе делает на рынке сейчас.
Меня интересовали тренды по много-ядерности-процессности, всякие там OpenCL на армовских чипах, энергопотребление и прочее. К тому же, так как я там был по работе, то меня интересовали вопросы секурности. Впрочем, с секурностью как правило у всех всё очень плохо обстоит…
Так вот, если вы ребята доведёте эту мультиклеточную архитектуру до ума, то будет настоящая революция. Традиционная не-параллельная обработка подошла сейчас к своему пределу, бизнесу нужны параллельные вычисления, причём очень так нехило нужны. Интел вообще похоже не способен изобрести что-то новое, его огонь угасает. У ARM все эти костыли типа neon и пр — скорее маркетинг, но в ARM сидят не дураки и они прекрасно понимают куда дует ветер сейчас. Но вот то что они делают с Mali — конечно очень жаль. Копируют то, что есть на рынке, причём плохо.
Складывается впечатление что они конечно подняли свою экосистему за счёт мобильных девайсов, но похоже стали её заложниками. Они рассказывали на этом мероприятии о том как им удалось там всё заоптимизировать и понизить энергопотребление, но… чёрт побери, они топчутся на месте на мой взгляд. В своё время я надеялся что у них получится сделать больше чем то что мы видим сейчас.
Поэтому очень здорово что всё-таки есть люди, не скованные всей этой догматикой, люди способные создать что-то по-настоящему новое. Браво!
У меня просьба к автору — обязательно пишите новости по этой теме. Мне было необычайно интересно вас читать, у вас это получается. И тема мне близка и весьма интересна…
Спасибо за хорошую статью :)
Меня интересовали тренды по много-ядерности-процессности, всякие там OpenCL на армовских чипах, энергопотребление и прочее. К тому же, так как я там был по работе, то меня интересовали вопросы секурности. Впрочем, с секурностью как правило у всех всё очень плохо обстоит…
Так вот, если вы ребята доведёте эту мультиклеточную архитектуру до ума, то будет настоящая революция. Традиционная не-параллельная обработка подошла сейчас к своему пределу, бизнесу нужны параллельные вычисления, причём очень так нехило нужны. Интел вообще похоже не способен изобрести что-то новое, его огонь угасает. У ARM все эти костыли типа neon и пр — скорее маркетинг, но в ARM сидят не дураки и они прекрасно понимают куда дует ветер сейчас. Но вот то что они делают с Mali — конечно очень жаль. Копируют то, что есть на рынке, причём плохо.
Складывается впечатление что они конечно подняли свою экосистему за счёт мобильных девайсов, но похоже стали её заложниками. Они рассказывали на этом мероприятии о том как им удалось там всё заоптимизировать и понизить энергопотребление, но… чёрт побери, они топчутся на месте на мой взгляд. В своё время я надеялся что у них получится сделать больше чем то что мы видим сейчас.
Поэтому очень здорово что всё-таки есть люди, не скованные всей этой догматикой, люди способные создать что-то по-настоящему новое. Браво!
У меня просьба к автору — обязательно пишите новости по этой теме. Мне было необычайно интересно вас читать, у вас это получается. И тема мне близка и весьма интересна…
Спасибо за хорошую статью :)
Какой GPU, кстати, лучше — Mali или Vivante?
На мой взгляд, Mali посолиднее будет. Но в лидерах сейчас всякие Imagination конечно.
Mali только в последней линейке T600 вышел на более-менее нормальный уровень, топовый GPU T678 даже говорят догнал PowerVR и только-только стал юзабельным.
Суть не в этом — все повязаны патентами и догмами, копируют друг у друга, а реально свежих подходов ни у кого толком нет. Эх, вот взять бы да все патенты и отменить! (с)
На этом фоне мультиклеты — действительно здорово.
Mali только в последней линейке T600 вышел на более-менее нормальный уровень, топовый GPU T678 даже говорят догнал PowerVR и только-только стал юзабельным.
Суть не в этом — все повязаны патентами и догмами, копируют друг у друга, а реально свежих подходов ни у кого толком нет. Эх, вот взять бы да все патенты и отменить! (с)
На этом фоне мультиклеты — действительно здорово.
Я вот пытаюсь найти какую-то информацию об этом, может у вас понимание есть: у ARM'ов их графпроцессоры в принципе возможно нагрузить GPGPU? Ведь в отличие от Nvidia etc у них графпроцессор живет в том же адресном пространстве, что и сам CPU, за счет чего нет необходимости долго и мучительно копировать данные туда-сюда? Если я что-то путаю, поправьте плиз. Если на этом Mali можно запустить GPGPU счет — это будет нечто.
OpenCL в Mali поддерживается только начиная с T6xx, это подтвердил их разработчик, делавший презентацию. Кстати именно он и руководит разработкой Mali у них, толковый парень.
Собственно для GPGPU они и продвигают эту линейку — там был стенд где показывали работу десятка специальных карт-числодробилок воткнутых в какую-то материнку. Всё чин чином, энергопотребление небольшое, можно вживую «потрогать руками», а гигафлопсы на графике большущие.
Был слайд где они хвастались что при том же тепловыделении они вдвое быстрее чем существующие решения от нвидии и ко. Полагаю что там конечто что-то подкручено, но всё равно похоже на правду, да и это только начало.
На consumer девайсах на андроиде сейчас есть Renderscript — это тот же OpenCL один в один, только на яве. Так что можно запустить счёт и на таблетке…
Ну а про копировние данных — думаю без этого не обойтись, в OpenCL же юниты, коры и тп. Постоянное прокачивание данных — это та ложка дёгтя, что есть в OpenCL.
Собственно для GPGPU они и продвигают эту линейку — там был стенд где показывали работу десятка специальных карт-числодробилок воткнутых в какую-то материнку. Всё чин чином, энергопотребление небольшое, можно вживую «потрогать руками», а гигафлопсы на графике большущие.
Был слайд где они хвастались что при том же тепловыделении они вдвое быстрее чем существующие решения от нвидии и ко. Полагаю что там конечто что-то подкручено, но всё равно похоже на правду, да и это только начало.
На consumer девайсах на андроиде сейчас есть Renderscript — это тот же OpenCL один в один, только на яве. Так что можно запустить счёт и на таблетке…
Ну а про копировние данных — думаю без этого не обойтись, в OpenCL же юниты, коры и тп. Постоянное прокачивание данных — это та ложка дёгтя, что есть в OpenCL.
Ага, википедия говорит, только в самсунговских Exynos 5 есть Mali T6xx. А эти самсунги вроде как не добры к линуксу.
То что вы рассказываете звучит здорово, в перспективе. Я сейчас купил андроидную приставку к телевизору на RK3066, с целью погонять на нем линукс и проверить производительность в расчетах. Ну и думал, что может есть способ граф. процессор завести. Похоже, не судьба — там только Mali 400 (OpenVG, OpenGL). А вот ява на таком маленьком устройстве меня совсем не радует.
То что вы рассказываете звучит здорово, в перспективе. Я сейчас купил андроидную приставку к телевизору на RK3066, с целью погонять на нем линукс и проверить производительность в расчетах. Ну и думал, что может есть способ граф. процессор завести. Похоже, не судьба — там только Mali 400 (OpenVG, OpenGL). А вот ява на таком маленьком устройстве меня совсем не радует.
Да, к сожалению на 400-тых мали посчитать не получится.
Недавно ко мне тут приезжал коллега, рассказывал что мучается тоже с Exynos 5, хочет сейчас перейти на другой чип посвежее, но пока не определился, ищет.
Да и нет ничего толкового ещё на 600-тых.
А самсунги совсем испортились. Мы у них чипы заказывали одно время, а они потом сказали что больше не будут мелочью заниматься и сняли их с производства. Хоть бы предупредили… Я бы вообще сказал, что они стали очень похожи на Apple, сидят там себе за закрытыми дверями. Зато они лидеры рынка. Пока что.
В свете последних событий вокруг ихнего Exynos отношение к ним стало меняться в худшую сторону.
От явы на андроиде так просто не уйти, на то он и андроид. Хоть дальвик и заточен хорошо, но и в гиге оперативки иногда бывает ему тесно. Мы на этом добре только пимпочки пишем чтоб юзер пальцами тыкал, а уж крутится всё совсем на другом чипе.
Недавно ко мне тут приезжал коллега, рассказывал что мучается тоже с Exynos 5, хочет сейчас перейти на другой чип посвежее, но пока не определился, ищет.
Да и нет ничего толкового ещё на 600-тых.
А самсунги совсем испортились. Мы у них чипы заказывали одно время, а они потом сказали что больше не будут мелочью заниматься и сняли их с производства. Хоть бы предупредили… Я бы вообще сказал, что они стали очень похожи на Apple, сидят там себе за закрытыми дверями. Зато они лидеры рынка. Пока что.
В свете последних событий вокруг ихнего Exynos отношение к ним стало меняться в худшую сторону.
От явы на андроиде так просто не уйти, на то он и андроид. Хоть дальвик и заточен хорошо, но и в гиге оперативки иногда бывает ему тесно. Мы на этом добре только пимпочки пишем чтоб юзер пальцами тыкал, а уж крутится всё совсем на другом чипе.
Так зачем андроид, если можно линукс :) Правда, у вас там юзер в экран тыкает, да, увы.
А у нас и линукса нет на самом деле :)
Только bare metal, только хардкор!
Зато такая конфетка получается…
Только bare metal, только хардкор!
Зато такая конфетка получается…
А поделитесь ссылкой на проект, пожалуйста. Так, посмотреть на пример игрищ с чистым железом.
Вот тут меня уже спрашивали. Кое-что у нас в железе поменялось, но суть та же.
К сожалению больше подробностей раскрыть не могу, на то есть причины…
PS Проект у нас очень нетипичный, я вас предупредил :)
К сожалению больше подробностей раскрыть не могу, на то есть причины…
PS Проект у нас очень нетипичный, я вас предупредил :)
Отличный у вас проект, по крайней мере не скучно.
В тему, недавно сидел на докладе, парень рассказывал о малоточных вычислениях на встроенных устройствах. Утверждение: считать с малой точностью возможно и очевидно быстрее/энергоэффективнее. Но что принципиально, точность (overflow/underflow) в итеративных алгоритмах типа Lanzcos можно контролировать с помощью очень несложного preconditioner'а. В качестве примера он там приводил эффективную производительность расчета, достигнутую на FPGA — она превышала теоретический предел Nvidia Fermi на порядок или два (правда как сравнивать попугаев разной точности тоже вопрос — число итераций ведь от точности небось зависит). Так что если вам актуально — вот.
В тему, недавно сидел на докладе, парень рассказывал о малоточных вычислениях на встроенных устройствах. Утверждение: считать с малой точностью возможно и очевидно быстрее/энергоэффективнее. Но что принципиально, точность (overflow/underflow) в итеративных алгоритмах типа Lanzcos можно контролировать с помощью очень несложного preconditioner'а. В качестве примера он там приводил эффективную производительность расчета, достигнутую на FPGA — она превышала теоретический предел Nvidia Fermi на порядок или два (правда как сравнивать попугаев разной точности тоже вопрос — число итераций ведь от точности небось зависит). Так что если вам актуально — вот.
Ну а про копировние данных — думаю без этого не обойтись, в OpenCL же юниты, коры и тп. Постоянное прокачивание данных — это та ложка дёгтя, что есть в OpenCL.
Юниты коры и т.п. — это логические сущности, не обязательно им быть реальными в современном железе. АМД, вон, делает OpenCL который может на системах с последними Radeon и IOMMUv2 лазить в системную память с GPU.
И еще, не подскажете, уже есть продаваемые железяки с картами-числодробилками? А то все обещают :)
Вопрос по ассемблеру этой машины: есть ли в свободном доступе таблицы опкодов и описание упаковки полей, упомянутых в manual_soft.pdf:
В мультиклеточном процессоре существуют короткие команды, размерностью 32 бита, и
длинные, размерностью 64 бита. В команде мультиклеточного процессора закодированы:
• код операции, определяющий действие, которое необходимо выполнить процессору;
• суффикс операции, определяющий правила формирования операндов операции;
• тип операции, определяющий размер операндов и интерпретацию их значений;
• набор данных (значение ссылки на результат команды, значение ссылки на регистр,
непосредственное значение) необходимый для формирования операндов;
• прочие данные, необходимые для выполнения операции или действий, связанных с
данной операцией.
Да. Эти таблицы были в прежней версии руководства. Но почему-то их решили заменить на рисунки. Возможно, это связано с тем, что сейчас набор инструкций пересматривается и кодировка будет изменена. В общем, я передам, что двоичное представление инструкций тоже интересно. Там нет ничего секретного
Клёво, спасибо.
Кстати, в мануале ошибки, например в коде сложения 64-разрядных чисел какая-то дикая путаница в строках 22 и 23, должно было быть 22: adcl @5, @3 а строки 23 не должно быть вообще. В связи с этим нотация @x для ссылки на результаты предыдущих команд не совсем удобна: при удалении промежуточных команд нужно пересчитывать смещения. Логично было бы иметь возможность ссылаться на метки, а ассемблер бы уже пересчитывал метки в смещения.
Кстати, в мануале ошибки, например в коде сложения 64-разрядных чисел какая-то дикая путаница в строках 22 и 23, должно было быть 22: adcl @5, @3 а строки 23 не должно быть вообще. В связи с этим нотация @x для ссылки на результаты предыдущих команд не совсем удобна: при удалении промежуточных команд нужно пересчитывать смещения. Логично было бы иметь возможность ссылаться на метки, а ассемблер бы уже пересчитывал метки в смещения.
Ага. Это верно. Последние версии ассемблера уже позволяют именовать ссылки. Там можно так писать:
test:
size1 := getl #0
size1 := getl #1
newsize := addl @1, @2 ; прежний формат тоже сохранён для коротких выражений
value := getl #2
jne @value, start
je @value, stop
complete
Возможно, сам формат описания будет несколько другим, но сама возможность такая останется.
Ну в принципе можем выложить таблицы опкодов, а для чего такие подробности нужны?
— Так проще понять что к чему. Естественные ограничения команд и т.п.
— К тому же дизассемблера у вас вроде нет, по крайней мере в составе SDK.
— К тому же дизассемблера у вас вроде нет, по крайней мере в составе SDK.
ОпКоды можно посмотреть тут rghost.ru/42397209
Спасибо. Непонятны следующие вещи:
— где кодируется формат команды — aa или av?
— где кодируется интерпретация F1/F2 — @s либо #ir?
— где кодируется формат команды — aa или av?
— где кодируется интерпретация F1/F2 — @s либо #ir?
В 24-25 битах, т.е.
Суффикс:
...... 0X — формат AA
...... 00 — F2 содержит адрес коммутатора
...... 01 — F2 содержит номер регистра
Формат AV размер 64 бит. Старшая часть имеет такую же структуру как и формата AA, младшие 32 бита — значение поля V
Суффикс:
...... 0X — формат AA
...... 00 — F2 содержит адрес коммутатора
...... 01 — F2 содержит номер регистра
Формат AV размер 64 бит. Старшая часть имеет такую же структуру как и формата AA, младшие 32 бита — значение поля V
Спасибо.
Я кажется понял, чего ищу: нет ли у вас списка рассылки для разработчиков/иного места где можно получить ответы на подобные вопросы?
Я кажется понял, чего ищу: нет ли у вас списка рассылки для разработчиков/иного места где можно получить ответы на подобные вопросы?
Т. е. я правильно понял, что результаты команд в пределах отдельного параграфа как бы автоматически сохраняются как «локальные переменные», и за счёт этого пропадает необходимость в регистрах общего назначения?
А между параграфами передача данных возможна только через стек / память?
И ещё вопрос, в связи с активной разработкой архитектуры и упоминанием, что набор инструкций пересматривается: последующие версии процессора планируются совместимыми с текущей?
А между параграфами передача данных возможна только через стек / память?
И ещё вопрос, в связи с активной разработкой архитектуры и упоминанием, что набор инструкций пересматривается: последующие версии процессора планируются совместимыми с текущей?
* Извиняюсь, что общие регистры есть, уже нашёл в описании процессора на сайте.
Полной совместимости при выпуске новых версий процессора достичь всё равно не удастся, изменения будут касаться не только системы команд.
Ясно, спасибо. Но в общем, это нормально, учитывая, что для них нет старого софта, который должен работать на новых версиях без перекомпиляции, как с линейкой Intel, например.
Ну даже Intel в случае с Itanium решил от обратной совместимости отойти…
В первую очередь, я об x86 говорил, конечно. Itanium — это, скорее, отдельная линейка процессоров с другой архитектурой, а внутри неё, если не ошибаюсь, потомки тоже совместимы с предыдущими версиями.
Вообще, если в будущем ориентироваться на массовый рынок, где процессоры поставляются отдельно от программ, то обратная совместимость быть должна, хотя бы начиная с какой-то версии.
Иначе невозможно будет обновить процессор, не перекомпилируя при этом весь софт — ОС, программы и т. д. — а ведь исходных кодов у пользователя может и не быть.
Вообще, если в будущем ориентироваться на массовый рынок, где процессоры поставляются отдельно от программ, то обратная совместимость быть должна, хотя бы начиная с какой-то версии.
Иначе невозможно будет обновить процессор, не перекомпилируя при этом весь софт — ОС, программы и т. д. — а ведь исходных кодов у пользователя может и не быть.
Параграф, похоже, следует сопоставлять скорее с одной командой традиционного CPU, а, точнее, с микропрограммой, которая внутри этого CPU её реализует. Тут, похоже, говоря в терминах рефакторинга, «заинлайнили» уровень микропрограмм, получив некоторую «деинкапсуляцию» микропрограмм в качестве неизбежного результата.
Если бы Intel поменял опкоды микропрограмм в новой версии процессора, этого бы никто не заметил — тоже плюс от инкапсуляции. А тут — «кишки наружу». С одной стороны, больше потенциал повышения эффективности, с другой — гимор. Слава Богу, «наследства» для обратной совместимости ещё нет…
Есть подозрение, что обратную совместимость в итоге низведут до уровня «рекомендация — не догма»… Можно будет весь негатив, исходящий из этого, инкапсулировать на уровне компилятора С (или даже «символьного» ассемблера — программы на ассемблере останутся обратно совместимыми) или каких-нибудь managed runtimes.
Если бы Intel поменял опкоды микропрограмм в новой версии процессора, этого бы никто не заметил — тоже плюс от инкапсуляции. А тут — «кишки наружу». С одной стороны, больше потенциал повышения эффективности, с другой — гимор. Слава Богу, «наследства» для обратной совместимости ещё нет…
Есть подозрение, что обратную совместимость в итоге низведут до уровня «рекомендация — не догма»… Можно будет весь негатив, исходящий из этого, инкапсулировать на уровне компилятора С (или даже «символьного» ассемблера — программы на ассемблере останутся обратно совместимыми) или каких-нибудь managed runtimes.
Пройдемся по вашим преимуществам:
Сколько конкретно мВт на Мгц при максимальной нагрузке? Это стандартный тест для сравнения энергоэффективности.
Нет цифры — значит это wishful thinking.
Я правильно понимаю, что это гепотетическая возможность?
Сейчас вы только заканчиваете доведение C компилятора до коммерческого уровня, сколько лет займет реализация компиляторов для этих «безопасных языков программирования»?
Сейчас это поддержано в вашем софте и железе, или это гепотетическая возможность?
Как определять, что одно ядро допустило сбой? А что если сбой в коммуникации ядер? Именно решение этих вопросов и составляет основную сложность устойчивости с сбоям, и даже гепотетического решения я у вас не вижу.
Масштабирование MCp до 4-х ядер уже привело к фатальному провалу производительности из-за вашей архитектуры: 180нм и жалкие 100Мгц.
Процессоры на классических архитектурах на 180нм работают на частотах 800-2000 Мгц.
Я не вижу, каким образом при работе со схемой «все ядра имеют доступ ко всем результатам вычислений» не возникает экспоненциальное падение производительности с ростом ядер. Именно коммуникация ограничивает скорость современных процессоров, а не скорость вычислений.
Сейчас это есть? да/нет
Опять же, вспомним, почему существует SMT? Не потому, что кому-то нравится запускать потоки одновременно, а для того, чтобы скрывать латентность доступа к медленной памяти. Вас эта проблема вообще не касается, ввиду отсутствия внешней памяти. Почему тогда упомянут SMT — не ясно.
По факту, я не вижу ни одного преимущетсва, которое существует сейчас. То что в будущем можно сделать много хорошего — это беспорно. Но интересует, что представляет из себя Мультиклет уже сейчас.
Хорошей энергоэффективностью
Сколько конкретно мВт на Мгц при максимальной нагрузке? Это стандартный тест для сравнения энергоэффективности.
Нет цифры — значит это wishful thinking.
Нестандартная организация ветвлений даёт интересные возможности реализации, так называемых, managed runtime
Я правильно понимаю, что это гепотетическая возможность?
Сейчас вы только заканчиваете доведение C компилятора до коммерческого уровня, сколько лет займет реализация компиляторов для этих «безопасных языков программирования»?
Особенность кодирования программ (подразумевается машинный код) и особенность их исполнения позволяют сделать MCp постепенно деградирующим процессором.
Сейчас это поддержано в вашем софте и железе, или это гепотетическая возможность?
Как определять, что одно ядро допустило сбой? А что если сбой в коммуникации ядер? Именно решение этих вопросов и составляет основную сложность устойчивости с сбоям, и даже гепотетического решения я у вас не вижу.
Ко всему этому MCp ещё относительно легко можно масштабировать (позволял бы техпроцесс)
Масштабирование MCp до 4-х ядер уже привело к фатальному провалу производительности из-за вашей архитектуры: 180нм и жалкие 100Мгц.
Процессоры на классических архитектурах на 180нм работают на частотах 800-2000 Мгц.
Я не вижу, каким образом при работе со схемой «все ядра имеют доступ ко всем результатам вычислений» не возникает экспоненциальное падение производительности с ростом ядер. Именно коммуникация ограничивает скорость современных процессоров, а не скорость вычислений.
и запускать в режиме многопоточности (имеется в виду SMT — Simultaneous Multi Threading) да ещё и с динамическим разделением ресурсов между нитями
Сейчас это есть? да/нет
Опять же, вспомним, почему существует SMT? Не потому, что кому-то нравится запускать потоки одновременно, а для того, чтобы скрывать латентность доступа к медленной памяти. Вас эта проблема вообще не касается, ввиду отсутствия внешней памяти. Почему тогда упомянут SMT — не ясно.
По факту, я не вижу ни одного преимущетсва, которое существует сейчас. То что в будущем можно сделать много хорошего — это беспорно. Но интересует, что представляет из себя Мультиклет уже сейчас.
Посмотрел на ваш сайт и, если честно, у меня возникло странное ощущение. Вроде, человек с вашим уровнем осведомлённости. должен знать ответы на почти все эти вопросы. В связи с этим, у меня возникает вопрос: «почему для вас так важно завалить MCp, словно нелюбимого студента, на экзамене?» :) Ладно. Давненько я не был в роли наглого студента, будет приятно вспомнить молодость.
Пройдемся по вашим преимуществам:
Они не мои, а процессора. Мои преимущества: весёлый характер, добрый нрав, знание 10+ языков программирования, основ теоретический физики и машинного обучения, членство в AAAI, а также неплохая работоспособность :)
Сколько конкретно мВт на Мгц при максимальной нагрузке? Это стандартный тест для сравнения энергоэффективности.
Нет цифры — значит это wishful thinking.
Всё это есть на сайте. Странно, что вы рассмотрели информацию о 180nm, но не заметили, что максимальная нагрузка (это та, которая при комплексном БПФ) достигается на 100MHz при потреблении 1.08W. И не забывайте при этом, что на такой нагрузке 2.4GFlops — это не абстрактная производительность (просто перемножили число операций на частоту), а производительность на реальном алгоритме.
Я правильно понимаю, что это гепотетическая возможность?
Сейчас вы только заканчиваете доведение C компилятора до коммерческого уровня, сколько лет займет реализация компиляторов для этих «безопасных языков программирования»?
Нет. Это реальная возможность. Причины я достаточно подробно указал: проверки и программирование переходов по их результатам можно совмещать с самими полезными вычислениями. Мы (чтобы вы понимали, что Мультиклет не один воин на этом поле, мы — это: Мультиклет, УрФУ, ИММ УрО РАН и (возможно в будущем, на что я надеюсь) ЮФУ) занимаемся доведением компилятора до коммерческого уровня тоже достаточно необычным способом, который позволит нам фронтенды для других языков реализовать относительно быстро. На самом деле, frontend Си99 для нашей новой системы уже реализован, где-то за 3 недели (работа 1-го сотрудника). Мы рассчитываем, что через год будет поддержка ещё нескольких языков программированя на хорошем уровне. Я надеюсь, что о нашей системе компиляции я поведаю как-нибудь Хабросообществу.
Хотя, конечно, как мегазлобный препод, вы можете сказать: то, что не выложено на сайте — всего лишь гИпотетическая возможность. Что же, ваше право.
Сейчас это поддержано в вашем софте и железе, или это гепотетическая возможность?
Как определять, что одно ядро допустило сбой? А что если сбой в коммуникации ядер? Именно решение этих вопросов и составляет основную сложность устойчивости с сбоям, и даже гепотетического решения я у вас не вижу.
Более интеллектуальные способы ещё не запатентованы, поэтому я о них не могу пока рассказывать. А самый простой способ я указал в тексте: можно периодически прогонять тесты клеток, заставляя их выполнять одно и то же, аппаратно обнаруживать различия в записываемых во вне результатах (простое сравнение), и методом комитета выбирать сбойную клетку, отключать её, и так далее. Коммутатор можно так же резервировать (о чём я много раз писал выше), и проверять (опять же, это самый очевидный способ, неочевидные патентуются), сравнивая значения на выходах устройств.
Масштабирование MCp до 4-х ядер уже привело к фатальному провалу производительности из-за вашей архитектуры: 180нм и жалкие 100Мгц.
Процессоры на классических архитектурах на 180нм работают на частотах 800-2000 Мгц.
Эх. А вот это уже даже совсем не смешно (если действительно вы работаете над тем, чтобы микроэлектронику сделать своей работой). Ибо такое сравнение — сравнение эллиптических тараканов в сингулярности со сферическими конями в вакууме.
А энергопотребление у последних чипов какое? А синтезировались они каким программным обеспечением, и какие оптимизации синтеза были им доступны? А какая оптимизация была проведена на фабрике? Какие базовые элементы использовались? А какой длины у них конвейеры? Сколько человеко-часов было затрачено на ручную оптимизацию схемы? И т.д. Называйте тогда уж модель традиционного процессора с такой частотой и производителя. В этом случае уже можно будет конкретно сравнить. А так: тараканы и лошади. И очень странно, что вы этого не понимаете, господин профессор :)
Я не вижу, каким образом при работе со схемой «все ядра имеют доступ ко всем результатам вычислений» не возникает экспоненциальное падение производительности с ростом ядер. Именно коммуникация ограничивает скорость современных процессоров, а не скорость вычислений.
А по каким причинам оно должно возникнуть? Даже если коммутатор может распространять только одно значение за такт (а коммутатор — штука компактная, ибо простая, и стоит в центре процессора, вокруг которого развешены клетки, и срабатывает за такт), то падение производительности будет линейным. И при этом, существует много методов распространять не одно значение за такт, а несколько. Та же кольцевая шина, например.
Вот если бы это был настоящий коммутатор, когда надо обеспечивать передачу значений в режиме точка-точка, тогда да, задержки росли бы существенно. Как, например, в традиционных OoOE или VLIW процессорах, когда значение из RF нужно передать очень быстро определённому функциональному блоку. Но такая коммутация в MCp не нужна. Кстати, в тех же VLIW-ах, даже для встраиваемых решений, успешно решается проблема коммутации 8 значений 8 разным потребителям (к сожалению, забыл, какая именно модель Blackfin) одновременно. В MCp нужно решать более простую проблему.
Сейчас это есть? да/нет
Опять же, вспомним, почему существует SMT? Не потому, что кому-то нравится запускать потоки одновременно, а для того, чтобы скрывать латентность доступа к медленной памяти. Вас эта проблема вообще не касается, ввиду отсутствия внешней памяти. Почему тогда упомянут SMT — не ясно.
Мне кажется, я достаточно раз вставил слово «может» перед каждым глаголом, чтобы создать у читателя ощущение, что это возможность на будущее. SMT, кроме сокрытия задержек доступа к памяти помогает решать и проблему задержек при обработке прерываний. Но это так, к слову. Ибо следующее поколение MCp будет работать и с внешней памятью тоже. И, кажется, уже в этой, следующей модели SMT будет (точно не знаю).
По факту, я не вижу ни одного преимущетсва, которое существует сейчас. То что в будущем можно сделать много хорошего — это беспорно. Но интересует, что представляет из себя Мультиклет уже сейчас
Так об этом детально написано на сайте. Я своей целью ставил рассказ именно об особенностях архитектуры. Чтобы заинтересовавшиеся могли лучше понимать информацию на сайте. Ну, и хотелось, конечно, привлечь внимание к проекту рассказом о потенциале процессора.
Главными же преимуществами, которые существуют уже сейчас являются: (1) 4 инструкции за так с простым распределённым устройством управления; (2) отсутствие необходимости аппаратно упорядочивать доступы к памяти; (3) дружелюбность к безопасным и функциональным языкам программирования; (4) возможность пообсуждать необычную архитектуру с хорошими людьми на Хабре :)
Пройдемся по вашим преимуществам:
Они не мои, а процессора. Мои преимущества: весёлый характер, добрый нрав, знание 10+ языков программирования, основ теоретический физики и машинного обучения, членство в AAAI, а также неплохая работоспособность :)
Сколько конкретно мВт на Мгц при максимальной нагрузке? Это стандартный тест для сравнения энергоэффективности.
Нет цифры — значит это wishful thinking.
Всё это есть на сайте. Странно, что вы рассмотрели информацию о 180nm, но не заметили, что максимальная нагрузка (это та, которая при комплексном БПФ) достигается на 100MHz при потреблении 1.08W. И не забывайте при этом, что на такой нагрузке 2.4GFlops — это не абстрактная производительность (просто перемножили число операций на частоту), а производительность на реальном алгоритме.
Я правильно понимаю, что это гепотетическая возможность?
Сейчас вы только заканчиваете доведение C компилятора до коммерческого уровня, сколько лет займет реализация компиляторов для этих «безопасных языков программирования»?
Нет. Это реальная возможность. Причины я достаточно подробно указал: проверки и программирование переходов по их результатам можно совмещать с самими полезными вычислениями. Мы (чтобы вы понимали, что Мультиклет не один воин на этом поле, мы — это: Мультиклет, УрФУ, ИММ УрО РАН и (возможно в будущем, на что я надеюсь) ЮФУ) занимаемся доведением компилятора до коммерческого уровня тоже достаточно необычным способом, который позволит нам фронтенды для других языков реализовать относительно быстро. На самом деле, frontend Си99 для нашей новой системы уже реализован, где-то за 3 недели (работа 1-го сотрудника). Мы рассчитываем, что через год будет поддержка ещё нескольких языков программированя на хорошем уровне. Я надеюсь, что о нашей системе компиляции я поведаю как-нибудь Хабросообществу.
Хотя, конечно, как мегазлобный препод, вы можете сказать: то, что не выложено на сайте — всего лишь гИпотетическая возможность. Что же, ваше право.
Сейчас это поддержано в вашем софте и железе, или это гепотетическая возможность?
Как определять, что одно ядро допустило сбой? А что если сбой в коммуникации ядер? Именно решение этих вопросов и составляет основную сложность устойчивости с сбоям, и даже гепотетического решения я у вас не вижу.
Более интеллектуальные способы ещё не запатентованы, поэтому я о них не могу пока рассказывать. А самый простой способ я указал в тексте: можно периодически прогонять тесты клеток, заставляя их выполнять одно и то же, аппаратно обнаруживать различия в записываемых во вне результатах (простое сравнение), и методом комитета выбирать сбойную клетку, отключать её, и так далее. Коммутатор можно так же резервировать (о чём я много раз писал выше), и проверять (опять же, это самый очевидный способ, неочевидные патентуются), сравнивая значения на выходах устройств.
Масштабирование MCp до 4-х ядер уже привело к фатальному провалу производительности из-за вашей архитектуры: 180нм и жалкие 100Мгц.
Процессоры на классических архитектурах на 180нм работают на частотах 800-2000 Мгц.
Эх. А вот это уже даже совсем не смешно (если действительно вы работаете над тем, чтобы микроэлектронику сделать своей работой). Ибо такое сравнение — сравнение эллиптических тараканов в сингулярности со сферическими конями в вакууме.
А энергопотребление у последних чипов какое? А синтезировались они каким программным обеспечением, и какие оптимизации синтеза были им доступны? А какая оптимизация была проведена на фабрике? Какие базовые элементы использовались? А какой длины у них конвейеры? Сколько человеко-часов было затрачено на ручную оптимизацию схемы? И т.д. Называйте тогда уж модель традиционного процессора с такой частотой и производителя. В этом случае уже можно будет конкретно сравнить. А так: тараканы и лошади. И очень странно, что вы этого не понимаете, господин профессор :)
Я не вижу, каким образом при работе со схемой «все ядра имеют доступ ко всем результатам вычислений» не возникает экспоненциальное падение производительности с ростом ядер. Именно коммуникация ограничивает скорость современных процессоров, а не скорость вычислений.
А по каким причинам оно должно возникнуть? Даже если коммутатор может распространять только одно значение за такт (а коммутатор — штука компактная, ибо простая, и стоит в центре процессора, вокруг которого развешены клетки, и срабатывает за такт), то падение производительности будет линейным. И при этом, существует много методов распространять не одно значение за такт, а несколько. Та же кольцевая шина, например.
Вот если бы это был настоящий коммутатор, когда надо обеспечивать передачу значений в режиме точка-точка, тогда да, задержки росли бы существенно. Как, например, в традиционных OoOE или VLIW процессорах, когда значение из RF нужно передать очень быстро определённому функциональному блоку. Но такая коммутация в MCp не нужна. Кстати, в тех же VLIW-ах, даже для встраиваемых решений, успешно решается проблема коммутации 8 значений 8 разным потребителям (к сожалению, забыл, какая именно модель Blackfin) одновременно. В MCp нужно решать более простую проблему.
Сейчас это есть? да/нет
Опять же, вспомним, почему существует SMT? Не потому, что кому-то нравится запускать потоки одновременно, а для того, чтобы скрывать латентность доступа к медленной памяти. Вас эта проблема вообще не касается, ввиду отсутствия внешней памяти. Почему тогда упомянут SMT — не ясно.
Мне кажется, я достаточно раз вставил слово «может» перед каждым глаголом, чтобы создать у читателя ощущение, что это возможность на будущее. SMT, кроме сокрытия задержек доступа к памяти помогает решать и проблему задержек при обработке прерываний. Но это так, к слову. Ибо следующее поколение MCp будет работать и с внешней памятью тоже. И, кажется, уже в этой, следующей модели SMT будет (точно не знаю).
По факту, я не вижу ни одного преимущетсва, которое существует сейчас. То что в будущем можно сделать много хорошего — это беспорно. Но интересует, что представляет из себя Мультиклет уже сейчас
Так об этом детально написано на сайте. Я своей целью ставил рассказ именно об особенностях архитектуры. Чтобы заинтересовавшиеся могли лучше понимать информацию на сайте. Ну, и хотелось, конечно, привлечь внимание к проекту рассказом о потенциале процессора.
Главными же преимуществами, которые существуют уже сейчас являются: (1) 4 инструкции за так с простым распределённым устройством управления; (2) отсутствие необходимости аппаратно упорядочивать доступы к памяти; (3) дружелюбность к безопасным и функциональным языкам программирования; (4) возможность пообсуждать необычную архитектуру с хорошими людьми на Хабре :)
Боюсь «завалить» МСр на хабре невозможно, не стоит переоценивать хабрасилу :-)
К Мультиклету я дышу не ровно именно из-за его агрессивной рекламы в худших западных традициях (2.4 GFLOP — именно оттуда) с выдачей минимальной технической информации (особенно по-началу).
К Миландру например у меня никаких претензий нет, все четко и понятно, максимум технической информации, минимум кукурузы.
2.4GFLOPs — это не может быть реальной производительностью на реальном алгоритме, поскольку достигается на одной лишь операции (умножении комплексных чисел) в случае если нигде нет никаких задержек.
Если говорить о MIPS (миллионах инструкций в секунду), то у вас их 400, 800 если считать что с упакованными данными все операции работают.
Итак 800 MIPS, это 1080/800 = 1.35 мВт на 1 MIPS.
У банального Cortex M4 — 0.53 мВт на 1 MIPS, отрыв в 2.5 раза.
Но было бы честнее сравнивать с DSP — т.к. гонять в тестах вы собираетесь я полагаю DSP-подобные задачи:
TMS320C6657 — 3.5W, 80'000 MIPS (160 GFLOP операции там MADD), это 0.042 мВт на MIPS, отрыв в 32 раза.
К Мультиклету я дышу не ровно именно из-за его агрессивной рекламы в худших западных традициях (2.4 GFLOP — именно оттуда) с выдачей минимальной технической информации (особенно по-началу).
К Миландру например у меня никаких претензий нет, все четко и понятно, максимум технической информации, минимум кукурузы.
2.4GFLOPs — это не может быть реальной производительностью на реальном алгоритме, поскольку достигается на одной лишь операции (умножении комплексных чисел) в случае если нигде нет никаких задержек.
Если говорить о MIPS (миллионах инструкций в секунду), то у вас их 400, 800 если считать что с упакованными данными все операции работают.
Итак 800 MIPS, это 1080/800 = 1.35 мВт на 1 MIPS.
У банального Cortex M4 — 0.53 мВт на 1 MIPS, отрыв в 2.5 раза.
Но было бы честнее сравнивать с DSP — т.к. гонять в тестах вы собираетесь я полагаю DSP-подобные задачи:
TMS320C6657 — 3.5W, 80'000 MIPS (160 GFLOP операции там MADD), это 0.042 мВт на MIPS, отрыв в 32 раза.
К Миландру например у меня никаких претензий нет, все четко и понятно, максимум технической информации, минимум кукурузы.
Миландр и не делает процессоров на новой оригинальной архитектуре. Вам не кажется, что при таком разном роде занятий силы у коллективов уходят на разное? Миландр может себе позволить описать все детальки. Мультиклет должен пока вкладывать огромные силы в доведение новой архитектуры до ума. У Миландра есть документация от ARM, Мультиклету нужна писать всё самому. И компания ещё не такая большая, ресурсы ограничены.
2.4GFLOPs — это не может быть реальной производительностью на реальном алгоритме, поскольку достигается на одной лишь операции (умножении комплексных чисел) в случае если нигде нет никаких задержек.
Если говорить о MIPS (миллионах инструкций в секунду), то у вас их 400, 800 если считать что с упакованными данными все операции работают.
Итак 800 MIPS, это 1080/800 = 1.35 мВт на 1 MIPS.
То, что вы не верите в это, не означает, что этого быть не может. В SDK есть код того самого преобразования Фурье. Любой желающий может его прочитать, убедится, что задержки в нём все скрыты. благодаря особенностям архитектуры, и подсчитать, что этот код позволяет выжать пиковые 2.4GFlops. Если денюжек не жаль, можно его запустить на реальном процессоре и так же убедится в том, что реальная производительность на реальной задаче близка к пиковой. Наверное, скоро будет каким-то образом организован удалённый доступ к платам для тестов, и производительность MCp сможет оценить больший круг желающих. То есть, компания ничего не скрывает.
Вполне можете брать эти 2400 MIPS для рассчётов различных «попугаев». И Cortex M4 уже не выглядит таким героическим. Кроме того, какой именно Cortex M4 подразумевается? На каком техпроцессе, с какими оптимизациями?
Но было бы честнее сравнивать с DSP — т.к. гонять в тестах вы собираетесь я полагаю DSP-подобные задачи:
TMS320C6657 — 3.5W, 80'000 MIPS (160 GFLOP операции там MADD), это 0.042 мВт на MIPS, отрыв в 32 раза.
Это уже конкретнее. Спасибо. Погуглим… Не, ну вы, конечно, молодец. Сравнили MCp с 1.25GHz процессором, у которого к тому же 8 функциональных устройств, и который делается на 40nm. Чего вы ожидали? Очевидно, он будет потреблять много меньше на MIPS. Чтобы сравнивать именно архитектуры, нужно все прочие параметры зафиксировать, хотя бы техпроцесс и максимальную потребляемую мощность. Cтранно, что вы это активно не хотите замечать.
MADD в MCP тоже есть.
Миландр и не делает процессоров на новой оригинальной архитектуре. Вам не кажется, что при таком разном роде занятий силы у коллективов уходят на разное? Миландр может себе позволить описать все детальки. Мультиклет должен пока вкладывать огромные силы в доведение новой архитектуры до ума. У Миландра есть документация от ARM, Мультиклету нужна писать всё самому. И компания ещё не такая большая, ресурсы ограничены.
2.4GFLOPs — это не может быть реальной производительностью на реальном алгоритме, поскольку достигается на одной лишь операции (умножении комплексных чисел) в случае если нигде нет никаких задержек.
Если говорить о MIPS (миллионах инструкций в секунду), то у вас их 400, 800 если считать что с упакованными данными все операции работают.
Итак 800 MIPS, это 1080/800 = 1.35 мВт на 1 MIPS.
То, что вы не верите в это, не означает, что этого быть не может. В SDK есть код того самого преобразования Фурье. Любой желающий может его прочитать, убедится, что задержки в нём все скрыты. благодаря особенностям архитектуры, и подсчитать, что этот код позволяет выжать пиковые 2.4GFlops. Если денюжек не жаль, можно его запустить на реальном процессоре и так же убедится в том, что реальная производительность на реальной задаче близка к пиковой. Наверное, скоро будет каким-то образом организован удалённый доступ к платам для тестов, и производительность MCp сможет оценить больший круг желающих. То есть, компания ничего не скрывает.
Вполне можете брать эти 2400 MIPS для рассчётов различных «попугаев». И Cortex M4 уже не выглядит таким героическим. Кроме того, какой именно Cortex M4 подразумевается? На каком техпроцессе, с какими оптимизациями?
Но было бы честнее сравнивать с DSP — т.к. гонять в тестах вы собираетесь я полагаю DSP-подобные задачи:
TMS320C6657 — 3.5W, 80'000 MIPS (160 GFLOP операции там MADD), это 0.042 мВт на MIPS, отрыв в 32 раза.
Это уже конкретнее. Спасибо. Погуглим… Не, ну вы, конечно, молодец. Сравнили MCp с 1.25GHz процессором, у которого к тому же 8 функциональных устройств, и который делается на 40nm. Чего вы ожидали? Очевидно, он будет потреблять много меньше на MIPS. Чтобы сравнивать именно архитектуры, нужно все прочие параметры зафиксировать, хотя бы техпроцесс и максимальную потребляемую мощность. Cтранно, что вы это активно не хотите замечать.
MADD в MCP тоже есть.
Открыл пример examples20121009.7z\examples\asm\fft\fft_test1\fft_test1.asm
Давайте для простоты посмотрим в цикл L5:
1 четверка команд — 5 операций (3 для цикла, 1 — загрузка 2*32)
2: 8 операций (4 загрузки 2*32)
3: 24 (4 комплексных умножения)
4: 8 операций (4 загрузки 2*32)
5: 8 (4 комплексных сложения)
6: 8 (4 комплексных сложения)
7: 16 (2 умножения, 2 загрузки)
8: 16 (2 умножения, 2 сложения)
9: 8 (4 комплексных сложения)
10: 16 (2 умножения, 2 сложения)
11: 16 (2 умножения, 2 сложения)
12: 8 (4 комплексных сложения)
13: 8 (2 сложения 2 записи)
14: 8 (4 записи)
15: 4 (2 записи)
Итак, на этом куске кода за 15 тактов у нас будет выполняется 156 операций (а не 360),
что дает нам на этом цикле производительность 1040 MFLOPS.
Вот с этой цифрой я мог бы согласится, как с реалистичной оценкой производительности в оптимальном случае ручной оптимизации и максимально распарралеливаемого алгоритма, когда все происходит без задержек.
Вы согласны с этой оценкой?
Насчет Cortex-M4 — www.st.com/internet/mcu/subclass/1521.jsp, 90nm
О техпроцессе: история как вы знаете любит повторяться. Мултиклет — не первый Российский микроэлектронный проект, обещавший революцию. До него был Эльбрус — но его основатель говорил слова, печально похожие на ваши — «не было денег на ручную оптимизацию топологии, лепили из библиотеки стандартных ячеек» и «техпроцесс слабоват, вот еще чуть-чуть — и мы всех порвем». Чем закончилось — всем известно. Если у вас на текущем техпроцессе не удается рвать конкурентов по энергопотреблению — то не стоит это и заявлять.
Давайте для простоты посмотрим в цикл L5:
1 четверка команд — 5 операций (3 для цикла, 1 — загрузка 2*32)
2: 8 операций (4 загрузки 2*32)
3: 24 (4 комплексных умножения)
4: 8 операций (4 загрузки 2*32)
5: 8 (4 комплексных сложения)
6: 8 (4 комплексных сложения)
7: 16 (2 умножения, 2 загрузки)
8: 16 (2 умножения, 2 сложения)
9: 8 (4 комплексных сложения)
10: 16 (2 умножения, 2 сложения)
11: 16 (2 умножения, 2 сложения)
12: 8 (4 комплексных сложения)
13: 8 (2 сложения 2 записи)
14: 8 (4 записи)
15: 4 (2 записи)
Итак, на этом куске кода за 15 тактов у нас будет выполняется 156 операций (а не 360),
что дает нам на этом цикле производительность 1040 MFLOPS.
Вот с этой цифрой я мог бы согласится, как с реалистичной оценкой производительности в оптимальном случае ручной оптимизации и максимально распарралеливаемого алгоритма, когда все происходит без задержек.
Вы согласны с этой оценкой?
Насчет Cortex-M4 — www.st.com/internet/mcu/subclass/1521.jsp, 90nm
О техпроцессе: история как вы знаете любит повторяться. Мултиклет — не первый Российский микроэлектронный проект, обещавший революцию. До него был Эльбрус — но его основатель говорил слова, печально похожие на ваши — «не было денег на ручную оптимизацию топологии, лепили из библиотеки стандартных ячеек» и «техпроцесс слабоват, вот еще чуть-чуть — и мы всех порвем». Чем закончилось — всем известно. Если у вас на текущем техпроцессе не удается рвать конкурентов по энергопотреблению — то не стоит это и заявлять.
1. Конкуретнов-то MCp как раз побеждает. Просто вы пытаетесь сравнить наш процессор не с конкурентами, а с устройствами совершенно другого класса. Сравнение именно с конкурентами, с той же стоимостью, тем же уровнем «приёмки» с возможностью заказа для военных применений и т.д. есть на сайте.
2. О революции вообще никто не говорил. Говорили о принципиально новой интересной архитектуре. Она действительно принципиально новая (чего у Бабаяна не было) и интересная (чего так же не было у Бабаяна). Тут обмана нет. Кроме того, денег «Мультиклет» у государства не выпрашивает и работает своими силами. Участие в Сколково даёт только налоговые льготы, а не потоки финансирования. Поэтому сравнение с Эльбрусом совершенно некорректно.
3. С оценкой согласен. Только вы не учитываете одного (я об этом не рассказывал, ибо это всё детали, которые могут поменяться в следующей версии; но в документации это написано). Текущая версия MCp может переключаться в режим, когда выполнение следующего параграфа начинается одновременно с текущим. Когда программист может гарантировать, что параграфы независимы по данным, он может включать такой режим. В этой реализации FFT такой режим включается. Поэтому во внутренние буферы клеток постоянно подкачиваются команды из следующих параграфов, и они тоже исполняются. Эх… К сожалению, я больше не могу уделять много времени нашей дискуссии, ибо и так выбился из планов. Давайте мы в проведём несколько тестов, о которых нам в этой ветке подсказали, за что сообществу огромное спасибо (скорее всего, это будет линейная алгебра и криптография). И тогда уже с этими результатами обсудим архитектуру ещё раз. Мне бы очень хотелось вас переубедить, ибо, если вас получится, то архитектуру, действительно, можно будет считать очень клёвой. Но пока, к сожалению, время не позволяет.
До новых споров и удачи!
2. О революции вообще никто не говорил. Говорили о принципиально новой интересной архитектуре. Она действительно принципиально новая (чего у Бабаяна не было) и интересная (чего так же не было у Бабаяна). Тут обмана нет. Кроме того, денег «Мультиклет» у государства не выпрашивает и работает своими силами. Участие в Сколково даёт только налоговые льготы, а не потоки финансирования. Поэтому сравнение с Эльбрусом совершенно некорректно.
3. С оценкой согласен. Только вы не учитываете одного (я об этом не рассказывал, ибо это всё детали, которые могут поменяться в следующей версии; но в документации это написано). Текущая версия MCp может переключаться в режим, когда выполнение следующего параграфа начинается одновременно с текущим. Когда программист может гарантировать, что параграфы независимы по данным, он может включать такой режим. В этой реализации FFT такой режим включается. Поэтому во внутренние буферы клеток постоянно подкачиваются команды из следующих параграфов, и они тоже исполняются. Эх… К сожалению, я больше не могу уделять много времени нашей дискуссии, ибо и так выбился из планов. Давайте мы в проведём несколько тестов, о которых нам в этой ветке подсказали, за что сообществу огромное спасибо (скорее всего, это будет линейная алгебра и криптография). И тогда уже с этими результатами обсудим архитектуру ещё раз. Мне бы очень хотелось вас переубедить, ибо, если вас получится, то архитектуру, действительно, можно будет считать очень клёвой. Но пока, к сожалению, время не позволяет.
До новых споров и удачи!
Кстати, а чем таки закончилась история с Эльбрусом? Расскажите пожалуйста. Они таки выпустили новый вариант Е2К? Или плавно и ненавязчиво пересели на спарки?
E2K выпустили (на буржуйской фабрике), но Intel порвать не удалось — пришлось всей командой разработчиков идти в Intel рвать его изнутри. В итоге все засекретили и E2K продают только военным.
Для около-гражданских применений — спарки. Мне на тест наш спарк не дали. :-)
Для около-гражданских применений — спарки. Мне на тест наш спарк не дали. :-)
Behold! 4pda.ru/2012/12/21/83509/
В итоге все засекретили
Великолепный ход! <facepalm/>
Информации, видимо, мало потому, что не всё ещё запатентовали.
Статья, скорее — взгляд программиста, работающего с процессором, чем техническое описание. Но зато с примерами кода, они уже что-то проясняют.
Статья, скорее — взгляд программиста, работающего с процессором, чем техническое описание. Но зато с примерами кода, они уже что-то проясняют.
Ну по сравнению с рекламой Cortex M4, www.arm.com/products/processors/cortex-m/cortex-m4-processor.php см таблицу внизу по поводу динамического потребления, заявления о высокой производительности и низком потреблении с приведением реальных значений на мой взгляд не так агрессивны, как 8 µW/MHz с незаметной пометкой внизу * Base usable configuration includes DSP extensions, 1 IRQ + NMI, excludes ETM, MPU, FPU and debug, которая иногда отсутствует. А у Миландра есть процессор с блоком FPU одинарной или двойной точности? Но на сайте у Миландра да всё красиво оформлено и перевод документации качественный, но и у нас все необходимое постепенно появляется на сайте.
У Миландра нет процессоров с 32-х битным FPU, и возможно на то есть причина — они делают то, что востребовано оборонной промышленностью, и на что организован ОКР заинтересованными сторонами.
А ARM я думаю вполне честен, они написали конкретную цифру в конкретных условиях — 0.008 мВт/Мгц, и не включили FPU по вполне понятной причине — далеко не во всех встраиваемых/DSP применениях нужен FPU. Да и FPU не даст увеличение энергопотребления даже на порядок (да даже вдвое не даст), так что цифра остается достаточно корректной.
Кстати интересен вопрос (я вполне серьезно тут), почему не сложилось с финансированием от Сколково?
А ARM я думаю вполне честен, они написали конкретную цифру в конкретных условиях — 0.008 мВт/Мгц, и не включили FPU по вполне понятной причине — далеко не во всех встраиваемых/DSP применениях нужен FPU. Да и FPU не даст увеличение энергопотребления даже на порядок (да даже вдвое не даст), так что цифра остается достаточно корректной.
Кстати интересен вопрос (я вполне серьезно тут), почему не сложилось с финансированием от Сколково?
Сколково грант не выделило, хотя кто знает может когда-нибудь в будущем и выделит, причиной отсутствия гранта вроде был странный анализ процессора экспертами, следствием чего явился документ multiclet.com/docs/PO/multicellular_architecture.doc. За официальными сведениями обращайтесь в коммерческий отдел компании. Хотя странно, что государство не хочет выделить средства на такой перспективный проект для промышленной, оборонной, научной, аэрокосмической и других сфер применения отечественного процессора.
Sign up to leave a comment.
Баллада о «Мультиклете»