Сообщество

Условия, при которых сопроцессор может быть эффективен:
1. Необходима очень длинная непрерывная последовательность арифметических операций. От длины зависит доля накладных расходов на преобразование операнда из традиционного, позиционного вида в модулярно-логарифмический. Чем короче последовательность, тем ниже эффективность. При сравнении эти расходы никак не учитывались, хотя для эффективности конвейерной организации процесса преобразования, очень важна непрерывность его загрузки. Подобные алгоритмы единичны.
2. В этой последовательности преимущественно должны быть операции умножения, деления и т.п. (а не сложения и вычитания). В реальности же, доля сложений и вычитаний составляет более 50% от общего количества операций.
3. В современных процессорах и сложение и умножение, в потоке, выполняется за один такт. Заменяя в модулярно-логарифмическом сопроцессоре умножение сложением, мы вряд ли сократим длительность такта, так как она зависит не только от АЛУ, но и от технологии, схемотехники и общей организации вычислительного процесса.

micron_multiclet wrote:

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

P.S. Вернее даже не сомнительное, а заблудительное. Сказано так, что не может перемежаться другими коммандами, которых полно в любой программе. А на деле, я пояснил точку зрения.

И физические модели и генерация реалистичного изображения в играх связаны с "длинными непрерывными последовательностями арифметических операций". А вот задачи управления, как правило другие. Сняли с датчика значение (в нормальном виде) сделали несколько операций с ним и выдали результат на какое-либо исполнительное устройство (также в нормальном виде). Здесь нет длинных последовательностей, а есть большой объем вычислений состоящий из массы коротких цепочек.
P.S. Речь идет о характерных чертах "арифметики", а не о том, какие еще команды есть в программе. Это "не от той стенки гвоздь"!

micron_multiclet wrote:

Условия, при которых сопроцессор может быть эффективен:
1. Необходима очень длинная непрерывная последовательность арифметических операций. От длины зависит доля накладных расходов на преобразование операнда из традиционного, позиционного вида в модулярно-логарифмический. Чем короче последовательность, тем ниже эффективность. При сравнении эти расходы никак не учитывались, хотя для эффективности конвейерной организации процесса преобразования, очень важна непрерывность его загрузки. Подобные алгоритмы единичны.
2. В этой последовательности преимущественно должны быть операции умножения, деления и т.п. (а не сложения и вычитания). В реальности же, доля сложений и вычитаний составляет более 50% от общего количества операций.
3. В современных процессорах и сложение и умножение, в потоке, выполняется за один такт. Заменяя в модулярно-логарифмическом сопроцессоре умножение сложением, мы вряд ли сократим длительность такта, так как она зависит не только от АЛУ, но и от технологии, схемотехники и общей организации вычислительного процесса.

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

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

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

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

Yaisis wrote:

Тут встаёт другой вопрос -- насколько затратно реализовать в процессоре сразу две системы ?

Я бы расширил целые числа до дробей, это принципиально расширяет поле деятельности до рациональных чисел, вместо ЛСС и FP, если уж вопрос так стоит.

VaalKIA wrote:

Yaisis wrote:

Тут встаёт другой вопрос -- насколько затратно реализовать в процессоре сразу две системы ?

Я бы расширил целые числа до дробей, это принципиально расширяет поле деятельности до рациональных чисел, вместо ЛСС и FP, если уж вопрос так стоит.

Я так понял, ЛСС -- это и есть дробное число.
Оно внутри состоит из целой части и дробной, плюс бит знака числа.

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 (АЛУ для целых чисел почти в тупую используется, за исключением округления) и по диапазону очень неплохо будет, можно и научные расчёты делать.

VaalKIA wrote:

Расшифровывается как Логарифмическая Система Счисления (это термин авторов ЛСС сопроцессора), честно гвооря, не вдавался в подробности, плавающая там точка (FP - Floating Point) или фиксированная(что программисты как раз и ассоциируют с дробным числом). И вы не путаете дроби и дробные числа?

Я вначале подумал, что там дробь, но похоже, что там фиксированная точка.

Давно я тут не был и что-то тихо тут у вас стало.

Зашёл сюда чтобы написать следующее:
У вас пока процессор слабо развитый и поэтому я подумал, что может вам создать конкурента Arduino и всяким микроконтроллерам.

Я не знаю, как там устроено, но в их процессорах наверняка нет суперскалярности, а ваш четырёхклеточный будет работать, как суперскалярный по производительности и при этом мало потреблять энергии.
Поэтому вы можете все микроконтроллеры уделать.
Они не будут там встраивать суперскалярность, так как это повысит энергопотребление и сложность чипа.
И таким образом ваша архитектура идеально туда ложиться.
Тем более с 4-мя клетками у вас нет проблем, а там этого хватит.
Если что, то вы и 8 можете сделать. Может даже и 16.
Плюс там не нужна ОС, надо будет только прошивки с кодом загружать и всё.
Т.е. как раз подходит для вашего текущего развития.
Нужен будет компилятор и набор библиотек.

Техпроцесс там тоже наверно не такой уж современный.
И частоты наверно небольшие.

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

Только вам надо будет ещё соответствовать по цене китайским аналогам, иначе все будут покупать и дальше китайские модули.
(возможно с ценой у вас возникнут проблемы)

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

Несколько месяцев нет новостей, хотелось бы знать как поживает Мультиклет.

Да, действительно, как-то мы забросили форумные и сайтовые новости) с одной стороны, разработки и идеи проектов приобретают секретный характер, а с другой - нас же всегда критиковали за большой объем пиара, не подкрепленный ярдами освоения бюджетных средств, как у некоторых (не будем показывать пальцем))). Так что тихо ваяем «за печкой» 64 клеточник на 28 нм, улучшаем C компилятор (который, кстати, на кормарке уже лучше, чем Байкал и Эльбрус - см. статью на хабре), и активно готовим еще ряд проектов, о которых позже расскажем обязательно. Но первые новостные тексты, как обычно - на синьюс и/или хабре.

micron_multiclet wrote:

улучшаем C компилятор (который, кстати, на кормарке уже лучше, чем Байкал и Эльбрус - см. статью на хабре)

Можно по точнее какую статью имеете ввиду? Хоть название

EviLOne wrote:

micron_multiclet wrote:

улучшаем C компилятор (который, кстати, на кормарке уже лучше, чем Байкал и Эльбрус - см. статью на хабре)

Можно по точнее какую статью имеете ввиду? Хоть название

https://habr.com/ru/post/434982/

Я так понял, что S1 -- это 16 ядерный процессор, каждое ядро которого состоит из 4 клеток.
Т.е. получается в других процессорах это суперскалярность, а тут более эффективная её реализация, через клетки.

И получается, что аппаратное распараллеливание действует всего на 4 клетки ?
Или код загружается сам во все 64 клетки и там расспараллеливается, но при этом связаны между собой только каждые 4 клетки ?

И как это программируется -- один код для всего процессора или программист сам разбивает код на 16 потоков, которые уже распараллеливаются сами в каждом ядре ?

В мультиклеточных процессорах нет ядер) только клетки или мультиклетки (сообщество 4-х клеток). В Multiclet S1 64 клетки поделенные на 4 кластера по 4 мультиклетки в каждом.
Параллелизм распространяется сразу на все 64 клетки, как естественное свойство микроархитектуры. На программисте это вообще никак не сказывается, та же программа на С преобразуется компилятором в код, который реализуется чипом. Программист только увидит сверхэффективность исполнения программы на новом процессоре и все ( ну примерно так))))

Принимаем сегодня участие в форуме Huawey в Сколково с докладом наших проектов в секциях ИскИн и Софт (сокращенно, названия длинные). Вызываем интерес)

sorry Huawei of course

Параллелизм распространяется сразу на все 64 клетки

Тогда в чём смысл деления на кластеры и объединения в мультиклетки?

Смысл чисто технологический - так проще организовать клоковое дерево

micron_multiclet wrote:

В мультиклеточных процессорах нет ядер) только клетки или мультиклетки (сообщество 4-х клеток). В Multiclet S1 64 клетки поделенные на 4 кластера по 4 мультиклетки в каждом.
Параллелизм распространяется сразу на все 64 клетки, как естественное свойство микроархитектуры. На программисте это вообще никак не сказывается, та же программа на С преобразуется компилятором в код, который реализуется чипом. Программист только увидит сверхэффективность исполнения программы на новом процессоре и все ( ну примерно так))))

Это я и хотел услышать.

Замечательная информация по топику, на известном ресурсе: https://habr.com/ru/post/480962/