Один из вариантов ответа - это хорошо известный факт, что люди во всём мире оценивают инфляцию выше реальной. В том числе помнят, как подорожали авто, не обращая внимания на их удельный вес в инфляции.
П.С. Лично про себя - у меня в профиле трат такси, которое выросло не более, чем в 1.5 раза.
По сути единственный рабочий известный мне метод - это заведение лимитов. Для меня это бы выглядело примерно как: - 33% - на ежедневные-ежемесячные траты; - 33% - на среднесрочные траты (медицина, отпуск); - 33% - на долгосрочные (покупка квартиры, накопления).
То есть для условного Димы это будет 100к на каждый месяц. Хочешь "готовую еду" заказывай хочешь - игрушки по $70 со стима покупай, но в лимит по итогам месяца будь добр уложиться.
Любой другой способ (известный мне) способ подвержен постепенной деградации по "методу салями" - человек очень убедительно уговаривает сам себя, что "вот эту же чашечку кофе я могу выпить, да"?
Радость и счастье - это разные вещи. И их смешивание ведёт к фрустрации: "я же каждый день балую себя, покупаю вкусный кофе и круассан - почему я не чувствую себя менее счастливым, чем бедный сосед с 5ю детьми?".
И вкусный пирожок с кофе (не дай бог, чтобы это было вашим самым лучшим воспоминанием) - это как раз радость, которая проходит в моменте и забывается.
Почти всё написанное про архитектуру CPU будто написано из неверных предпосылок (проблема не в том, что CPU считает быстро, но плохо, проблема в том, что быстрый CPU ждёт данных из памяти на Stall) - в итоге выглядит ужасно. Но абзац ниже - квинтэссенция некорректности:
Игровые приставки и ПК. PlayStation 5 и Xbox Series X работают на ~3,5 ГГц, и дальше наращивать такт просто некуда — вместо этого Sony и Microsoft добиваются роста FPS через оптимизацию шейдеров, использование SIMD-инструкций и эффективную многопоточность. Разработчики переориентировались с «разгона» на повышение IPC (instructions per cycle) и асинхронные вычисления, чтобы получить каждый лишний кадр.
Увеличить тактовую частоту можно, ценой удлинения конвейра. Но зачем?
Шейдеры - считаются на видеокарте (и у неё не 3.5 ГГЦ частота)
SIMD-инструкции - это просто частный, далеко не всегда применимый случай увеличения скорости вычислений.
Теперь как правильно (см рисунок ниже):
Демонстрационная картинка из интернета. Примерно 50% времени CPU ждёт данных из памяти и только 50% времени работает.
Все вычисления делятся на вычисления с "регулярным (иногда говорят геометрическим) параллелизмом" (для этого нужны CUDA \ OpenMP .....). И без "регулярного параллелизма" - для этого нужны CPU. И на уровне программной модели - основное направление выделение этого самого "регулярного параллелизма" из существующих алгоритмов.
По поводу CPU (см картинку выше) - основная проблема в том, что процессор ждёт данных из памяти едва ли не больше, чем работает. Проблема также в том, что подсистема памяти включая кэши "хуже прогрессирует" с уменьшением техпроцесса.
По поводу архитектур CPU более детально:
Примерно 50% времени CPU ждёт данных из памяти, и только 50% времени работает. И это ключевая проблема разработки производительных CPU сегодня.
Ускорение процессора - обязательно повлечёт удлинение конвейра. Которое само повлечёт негативные эффекты, как то:
"удорожание" неверного предсказания перехода MissBranchPredict
Увеличение числа спекулятивных и ненужных load - увеличение нагрузки на подсистему памяти.
Уменьшение времени простоя процессора - в основном увеличение ROB (reorder buffer) и prefetch в кэшах. Как уже сказано выше - прогресс подсистемы кэшей куда хуже с уменьшением техпроцесса, чем комбинационной логики (вычислительной части).
Ещё одно - так и не подтверждён ваш тезис, что расширение 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. Скрытые параметры - это про выбор одного из вариантов при коллапсе волновой функции.
Смотрите разницу: - квантовая запутанность - минимум две частицы. Скрытые параметры - не обязательно две. - квантовая запутанность - про эволюцию волновой функции; скрытые параметры - про коллапс;
А почему вы не ищите аномалии в другую сторону?
Один из вариантов ответа - это хорошо известный факт, что люди во всём мире оценивают инфляцию выше реальной. В том числе помнят, как подорожали авто, не обращая внимания на их удельный вес в инфляции.
П.С.
Лично про себя - у меня в профиле трат такси, которое выросло не более, чем в 1.5 раза.
По сути единственный рабочий известный мне метод - это заведение лимитов.
Для меня это бы выглядело примерно как:
- 33% - на ежедневные-ежемесячные траты;
- 33% - на среднесрочные траты (медицина, отпуск);
- 33% - на долгосрочные (покупка квартиры, накопления).
То есть для условного Димы это будет 100к на каждый месяц. Хочешь "готовую еду" заказывай хочешь - игрушки по $70 со стима покупай, но в лимит по итогам месяца будь добр уложиться.
Любой другой способ (известный мне) способ подвержен постепенной деградации по "методу салями" - человек очень убедительно уговаривает сам себя, что "вот эту же чашечку кофе я могу выпить, да"?
А если смотреть на цифры, а не лозунги? Вот я погуглил:
яйца (они же "больше всего" подорожали, да)?
- 2021 год 70р
- 2025 год 120р
Хлем бородинский:
- 2021 год 40+ руб
- 2025 год 60 руб
Воппер (в бургеркинге):
- 2021 год - 200руб
- 2025 год - 300 руб
....
Радость и счастье - это разные вещи.
И их смешивание ведёт к фрустрации: "я же каждый день балую себя, покупаю вкусный кофе и круассан - почему я не чувствую себя менее счастливым, чем бедный сосед с 5ю детьми?".
И вкусный пирожок с кофе (не дай бог, чтобы это было вашим самым лучшим воспоминанием) - это как раз радость, которая проходит в моменте и забывается.
Почти всё написанное про архитектуру CPU будто написано из неверных предпосылок (проблема не в том, что CPU считает быстро, но плохо, проблема в том, что быстрый CPU ждёт данных из памяти на Stall) - в итоге выглядит ужасно. Но абзац ниже - квинтэссенция некорректности:
Увеличить тактовую частоту можно, ценой удлинения конвейра. Но зачем?
Шейдеры - считаются на видеокарте (и у неё не 3.5 ГГЦ частота)
SIMD-инструкции - это просто частный, далеко не всегда применимый случай увеличения скорости вычислений.
Теперь как правильно (см рисунок ниже):
Все вычисления делятся на вычисления с "регулярным (иногда говорят геометрическим) параллелизмом" (для этого нужны CUDA \ OpenMP .....). И без "регулярного параллелизма" - для этого нужны CPU.
И на уровне программной модели - основное направление выделение этого самого "регулярного параллелизма" из существующих алгоритмов.
По поводу CPU (см картинку выше) - основная проблема в том, что процессор ждёт данных из памяти едва ли не больше, чем работает. Проблема также в том, что подсистема памяти включая кэши "хуже прогрессирует" с уменьшением техпроцесса.
По поводу архитектур CPU более детально:
Примерно 50% времени CPU ждёт данных из памяти, и только 50% времени работает. И это ключевая проблема разработки производительных CPU сегодня.
Ускорение процессора - обязательно повлечёт удлинение конвейра. Которое само повлечёт негативные эффекты, как то:
"удорожание" неверного предсказания перехода MissBranchPredict
Увеличение числа спекулятивных и ненужных load - увеличение нагрузки на подсистему памяти.
Уменьшение времени простоя процессора - в основном увеличение ROB (reorder buffer) и prefetch в кэшах. Как уже сказано выше - прогресс подсистемы кэшей куда хуже с уменьшением техпроцесса, чем комбинационной логики (вычислительной части).
Ещё одно - так и не подтверждён ваш тезис, что расширение 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. Скрытые параметры - это про выбор одного из вариантов при коллапсе волновой функции.
Смотрите разницу:
- квантовая запутанность - минимум две частицы. Скрытые параметры - не обязательно две.
- квантовая запутанность - про эволюцию волновой функции; скрытые параметры - про коллапс;
Я в курсе что такое неравенства Белла.
"параллельные" вычисления в квантовом компьютере происходят не за счёт "истинной случайности", а за счёт квантовой запутанности.