Pull to refresh

Comments 7

Пока что вы делаете печально известный Maticore (ethz). Использование простой парадигмы Вычисляй Больше сохраняй Меньше (и трюк с циклами - циклы на машине состояний, экономятся tick-и и, возможно, выполняя инкремент параллельно телу цикла) позволили немного повысить эффективность. Да и в общем-то все делают подобные альтернативы максимально похожими на граф исполнения. (https://safari.ethz.ch/architecture_seminar/spring2021/lib/exe/fetch.php?media=manticore.pdf)

К сожалению, шины довольно энергозатратны (да и явный разрыв между публикациями "авторов" суперCPU и собственно самим суперCPU) не дают процессору пойти в жизнь. (а еще тяжесть разработки для него).

Не проще заполнять RS\D триггеры по сигналу, а затем вычитывать последовательность по счетчику? Быстрее, меньше тепла, чуть больше транзисторов. Логическая глубина при записи 2. При чтении - сумматор+декодер.

А в общем - у вас есть 1 дельная мысль в ваших публикациях, а именно - увеличение "специализации" кэша.

(спойлер - большинство PhD исследуют именно кэш. Сложить 2 числа -не более 100 транзисторов. Получить данные из кэша - гораздо больше)

А можно схему этого вашего печально известного? После работы вечером ознакомлюсь. Судя потому что вы считаете что вычитание по счётчику быстрее мгновенной записи в последовательность - можно только задать вопрос - как это у вас большее число получается меньшим? В чем логика? В сравнении работает математика, а не утверждение, и тут всё измеримо, в отличии от рассуждений.

Вы энергопотребление посчитайте, с переносом от одного RS триггеру к другому. Правильно, много. А теперь откройте таблицу задержек логических элементов для 7 nm (не топ). Инвертер - 2 ps. Сумматор - см. logical depth carry-lookahed adder. Умножьте на 4 - получите задержку (в ps).

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

Ссылочку на схему вашего печально известного

Я привел вам ссылку на публикацию, где описаны все особенности данного CPU (дерево шин, обработка циклов и прочее). Подсказка - даже предложенное дерево шин является неоптимальным для обработки тех же нейросетей (да и всего остального).

Создатели DSP, которыми вдохновляются авторы, уже давно перешли на grid-ы (память, ряд ядер (с SIMD), шина, ряд ядер (c SIMD)/кеш, ..., память). Иногда к этому добавляют возможность коммуникации с предыдущими слоями\ исходным банком памяти, чтобы не тащить данные через 100 ядер и 100 шин (ну и соответственно с последующими слоями\целевой памятью).

 А чем отличается количество энергии

Очень сильно отличается. Сколько, по вашему, потребляет селектор? Правильно, примерно n*log(m) переключений (m- количество линий, n - количество переключений транзисторов в 1 селекторе (как правило, меньше 20)).

Для буфера в 1 кБ получаем 3*10 = 30 транзисторов. Для передачи от регистра к регистру - 1000*4 = 4000. И так, разница уже в 2 порядка.

Задержек нет-нет вентили приведены в состояние пропускания сигнала задолго до его прохождения. А вот энергопотребление на работу вентилей - будет. 

Ого. Вообще-то основные задержки - в вентилях (пока еще). А вы делаете ParallelToSerial converter

Я привел вам ссылку на публикацию

вы привели ссылочку на файл. Нет причины доверять.

К этому моменту вы забыли посчитать дешифратор адресов, на что Вам было отвечено

работа дешифратора адресов на каждую ячейку ,счётчик это ещё так - "цветочки"

На это

Вообще-то основные задержки - в вентилях (пока еще).

я ответил уже что ключевой логический элемент приводится в нужное состояние заблаговременно (иначе я не стал0бы даже пытаться, не то, чтобы писать или говорить),

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

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

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

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

Спасибо за подсказу и внимание, буду знать что по циклам похожее было.

Sign up to leave a comment.

Articles