Ну вот я тон комментатора выше не поддерживаю, а идею боле-менее да (сам из системного программирования - что-то типа от HPC \ компиляторы и до архитектура системы, чтобы некие требования по перфомансу выполнять).
Поправьте меня, если я не прав, но когда я смотрел ролики про продуктовую фронт-бэк разработку, меня вот какое мнение не покидало:
Основная сложность разработки - это силами небольшого количества высококвалифицированных тех-\тим- лидов буквально пасти большое количество джун+ / миддл- (ну примерно как начальник склада пинает мотивирует грузчиков, чтобы они работале). Появился вот такой-то запрос - прокинуть его через 5-10-20 слоёв монолита / микросервисов.
При этом эти самые джун+/миддл- получали какие-то нереальные в смысле соотношения требования / оплата (по меркам смежных отраслей, или той же самой IT-шечки 10 лет назад) деньги. Ну пусть будет 200-300к/месяц.
Так вот когда всякие курсы поставили на поток выпуск джун-фронтэндеров - случилась предсказуемая заранее фигня: несмотря на низкий общий уровень выходцев с курсов - на рынок всё равно вышло много людей способных выполнять задачи джун+ / миддл- из пунктов выше за меньшие деньги (у пусть будет 100-200к). А как говорится в рекламе "зачем платить больше", если ключевая экспертиза сосредоточена в головах единиц тех самых тех- \ тим- лидов?
Ну и да - одновременно на это наложилось снижение спроса:
"охлажение" после ковида;
дорогой кредит
мнение: зачем нанимать сечас, если скоро расходы на прогеров, благодаря ИИ кратно упадут"
Объясните - в чём я не прав? Если коротко - очень долго фронтам, особенно "в серединке" пирамиды компетенций, переплачивали относительно квалификации в других профессиях, за не особо-то и сложную работу. Сейчас переплачивать перестали, а хотелки - на уровне как раньше.
При чем когда им надо реально схантить кого-то, то они или берут из этой базы или моментально снижают требования с 8 этапов до максимум пары.
Ну это же так не работает в реале в большой компании.
Или ЛПР продавливает бюрократию - мне нужне этот человек (и тогда число раундов снижается до 0) в мою команду, а не ваши раунды интервью.
Или продавливать бюрократию веса не хватает - и тогда летят рассылки "приходите на интервью, ну позязя, мы в вас ну ооооочень заинтересованы, приходишь, а там "почему вы выбрали нашу компанию"".
Ну вот я будучи программистом с 6-8 летним стажем - не брезговал ездить на электричке -> метро. Сейчас, будучи программистом с 15-летним, не брезгую метро (да сэкономленные на такси деньги, как вы догадываетесь пошли на переезд Подольск - Москва).
ОТ - часто гораздо удобнее такси. Банально на ноутбуке работать в ОТ можно (хотя я и очень не люблю), в такси нельзя. А прогуляться электричка-метро (в моём случае это было Бутовская - скобелевская) позволяло нагулять необходимые 10_000 шагов в день.
> Деньги должны работать, и чем быстрее они оборачиваются, тем здоровее экономическая система в целом. Прочитайте что такое "норма сбережения", откуда она берётся и какую функцию для "здоровья экономики" (!sic) выполняет. Узнавать новое - полезно для мозга.
Все вычисления делятся на вычисления с "регулярным (иногда говорят геометрическим) параллелизмом" (для этого нужны CUDA \ OpenMP .....). И без "регулярного параллелизма" - для этого нужны CPU.
При наличии опорных кадров (надеюсь они есть в любом приличном формате) - задача декодирования это задача с регулярным параллелизмом, т.е. задача для GPU (в худшем случае для OpenMP).
Iphone вроде бы с первой версии видео-кодеки на GPU заворачивал.
Если в 2025 году для этого всё ещё нужен мощный CPU - просветите зачем.
Один из вариантов ответа - это хорошо известный факт, что люди во всём мире оценивают инфляцию выше реальной. В том числе помнят, как подорожали авто, не обращая внимания на их удельный вес в инфляции.
П.С. Лично про себя - у меня в профиле трат такси, которое выросло не более, чем в 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. я сова хД
Раскройте термин "недоплачивали", как вы его понимаете, в частности в рыночной экономике?
ок, спасибо.
Не для спора - то тогда это значит, что количество вакансий изменилось за 2 года на на 1.17 * 0.72.
То есть классика - когда число вакансий растёт мы не замечаем, а когда падает - начинаем сравнивать практически с максимумом.
вы же знаете решение задачи "о разборчивой принцессе"?
Ну вот я тон комментатора выше не поддерживаю, а идею боле-менее да (сам из системного программирования - что-то типа от HPC \ компиляторы и до архитектура системы, чтобы некие требования по перфомансу выполнять).
Поправьте меня, если я не прав, но когда я смотрел ролики про продуктовую фронт-бэк разработку, меня вот какое мнение не покидало:
Основная сложность разработки - это силами небольшого количества высококвалифицированных тех-\тим- лидов буквально пасти большое количество джун+ / миддл- (ну примерно как начальник склада
пинаетмотивирует грузчиков, чтобы они работале). Появился вот такой-то запрос - прокинуть его через 5-10-20 слоёв монолита / микросервисов.При этом эти самые джун+/миддл- получали какие-то нереальные в смысле соотношения требования / оплата (по меркам смежных отраслей, или той же самой IT-шечки 10 лет назад) деньги. Ну пусть будет 200-300к/месяц.
Так вот когда всякие курсы поставили на поток выпуск джун-фронтэндеров - случилась предсказуемая заранее фигня: несмотря на низкий общий уровень выходцев с курсов - на рынок всё равно вышло много людей способных выполнять задачи джун+ / миддл- из пунктов выше за меньшие деньги (у пусть будет 100-200к). А как говорится в рекламе "зачем платить больше", если ключевая экспертиза сосредоточена в головах единиц тех самых тех- \ тим- лидов?
Ну и да - одновременно на это наложилось снижение спроса:
"охлажение" после ковида;
дорогой кредит
мнение: зачем нанимать сечас, если скоро расходы на прогеров, благодаря ИИ кратно упадут"
Объясните - в чём я не прав?
Если коротко - очень долго фронтам, особенно "в серединке" пирамиды компетенций, переплачивали относительно квалификации в других профессиях, за не особо-то и сложную работу. Сейчас переплачивать перестали, а хотелки - на уровне как раньше.
Ну это же так не работает в реале в большой компании.
Или ЛПР продавливает бюрократию - мне нужне этот человек (и тогда число раундов снижается до 0) в мою команду, а не ваши раунды интервью.
Или продавливать бюрократию веса не хватает - и тогда летят рассылки "приходите на интервью, ну позязя, мы в вас ну ооооочень заинтересованы, приходишь, а там "почему вы выбрали нашу компанию"".
У меня только одни вопрос-с почему в мае 2024 новых вакансий на 17% больше, чем в мае 2024?
Хотел бы добавить одно уточнение (не отменяя общей правильности ответа):
У GPU (в первую очередь nVidia) всё-таки есть определённые проблемы с fp64 вычислениями. Как производительностью так и точностью (в ряде сценариев).
То есть доля правды, в словах человека выше - всё же есть.
Ну вот я будучи программистом с 6-8 летним стажем - не брезговал ездить на электричке -> метро.
Сейчас, будучи программистом с 15-летним, не брезгую метро (да сэкономленные на такси деньги, как вы догадываетесь пошли на переезд Подольск - Москва).
ОТ - часто гораздо удобнее такси.
Банально на ноутбуке работать в ОТ можно (хотя я и очень не люблю), в такси нельзя. А прогуляться электричка-метро (в моём случае это было Бутовская - скобелевская) позволяло нагулять необходимые 10_000 шагов в день.
> Деньги должны работать, и чем быстрее они оборачиваются, тем здоровее экономическая система в целом.
Прочитайте что такое "норма сбережения", откуда она берётся и какую функцию для "здоровья экономики" (!sic) выполняет. Узнавать новое - полезно для мозга.
При наличии опорных кадров (надеюсь они есть в любом приличном формате) - задача декодирования это задача с регулярным параллелизмом, т.е. задача для GPU (в худшем случае для OpenMP).
Iphone вроде бы с первой версии видео-кодеки на GPU заворачивал.
Если в 2025 году для этого всё ещё нужен мощный CPU - просветите зачем.
А почему вы не ищите аномалии в другую сторону?
Один из вариантов ответа - это хорошо известный факт, что люди во всём мире оценивают инфляцию выше реальной. В том числе помнят, как подорожали авто, не обращая внимания на их удельный вес в инфляции.
П.С.
Лично про себя - у меня в профиле трат такси, которое выросло не более, чем в 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 товарища констебля сохранность хитрой задницы не входит ни с каким весом.
Поэтому на месте задницы - лучше знать.