Forums » Мультиклеточная архитектура »
Оптимизация архитектуры
Added by krufter_multiclet over 9 years ago
Предложения по оптимизации мультиклеточной архитектуры для следующих ревизий процессоров можно размещать в данной теме.
Текущий список запланированных оптимизаций:
Общее:
1) GPIO с несколькими альтернативными функциями
2) Блок семафоров аппаратный
3) Присваивание процессору индивидуального номера прямо в кристалле
4) Доработка системы сброса (некоторая избирательность по системным настройкам, дебагеру)
5) Отдельное тактирование разных веток периферийной шины
6) Домены по питанию
7) Вывод тактовой частоты процессора с делителем
8) Одно напряжение питания
9) Аппаратный делитель
10) Обмен результатами между параграфами без памяти
11) Возможность использовать в качестве первого аргумента команды регистры, косвенную адресацию
12) Отправка результата команды сразу в регистр
13) Развязка записи в РОН от complete
14) Рассмотреть вопрос зависимости не только по данным, но и по факту выполнения команд
15) Доступ к флагам, например @1.z - получение Zero flag
Периферия:
1)Ethernet 10/100 MAC+PHY (2 канала)
2)Доработка RTC, ШИМ
3)Аппаратный блок CRC (Blake2, ГОСТ Р 34.11-2012)
4)USB PHY (Device + Host) 2.0, 480 Мбит/с
5)Температурный датчик
6)Загрузчик по UART + защищенные режимы
7)Шифрование по ГОСТ89 или ГОСТ-2015
8)Доработать SPI для повышения частоты работы процессора
Replies (146)
RE: Оптимизация архитектуры - Added by micron_multiclet about 7 years ago
Условия, при которых сопроцессор может быть эффективен:
1. Необходима очень длинная непрерывная последовательность арифметических операций. От длины зависит доля накладных расходов на преобразование операнда из традиционного, позиционного вида в модулярно-логарифмический. Чем короче последовательность, тем ниже эффективность. При сравнении эти расходы никак не учитывались, хотя для эффективности конвейерной организации процесса преобразования, очень важна непрерывность его загрузки. Подобные алгоритмы единичны.
2. В этой последовательности преимущественно должны быть операции умножения, деления и т.п. (а не сложения и вычитания). В реальности же, доля сложений и вычитаний составляет более 50% от общего количества операций.
3. В современных процессорах и сложение и умножение, в потоке, выполняется за один такт. Заменяя в модулярно-логарифмическом сопроцессоре умножение сложением, мы вряд ли сократим длительность такта, так как она зависит не только от АЛУ, но и от технологии, схемотехники и общей организации вычислительного процесса.
RE: Оптимизация архитектуры - Added by VaalKIA about 7 years ago
micron_multiclet wrote:
Весьма сомнительое утверждение, точно так же, как в коде программ выбирается тип с плавающей точкой, точно так же может быть выбран тип ЛСС, таким образом, преобразования нужны будут только на вводе и выводе, а вот интенсивность этого, это уже другой вопрос. Фактически, например, при каком-нибудь сложном физическом моделировании ввода вообще не будет, а вывод будет по запросу, хоть раз в час, для физического движка игры, наоборот, вывод несколько раз в секунду, однако там вопрос в количестве данных вывода, они, как правило, очень скромные по объёму, а внутреннее состояние преобразовывать не требуется. В общем, если это не прикладное решение, которое выполняет лишь часть расчётов и гонит поток данных в другую систему (какой-нибудь препроцесинг 3д координат для видео карты, где принимается на вход флоат, условно), а самодостаточный процесс, то вполне себе имеет право на существование.Условия, при которых сопроцессор может быть эффективен:
1. Необходима очень длинная непрерывная последовательность арифметических операций. От длины зависит доля накладных расходов на преобразование операнда из традиционного, позиционного вида в модулярно-логарифмический. Чем короче последовательность, тем ниже эффективность.
P.S. Вернее даже не сомнительное, а заблудительное. Сказано так, что не может перемежаться другими коммандами, которых полно в любой программе. А на деле, я пояснил точку зрения.
RE: Оптимизация архитектуры - Added by micron_multiclet about 7 years ago
И физические модели и генерация реалистичного изображения в играх связаны с "длинными непрерывными последовательностями арифметических операций". А вот задачи управления, как правило другие. Сняли с датчика значение (в нормальном виде) сделали несколько операций с ним и выдали результат на какое-либо исполнительное устройство (также в нормальном виде). Здесь нет длинных последовательностей, а есть большой объем вычислений состоящий из массы коротких цепочек.
P.S. Речь идет о характерных чертах "арифметики", а не о том, какие еще команды есть в программе. Это "не от той стенки гвоздь"!
RE: Оптимизация архитектуры - Added by Yaisis about 7 years ago
micron_multiclet wrote:
Условия, при которых сопроцессор может быть эффективен:
1. Необходима очень длинная непрерывная последовательность арифметических операций. От длины зависит доля накладных расходов на преобразование операнда из традиционного, позиционного вида в модулярно-логарифмический. Чем короче последовательность, тем ниже эффективность. При сравнении эти расходы никак не учитывались, хотя для эффективности конвейерной организации процесса преобразования, очень важна непрерывность его загрузки. Подобные алгоритмы единичны.
2. В этой последовательности преимущественно должны быть операции умножения, деления и т.п. (а не сложения и вычитания). В реальности же, доля сложений и вычитаний составляет более 50% от общего количества операций.
3. В современных процессорах и сложение и умножение, в потоке, выполняется за один такт. Заменяя в модулярно-логарифмическом сопроцессоре умножение сложением, мы вряд ли сократим длительность такта, так как она зависит не только от АЛУ, но и от технологии, схемотехники и общей организации вычислительного процесса.
Ну я так и думал, что на преобразованиях будет потеря времени, а преобразовывать придётся из-за сложений и вычитаний, и они в данном случае будут выполняться медленно. Но умножение, деление, возведение в степень, извлечение из корня и т.д. -- быстро.
Текущая система конечно выгодней для многих алгоритмов, т.к. большинство операций в коде -- это сложение и вычитание, а деление часто стараются заменить умножением.
В реальности же, если представить наличие в процессоре одновременно двух подходов с соответствующими инструкциями, то программист мог бы оптимизировать свои алгоритмы и заранее переключаться между двумя системами, используя наиболее выгодную в каждый момент времени. Или выбирать тип данных в зависимости от алгоритма.
Так же эту оптимизацию мог бы проводить и компилятор, но не так эффективно.
Тут встаёт другой вопрос -- насколько затратно реализовать в процессоре сразу две системы ?
Это сильно увеличит площадь кристалла и лучше отказаться от этого или на аппаратном уровне у них будет много общего и там можно много чего унифицировать ?(я предполагаю, что всё нужное в процессоре уже есть)
Ну и так же нужно ещё проанализировать, а надо ли это вообще... , а то может и так сойдёт.
Если же это создавать, то это идёт добавление нового типа данных и соответствующих инструкций к нему, которые будут задействовать общие аппаратные схемы с плавающей точкой и целыми числами.
Наличие такого типа, возможно, для кого-то будет конкурентным преимуществом, т.к. кроме повышения быстродействия там ещё и сильно снижаются ошибки округления на соответствующих алгоритмах.
RE: Оптимизация архитектуры - Added by VaalKIA about 7 years ago
Yaisis wrote:
Тут встаёт другой вопрос -- насколько затратно реализовать в процессоре сразу две системы ?
Я бы расширил целые числа до дробей, это принципиально расширяет поле деятельности до рациональных чисел, вместо ЛСС и FP, если уж вопрос так стоит.
RE: Оптимизация архитектуры - Added by Yaisis about 7 years ago
VaalKIA wrote:
Yaisis wrote:
Тут встаёт другой вопрос -- насколько затратно реализовать в процессоре сразу две системы ?
Я бы расширил целые числа до дробей, это принципиально расширяет поле деятельности до рациональных чисел, вместо ЛСС и FP, если уж вопрос так стоит.
Я так понял, ЛСС -- это и есть дробное число.
Оно внутри состоит из целой части и дробной, плюс бит знака числа.
RE: Оптимизация архитектуры - Added by VaalKIA about 7 years ago
Yaisis wrote:
VaalKIA wrote:
Yaisis wrote:
Я так понял, ЛСС -- это и есть дробное число.
Расшифровывается как Логарифмическая Система Счисления (это термин авторов ЛСС сопроцессора), честно гвооря, не вдавался в подробности, плавающая там точка (FP - Floating Point) или фиксированная(что программисты как раз и ассоциируют с дробным числом). И вы не путаете дроби и дробные числа?
Под дробными числами, понимают, обычно, числа, где есть знаки после запятой, не важно в какой системе исчисления.
Под дробями понимают два целых числа: числитель и знаменатель.
В какой бы системе вы не взяли дробное число, это будет дробь с зафиксированным знаменателем, что сильно скажется на точности и не позволит точно записывать многие значения. Например
1/3 = 0.3333(3) = 0.0101(01)
1/5 = 0.2 = 0.001100110011(0011)
Ну и эффекты для дробных/FP чисел, (1/3)*3=0.9; 0.2 = 0.1999969482421875, даже без всяких операций, на заметку тем, кто делает калькуляторы и работает с финансами, где надо применять двоично-десятичное кодирование (есть в z80), то есть рабтать с десятичными числами в битовом представлении (четыре бита на знак), иначе результаты будут расходиться с тем, что может посчитать человек на бумажке.
Да, дроби нужно будет округлять, то есть уменьшать точность, хотя бы потому, что квадратный корень, это часто иррациональное число, для этого хорошо подходит ряд фарея, при этом используя цепные дроби и не особо сложный алгоритм можно получить два непосредственных предка числа в дереве Штерна-Брокко, не осуществляя поиск от корня.
При этом понятно, почему дроби не использовали раньше: диапазон был маловат и память дорога, либо скорость маленькая (то есть они проигрывали или FP или FixP), но сейчас если 64+64бита дробь сделать, то получим много бонусов и по сложности это проще FP (АЛУ для целых чисел почти в тупую используется, за исключением округления) и по диапазону очень неплохо будет, можно и научные расчёты делать.
RE: Оптимизация архитектуры - Added by Yaisis about 7 years ago
VaalKIA wrote:
Расшифровывается как Логарифмическая Система Счисления (это термин авторов ЛСС сопроцессора), честно гвооря, не вдавался в подробности, плавающая там точка (FP - Floating Point) или фиксированная(что программисты как раз и ассоциируют с дробным числом). И вы не путаете дроби и дробные числа?
Я вначале подумал, что там дробь, но похоже, что там фиксированная точка.
RE: Оптимизация архитектуры - Added by Yaisis over 5 years ago
Давно я тут не был и что-то тихо тут у вас стало.
Зашёл сюда чтобы написать следующее:
У вас пока процессор слабо развитый и поэтому я подумал, что может вам создать конкурента Arduino и всяким микроконтроллерам.
Я не знаю, как там устроено, но в их процессорах наверняка нет суперскалярности, а ваш четырёхклеточный будет работать, как суперскалярный по производительности и при этом мало потреблять энергии.
Поэтому вы можете все микроконтроллеры уделать.
Они не будут там встраивать суперскалярность, так как это повысит энергопотребление и сложность чипа.
И таким образом ваша архитектура идеально туда ложиться.
Тем более с 4-мя клетками у вас нет проблем, а там этого хватит.
Если что, то вы и 8 можете сделать. Может даже и 16.
Плюс там не нужна ОС, надо будет только прошивки с кодом загружать и всё.
Т.е. как раз подходит для вашего текущего развития.
Нужен будет компилятор и набор библиотек.
Техпроцесс там тоже наверно не такой уж современный.
И частоты наверно небольшие.
Поэтому можете собрать плату, как Ардуино с аналоговыми входами и цифровыми, и чтобы она была совместима со всеми модулями, которые используются в Ардуино.
Только вам надо будет ещё соответствовать по цене китайским аналогам, иначе все будут покупать и дальше китайские модули.
(возможно с ценой у вас возникнут проблемы)
Подумайте над этим, выгодно будет вам или нет.
Может вы на этом начнёте зарабатывать и будет приток денег, а потом разовьётесь и до других рынков.
RE: Оптимизация архитектуры - Added by VaalKIA about 5 years ago
Несколько месяцев нет новостей, хотелось бы знать как поживает Мультиклет.
RE: Оптимизация архитектуры - Added by micron_multiclet about 5 years ago
Да, действительно, как-то мы забросили форумные и сайтовые новости) с одной стороны, разработки и идеи проектов приобретают секретный характер, а с другой - нас же всегда критиковали за большой объем пиара, не подкрепленный ярдами освоения бюджетных средств, как у некоторых (не будем показывать пальцем))). Так что тихо ваяем «за печкой» 64 клеточник на 28 нм, улучшаем C компилятор (который, кстати, на кормарке уже лучше, чем Байкал и Эльбрус - см. статью на хабре), и активно готовим еще ряд проектов, о которых позже расскажем обязательно. Но первые новостные тексты, как обычно - на синьюс и/или хабре.
RE: Оптимизация архитектуры - Added by EviLOne about 5 years ago
micron_multiclet wrote:
улучшаем C компилятор (который, кстати, на кормарке уже лучше, чем Байкал и Эльбрус - см. статью на хабре)
Можно по точнее какую статью имеете ввиду? Хоть название
RE: Оптимизация архитектуры - Added by VaalKIA about 5 years ago
EviLOne wrote:
micron_multiclet wrote:
улучшаем C компилятор (который, кстати, на кормарке уже лучше, чем Байкал и Эльбрус - см. статью на хабре)
Можно по точнее какую статью имеете ввиду? Хоть название
RE: Оптимизация архитектуры - Added by Yaisis about 5 years ago
Я так понял, что S1 -- это 16 ядерный процессор, каждое ядро которого состоит из 4 клеток.
Т.е. получается в других процессорах это суперскалярность, а тут более эффективная её реализация, через клетки.
И получается, что аппаратное распараллеливание действует всего на 4 клетки ?
Или код загружается сам во все 64 клетки и там расспараллеливается, но при этом связаны между собой только каждые 4 клетки ?
И как это программируется -- один код для всего процессора или программист сам разбивает код на 16 потоков, которые уже распараллеливаются сами в каждом ядре ?
RE: Оптимизация архитектуры - Added by micron_multiclet almost 5 years ago
В мультиклеточных процессорах нет ядер) только клетки или мультиклетки (сообщество 4-х клеток). В Multiclet S1 64 клетки поделенные на 4 кластера по 4 мультиклетки в каждом.
Параллелизм распространяется сразу на все 64 клетки, как естественное свойство микроархитектуры. На программисте это вообще никак не сказывается, та же программа на С преобразуется компилятором в код, который реализуется чипом. Программист только увидит сверхэффективность исполнения программы на новом процессоре и все ( ну примерно так))))
RE: Оптимизация архитектуры - Added by micron_multiclet almost 5 years ago
Принимаем сегодня участие в форуме Huawey в Сколково с докладом наших проектов в секциях ИскИн и Софт (сокращенно, названия длинные). Вызываем интерес)
RE: Оптимизация архитектуры - Added by VaalKIA almost 5 years ago
Параллелизм распространяется сразу на все 64 клетки
Тогда в чём смысл деления на кластеры и объединения в мультиклетки?
RE: Оптимизация архитектуры - Added by micron_multiclet almost 5 years ago
Смысл чисто технологический - так проще организовать клоковое дерево
RE: Оптимизация архитектуры - Added by Yaisis almost 5 years ago
micron_multiclet wrote:
В мультиклеточных процессорах нет ядер) только клетки или мультиклетки (сообщество 4-х клеток). В Multiclet S1 64 клетки поделенные на 4 кластера по 4 мультиклетки в каждом.
Параллелизм распространяется сразу на все 64 клетки, как естественное свойство микроархитектуры. На программисте это вообще никак не сказывается, та же программа на С преобразуется компилятором в код, который реализуется чипом. Программист только увидит сверхэффективность исполнения программы на новом процессоре и все ( ну примерно так))))
Это я и хотел услышать.
RE: Оптимизация архитектуры - Added by VaalKIA almost 5 years ago
Замечательная информация по топику, на известном ресурсе: https://habr.com/ru/post/480962/
- « Previous
- 1
- …
- 4
- 5
- 6
- Next »