Я слежу за китайскими успехами в области процессоров, а тут как раз пришла новость о создании у нас компьютеров на китайском ЦПУ. Поспешил выложить то что знал об этих процессорах.
Добалю про "бесконечно малую". Нас в институте на такой фразе сразу обрывали и посылали переделывать курсовик.... Тогда-то и приучили что нет просто малых или просто больших величин - они всегда малы или велики по сравнению с чем-то.
Вы не знаете заранее насколько велики или малы будут координаты точек, соответственно абсолютное значение смещения может либо быть проигнорировано при сложении (координаты имеют порядок 1e+20 или больше), либо может привести к серьезному сдвигу всей фигуры (координаты порядка 1e-8 ).
Минимально тут надо поправить на вычисление относительного сдвига, например 0,00001% от координаты проверяемой точки.
Таких проектов использования животных в войне во все времена полно было. Но вот реально кошек в качестве снарядов использовали только в Полтаве против шведов:
«Шведы осадили крепость, и дела в городе ухудшились – из-за неимения патронов россияне использовали куски железа и камни. Бросали с валов их, а также куски деревьев и даже дохлых котов. Однажды русские попали дохлым котом в плечо Карлу XII! На эту неслыханную обиду шведы забросали россиян градом ручных гранат, и те несколько дней не осмеливались повторять эту наглость»
Шведский историк Петер Энглунд «Полтава. Рассказ о гибели одной армии».
Ваша архитектура походит на попытку всунуть OoO во VLIW.
Не так. Я размышлял о том как переложить OoO на плечи компилятора. Процессор в момент выполнения жестко ограничен ресурсами, в отличии от компилятора, который имеет больше свободного времени для разбора кода.
Разгрузка эта будет достигнута ценой постоянных конфликтов параграфов между собой, их перестановкой и, в конечном итоге, pipeline stalls.
Параграфы должны выполняться строго последовательно, а вот линейки команд процеонов могут выполняться как параллельно, так и последовательно в зависимости от свободных ресурсов, именно поэтому я пришел к отложенным операциям записи, когда ядро сначала аккумулирует все записываемые данные от префикса, затем разрешает конфликты и только после этого производит запись.
Как вы вот предполагаете атомарные операции откладывать? Это нарушит их сериализуемость. А атомарные операции нынче повсюду.
Атомарность записи обеспечивается только внутри параграфа.
Хорошо, вот пример на ветвления. Пусть будет обычный CASE на десяток вариантов (или многоуровневый IF-ELSE). В CISC,RISC и VLIW это выльется в десяток последовательных сравнений с переходами. Причем спекулятивное исполнение им не сильно поможет, параллельно можно запустить 2-4 варианта, не больше. Процеоны же позволяют параллельно запустить сравнения по всем вариантам и выдать правильный адрес перехода.
Процеоны не имеют своих кэшей, ходят постоянно в ядра. Т.е. мало того, что все обращения к памяти будут проходить через шину между процеонами и ядрами, так еще здесь же будет постоянно гулять трафик для поддержания когерентности кэшей.
Не так. Все обращения по записи в память откладываются до завершения параграфа, поэтому проблемы когерентности кэшей не будет (если разные процеоны пытаются писать в одну ячейку, более ранние данные сразу заменяются пришедшими позже).
Как кэши вообще эти устроены? Один общий пул для всех ядер? Несколько уровней? Вся производительность в этом месте и умрет.
Кэши двухуровневые. L1 - на ядро, L2 - на процессор. Задачи должны как можно реже мигрировать между ядрами, тогда в кэше L1 будут нужные данные. Именно для разгрузки обращений в память сделаны отложенные операции чтения/записи. А непосредственное чтение возможно только из заранее зарезервированной области.
Все это в итоге выглядит как VLIW — без компилятора, который идеально разложит все обращения к памяти, это все работать не будет.
И да и нет. Это не VLIW - процеонная схема гораздо гибче (в теории) и позволяет выделять переменное количество ресурсов в зависимости от нагрузки. Но увы, компилятор действительно нужен более сложный.
Короткие циклы можно раскрутить на процеонах, как я описывал в статье.
Предположим есть код:
char k=64; ................ //возможно здесь k изменился for (i=0;i<k;i++) sum+=a[i]*b[i];
В этом случае компилятор создает параграф типа-2, в котором будет только ОДНА линейка команд, но параллельно выполняющаяся на нескольких процеонах. А результат просуммируется в конце.
В дополнение, когда появится гос. портал для юридических лиц
Уже давно работают госуслуги для юрлиц.
А вы сами не пробовали получить для себя подтвержденную запись на госуслугах?
На самом деле, куда важнее цифровая подпись. Причём в таком виде, чтобы легко обмениваться финансовой информацией. По типу как это сделано в контур-диадок.
Спекулятивное выполнение можно запланировать на уровне компилятора. Предположим есть код: if (3*a > 255) b=b/10+1; else b++; Компилятор это разбивает на 3 линейки вычисляющиеся параллельно, а в конце просто выбирается нужный результат.
У меня описан немного другой подход - процеон это минимальный вычислительный блок для самых простых операций, но которые могут объединяться в ядре для выполнения сложной команды-параграфа.
А насчет суперFPGA я не совсем понял. Можно пояснить ?
Я слежу за китайскими успехами в области процессоров, а тут как раз пришла новость о создании у нас компьютеров на китайском ЦПУ. Поспешил выложить то что знал об этих процессорах.
А еще Pentium прославился ошибкой FDIV bug - первая ошибка такого класса в микропроцессорах.
А есть ли поддержка иерархической структуры доменов (типа "дерева" в MS AD)?
Добалю про "бесконечно малую". Нас в институте на такой фразе сразу обрывали и посылали переделывать курсовик.... Тогда-то и приучили что нет просто малых или просто больших величин - они всегда малы или велики по сравнению с чем-то.
Вы не знаете заранее насколько велики или малы будут координаты точек, соответственно абсолютное значение смещения может либо быть проигнорировано при сложении (координаты имеют порядок 1e+20 или больше), либо может привести к серьезному сдвигу всей фигуры (координаты порядка 1e-8 ).
Минимально тут надо поправить на вычисление относительного сдвига, например 0,00001% от координаты проверяемой точки.
Таких проектов использования животных в войне во все времена полно было. Но вот реально кошек в качестве снарядов использовали только в Полтаве против шведов:
А как вам вычисляемый GOTO в фортране ? Нет, если его использовать в стиле Switch-Case, то вроде норм. А если метки раскиданы по программе....
Еще можно отдельно телефон для звонков и СМС и отдельно смартфон.
Последний раз я коаксил прокладывать в 1998 году (два длинных цеха соединял) . После - только витая пара.
А вот и попробуйте что-нибудь подобрать, попробуем вместе придумать как это можно закодить для процеонов.
А если в rax окажется 2**32 ?
Вы плохо читали статью. Попробую поподробнее.
Есть CASE
Как это выглядит в коде параграфа для процеонов (предполагаем что а уже в R1):
В NextCommand попадет только результат одной линейки. Или вообще ничего.
Не так. Я размышлял о том как переложить OoO на плечи компилятора. Процессор в момент выполнения жестко ограничен ресурсами, в отличии от компилятора, который имеет больше свободного времени для разбора кода.
Параграфы должны выполняться строго последовательно, а вот линейки команд процеонов могут выполняться как параллельно, так и последовательно в зависимости от свободных ресурсов, именно поэтому я пришел к отложенным операциям записи, когда ядро сначала аккумулирует все записываемые данные от префикса, затем разрешает конфликты и только после этого производит запись.
Атомарность записи обеспечивается только внутри параграфа.
Хорошо, вот пример на ветвления. Пусть будет обычный CASE на десяток вариантов (или многоуровневый IF-ELSE). В CISC,RISC и VLIW это выльется в десяток последовательных сравнений с переходами. Причем спекулятивное исполнение им не сильно поможет, параллельно можно запустить 2-4 варианта, не больше. Процеоны же позволяют параллельно запустить сравнения по всем вариантам и выдать правильный адрес перехода.
Тогда любой цикл без вызова внешних функций - "числодробилка".
Не так. Все обращения по записи в память откладываются до завершения параграфа, поэтому проблемы когерентности кэшей не будет (если разные процеоны пытаются писать в одну ячейку, более ранние данные сразу заменяются пришедшими позже).
Кэши двухуровневые. L1 - на ядро, L2 - на процессор. Задачи должны как можно реже мигрировать между ядрами, тогда в кэше L1 будут нужные данные.
Именно для разгрузки обращений в память сделаны отложенные операции чтения/записи. А непосредственное чтение возможно только из заранее зарезервированной области.
И да и нет. Это не VLIW - процеонная схема гораздо гибче (в теории) и позволяет выделять переменное количество ресурсов в зависимости от нагрузки. Но увы, компилятор действительно нужен более сложный.
Короткие циклы можно раскрутить на процеонах, как я описывал в статье.
Предположим есть код:
char k=64;
................ //возможно здесь k изменился
for (i=0;i<k;i++) sum+=a[i]*b[i];
В этом случае компилятор создает параграф типа-2, в котором будет только ОДНА линейка команд, но параллельно выполняющаяся на нескольких процеонах. А результат просуммируется в конце.
Уже давно работают госуслуги для юрлиц.
А вы сами не пробовали получить для себя подтвержденную запись на госуслугах?
На самом деле, куда важнее цифровая подпись. Причём в таком виде, чтобы легко обмениваться финансовой информацией. По типу как это сделано в контур-диадок.
Спекулятивное выполнение можно запланировать на уровне компилятора. Предположим есть код:
if (3*a > 255) b=b/10+1; else b++;
Компилятор это разбивает на 3 линейки вычисляющиеся параллельно, а в конце просто выбирается нужный результат.
У меня описан немного другой подход - процеон это минимальный вычислительный блок для самых простых операций, но которые могут объединяться в ядре для выполнения сложной команды-параграфа.
А насчет суперFPGA я не совсем понял. Можно пояснить ?
И не только конвейера, еще коммутатора обращений к памяти ( MMU ), управлением задачами и распределением нагрузки.