Ещё одно - так и не подтверждён ваш тезис, что расширение ISA потребует поддержки в прикладном коде.
И да, реализация BLAS потребует адаптации к новым взможностям процессора.
Сначала реализовываем BLAS на "урезанном" (удобном для вас) наборе интринсиков без дополнительных расширений (100% цель достигнута с той же эффективностью и в сроки что и у вас); А потом ещё и оптимизировать, если получиться, с использованием расширенного набора инструкций - 150% эффективности от вашей реализации. То есть с строго лучше.
Более того: в первом же комментарии было указано, что мiddleware (включая библиотеки) придётся переделывать. С чем вы спорите?
Вы правильно прочувствовали суть проблемы, но я немного формализую Ваш ответ.
Не надо так - это неверная переформулировка.
Во-вторых размер контекста не столь критичен в мире GP CPU (про RVA - это же к тому, чтобы задуматься "что важно что не важно в мире CPU" у вас эти настройки похожи на микроконтроллерные а не CPU-шные).
Проблема в невозможности проводить оптимизации компилятору при любом не статическом вызове (call / ret - с динамически слинкованной библиотекой вообще без шансов, со статически слинкованной - или -lto или дополнительные фазы анализа, без гарантии отсутствия false positive) может измениться контекст.
Именно по этой причине я считаю, что векторные вычисления должны быть вынесены в отдельный аппаратный блок, а не интегрированны в основное ядро.
Не уверен, что это хорошее решение. У нас уже есть GPU / NPU(скорее зонтичный термин) для тяжеловесных решений. А для легковесных - latency критически важно. Какое latency и какой ценой сможете обеспечить для 1, 2 или 5 векторных инструкций? Типовой случай - в цикле делается сколько-то векторных инструкций и "чуть-чуть" дорабатывается не-векторными. Ну и что делать будете?
> middleware в виде (1)компиляторов, (2)ОС, (3)платформ и (4)библиотек - которое пишется один раз...
... Или Вы полагаете, что достаточно добавить поддержку в компилятор и на этом успокоиться ?
Это очень плохой способ вести дискуссию ((
========================================
Прошу учесть, что RVA профиль не для микроконтроллеров, а для +/- полноценных процессоров, и в мире процессоров многие ваши умолчания могут быть просто не верны: "The RVA20 profiles are intended to be used for 64-bit application processors running rich OS stacks. Only user-mode (RVA20U64) and supervisor-mode (RVA20S64) profiles are specified in this family".
У разработчика цифровой микросхемы каждый вентиль на счету.
Это прям классическое "лучшее враг хорошего" и нездоровый перфикционизм. Выиграть +1% площади для GP CPU - намного менее полезно, чем "заранее потерять 1% пользователей". Потому, что этот 1% неудовлетворённых пользователей всегда будет тянуть вас назад.
Вот про кэши - кажется, что это может добавить довольно много лишней сложности / проблем / аппаратных ошибок. А может быть и "удастся проскочить (типа игнорим все "тонкие" настройки)"- тут судить не берусь, надо прям читать и разбираться - но всё-таки это стандарт для очень гетерогенного набора изделий, а не спека на одно изделие.
> middleware для того и существует, чтобы ISA не проникала в опльзовательский код
И конечный софт и библиотеки придется адаптировать к новым инструкциям
Объясните как вы видите, что наличие дополнительных инструкций влияет на прикладной код (напоминаю RVA - про процессоры, а не микроконтроллеры). Что интерфейс numpy (или BLAS или pytorch) должен измениться из-за изменения ISA?
Векторное расширение проблемы, какие?
Before using the vector unit, we must “configure” it
Стейт (длина / битность...), который влияет семантику векторных инструкций.
То есть при выполнении любой векторной инструкции разработчику компилятора следует убедиться, что "стейт" векторного расширения не был изменён (например пользовательский код использует 2 библиотеки для работы с векторами или одна библиотека вызывает другую).
Или даже (глупый, но функционально не запрещённый возможный пример) - работа с векторами в обработчике сигналов? Вы компилируете библиотеку, а ход трасса кода такая: 1. Настройка стейта векторного расширения 2. Уход в обработчик сигнала, перенастройка стейта векторного расширения 3. Возврат в пользовательский кода и выполнение векторной инструкции с неверный стейтом
Про площадь - ну допустим (хотя видится, что при реализации по-уму вся эта не критичная по площади комбинаторика будет о-малое занимать). Ну с векторным расширением, насколько я краем уха слышал в RISC-V проблемы.
ведь все эти расширения должны поддерживаться в софте
Э.... а вот это вообще не понял. Middlewaare (в виде компиляторов, ОС, платформ и библиотек - которое пишется один раз) для того и существует, чтобы писатель конечного софта этим не заморачивался.
я сова - то есть у меня продуктивная работа начинается как раз часов в 16 а то и 19.
Так вот как-то поставил себе цель сменить расписание на "пораньше". В течении полу-года я вставал в 9, приходил на работу в 10.30, шёл в спортзал в 12.00 затарившись кофе (был на работе).
Через пол-года я понял, что никакого значимого изменения в ритмах суточной активности (это когда в какое время дня я тряпка выжатая, а в какое хочется работнуть, в том числе головой) - не произошло.
Из этого я сделал выводы: 1. "быть совой" достаточно объективный феномен, как минимум чтобы за пол-года его нельзя было "перевоспитать". 2. я сова хД
Я всегда воспринимал NIST - как "на 5 лет впереди ГОСТ", по понятным причинам (но с безопасностью давно не соприкосался, не в курсе выпустили наши аналог или нет).
Но вот эта устаревшая фигня со "сложными" паролями затянулась, мне неясно из-за чего (более soft-skills коллеги ещё в 2017 говорили, что из-за человеческой инертности).
С моей точки зрения достаточно увидеть пароли пользователя: " - "колобок-1" "колобок-2"...."колобок-33" - чтобы понять, что пора что-то в консерватории менять.
Сложные уникальные пароли трудно запоминать. Рекомендации безопасности требуют создавать длинные пароли, состоящие из случайных символов. Однако человек не может держать много несуразных строк в памяти. Как итог, в ход идут записи в открытом виде, которые хранятся в небезопасных местах, на виду у всех желающих. А еще их можно потерять.
Если ваш системный администратор требует этого - немедленно отправьте его на курсы повышения квалификации. Если ИБ-специалист - выгоните его.
Даже в гос.структурах, 8 лет как best practices длинные, легко запоминаемые пользователями, желательно с индивидуальными особенностями литерации пароли, без обязательного срока экспирации (NIST-2017 https://pages.nist.gov/800-63-3/sp800-63-3.html ).
Вы хотите двух, слабо совместимых вещей: - быть инженером - сидеть в башне из слоновой кости (заниматься "высокой" деятельностью игнорируя потребности реального мира).
Во-первых: инженер - это человек, который решает технические задачи в условиях ограничения реального мира. И да вот сейчас реальный мир диктует вот такие ограничения (в том числе экономические).
Во-вторых куча мест (давайте про IT) - где нужна высокая квалификация инженера. Я вот работаю в системном программировании (компилятор, HPC, дизайн аппаратных модулей) где огромное количество высокоинтеллектуальных задач. Тянете? Идите к нам (ЗП +/- такие же как в прикладном, только задачи интереснее). Не тянете - идите перекладывать JSON-ы за хорошие деньги, зачем жаловаться.
Про кухню - вы возмущаетесь тем, что не решена хорошо известная и сложная проблема "последней мили до входной двери клиента". Возмущаетесь так, будто открыли Америку. Нет проблема хорошо известна и текущая точка оптимума (частью которой является стоимость труда инженеров) - находится вот там, где находится.
Ну и последнее: наша, инженеров, итоговая миссия - делать жизнь людей лучше (комфортнее, интереснее, сытнее, долголетнее....). Сейчас мы добрались до массового сегмента. Это абсолютно везде сопровождается снижением средних требований, но ростом максимальных. Так это же замечательно - жизнь людей улучшается, сотни тысяч людей (даже без особого таланта) становятся инженерами и хорошо зарабатывают. Те, кто с особым талантом - тоже могут найти своё место.
дело не в маркетинге, а в асимметрии информации что собственно и является причиной деградации исходного рынка "лимонов" (подержанных авто).
Если у вас есть агент - который делает за вас всю работы, а вы не можете проверить его не то, что "до", но и в процессе и сразу после - всё такой рынок почти неизбежно испортится.
Ну смотря как вы определяете "опасность". Вот например репутацию вы упомянули, а недополученную (хоть от финансовых операций хоть от коммерческих) - почему-то нет.
Нет. 1. Квантовая запутанность - это общее состояние (общая волновая функция) минимум двух частиц. 2. Скрытые параметры - это про выбор одного из вариантов при коллапсе волновой функции.
Смотрите разницу: - квантовая запутанность - минимум две частицы. Скрытые параметры - не обязательно две. - квантовая запутанность - про эволюцию волновой функции; скрытые параметры - про коллапс;
А это как раз разница между истинной случайностью и недостатком информации.
"Истинная" и "неистинная" случайности тут вообще не при чём (замените во всех своих рассуждениях "истинную случайность" на "крайне сложные вычисления" - ничего не изменится).
По уму тут нужны: - неравенства Бэлла, чтобы доказать истинную случайность. - или квантовая запутанность частиц - чтобы объяснить откуда берётся "параллельность" вычислений.
> Главное не переборщить с такими "сбросами", а то потом нужно будет лечиться в другом месте...))
nochnoj: кончаются к 50 годам от цирроза
Это проблема всех многих типовых несогласных желающих выглядеть "умнее большинства". Начисто игнорируют часть важных уже упонянутых моментов, лишь бы показать себя в белом пальто.
ИБ - это расходные статьи, которые обосновываются "зато с вами не случилось ХХХ". Бизнес часто положительных эффектов "пряника" от ИБ не видит.
При этом потребность в ИБ для самого малого бизнеса (а не их клиентов) - сомнительна. У них и денег меньше, в среднем, и удельные расходы на ИБ (из-за эффекта масштаба) выше и тяжесть последствий при реализации риска ниже.
Ещё одно - так и не подтверждён ваш тезис, что расширение ISA потребует поддержки в прикладном коде.
Сначала реализовываем BLAS на "урезанном" (удобном для вас) наборе интринсиков без дополнительных расширений (100% цель достигнута с той же эффективностью и в сроки что и у вас);
А потом ещё и оптимизировать, если получиться, с использованием расширенного набора инструкций - 150% эффективности от вашей реализации.
То есть с строго лучше.
Более того: в первом же комментарии было указано, что мiddleware (включая библиотеки) придётся переделывать. С чем вы спорите?
Не надо так - это неверная переформулировка.
Во-вторых размер контекста не столь критичен в мире GP CPU (про RVA - это же к тому, чтобы задуматься "что важно что не важно в мире CPU" у вас эти настройки похожи на микроконтроллерные а не CPU-шные).
Проблема в невозможности проводить оптимизации компилятору при любом не статическом вызове (call / ret - с динамически слинкованной библиотекой вообще без шансов, со статически слинкованной - или -lto или дополнительные фазы анализа, без гарантии отсутствия false positive) может измениться контекст.
Не уверен, что это хорошее решение.
У нас уже есть GPU / NPU(скорее зонтичный термин) для тяжеловесных решений.
А для легковесных - latency критически важно. Какое latency и какой ценой сможете обеспечить для 1, 2 или 5 векторных инструкций?
Типовой случай - в цикле делается сколько-то векторных инструкций и "чуть-чуть" дорабатывается не-векторными. Ну и что делать будете?
Это очень плохой способ вести дискуссию ((
========================================
Прошу учесть, что RVA профиль не для микроконтроллеров, а для +/- полноценных процессоров, и в мире процессоров многие ваши умолчания могут быть просто не верны: "The RVA20 profiles are intended to be used for 64-bit application processors running rich OS stacks. Only user-mode (RVA20U64) and supervisor-mode (RVA20S64) profiles are specified in this family".
Это прям классическое "лучшее враг хорошего" и нездоровый перфикционизм. Выиграть +1% площади для GP CPU - намного менее полезно, чем "заранее потерять 1% пользователей". Потому, что этот 1% неудовлетворённых пользователей всегда будет тянуть вас назад.
Вот про кэши - кажется, что это может добавить довольно много лишней сложности / проблем / аппаратных ошибок. А может быть и "удастся проскочить (типа игнорим все "тонкие" настройки)"- тут судить не берусь, надо прям читать и разбираться - но всё-таки это стандарт для очень гетерогенного набора изделий, а не спека на одно изделие.
Объясните как вы видите, что наличие дополнительных инструкций влияет на прикладной код (напоминаю RVA - про процессоры, а не микроконтроллеры).
Что интерфейс numpy (или BLAS или pytorch) должен измениться из-за изменения ISA?
Стейт (длина / битность...), который влияет семантику векторных инструкций.
То есть при выполнении любой векторной инструкции разработчику компилятора следует убедиться, что "стейт" векторного расширения не был изменён (например пользовательский код использует 2 библиотеки для работы с векторами или одна библиотека вызывает другую).
Или даже (глупый, но функционально не запрещённый возможный пример) - работа с векторами в обработчике сигналов?
Вы компилируете библиотеку, а ход трасса кода такая:
1. Настройка стейта векторного расширения
2. Уход в обработчик сигнала, перенастройка стейта векторного расширения
3. Возврат в пользовательский кода и выполнение векторной инструкции с неверный стейтом
Про площадь - ну допустим (хотя видится, что при реализации по-уму вся эта не критичная по площади комбинаторика будет о-малое занимать). Ну с векторным расширением, насколько я краем уха слышал в RISC-V проблемы.
Э.... а вот это вообще не понял.
Middlewaare (в виде компиляторов, ОС, платформ и библиотек - которое пишется один раз) для того и существует, чтобы писатель конечного софта этим не заморачивался.
я сова - то есть у меня продуктивная работа начинается как раз часов в 16 а то и 19.
Так вот как-то поставил себе цель сменить расписание на "пораньше".
В течении полу-года я вставал в 9, приходил на работу в 10.30, шёл в спортзал в 12.00 затарившись кофе (был на работе).
Через пол-года я понял, что никакого значимого изменения в ритмах суточной активности (это когда в какое время дня я тряпка выжатая, а в какое хочется работнуть, в том числе головой) - не произошло.
Из этого я сделал выводы:
1. "быть совой" достаточно объективный феномен, как минимум чтобы за пол-года его нельзя было "перевоспитать".
2. я сова
хД
Так профиль (с набором обязательных расширений) - это же наоборот огромный шаг вперёд к унификации.
То есть теперь будет минимальный набор расширений, на наличие которых компилятор может закладываться.
Проблема как раз в том, что профили внедрили слишком поздно и всяких кадавров успели понаделать.
В KPI товарища констебля сохранность хитрой задницы не входит ни с каким весом.
Поэтому на месте задницы - лучше знать.
Я всегда воспринимал NIST - как "на 5 лет впереди ГОСТ", по понятным причинам (но с безопасностью давно не соприкосался, не в курсе выпустили наши аналог или нет).
Но вот эта устаревшая фигня со "сложными" паролями затянулась, мне неясно из-за чего (более soft-skills коллеги ещё в 2017 говорили, что из-за человеческой инертности).
С моей точки зрения достаточно увидеть пароли пользователя: " - "колобок-1" "колобок-2"...."колобок-33" - чтобы понять, что пора что-то в консерватории менять.
Огромное спасибо за статью.
А какие модели максимум можно обучить на 8RTX4090 / H100?
Было бы интересно посмотреть что произойдёт с ростом модели (70B - влезет или нет?)
Selectel
Если ваш системный администратор требует этого - немедленно отправьте его на курсы повышения квалификации.
Если ИБ-специалист - выгоните его.
Даже в гос.структурах, 8 лет как best practices длинные, легко запоминаемые пользователями, желательно с индивидуальными особенностями литерации пароли, без обязательного срока экспирации (NIST-2017 https://pages.nist.gov/800-63-3/sp800-63-3.html ).
Вы хотите двух, слабо совместимых вещей:
- быть инженером
- сидеть в башне из слоновой кости (заниматься "высокой" деятельностью игнорируя потребности реального мира).
Во-первых: инженер - это человек, который решает технические задачи в условиях ограничения реального мира. И да вот сейчас реальный мир диктует вот такие ограничения (в том числе экономические).
Во-вторых куча мест (давайте про IT) - где нужна высокая квалификация инженера. Я вот работаю в системном программировании (компилятор, HPC, дизайн аппаратных модулей) где огромное количество высокоинтеллектуальных задач. Тянете? Идите к нам (ЗП +/- такие же как в прикладном, только задачи интереснее). Не тянете - идите перекладывать JSON-ы за хорошие деньги, зачем жаловаться.
Про кухню - вы возмущаетесь тем, что не решена хорошо известная и сложная проблема "последней мили до входной двери клиента". Возмущаетесь так, будто открыли Америку. Нет проблема хорошо известна и текущая точка оптимума (частью которой является стоимость труда инженеров) - находится вот там, где находится.
Ну и последнее: наша, инженеров, итоговая миссия - делать жизнь людей лучше (комфортнее, интереснее, сытнее, долголетнее....). Сейчас мы добрались до массового сегмента. Это абсолютно везде сопровождается снижением средних требований, но ростом максимальных. Так это же замечательно - жизнь людей улучшается, сотни тысяч людей (даже без особого таланта) становятся инженерами и хорошо зарабатывают. Те, кто с особым талантом - тоже могут найти своё место.
Что по-вашему не так? По-моему всё так.
дело не в маркетинге, а в асимметрии информации что собственно и является причиной деградации исходного рынка "лимонов" (подержанных авто).
Если у вас есть агент - который делает за вас всю работы, а вы не можете проверить его не то, что "до", но и в процессе и сразу после - всё такой рынок почти неизбежно испортится.
Это случай, когда надо объяснять, что значат "тэги" <pedant mode>?
Really?
<pedant mode>
Я понимаю "горячий" заголовок, но дистрибутивность - это закон согласования ДВУХ бинарных операций.
</pedenat mode>
Ну смотря как вы определяете "опасность". Вот например репутацию вы упомянули, а недополученную (хоть от финансовых операций хоть от коммерческих) - почему-то нет.
Нет.
1. Квантовая запутанность - это общее состояние (общая волновая функция) минимум двух частиц.
2. Скрытые параметры - это про выбор одного из вариантов при коллапсе волновой функции.
Смотрите разницу:
- квантовая запутанность - минимум две частицы. Скрытые параметры - не обязательно две.
- квантовая запутанность - про эволюцию волновой функции; скрытые параметры - про коллапс;
Я в курсе что такое неравенства Белла.
"параллельные" вычисления в квантовом компьютере происходят не за счёт "истинной случайности", а за счёт квантовой запутанности.
"Истинная" и "неистинная" случайности тут вообще не при чём (замените во всех своих рассуждениях "истинную случайность" на "крайне сложные вычисления" - ничего не изменится).
По уму тут нужны:
- неравенства Бэлла, чтобы доказать истинную случайность.
- или квантовая запутанность частиц - чтобы объяснить откуда берётся "параллельность" вычислений.
Это проблема
всехмногих типовых несогласных желающих выглядеть "умнее большинства".Начисто игнорируют часть важных уже упонянутых моментов, лишь бы показать себя в белом пальто.
Тяжесть последствий при реализации риска для малого бизнеса существенно меньше.
Восстановили бэкап базы с прошлой недели (раз в неделю делаем air gap бэкап), текущие заказы восстановили из "оперативной памяти" исполнителей.
ИБ - это расходные статьи, которые обосновываются "зато с вами не случилось ХХХ".
Бизнес часто положительных эффектов "пряника" от ИБ не видит.
При этом потребность в ИБ для самого малого бизнеса (а не их клиентов) - сомнительна.
У них и денег меньше, в среднем, и удельные расходы на ИБ (из-за эффекта масштаба) выше и тяжесть последствий при реализации риска ниже.