Мы используем файлы cookie и сервисы аналитики. Ознакомьтесь с нашей Политикой сбора данных и выберите, какие типы cookie вы разрешаете:
cookie_policy_accepted — хранит ваш выбор cookiePHPSESSID — сессияkey3 — запоминание входа_ix — единая сессия входа на ixbt.comadminuserskey — вход администратораtopic_add_autosave — автосохранение черновикаls_photoset_target_tmp — временные данные загрузки фотоgeo_country — определяет ваш регион_ga, _ga_*, _ym_uid, _ym_d, _ym_* — статистика посещений__gads, __gpi — таргетирование объявленийВы всегда можете изменить свои предпочтения в настройках.
Ну и совковый аналог первых 8086 писюков — EC1840 на ВМ86.
А вот результат на 1С увидеть было бы интересно (ейной я тоже не пользуюсь, но она есть в 90% организаций в этой стране).И браузерные тесты ещё, с Facebook например, по загрузке CPU оценить.
Видимо метод «уменьшения задержек при доступе к памяти» просочился и туда.
Intel'я всегда славились меньшим latency при доступе к кэшам/памяти по сравнению с AMD, и ноги у уязвимости имхо растут как раз отсюда. Банальное читерство.
Фокус в том, что AMD не позволяет при этом прочитать нужный байт из защищённой области памяти перед спекулятивным выполнением — т.е. обращение к кэшу при этом происходит скорее всего по исходному состоянию регистра или по какому-то умолчанию, возвращаемому в регистр в случае ошибки доступа.
Тест показал, что спекулятивное выполнение на AMD есть, и кэш вроде как трогается, но безрезультатно. Прочитать ничего при этом не удалось.Что вполне себе соответствует заявлению AMD о том, что в их архитектуре при обращении к памяти всегда проверяется уровень доступа.