Что оптимальнее -- расширение cpu или отдельный блок -- здесь нет однозначного ответа: есть примеры удачных решений как первой категории, так и второй. Тот же упомянутый в статье гомогенный Fujitsu Fugaku.
Валерия, мы говорим о процессоре общего назначения или о специализированном ?
Если о GP CPU, то я хочу увидеть цифры и результаты симуляции на реальных смешанных задачах. Какой оверхед создает добавление матричного расширения в ядро, как часто испольуется это расширение пользовательскими приложениями и какой суммарный прирост производительности мы получим. Логика подсказывает, что из тысячи пользовательских приложений (процессов) только одно будет использовать ускоритель с пользой (да и то не постоянно), для остальных 999-ти процессов наличие этого ускорителя является существенным замедлителем из-за оверхеда связанного с переключением контекста.
смею предположить что матричные регистры вообще не сохраняються при переключении, а содаеться очередь команд от разных контекстов. и если существует несколько пытающихся использовать AMX они ждут друг друга, один поток выполнил часть
Такое возможно только если взаимодействие с матричным усокрителем происходит через ядро ОС, через syscall. Иначе как заблокировать (ожидать) окончания исполнения потока команд выполняющих рассчет матриц ? Ведь пользовательскому процессу запрещено блокировать прерывания, тем более от таймера переключения задач. А если мы работаем через ядро, то нафига нам вагон этих инструкций в вычислительном ядре, не будет ли более логичным унести их наружу в отдельное устройство со своими кэшами и т.д.
Я задал этот вопрос в надежде, что автор статьи провел какие-то исследования в этом направлении и имеет расчетные данные по оверхеду. Тут я полностью придерживаюсь количественного подхода Д. Паттерсона - мы можем впихнуть впроцессор сколь угодно навороченный функционал, но перед этим мы обязаны произвести кое-какие математические выкладки и понять как этот новый функционал повлияет на исполнения всех остальных, не специализированных задач.
В общем, я категорически против того, чтобы из RISC-V делали очередной CISC. Если требуется матричный вычислитель - ставьте отдельный IP блок GPGPU, посадите его на внутренний интерконнект, снабдите вагоном статической памяти не опираясь на размер регистрового файла. Но раздувать ядро и ISA это просто глупо!
А если просто побаловаться, то можно и в процессор расширение :)
Проблема в том, что уже само наличие такого расширения вносит существенные поблемы с переключением контекста, так как ОС обязана сохранять состояние для каждого процесса, независимо от того используется это расширение пользовательским процессом или нет. Иными словами, добавив поддежку матричных инструкций в ядро ОС мы тут же радикально ухудшаем производительность всей системы целиком.
Как вариант, сделать так, чтобы инструкции матрично-векторных расширений не были доступны пользовательскому уровню (в терминах RISC-V - только для Supervisor mode), а взаимодействие происходило бы через ядро операционной системы, т.е. через отдельный syscall. В этом случае сохранять каждый раз состояние огромного векторно-матричного регистрового файла при переключении контекста не потребуется, его нужно будет сохранять и восстанавливать только при выполнении пользователем syscall-а (либо сделать доступ атомарным). Фактически, работа с векторно-матричным ускорителем превращается в работу с отдельным "виртуальным" устройством через стандартный API операционной системы. Если немного подумать, то становится понятно, что такое устройство надо вынести в отдельный кусок железа за переделы вычислительного ядра и таким образом мы получаем GPGPU.
Все эти векторные и матричные расширения существенно увеличивают размер регистрового файла. Мне интересно как это сказывается на времени переключения контекста в Unix подобных операционных системах ? На сколько деградирует производительность ОС на процессорах с такими раширениями ? Ведь системе, при переключении задач, приходится сохранять гигантские обьемы данных во внешней памяти, перекачивать (прогревать) заново все кэши. Как это все работает, и не является ли более оптимальным держать векторно-матричный вычислитель в виде отдельного блока (читай GPGPU) ?
Вопрос был риторический. Очевидно, что нигде сейчас российским предприятиям микросхемы флеш памяти не изготовить. Почему GS Nanotech пытается убедить всех в обратном - не понятно. Могли бы просто говорить, что "корпусируем китайские кристаллы", это будет правдой на 100% и она всех устроит.
Я согласен. Но ведь известно, что доступ к производству даже пототипов микросхем для разработчиков из РФ закрыт уже 2.5 года как. Где они прототип изготовили ? На зеленоградском Микроне, который отродясь не умел во флеш память ?
Никого они не надули, заказчики прекрасно знают и понимают чьи кристаллы там внутри. Заказчикам важно, чтобы микросхема присутствовала в реестре. Более того, они даже рады тому, что там внутри Winbond, а не какое-то чудо от петорзаводского политеха.
После того как Горшенин отказался обзирать разработанный нами процессорный модуль на базе Скифа (и ПЭВМ на базе этого модуля), мне лично всё стало ясно в его деятельности: заносишь денег - обзираем, не заносишь - не обзираем, российскость глубоко вторична или даже опциональна.
С GS Nanotech вообще как-то странно - всем известно что они занимаются только корпусированием кристаллов и своей литографии у них никогда не было. Откуда бы взятся микросхемам своей разработки и тем более своего производства ?
Важный вопрос юристам: достаточно ли выполнить корпусирование произведенного зарубежом кристалла на территории РФ чтобы изготовленная таким образом микросхема считалась микросхемой первого уровня ? ИМХО, тут очередная дырка в законе.
А где я должен был его слушать ? Я читал статью здесь и на сайте ТАСС. В статьях упоминается некий сайт https://dev.mcst.ru/ , на нем присутствуют ссылки для скачивания трех тарболлов с исходниками. Больше я там ничего не нашел. Уже здесь в комментариях начали скидывать полезные ссылки на репозитории, в том числе на https://git.openelbrus.ru/mcst.
Ну по мне так наличие живого репозитория с регулярными коммитами куда более важней чем неуклонное следование требованиям лицензий. У МЦСТ всегда к этому вопросу было пофигистское отношение и ожидать что они в корне его пересмотрят просто наивно. Но если они задумали подтянуть комьюнити, то следовало бы организовать это дело поприличней - репозитории, сайт с доками и wiki, форум/mail-list для общения разработчиков (а не закрытый телеграмм канал).
Меня больше смутило то, что это не git репозиторий в который планируются регулярные коммиты и прочие PR, а просто срез. Типа просили - на-те получите. Это конечно большое достижение, но не то, что требуется современным разработчикам.
Валерия, мы говорим о процессоре общего назначения или о специализированном ?
Если о GP CPU, то я хочу увидеть цифры и результаты симуляции на реальных смешанных задачах. Какой оверхед создает добавление матричного расширения в ядро, как часто испольуется это расширение пользовательскими приложениями и какой суммарный прирост производительности мы получим. Логика подсказывает, что из тысячи пользовательских приложений (процессов) только одно будет использовать ускоритель с пользой (да и то не постоянно), для остальных 999-ти процессов наличие этого ускорителя является существенным замедлителем из-за оверхеда связанного с переключением контекста.
Такое возможно только если взаимодействие с матричным усокрителем происходит через ядро ОС, через syscall. Иначе как заблокировать (ожидать) окончания исполнения потока команд выполняющих рассчет матриц ? Ведь пользовательскому процессу запрещено блокировать прерывания, тем более от таймера переключения задач. А если мы работаем через ядро, то нафига нам вагон этих инструкций в вычислительном ядре, не будет ли более логичным унести их наружу в отдельное устройство со своими кэшами и т.д.
Я задал этот вопрос в надежде, что автор статьи провел какие-то исследования в этом направлении и имеет расчетные данные по оверхеду. Тут я полностью придерживаюсь количественного подхода Д. Паттерсона - мы можем впихнуть впроцессор сколь угодно навороченный функционал, но перед этим мы обязаны произвести кое-какие математические выкладки и понять как этот новый функционал повлияет на исполнения всех остальных, не специализированных задач.
В общем, я категорически против того, чтобы из RISC-V делали очередной CISC. Если требуется матричный вычислитель - ставьте отдельный IP блок GPGPU, посадите его на внутренний интерконнект, снабдите вагоном статической памяти не опираясь на размер регистрового файла. Но раздувать ядро и ISA это просто глупо!
Валерия, разверните пожалуйста мысль по подробнее. Что Вы имеете в виду ?
Проблема в том, что уже само наличие такого расширения вносит существенные поблемы с переключением контекста, так как ОС обязана сохранять состояние для каждого процесса, независимо от того используется это расширение пользовательским процессом или нет. Иными словами, добавив поддежку матричных инструкций в ядро ОС мы тут же радикально ухудшаем производительность всей системы целиком.
Как вариант, сделать так, чтобы инструкции матрично-векторных расширений не были доступны пользовательскому уровню (в терминах RISC-V - только для Supervisor mode), а взаимодействие происходило бы через ядро операционной системы, т.е. через отдельный syscall. В этом случае сохранять каждый раз состояние огромного векторно-матричного регистрового файла при переключении контекста не потребуется, его нужно будет сохранять и восстанавливать только при выполнении пользователем syscall-а (либо сделать доступ атомарным). Фактически, работа с векторно-матричным ускорителем превращается в работу с отдельным "виртуальным" устройством через стандартный API операционной системы. Если немного подумать, то становится понятно, что такое устройство надо вынести в отдельный кусок железа за переделы вычислительного ядра и таким образом мы получаем GPGPU.
Все эти векторные и матричные расширения существенно увеличивают размер регистрового файла. Мне интересно как это сказывается на времени переключения контекста в Unix подобных операционных системах ? На сколько деградирует производительность ОС на процессорах с такими раширениями ? Ведь системе, при переключении задач, приходится сохранять гигантские обьемы данных во внешней памяти, перекачивать (прогревать) заново все кэши. Как это все работает, и не является ли более оптимальным держать векторно-матричный вычислитель в виде отдельного блока (читай GPGPU) ?
А как выглядят такие станки ? Можете дать пару ссылок ? Не требуется ли для него чистая комната ?
Просто обьявить, что упаковка (корпусирование) это второй уровень. Делов то. :)
Михаил, попробуем еще раз что ?
Вопрос был риторический. Очевидно, что нигде сейчас российским предприятиям микросхемы флеш памяти не изготовить. Почему GS Nanotech пытается убедить всех в обратном - не понятно. Могли бы просто говорить, что "корпусируем китайские кристаллы", это будет правдой на 100% и она всех устроит.
Я согласен. Но ведь известно, что доступ к производству даже пототипов микросхем для разработчиков из РФ закрыт уже 2.5 года как. Где они прототип изготовили ? На зеленоградском Микроне, который отродясь не умел во флеш память ?
Никого они не надули, заказчики прекрасно знают и понимают чьи кристаллы там внутри. Заказчикам важно, чтобы микросхема присутствовала в реестре. Более того, они даже рады тому, что там внутри Winbond, а не какое-то чудо от петорзаводского политеха.
После того как Горшенин отказался обзирать разработанный нами процессорный модуль на базе Скифа (и ПЭВМ на базе этого модуля), мне лично всё стало ясно в его деятельности: заносишь денег - обзираем, не заносишь - не обзираем, российскость глубоко вторична или даже опциональна.
С GS Nanotech вообще как-то странно - всем известно что они занимаются только корпусированием кристаллов и своей литографии у них никогда не было. Откуда бы взятся микросхемам своей разработки и тем более своего производства ?
Важный вопрос юристам: достаточно ли выполнить корпусирование произведенного зарубежом кристалла на территории РФ чтобы изготовленная таким образом микросхема считалась микросхемой первого уровня ? ИМХО, тут очередная дырка в законе.
Этот Д.Стэтхем просто кладезь админской мудрости. А кстати, кто это? ;)
А где я должен был его слушать ? Я читал статью здесь и на сайте ТАСС. В статьях упоминается некий сайт https://dev.mcst.ru/ , на нем присутствуют ссылки для скачивания трех тарболлов с исходниками. Больше я там ничего не нашел. Уже здесь в комментариях начали скидывать полезные ссылки на репозитории, в том числе на https://git.openelbrus.ru/mcst.
Трушкин утверждает что они есть в наличии и их много, до 2030 года достаточно. А там уже свой литограф и массовое производство. ;-)))
Отлично!
Ну по мне так наличие живого репозитория с регулярными коммитами куда более важней чем неуклонное следование требованиям лицензий. У МЦСТ всегда к этому вопросу было пофигистское отношение и ожидать что они в корне его пересмотрят просто наивно. Но если они задумали подтянуть комьюнити, то следовало бы организовать это дело поприличней - репозитории, сайт с доками и wiki, форум/mail-list для общения разработчиков (а не закрытый телеграмм канал).
Не как образец для подражания, но хотя бы так:
https://github.com/MikronMIK32/
https://wiki.mik32.ru/Заглавная_страница
PS: Кое-какую документацию по E2K МЦСТ выкладывал в 2020 году.
Как известно, "пусто место святым не бывает". :)
Может быть и к лучшему, что не ввязались в эту тему. Конкурировать с гос конторами бессмысленно.
Да, я в курсе.
Меня больше смутило то, что это не git репозиторий в который планируются регулярные коммиты и прочие PR, а просто срез. Типа просили - на-те получите. Это конечно большое достижение, но не то, что требуется современным разработчикам.