pfg21, эта скорость же не с потолка берётся, как раз таки от изменения реализации внутренних механизмов.
Если ничего не меняется, почему тогда появляются уязвимости типа Meltdown, Spectre, Foreshadow, ZombieLoad, и т.п., когда изменяется внутренняя кухня модели исполнения в процессоре, её исследуют и находят косяки? Если бы ничего не менялось, уязвимости бы не появлялись.
Явно это всё не видно для пользователя, но это не значит что ничего не происходит.
Если раньше в процессоре без спекулятивного исполнения, без бранчпредиктора и без переупорядочивания команд, происходила операция, которая требует результата предыдущей команды или результата чтения из памяти, процессор банально останавливался и стоял ждал, пока придёт ответ, не выполняя никакой полезной работы. Современный процессор же начнёт спокойно выполнять код дальше, который не завязан на результат предыдущей операции.
Да, это не "видно глазом" из-за низких задержек для человеческого восприятия, но ждущий чего-то процессор, и не останавливающийся и делающий другую полезную работу -- это разве не кардинальное изменение процесса исполнения кода?
Если вы пишете hello, world, то разницы не увидите совершенно, за вас уже сделали колоссальную работу разработчики компилятора, ОС, драйверов. А если это какой-то неблокирующий IPC, который утилизирует знания о модели памяти, синхронизации кешей, работы блока переупорядочивания команд, NUMA не дай бог, то будет очень больно не учитывать все современные особенности модели исполнения.
Посмотрите какой-нибудь низкоуровневый проект, типа DPDK. Где для предотвращения cache false sharing в примитивах синхронизации выравнивали данные по границе одной кеш-линии (64 байта), а потом появился Sandy Bridge со своим парным префетчером (две линии по 64 байта за раз), и код сломался пока не пофиксили 128-байтным выравниванием. Архитектура та же, всё то же самое, никаких новых расширений не задействовали, а код сломался в новом процессоре. Почему же?
С кривыми руками можно и хер сломать.
Если 5 лет не было проблем, то и дальше не будет.
Никогда не понимал этих ломателей арча. Что там можно ломать то, если ты сам всё своими руками ставил и конфигурировал...
Если нет привычки читать форумы убунты и копипастить рандомные команды от анонов в шелл, то всё будет норм.
ПС Использую Арч больше 12 лет на нескольких десятках различных устройств, включая x86-64, ARM, серверы, miniPC, ноутбуки. Никогда ничего не ломалось за это время. Может что-то не так делаю. Не думаю, что с манджаро будет как-то иначе.
Синтаксис любого языка учится за пару часов. В чём проблема?
Каждой задаче -- свой инструмент.
Требовать от одного инструмента свойства другого -- неблагодарное занятие.
Если нужно забить гвоздь, используй молоток. Чем-то другим забить можно, не неудобно.
Лучше пропей их, чем отдавай всяким жуликам с онлайн курсов. Эти курсы не научат ничему уникальному, чему ты сам не сможешь научиться. Если не хочется учиться самому, значит это не твоё. Такое учится только самоучкой, стремлением, горящими глазами.
Какой смартфон? На какой операционной системе? Какой версия операционная система?
Современные ОС настолько сложны в плане менеджмента памяти и кешей, что полученные цифры вам ни о чём не скажут.
Арендуйте виртуальный сервер за пределами мордора. С него подключайтесь к нужному PPTP серверу, а уже в свою сторону поднимите адекватный туннель, что-то типа VLESS и подключайтесь уже к нему с пробросом на локальный PPTP.
Станислав Романов, ничего секретного. Погугли. Растбук -- основной и официальный источник знаний.
У неё есть более интерактивная, но чуть более старая версия от Браунского университета.
Есть крутые пошаговые уроки Rustlings.
Есть чуть устаревшие, но не менее крутые видео-лекции от Алекса Кладова.
Станислав Романов, нет там никакого гемора. Вас снова дезинформировали.
Единственная проблема, которую люди не осиливают -- это правила владения, которые проверяет компилятор и не даёт скомпилировать ошибочный код.
В плюсах тоже есть правила владения, которые в разы сложнее, и компилятор не выбрасывает ошибку, если ты что-то неправильно написал. Поэтому плюсовики привыкли писать на удачу и молиться, что не будет неопределённого поведения у кода. А в Расте просто ничего не соберётся, если нарушены правила владения.
Станислав Романов, что расту очень далеко до продакшена, говорят те, кто не осилил язык и находит оправдания. Кто осилил, без проблем уже пишет несколько лет.
Раст давно используют компании типа Гугла, Фейсбука, Амазона и прочие гиганты. В винде, линуксе, андроиде уже значительные части написаны на нём. Половина блокчейна, бирж и крипты написана на расте. Даже сраный Сбербанк уже нанимает разработчиков на этом языке.
Искренне советую изучать Раст вместо плюсов и никого не слушать.
В статье пишется о том, что рескейлинг происходит уже на этапе фрагментного шейдера.
Спустя миллион лет принципиальные хейтеры НВидии и прочих в Линуксы до сих пор не завезли нормальное дробное масштабирование. Даже сама НВидия крайне не советует использовать что-то отличное от целых коэффициентов.
Поэтому ничего не придумано умнее, чем сначала рендерить апскейл с целочисленным коэффициентом, например х2, а потом брать этот фреймбуфер и даунскейлить уже обратно фрагментным шейдером, чтоб мыла было меньше (спойлер: мыла не меньше!).
Если ничего не меняется, почему тогда появляются уязвимости типа Meltdown, Spectre, Foreshadow, ZombieLoad, и т.п., когда изменяется внутренняя кухня модели исполнения в процессоре, её исследуют и находят косяки? Если бы ничего не менялось, уязвимости бы не появлялись.
Явно это всё не видно для пользователя, но это не значит что ничего не происходит.
Если раньше в процессоре без спекулятивного исполнения, без бранчпредиктора и без переупорядочивания команд, происходила операция, которая требует результата предыдущей команды или результата чтения из памяти, процессор банально останавливался и стоял ждал, пока придёт ответ, не выполняя никакой полезной работы. Современный процессор же начнёт спокойно выполнять код дальше, который не завязан на результат предыдущей операции.
Да, это не "видно глазом" из-за низких задержек для человеческого восприятия, но ждущий чего-то процессор, и не останавливающийся и делающий другую полезную работу -- это разве не кардинальное изменение процесса исполнения кода?
Если вы пишете hello, world, то разницы не увидите совершенно, за вас уже сделали колоссальную работу разработчики компилятора, ОС, драйверов. А если это какой-то неблокирующий IPC, который утилизирует знания о модели памяти, синхронизации кешей, работы блока переупорядочивания команд, NUMA не дай бог, то будет очень больно не учитывать все современные особенности модели исполнения.
Посмотрите какой-нибудь низкоуровневый проект, типа DPDK. Где для предотвращения cache false sharing в примитивах синхронизации выравнивали данные по границе одной кеш-линии (64 байта), а потом появился Sandy Bridge со своим парным префетчером (две линии по 64 байта за раз), и код сломался пока не пофиксили 128-байтным выравниванием. Архитектура та же, всё то же самое, никаких новых расширений не задействовали, а код сломался в новом процессоре. Почему же?