Spoiler — новая уязвимость в процессорах Intel

в ryzen они под вопли про «элементы исскусственного интеллекта» вхерачили в проц блок для «ускорения» бенчмарков

Большей чуши не читал. Пишущий вообще не особо понимает, что это за блок такой. Который не совсем отдельный блок, и который называется opCACHE. Кстати, тоже потенциальное отверстие.

Да незачто, я просто редко отвечаю, так как мало достаточно времени в последнее время, а матчасть вот подтянул в этом обсуждении, спасибо.

Большей чуши не читал. Пишущий вообще не особо понимает, что это за блок такой. Который не совсем отдельный блок, и который называется opCACHE.

Ну, пруфов от AMD не будет, по очевидным причинам. Но то, что AMD действительно ускоряло бенчмарки — это известная штука: CPU-Z сменили бенчмарк, когда обнаружили, что Ryzen его специально дурит.

Ну. АМД хвастались своими аппаратными оптимизациями. Бенчмарк от CPU-Z хорошо поддался одной из таких оптимизаций. Иии? Как это может говорить о том, что АМД СПЕЦИАЛЬНО дурили бенчмарки? :D
Приведу умный коммент оттуда:

I seriously doubt they were detecting this specific benchmark. The benchmark was probably doing some calculations, stashing the results in machine registers, then overwriting them with new results without using them or storing them to RAM. A sufficiently clever optimizer in the CPU could notice that those instructions have no net effect, and decide to skip them entirely. There's already a lot of dataflow analysis going on in a modern CPU (to implement out-of-order execution), so it's not really a stretch to do something like this.

Шах и мат.

Кстати, именно слишком агрессивные оптимизации и поломали GCC. И многий другой софт, работающих сходным образом. Бага проявлялась и синими экранами в винде, и много чем ещё.

Дорогие аноны, ваш интересный и увлекательный спор возник по причине складывания яек в одну корзину. В медицине есть понятие in vivo/in vitro. In vitro в лабораторных условиях амд подвержен. In vivo ака ирл в боевых условиях наука считает, что ни один анонимус пока не повторил.

Всё как и раньше.

Вот помню раньше, во времена четвертых пней, атлончики драли их как бисти тукса, на известной пикче:)

Все эти атаки эксплуатировали одну и ту же проблему

Чушь, 3 разных проблемы. branch misprediction, btb aliasing и... а последнюю узнаешь, когда осилишь доки. «а кеш тут вообще не при чём», как говорится. :) (хоть и понятно, что результат атаки за счёт него извлекается)

Ну. АМД хвастались своими аппаратными оптимизациями. Бенчмарк от CPU-Z хорошо поддался одной из таких оптимизаций. Иии?

Если б дело было в этом... Но вот разработчики CPU-Z считают иначе. Когда они обнаружили, что их тест на AMD внезапно стал работать очень быстро:

We reviewed many software and synthetics benchmarks without being able to find a single case where such a performance boost occurs. We're now convinced that this special case is very unlikely to happen in real-world applications.

То есть ни в каком другом реальном софте это не проявлялось. Да и вообще разработчики уверены, что этот особый случай не мог сработать в реальных приложениях. Эта «оптимизация» — обман, нацеленный специально на бенчмарк.

Господя онаны, в чем собсно вопросц?! Ваш спор можно разрешить лишь эмпирически. Те если один онан предьявит общественности скринкаст удаленной отаке амд камня. Тогда второй капитулирует и признает поражение. Я готов быть вашим секундантом и засвидетельствовать все.

Но вот разработчики CPU-Z считают иначе

Пусть считают, если не умеют писать нормальные бенчмарки.

То есть ни в каком другом реальном софте это не проявлялось

Перечитай цитату. Они смотрели много других бенчей, но прикол возник только у них. Может, их код настолько крив?

Перечитай цитату. Они смотрели много других бенчей, но прикол возник только у них. Может, их код настолько крив?

Да, скорее всего он крив. И это лишнее подтверждение того, что синтетические бенчмарки гавно, поэтому многие тесты нынче делаются на реальных приложениях.

Но это всё равно ничего не меняте — если «оптимизация» проявляется только в тесте, то она нацелена конкретно на этот тест. AMD-шники «ускоряли» именно этот конкретный тест.

Это не такой уж и страшный обман. Если бы реальные приложения не начали падать и глючить.

Да, скорее всего он крив
Но это всё равно ничего не меняте
AMD-шники «ускоряли» именно этот конкретный тест.
Если бы реальные приложения не начали падать и глючить.

Поделил на ноль.
Как раз оптимизация ускоряла конкретно кривой код. За что АМД и поплатились. Собственно говоря, это micro OpCache и ни к какому обману конкретного бенча отношения не имеет. Хватит нести пургу. Эта фича ускоряет ещё много чего, и даже тот же GCC, без неё он работает медленнее. И эта техника оптимизации никуда не делась, просто её довели до ума. Иногда лучше не позориться.

Собственно говоря, это micro OpCache и ни к какому обману конкретного бенча отношения не имеет. Хватит нести пургу. Эта фича ускоряет ещё много чего, и даже тот же GCC, без неё он работает медленнее.

Ну так это ж не я придумываю. Разрабы теста проверили другие случаи и аналогичного ускорения не обнаружили. И те же разрабы теста заявили, что они уверены, что в реальных приложениях такого быть не могло. Если бы это была какая-то общая оптимизация, то ускорение было бы и в других приложениях тоже, разве нет? Или разработчики теста врут?

Разрабы теста

обосрались. А потом ещё раз обосрались написав ахинею, что красные разработали ускорение ТОЛЬКО ИХ бенчмарка. Аппаратно. За тонны нефти. И ещё раз обосрались, отстаивая свою точку зрения. Ни на какие мысли не наводит?
Кроме того, реальные приложения НЕ ИСПОЛЬЗУЮТ ограниченный набор ОДНИХ И ТЕХ ЖЕ ПРОСТЫХ математических операций, даже НЕ СЧИТЫВАЯ результат их выполнения. Они просто натренировали micro OpCache и бранч предиктор и узрели всю мощь OoO. Ещё вопросы?

обосрались. А потом ещё раз обосрались написав ахинею, что красные разработали ускорение ТОЛЬКО ИХ бенчмарка

Они сформулировали это осторожно. Мол «мы не обнаружили», а не «вы нас тут обдурить пытаетесь».

Но в результате они заменили тест на другой, и количество очков у AMD снизилось по сравнению Intel-ами. И та цитата как раз и была из объяснения того, почему это всё произошло.

Только вот... Если это они «обосрались» то почему только мы, анонимусы на лоре, это поняли? Почему все остальные об этом не написали? Почему процы AMD не заработали на новом тесте столько же очков сколько и на старом, почему они просели по сравнению с другими процами? И зачем вообще AMD оптимизировало в своих процессорах код, который не встречается нигде, кроме тестов?

Кроме того, реальные приложения НЕ ИСПОЛЬЗУЮТ ограниченный набор ОДНИХ И ТЕХ ЖЕ ПРОСТЫХ математических операций.

В каком смысле? Этих операций всего-то около десятка. И любой вычислительный код использует только их, других-то и нет. То есть какой-нибудь код криптографии, или матричного преобразования в 3D-игрушке использует на каждом элементе матрицы ОДНИ И ТЕ ЖЕ ПРОСТЫЕ математические операции.

В принципе, то был не единственный случай. Была и история с «Performance Bias» в биосе, подстраивающей производительность под конкретный тест. Не знаю, что оно могло бы делать... заливать другой микрокод?

И так делает не только AMD. Intel-ы тоже разгоняли проц, чтобы лучше показать его в демонстрации (хатя, справедливости ради, они в этом сознались, AMD вряд ли когда-то сознаются, что пытались ускорить тесты).

Но, ещё раз, даже если они действительно пытались сжульничать в тестах, я не вижу в этом ничего плохого. Ну добавляли они оптимизации под какие-то тесты, ну и пусть. Меня больше беспокоит то, что из-за этого мог начать падать gcc. Но то, что именно это было причиной, доказать не возможно. Это лишь догадка, правдоподобная, но догадка.

Если это они «обосрались» то почему только мы, анонимусы на лоре, это поняли?

Во-первых, ты там комменты то читал, анон? Во-вторых, можешь дать нормальный источник кроме этих разрабов? Ну, и в третьих

заменили тест на другой, и количество очков у AMD снизилось по сравнению Intel-ами.

Собственно, обосрались.

Этих операций всего-то около десятка

Ииии, дальше, дальше предложение читай.

есть какой-нибудь код криптографии, или матричного преобразования в 3D-игрушке использует на каждом элементе матрицы ОДНИ И ТЕ ЖЕ ПРОСТЫЕ математические операции.

И НЕ забирает результат их выполнения? Ты намеренно до конца не дочитал? Если нет - слазь с наркоты, я серьёзно. Пора уже. Если их тест выполнял условный XOR одних и тех же регистров в цикле, забивая их одними и теми же данными... Ну ты понял, да?

«Performance Bias»

Если бы ты знал хоть немного, как реализовано энергосбережение в процах у АМД, ты бы знал, что это опции чисто от материнки. А штука эта - снижение частоты, если работа на полной мощи не имеет смысла ввиду большого объема операций с памятью или прокачки большого количества данных через шину, а BIOS просто оверклокерский для мерянья пиписьками. Поэтому производитель матплаты залил фичу, которая позволяет либо снижать тактовую не значительно, либо значительно. Либо оставить в дефолте. Видишь ли... Cinebench - это тупо рендеринг. И если эта опция ускоряет синебенч - она просто ускоряет рендеринг. Прикинь, уже не только синебенч быстрее работать начинает, но и блендер к примеру...

справедливости ради, они в этом сознались, AMD вряд ли когда-то сознаются, что пытались ускорить тесты

Вот ты и обосрался. АМД ничего не делали. Как мы тупо видим, PerformanceBias влияет на Cinebench - читай рендеринг. А рендеринг - не синтетический тест, а специфичный юзкейс, причём введено это было исключительно в BIOS матплаты. А вот интел - реально именно РАЗОГНАЛ проц.

Да, Linux умеет в Performance Bias, и появилось оно с семейства Carrizo. Ну это чтобы ты сам смог почитать документацию ядра, в качестве пруфца.

Ну добавляли они оптимизации под какие-то тесты, ну и пусть

Видишь ли, объем микрокода сильно ограничен. И нет возможности узнать выполнение каких-то тестов. И да, такое мошенничество есть в дровах и у невидии, и у АМД. Только амд почему-то при запуске 3DMARK ЗАМЕДЛЯЕТ видяшки. Не знал? Тоже пруфец нужен? Возьми карту АМД не самую свежую и поставь дровишки до адреналиновской эпохи - там это хорошо видно. Вообще у них такая практика с Evergreen началась, это недавно они одумались, но до сих пор в своих дровах так и не завезли нормальных оптимизаций под 3dmark, хотя это дёшево и сердито, и никто бузить не будет. Они даже штатные профили сделали для галочки и запускают большинство тестов на буках на ВСТРОЕННОЙ видяшке. Когда я это заметил - у меня знатный баттхёрт был. Потом нашёл инфу, почему так.

Меня больше беспокоит то, что из-за этого мог начать падать gcc

Опять ты со своей теорией заговора. Да просто АМД выкатили бракованные процы - не довели технологию до ума. Извинились, исправили и всем всё поменяли. Не сразу правда, они месяца 3 изучали и обтекали, а потом стали патчить, ну и еще через какое-то время менять процы, выпущенные до какой-то ревизии без разбору, даже если бага не проявлялась у владельцев. Это не теория заговора, и чисто в бенчах мошенничать не выгодно: их бы за это задавили к чертям и синие и зелёные. С гавном бы жрали.

А тебе посоветую начать интересоваться темой почитывая спецификации и документацию, вместо того, чтобы писать о том, как учёные насилуют журнализдов.

Видишь ли, объем микрокода сильно ограничен. И нет возможности узнать выполнение каких-то тестов. И да, такое мошенничество есть в дровах и у невидии, и у АМД. Только амд почему-то при запуске 3DMARK ЗАМЕДЛЯЕТ видяшки.

Еще одна причина не обновлять драйвер

Во-первых, ты там комменты то читал, анон?

Да, и в них высказаны те же вопросы, что задал я. Ты, наверное, не понимаешь, что я имею ввиду.

Допустим, CPU-Z «облажались» и написали плохой тест, который 100500 раз XOR-ит регистр сам с собой. И пусть AMD-шный умный оптимизатор это обнаружил, и выкинул лишние инструкции. Вопрос не в этом. Вопрос в том, что реальные приложения этого, очевидно, не делают. Такой код делают только в тестах.

Выходит, процессор AMD настроен оптимизировать код, который не встречается в реальных приложениях, но встречается в тестах. Об этом и говорилось в той фразе про «вхерачили в проц блок для ускорения бенчмарков».

Вот, и вопрос: зачем вообще AMD встраивали подобную оптимизацию? Какой смысл тратить ресурсы разработчиков и процессора на ускорение кода, который не встречается в реальных приложениях?

Во-вторых, можешь дать нормальный источник кроме этих разрабов?

А «нормальный» — это, например, какой?

Я вот искал другие источники. Надеялся, что кто-то напишет, какой именно код использовался в старом тесте. Но что-то ничего не нашлось. Либо таки разрабы правы, либо, что более вероятно, всем пофиг.

Если бы ты знал хоть немного, как реализовано энергосбережение [...] И если эта опция ускоряет синебенч - она просто ускоряет рендеринг

Если так, то почему там не одна опция «maximum performance» а три разные опции для разных версий и тестов?

а BIOS просто оверклокерский для мерянья пиписьками

Это был не оверклокерский биос, это был биос материнок, отправленных первым ревьюверам ryzen-ов. Тем, кто должен был написать отзывы о процессоре.

Опять ты со своей теорией заговора. Да просто АМД выкатили бракованные процы

Ясное дело, они не специально gcc крашили. Конечно, это случайный баг. И по отдельности эти вещи не вызывали бы вопросов, но вместе:
(1) все по мелочам жульничают в тестах и демонстрациях,
(2) AMD заявили о новой супер-интеллектуальной оптимизации,
(3) AMD показывают неоправданно высокие результаты в нагрузочном тесте cpu-z,
(4) gcc начинает падать в случаях, похожих на нагрузочный тест...
— вместо они и заставили задуматься.

Это не теория заговора, и чисто в бенчах мошенничать не выгодно: их бы за это задавили к чертям и синие и зелёные. С гавном бы жрали.

Увы, мошенничать выгодно. Поэтому все так делают в разной степени.

А тебе посоветую начать интересоваться темой почитывая спецификации и документацию, вместо того, чтобы писать о том, как учёные насилуют журнализдов.

Так я и не против, кидайте ссылки, я почитаю. :) Я ж не сам сочиняю, я ссылаюсь на чужие статьи.

Вот, и вопрос: зачем вообще AMD встраивали подобную оптимизацию? Какой смысл тратить ресурсы разработчиков и процессора на ускорение кода, который не встречается в реальных приложениях?

float optionA = x * x; float optionB = y / 2.f;

float chosenOption = (rand() % 2) ? optionA : optionB;

Пример кода, который может встретиться в реальном приложении напрямую или после оптимизации и который может выиграть от подобной оптимизации. Если условие в третьей строчке вычислится раньше, чем ненужная первая или вторая, то их можно сразу выкинуть. Да, это копейки, но производительность складывается из сотни оптимизаций, каждая их которых даёт ускорение на полтора процента.

Даже комментировать не охота. Во-первых, на ТАКОЕ ускорение расчета небыло. Во-вторых, если какой=то кусок кода начинает где-то выполняться быстрее - речь идёт не о бенчмарках. Совсем не о них. Это касательно того, что якобы АМД жульничала. АМД здесь сжульничала точно так же, как и интел с мельдонием и l1tf, только последствия разные. Так понятно?

По поводу БИОС. Т.е. вам хоть в глаза ссы, всё божья роса? Ускорение конкретного бенчмарка, которое равно ускорению рендера - теория заговора? Дооо. БИОС не АМД пишут. Совсем не АМД, а пишут его AMI, Phoenix, Insyde и т.п. АМД пишут AGESA, в которой такого нет.

Так я и не против, кидайте ссылки, я почитаю.

Для начала забейте performance bias в гуглтранслейт.

Я озадачился этим вопросом. Дело в том, что performance bias в данном контексте это не то же, что и performance bias в ядре линукса. BIOS в данном случае фактически разгоняет систему. Опять же, какое отношение это имеет к АМД не совсем понятно. Точнее, совсем не понятно, так как разгоном занимается производитель мат. платы. Фактически меняются уровни напряжений, тайминги и частоты.

float optionA = x * x; float optionB = y / 2.f;
float chosenOption = (rand() % 2) ? optionA : optionB;

Спасибо за пример. Идея понятна. Но не понятно, может ли это сработать на практике.

Компилятор-то может заметить, что переменные optionA и optionB больше нигде в коде не используются, и оптимизирует такой код буквально до 5 инструкций.

Но не процессор. Он не может, как компилятор, посмотреть, где используется переменная. Для него вычисление нужно, пока не перезаписаны все участвовавшие в нём регистры. И обычного out-of-order просмотра наперёд тут мало, ведь надо просмотреть все возможные ветвления и переходы на неизвестную глубину. А если результат записан в память, то вычисление вообще нельзя выкинуть, потому что эту память могут читать в другом потоке.

Итого, на практике, при компиляции с оптимизацией, такого кода быть не может. А без оптимизации результат будет записан в память и его нельзя выкинуть. Получается, такая идея никогда не сработает...

Все готовятся к Войне.

АМД здесь сжульничала точно так же, как и интел с мельдонием и l1tf, только последствия разные. Так понятно?

Сравнение не совсем верное. Во-первых, в Intel-е баг вылазит только при атаке, и не мешает работе обычных приложений. А баг с gcc в AMD валил обычные приложения.

Во-вторых, в интеле это не оптимизация, а скорее особенность микроархитектуры — если они проделают те же проверки в другом порядке, то бага не будет, а производительность не изменится. Ну, если я правильно понял о чём речь, а то в этом треде у каждого своё представление о том, что называть этими словами. :)

Но, я же писал, даже если это правда, я это даже жульничеством не считаю. Это просто оптимизация, и даже если она срабатывает только для бенчмарков, в этом нет ничего плохого.

Для начала забейте performance bias в гуглтранслейт.

Я знаю как это переводится, просто не уверен, о какой фиче ядра идёт речь.

BIOS в данном случае фактически разгоняет систему. Опять же, какое отношение это имеет к АМД не совсем понятно. Точнее, совсем не понятно, так как разгоном занимается производитель мат. платы. Фактически меняются уровни напряжений, тайминги и частоты

Если так, то почему там не одна опция «разогнать до упора», а несколько опций для разных версий и тестов? Ну нельзя же одним напряжением разгонять только CineBench11, а другим только CineBench15?

Дооо. БИОС не АМД пишут. Совсем не АМД

Но биос заливает микрокод. Микрокод берётся у AMD. И AMD могла дать разные микрокоды для разных бенчмарков. А чем ещё могут отличаться те опции?

Во-первых

Смысл один, результат разный.

если они проделают те же проверки в другом порядке, то бага не будет, а производительность не изменится

То-то они не могут переписать микрокод для проверки значений в другом порядке. Вы же в курсе, что современные процессоры внутри совсем-совсем не x86?

почему там не одна опция «разогнать до упора»

Потому, что разные опции дают результат в разных профилях нагрузки. Можно разогнать «до упора», но руками. Здесь разгоняет производитель матплаты.

Но биос заливает микрокод. Микрокод берётся у AMD. И AMD могла дать разные микрокоды для разных бенчмарков. А чем ещё могут отличаться те опции?

В гугл, для начала. Меня этот троллинг уже доканывать начинает. Микрокод не может различаться (особенно, если учесть, что он в общем-то потом в рантайме может быть обновлён операционной системой, в BIOS не всегда микрокод самый свежий).

Эти вопросы просто глупы, и отвечать разумно на них мне даётся с большим трудом. Хватит. Если хочется узнать, что там такое - берём и читаем документацию. Пересказывать её я смысла просто не вижу.

Компилятор-то может заметить, что переменные optionA и optionB больше нигде в коде не используются, и оптимизирует такой код буквально до 5 инструкций.

Оптимизирует ли? А не ассемблерная ли вставка там может оказаться?

Он не может, как компилятор, посмотреть, где используется переменная.

А зачем? Если в цикле выполняется
xor eax,eax
mov eax,ebx
xor eax,eax

гхм, как бы можно сделать один xor и забыть про выполнение этого кода. Не?

То-то они не могут переписать микрокод для проверки значений в другом порядке.

Если бы могли, то, наверное, переписали бы.

А почему вы решили, что это делает микрокод? Весь out-of-order делается максимально параллельно, а чтобы что-то выполнялось параллельно — оно должно выполняться разными физическими компонентами. Микрокод может их включать или отключать, может подсказывать на какие компоненты направлять тот или иной код, но не может соединить эти компоненты в другом порядке.

Вы же в курсе, что современные процессоры внутри совсем-совсем не x86?

Я не понимаю что значит эта фраза. Она звучит как «вы же в курсе, что современный двигатель внутри совсем не бензиновый?»

Внутри процессор примерно такой: http://download.intel.com/newsroom/kits/xeon/e5/gallery/images/Sandy-Bridge_E... Это — x86 или не совсем?

Микрокод не может различаться

Почему? А что тогда там будет отличаться? Разные напряжения для CineBench11 и CineBench15? Если вы знаете, чем отличаются эти опции — скажите. Я не нашёл.

В гугл, для начала.

Там я уже был. Если у вас есть ссылки — давайте ссылки. А если и у вас ссылок нет, то откуда они у меня возьмутся?

(особенно, если учесть, что он в общем-то потом в рантайме может быть обновлён операционной системой)

Может быть обновлён, а может и не быть. А может операционная система проверяет версию микрокода, и не заливает, если более новая уже залита. И в этом тестовом микрокоде с биоса могли специально завысить версию, чтобы ОС его не перезаписала.

Оптимизирует ли?

Да, перед тем как написать, я проверил, что компилятор генерирует из такого кода.

А зачем? Если в цикле выполняется
xor eax,eax
mov eax,ebx
xor eax,eax

Да, такой код процессор мог бы оптимизировать. Но такой код не мог получиться в реальном приложении, только в бенчмарке.

Микрокод может их включать или отключать, может подсказывать на какие компоненты направлять тот или иной код, но не может соединить эти компоненты в другом порядке.

Вы не знаете, что может сделать микрокод, и чего не может. Просто не знаете.

Я не понимаю что значит эта фраза. Она звучит как «вы же в курсе, что современный двигатель внутри совсем не бензиновый?»

Потому, что внутри процессоры уже давно имеют RISC-архитектуру. Это x86? Я почему-то, думал, что X86 это CISC. А вот x86-инструкции потом транслируются в RISC. Там, конечно, не WLIW, но всё же.
Это примерно, как если бы двигатель был бензиновый, но для работы ему нужен был не бензин, а водород. И в нём стоял преобразователь бензина в водород навроде холодного термояда.

Почему?

По кочану и по капусте. Микрокод это как раз то, что превращает RISC в CISC. А ещё микрокод может быть обновлён средствами ОС в рантайме (что, вообще, обычно и происходит на нормальных ОС). Обновления микрокода это обновления именно микрокода. AGESA и BIOS - это совсем-совсем другие вещи.

Если вы знаете, чем отличаются эти опции — скажите. Я не нашёл.

Как минимум меняют не только напряжения, но и частоты и изменяют логику работы чипсета. Причём достаточно нестабильно. Они влияют на энергосбережение в первую очередь. А это в том числе и тайминги памяти, и частота таймера и много-много чего ещё.

И в этом тестовом микрокоде с биоса могли специально завысить версию

Чтобы потом огрести проблем. Ну, во-первых, нет. Во-вторых, микрокод весит... тадамм - 2048 байт. Вы в 2k прям дохера засунете кода, который будет узнавать конкретные бенчмарки? Вы вообще далеки от темы. Идите и ЧИТАЙТЕ ДОКУМЕНТАЦИЮ.

Да, перед тем как написать, я проверил, что компилятор генерирует из такого кода.

Угумс. Какой компилятор? GCC? Опции O3, или Os? Может, с O0 собирали?

Но такой код не мог получиться в реальном приложении, только в бенчмарке.

Так бенчмарк то и обосрался. Других проблем вообще небыло ни у кого.

Если у вас есть ссылки — давайте ссылки. А если и у вас ссылок нет, то откуда они у меня возьмутся?

Так я то понимаю, что CineBench и AIDA в чекбоксах - маркетинг, а вы нет. Поэтому и ссылок у вас нет.

Если ещё не понятно, то RISC не умеет части x86 команд. Представим, что оно не умеет MUL. Поэтому вместо использования MUL приходится писать такое:

xor AX, AX
mov CX, a
@l:
add AX, b
loop l
mov c, AX

как это было в 8086 :)

И XOR было быстрее, чем MOV AX, 0

И микрокод объясняет процессору, на что переписывать MUL или IMUL

Собственно, именно это и есть причина столь разного IPC у процессоров. Они уже давно у компаний представляют собой разные RISC-архитектуры с разным набором внутренних команд.

Ну и грубо говоря, если знать (одна из причин не раскрытия что именно есть в микрокоде) внутреннюю архитектуру проца, можно делать эксплойты и заставлять процессор условно вместо mov AX, DX делать MOV MSR07, AX

Вы не знаете, что может сделать микрокод, и чего не может.

Не знаю, могу лишь догадываться. Но я уверен, что микрокод не может менять расположение и соединения компонентов на кристалле.

Вы в 2k прям дохера засунете кода, который будет узнавать конкретные бенчмарки?

Например, в 64 байта целиком помещается программа рисующая трёхмерный туннель, а в 128 байт можно уместить ещё и звук. Так что в 2к байт можно довольно много засунуть. :)

Но моя догадка была противоположной — в микрокод помещалась оптимизация только одного/двух бенчмарков, потому для разных бенчмарков сделали разные микрокоды, отсюда и разные опции в биосе. И, кстати:

x86-инструкции потом транслируются в RISC. [...] Микрокод это как раз то, что превращает RISC в CISC. [...] микрокод весит... тадамм - 2048 байт.

Очевидно, что это неверно. Инструкций тысячи. В 2048 байт не поместится даже их список. То есть либо там не 2048 байт, либо микрокод никого никуда не превращает, либо ни то ни другое — выбирайте. :)

Как минимум меняют не только напряжения, но и частоты и изменяют логику работы чипсета. Причём достаточно нестабильно. Они влияют на энергосбережение в первую очередь. А это в том числе и тайминги памяти, и частота таймера и много-много чего ещё.

Нет, в первую очередь они всё-таки влияют на производительность, а не на энергосбережение. :)

Но это не отвечает на исходный вопрос — если эти опции всего лишь меняют напряжение, частоту, тайминги памяти, то почему этих опций три? Почему не одна опция, которая выставляет всё по-максимуму?

Если на пальцах. Пусть первая опция выставляет частоту в 110% от номинала, вторая в 120%, и третья в 130%, тогда... зачем нужны первые две, почему не обойтись сразу третьей?

изменяют логику работы чипсета

Кстати, а как биос может менять логику работы чипсета? И что вообще такое «логика работы чипсета»? Ну, например?

Угумс. Какой компилятор? GCC? Опции O3, или Os? Может, с O0 собирали?

gcc и clang, опции от -O1 и выше. Про O0 я тоже проверял: «без оптимизации результат будет записан в память и его нельзя выкинуть».

Так бенчмарк то и обосрался.

Ну да. Мы ж это и обсуждаем, что описываемая вами оптимизация, та что пропускает инструкции, результат которых не используется, сработает только для бенчмарков.

То есть если вы правы, и AMD действительно добавляли такую оптимизацию, то они ускоряли именно бенчмарки, потому что в обычном коде таких инструкций нет.

могу лишь догадываться. Но я уверен,

Деление на ноль. Я вроде обрисовал, что микрокод много чего может.

в 64 байта целиком помещается программа рисующая трёхмерный туннель, а в 128 байт можно уместить ещё и звук.

И этой программе нужна ОС. Сама по себе на голом железе, даже не смотря на наличие BIOS/UEFI она ни звук ни видео не выведет. Для анализа кода железке надо несколько более слож

ные операции выполнять, чем взять конкретный алгоритм и отправить его результат в STDOUT.

в первую очередь они всё-таки влияют на производительность, а не на энергосбережение. :)

А что, энергосбережение с производительностью никак не связано? Да, производительность для десктопа во главе угла.

Почему не одна опция, которая выставляет всё по-максимуму?

Потому, что если разогнать всю систему - она становится не стабильной. А вот если разогнать только один компонент, к которому чувствителен текущий профиль нагрузки -> вероятность возникновения проблем много меньше. Ну и вообще, эти опции не гарантируют стабильную работу системы. Вообще. Иногда даже стабилизация +1% требует значительных усилий.

то они ускоряли именно бенчмарки, потому что в обычном коде таких инструкций нет.

В обычном коде такие инструкции могут быть. Только вы так ничего и не поняли.

Любая команда для процессора — это набор микроопераций, простые команды — это одна микрооперация, сложные команды могут состоять из сотен, а для некоторых современных команд — из тысяч микроопераций.
Это значит, что некоторые простые команды (типа арифметических, логических) процессор выполняет на комбинаторной логике за одну микрооперацию, фактически это аппаратное выполнение команды.
Более сложные команды состоят из цепочек микроопераций с условными переходами, циклами, прерываниями. Так вот, эти цепочки микроопераций и являются микропрограммами выполнения команд процессора. Это, конечно, очень поверхностное и упрощенное объяснение механизма выполнения команд на современных процессорах х86-64, но, думаю, суть понятна.

https://barnaul.nethouse.ru/articles/1872

Не поленился, нашёл где человек пишет в общем-то более-менее понятно о том, что и как там работает. Так вот. АМД ускоряли не бенчмарк, а ускорение бенчмарка явилось лишь следствием. Сама по себе оптимизация того или иного кода может быть выполнена аже по нечайности: в данном случае, как я понимаю, просто предсказатель переходов тренировался, а потом ошибался в результате этой тренировки. Что и было исправлено, в общем-то. При чем тут опять же конкретный бенч - не ясно: если уж ускорять - так явно не CPU-Z, а что-то другое и не одно. Причём так, чтобы конкуренты с говном не сожрали.

Потому, что внутри процессоры уже давно имеют RISC-архитектуру.

Нет. Это — ошибки перевода и испорченного телефона. RISC — это не архитектура, а набор команд. Причём это даже не конкретный набор.

История такова. Первые процессоры были просты, десяток инструкций, несколько регистров... Интел среди первых поняла, что это — тупик, и начала расширять набор инструкций. В те времена процессор был только интерпретатором команд, и больше инструкций значило более сложный, дорогой и энергоёмкий процессор. Это разбило производителей на два условных лагеря:

• CISC (Complex Instruction Set Computer) — процессоры с набором инструкций типа Intel, где много разных команд. На них программы можно уместить в меньшее число инструкций, но процессор сложнее и дороже.
• RISC (Reduced Instruction Set Computer) — процессоры с минимальным ограниченным набором инструкций, чем меньше — тем лучше, дешевле процессор, меньше расход энергии. Это хорошо для встраиваемых систем, но программы займут больше инструкций, больше места и будут выполняться дольше.

Некоторые даже считали, что RISC-и скоро вытеснят Intel, они же проще, дешевле, жрут меньше энергии...

Интел же крупно имела их ввиду, и дальше улучшала процессор. Появился сопроцессор, кеши разного уровня, 32-разрядный режим с кучей новых регистров и буферов, SIMD, предсказание ветвлений, подгрузка в кеш... Инструкции оптимизировались, и вместо десятков тактов, теперь выполнялись за 1 такт, а иногда и по несколько штук за такт...

И оказалось, что на фоне всех этих модулей, тот «сложный» декодер CISC-инструкций не играет никакой роли ни в стоимости ни в затратах энергии. Так RISC-инструкции проиграли битву. Оглядываясь назад, это кажется очевидным: простой дешёвый самокат не может вытеснить «сложный» велосипед, а велосипед никогда не вытеснит автомобиль.

Битва-то проиграна, но слова RISC и CISC остались. И кто-то, описывая работу процессоров, решил на них сослаться...

Любой процессор, даже 8086й, внутри выполняет несколько микро-«операций»: запрос данных из памяти, передача параметра в ALU, сброс кеша инструкций для перехода по новому адресу... Причём это не «команды» или «инструкции», а именно «операции», на русском лучше подходит слово «действия». Считать ли такие действия RISC-ами? Там ведь даже «инструкций» нет, просто данные передаются по одним проводникам на кристалле или по другим... Но затем в процессоре появились очереди операций. А чтобы добавить в очередь, у операции должен быть какой-то код, вот его кто-то и назвал «RISC-подобной инструкцией».

Это кажется логичным, скажем, в очереди подгрузки данных есть несколько простых команд — «считать» или «записать» из памяти в указанное место кеша или регистр. Несколько простых команд — это похоже на RISC. И кто-то назвал это «RISC-like instructions». Это не официальное название. Официально это «микро-операции» и «макро-операции». RISC-подобными их назвал кто-то из объяснявших. Затем "-подобными" потерялось, остались RISC-операции. Дальше по испорченному телефону, кто-то решил, что если есть RISC-инструкции, то внутри RISC-архитектура.

На самом деле это чушь. RISC — это минимальный ограниченный набор инструкций. А теперь смотрим на современный процессор со всеми его кешами, TLB, BTB, PHT, BHB, RSB и другими страшными словами... Ну какой это нафиг минимальный набор?

Некоторые считают, что RISC — это когда данные и обработка идут в разных инструкциях. Но в процессорах нет даже этого. Наоборот, современные процессоры склеивают данные и обработку в одну ячейку, чтобы в буфер больше поместилось.

Итого: RISC-архитектуры нет вообще, нет такой штуки, есть только RISC-инструкции. Но в современных процессорах нет и их. «RISC-инструкции» есть только на пальцах, при объяснении принципов работы процессора. Причём это — неверная терминология, правильно назвать их «микро-операции», потому что они — действия, а не инструкции, и к RISC-ам отношения не имеют.

И XOR было быстрее, чем MOV AX, 0

Почему быстрее-то? XOR было короче! 2 байта (31 c0) вместо трёх (b8 00 00) для mov ax, 0.

Было бы странно, если бы арифметическое вычисление с присваиванием работало быстрее просто присваивания.

как это было в 8086 :)

В 8086 инструкция MUL была. :)

И микрокод объясняет процессору, на что переписывать MUL или IMUL

Это тоже ошибка перевода. Иногда можно встретить фразу, что в процессоре были «microcoded multiply and divide instructions». Воображение тут же рисует картину какого-то встроенного минипроцессора (конечно же RISC-а, мы же знаем умные слова!), который выполняет умножение, считывая какую-то микропрограмму.

Ничего такого не было. Операция умножения по какому-то из алгоритмов рассчитывалась как формула из AND/OR-операций, которую при изготовлении процессора зашивали в виде PLA.

«Микрокодом» это называется не потому, что там есть какая-то программа, инструкции, и выполняющий их процессор, а потому что алгоритм умножения закодирован в микропроцессоре в виде матрицы AND/OR-элементов.

Не держите инженеров Intel за идитотов. 🙂 Никто не встраивал внутрь 8086 ещё один процессор для декодирования и выполнения виртуальных микропрограмм умножения.

Итого: RISC-архитектуры нет вообще, нет такой штуки, есть
только RISC-инструкции.

Мда, анонимус, показавший в этом триде полное незнание процессорной архитектуры, на 2 страницах расписывает, что mOps и «RISC инструкции» - это 2 большие разницы... Ну пиши исчо, если по делу сказать нечего. Ты со SPOILER и meltdown-bnd то хоть разобрался уже? Или тролить проще, чем 2 строчки из вики осилить? :)

RISC — это не архитектура, а набор команд.

Или архитектура с таким набором команд, что подразумевается понятием «RISC-архитектура». И да, понятие RISC включает в себя только набор команд, а остальное оно опускает. Но если приплести сюа ещё и FPU, и контроллер памяти, видеоядро (что тоже в процессоре), а ещё L2 и L3, которых в ретро-процессорах нет - нафантазировать можно будет ещё больше. В данном контексте как RISC-инструкции можно рассматривать только микрооперации процессора, а сам современный процессор гораздо ближе к SoC. И именно потому, что современные процессоры являются SoC - согласно вашей терминологии нельзя называть их процессорами впринципе: это ошибки перевода. По вашим понятиям процессор не может включать в себя ни FPU, ни кэш, ни видеоядро, ни контроллёр памяти, ни PCIe и т.п.

Но с умножением на 8086 я обгадился, да. В остальном микрокод делает как раз то, что я описал. С огромным количеством нюансов. Иначе как бы L1TF правили микрокодом? С дикими просадками производительности? Правильно, заставили процессор делать больше микроопераций при выполнении ряда команд. Собственно, и порядок микроопераций тоже можно поменять. А вот

формула из AND/OR-операций, которую при изготовлении процессора зашивали в виде PLA

касается далеко не всего. И даже несчастный MUL можно заставить работать по дргому. Дело в том, что там не только PLA, но и GAL, только программируется как раз заливкой микрокода. И даже то, что залито в PLA можно, скорее всего, перепрограммировать. Микрокод как раз и нужен в том числе как страховка от ошибок в PLA. Следует учитывать, что мы уже не о ретро-процессорах говорим, в данном разрезе.

Разворачиваю пояснение: кое-что выполняется «нативно» в определённом понимании. Кое-что описывается микрокодом. Микро-операция - это команда, выполняемая процессором за один такт работы. Всё, что медленнее - несколько микроопераций. Менее, чем за один такт работы никакая операция выполнена быть не может. Процессор может выполнить несколько различных микро-операций за тот же такт работы одновременно, но опять же - не все. Отсюда и проистекает IPC, по той же причине оно меняется в зависимости от микрокода, что нам Интел продемонстировал наглядно в своих апдейтах.

Да, возможно, я выбрал слишком простую терминологию, но это написано для дебилов в этом отношении, если я начну писать всё в правильных терминах - это будет недоступно для понимания 90% читателей этого ресурса.

раз хоть один человек прочитал.

Минимум два, я тоже прочитал.

Мда, анонимус, показавший в этом триде полное незнание процессорной архитектуры, на 2 страницах расписывает

Ну, я мог бы снова сыграть в игру «что вы называете словами RISC и CISC», меня бы послали «читать документацию», я попросил бы цитату, получил бы ссылку на википедию, попросил бы процитировать нужный фрагмент, получил бы «там всё написано», процитировал бы сам, получил бы обсуждение того как кто понимает цитату...

Но в прошлый раз эта игра прошла неконструктивно. Так что я решил пропустить все эти этапы и сразу написать что это такое, откуда взялось, для чего, к чему применяется, к чему применение будет неверным и почему.

Ты со SPOILER и meltdown-bnd то хоть разобрался уже?

Кстати, да. Когда я спрашивал, «что лично вы называете Meltdown и Spectre» я хотел увидеть примерно такой же подробный ответ, как я выше расписал про RISC-и. Увы, не судьба.

А вот если разогнать только один компонент, к которому чувствителен текущий профиль нагрузки

Это-то понятно. Но у тех бенчмарков одинаковый профиль нагрузки. Так почему опции разные? Чем именно они отличаются?

Ну и вообще, эти опции не гарантируют стабильную работу системы. Вообще. Иногда даже стабилизация +1% требует значительных усилий.

Обычные опции разгона — да, не гарантируют даже, что система загрузится. Но именно эти опции — гарантируют, что система загрузится, запустит тест, этот тест выполнится, и выдаст результат лучше обычного. То есть эти опции обязаны быть стабильными. Это не обычный разгон.

В обычном коде такие инструкции могут быть. Только вы так ничего и не поняли.

Выше в треде пытались найти, пока не получилось. То, что нашли, либо будет оптимизировано компилятором, либо, при выключенной оптимизации, не может быть оптимизировано и процессором тоже, либо это будет код бенчмарка.

Или архитектура с таким набором команд, что подразумевается понятием «RISC-архитектура».

Про «RISC-подобные инструкции» можно сказать хоть что-то. Можно, взглянув на набор инструкций, сказать «да, это похоже на RISC» или «нет, тут дохрена лишних операций, это не RISC».

А про «RISC-архитектуру» нельзя сказать ничего. Все процессоры, которые когда-либо назывались RISC-ами, имели разную архитектуру. Даже у Berkeley RISC, создавшего этот термин, было два варианта архитектуры. У их последователей разнообразие ещё больше.

Ну а раз под этим термином не подразумевается ничего конкретного, то выходит, что и термина такого нет.

В остальном микрокод делает как раз то, что я описал.

В смысле? Транслирует одну CISC-инструкцию в сотни/тысячи RISC-инструкций? ;) Нет, этого он не делает. Иначе всё работало бы слишком медленно.

Подумайте, реализация в железе выполнит инструкцию быстрее, чем в виде микрокода и его интерпретатора. Так какой смысл инженерам делать медленно, если они могут сделать быстро?

Или вы не об этом? Тогда о чём речь?

Кстати, откуда вы это знаете, если вы же сами писали, что информация о том, что есть в микрокоде, не раскрыта?

Иначе как бы L1TF правили микрокодом? С дикими просадками производительности?

Так его и не правили. Просто посоветовали чистить кеш на входе и выходе в SGX/VM или чьи там данные мы хотим защитить. Исправление они собирались выпустить в каком-то новом процессоре, который, вроде, пока не вышел.

Если проверку доступности страницы делать не на этапе retirement, а в процессе ooo-обхода, то вектор атаки L1TF будет закрыт. То есть надо просто переставить порядок действий. Только вот сделать это надо на кристалле. Если б это можно было сделать микрокодом, конечно они бы сделали, и никакой просадки производительности при этом бы не было, действия те же, изменить надо только их порядок.

Кое-что описывается микрокодом. Микро-операция - это команда, выполняемая процессором за один такт работы.

Это не связанные между собой вещи. Есть «микрооперации» — действия, которые процессор выполняет во время работы. А есть «микрокод» — несколько килобайт непонятно-чего, которые биос или ОС заливают в процессор.

Вы, наверное, увидели буквы «код» в слове «микрокод», и решили, что в нём есть какие-то машинные инструкции. Причём именно те, которые внутри себя выполняет процессор. Почему вы так решили? В микрокоде может быть, например, какой-то примитивный конфиг, в котором закодировано какие процессорные блоки в каких случаях включать.

Отсюда и проистекает IPC, по той же причине оно меняется в зависимости от микрокода, что нам Интел продемонстировал наглядно в своих апдейтах.

У каких инструкций изменился IPC после обновления микрокода?

Дело в том, что там не только PLA, но и GAL, только программируется как раз заливкой микрокода.

А причём тут GAL к микрокоду? Апдейт микрокода процессора не сохраняется при ребуте же?

Можно спросить, откуда вы вообще эти умные слова берёте? В смысле, не сами слова, а их связь с микрокодом? Мне просто любопытно узнать источник.

Но в прошлый раз эта игра прошла неконструктивно.

Да я б не сказал... Про тег таки соизволили прочитать 2 строчки. Вот только извинений за туфту по поводу, яко бы, невозможности совпадения тегов, и что на ВИПТе надо евикшн сет брутфорсить, и за прочую чушь, я что-то не увидел.

RISC-и. Увы, не судьба.

Конечно не судьба, не надо было спрашивать глупости. Я вам объяснил, почему meltdown-bnd ничего не даёт. И, сколько вы ни пытались затролить мои объяснения, народ их прочитал, и понял, что вы простой троль. После чего вы ту тему и покинули, начав тролить на другие. Плюс ещё и со спойлером протупили, даже не поняв, что это отдельный сайд-ченнел, при чём, выделили мне именно ту фразу, где это и говорилось. :) Ну и тд. Полный ноль. Я, собственно, к тому, что зря народ с вами дальше дискуссии ведёт, но это уже личное дело каждого конечно.

Но именно эти опции — гарантируют, что система загрузится, запустит тест, этот тест выполнится, и выдаст результат лучше обычного.

Ссылку на документацию? Эти опции как раз иногда приводят к снижению стабильности системы.

пытались найти, пока не получилось

Ой-ей, ей. А вы понимаете, что оптимизация того кода, который вы ищете - не следствие оптимизации, как таковой, а следствие архитектуры компонентов аппаратной части? Т.е. это особенности работы OoO, тренировки предсказателя переходов, кэширования микро-операций, etc. ?

А про «RISC-архитектуру»

демагогия. Просто лапша на уши с вашей стороны, которая не опровергает слова оппонента никак, а лишь является водой и замыливанием глаз.

Транслирует одну CISC-инструкцию в сотни/тысячи RISC-инструкций?

Почему в сотни/тысячи? Максимум в десятки. В нашем случае это транслируется в микро-операции, которые мы выше обозвали RISC-инструкциями.

Так какой смысл инженерам делать медленно, если они могут сделать быстро?

Не могут. Быстрее даже аппаратно не получится, ибо там разновидность GAL, что это - найдите в вики. Аппаратная реализация на PAL будет ничем не быстрее такого подхода.

Так его и не правили.

А зачем выпустили микрокод?

Это не связанные между собой вещи.

То, что вы так утверждаете, не делает ваше утверждение правдой.

У каких инструкций изменился IPC после обновления микрокода?

https://3dnews.ru/963779 - советую обратить внимание на две строки: WIndows update и Windows + BIOS Update. Как бы если IPC не упал, то что это? И это ещё не касалось l1tf. А вот после l1tf был скандал: https://01.org/mcu-path-license-2018

Апдейт микрокода процессора не сохраняется при ребуте же?

При том, что GAL может быть построен и на энергозависимой памяти.

Вот только извинений за туфту по поводу, яко бы, невозможности совпадения тегов, и что на ВИПТе надо евикшн сет брутфорсить, и за прочую чушь, я что-то не увидел.

Почему же? Какие-то извинения были. Не совсем понятно за что, но что-то было.

Я вам объяснил, почему meltdown-bnd ничего не даёт. ... После чего вы ту тему и покинули,

Не «объяснили», и не «доказали», а только «утверждали». Объяснений я не дождался. Объяснение требует, в частности, определение термина meltdown. А его не было.

Я, в принципе, мог бы продолжить диалог в стиле «что вы называете термином евикшн сет», «что по-вашему значит PT в VIPT», «что вы назвали 4к-алиасами», но в ответ я всё равно получил бы «идите читайте документацию» и «в википедии всё написано».

Вот я и не вижу, ради чего это продолжать. Чтобы унизить человека и показать, что он не знает о чём говорит? Мне кажется, сам он это уже понял, потому и постоянные уходы от прямого ответа. Тогда зачем? Доказать это другим? А другим это не нужно, ни на какие вопросы мы уже давно не отвечаем.

Поэтому после фраз моего собеседника «Ох и дебилоид», «Ой тупица», «иди-ка ты, анонимус, в жопу» и «ещё раз: иди в жопу» я и покинул тему. Аргументы закончились, собеседник скатился до личных оскорблений, став в позу «у меня есть мнение, и оно самое правильное, но я его не скажу». И дальнейший диалог в формате «скажи» — «не скажу» — «ну скажи» — «нет не скажу» мне кажется бесперспективным.

Поэтому после фраз моего собеседника «Ох и дебилоид»,
«Ой тупица»,

Так это всё правда, к тому же все эти фразы снабжались подробными объяснениями. Да и все остальные люди в этом триде вам уже точно то же самое сказали, при чём гораздо раньше, чем я. Увы, я надеялся до последнего...

Я, в принципе, мог бы продолжить диалог в стиле «что вы
называете термином евикшн сет», «что по-вашему значит PT в
VIPT», «что вы назвали 4к-алиасами», но в ответ я всё равно
получил бы «идите читайте документацию» и «в википедии всё
написано».

Конечно. А как ещё с тупым тролем разговаривать, 2*2 ему объяснять по сто раз? Если я под эвикшн сетом или тегом понимаю ровно то, чем он и является, а вы под ним не понимаете вообще ничего, то вас надо послать читать википедию, что, кстати, совсем не сложно. И ссылки я давал конкретные, а не абстрактно читать. К счастью, кто читал этот трид - всё поняли. А на тупого троля мне, если честно, малость начхать. :)

Ты вообще не прав. Поиск уязвимостей в железе обращает общее внимание на проблему и позволяет в будущем избегать этих косяков в дизайне. Иначе далеко не единственный человек нашел бы и эксплуатировал эту уязвимость, если это уже не происходило - и для спасения репутации и быстрого поиска нового решения об этом нужно объявить, иначе же можно получить огромный судебный иск в т.ч. от тех, кто заявит, что производитель вводил их в заблуждение.

Ты нелестного мнения о тех, кто распространяет такую информацию, однако security through obscurity себя не оправдывает, особенно когда имеешь дело с массово производимыми товарами. Впрочем, они молчали до последнего в поисках решения. Здесь осторожность осведомленных инженеров может дорого обойтись в первую очередь уровням продаж

Не «объяснили», и не «доказали», а только «утверждали».

Ну ладно, допустим, анонимный троль не понял многократно повторенных объяснений, что и не удивительно, на фоне понимания всего остального. Но Woolf и какой-то другой анонимус подошли к этой теме с другой стороны, и попросили ВАС самого написать, как это вы собираетесь с помощью meltdown-bnd атаковать отсутствующую инструкцию bound. Им то вы могли ответить? Они-то вас ужасными словами не обзывали? :) Но почему-то ответа не последовало.

Ссылку на документацию?

На документацию чего? В мануале к материнке этих опций нет.

Эти опции как раз иногда приводят к снижению стабильности системы.

В целом может и приводят. Но как минимум из их названия следует, что они позволяют системе загрузиться, и пройти тест. Обычные опции разгона такой гарантии не дают.

вы понимаете, что оптимизация того кода, который вы ищете - не следствие оптимизации, как таковой, а следствие архитектуры компонентов аппаратной части?

Вы, наверное, забыли, что мы ищем. Я напомню. Я сослался на цитату, где говорится, что AMD впилили в Ryzen ускорение бенчмарков. Вы сказали, что это чушь, и оптимизировался код, который не считывает результат выполнения операций. Я ответил, что это и есть код бенчмарков, и сослался на авторов CPU-Z, которые заявили, что в реальных приложениях это не проявляется. Ну и дальше была попытка найти такие инструкции, которые не считывают результат операции, и встречаются не в бенчмарках. Пока что не нашли.

Просто лапша на уши с вашей стороны, которая не опровергает слова оппонента никак

Эта лапша показывает, что оппонент использует термин, который ничего не означает.

Почему в сотни/тысячи? Максимум в десятки.

А кто цитировал фразу «могут состоять из сотен, а для некоторых современных команд — из тысяч микроопераций»?

В нашем случае это транслируется в микро-операции, которые мы выше обозвали RISC-инструкциями.

Вы путаете «инструкции» и «действия» (операции). Действия — это процесс исполнения инструкции. Нельзя назвать действие инструкцией. Точнее, назвать-то можно что-угодно, но выглядит это глупо.

Если я скажу кому-то «эй, друг, иди сюда» — это инструкция, ОДНА инструкция. Если он подойдёт ко мне — это действие. А сколько это действий — смотря как считать. Может это одно действие «подход ко мне». А может 10 действий, потому что он сделал 10 шагов. А может 40 действий, ведь на каждом шаге он поднял ногу, передвинул её вперёд, опустил, и перенёс на неё вес. Можно и до миллиардов действий довести, если считать сокращения каждого мышечного волокна. Или до квадриллионов действий, если считать движение каждой молекулы.

Но никаких других микроинструкций от меня больше не поступало. Инструкция всё равно одна. Возможность условно разбить одну инструкцию на несколько действий ещё не делает человека RISC-процессором.

Или вы, и правда, называете RISC-ом процессор, в котором выполнение одной инструкции можно условно разбить на несколько действий? Тогда всё в мире — RISC-процессоры, и ничего другого в мире не было никогда.

Не могут. Быстрее даже аппаратно не получится, ибо там разновидность GAL.

Где это «там» — разновидность GAL?

Аппаратная реализация на PAL будет ничем не быстрее такого подхода.

А аппаратная реализация в виде заточенной под эту задачу интегральной схемы — будет.

Вы всё перепутали. В 8086 умножение было зашито в PAL. А сейчас его делают специализированной схемой. Поэтому раньше умножение занимало сотню тактов, а сейчас не занимает и десятка. Как, по-вашему, им это удалось?

При том, что GAL может быть построен и на энергозависимой памяти.

Да? Не помню таких. Например?

А зачем выпустили микрокод?

Его постоянно выпускают. Какой именно выпуск вас интересует?

То, что вы так утверждаете, не делает ваше утверждение правдой.

Но и не делает его ложным. Вы высказали одну догадку, я высказал другую. Без доказательств с вашей стороны обе догадки могут быть верны.

https://3dnews.ru/963779 - если IPC не упал, то что это?

Винда обновилась, и что-то делает медленнее. Почему вы решили, что у каких-то инструкций изменился IPC? Потому что винда стала медленнее после апдейта?

советую обратить внимание на две строки: WIndows update и Windows + BIOS Update

А причём BIOS Update к микрокоду, если вы сами писали, что ОС сама обновляет микрокод?

А вот после l1tf был скандал: https://01.org/mcu-path-license-2018

И где там скандал?

Так это всё правда, к тому же все эти фразы снабжались подробными объяснениями.

О да, я помню эти подробные объяснения:
> «Я не знаю, сколько раз это надо повторить, чтобы вы не сказали, что это один и тот же брут форс.»
спустя пару сообщений:
> «Вот же идиот, таки сморозил, что это один и тот же брут-форс...»
и ещё через пару сообщений:
> «Ох и дебилоид, ещё и с чтением проблемы. Разумеется, они берут тот же алгоритм ... Это именно то, что я и говорил.»
Ну да, вот именно это и говорил. Может, это были не оскорбления, а самокритика?

Но Woolf и какой-то другой анонимус подошли к этой теме с другой стороны, и попросили ВАС самого написать, как это вы собираетесь с помощью meltdown-bnd атаковать отсутствующую инструкцию bound. Им то вы могли ответить?

Не помню, где они меня об этом просили. Можно ссылку?

Но, вообще, я пытался. Только для этого нужно было сначала определить, что такой meltdown/spectre. И я даже успел описать Spectre на пальцах. Но потом мне сказали, что и meltdown описывается так же, но есть некоторые «технические детали различий», которые мне не скажут, но я могу поугадывать, либо «платите деньги за ликбез».

Вот на этом всё и остановилось. Нет смысла обсуждать отдельные вектора meltdown/spectre, если нет определения того, что вообще называть meltdown и spectre.

Феерический бред по каждому пункту. У вас нет документации на фичу, но вы утверждаете, что она стабильна и вообще не маркетинговый буллшит, причем делаете далеко идущие выводы в сторону производителя процессора, а не материнской платы.

Вы просите пруфов, которых сами не предоставляете. Все ваши пруфы - на какое-то объяснение от малопонятных людей, в условном интернет.

Про скандал с l1tf писалось в этой ветке не единожды, только не писалось именно о лицензии, которую intel в последствии сократили. И писалось о падении производительности.

Вы не знаете, как распространяется микрокод, и не в курсе, что в Microsoft он прилетает после того, как прилетает сначала OEM. Микрософт не OEM. И многого другого не знаете, при этом пытаетесь кого-то учить. Надоело, стул дымит. Пойду куплю нормальное кресло, а на вас забью.

«Я не знаю, сколько раз это надо повторить, чтобы вы не
сказали, что это один и тот же брут форс.»

«Ох и дебилоид, ещё и с чтением проблемы. Разумеется, они
берут тот же алгоритм ... Это именно то, что я и говорил.»

Охх... в последний раз что-то пытаюсь объяснить этому... воздерживаясь от перехода на личности... Так вот, выделенные вами «не один и тот же брут форс» и «тот же алгоритм» - это 2 совершенно разные вещи. Алгоритм поиска эвикшн сета был тот же, что и при любом другом поиске эвикшн сета брут-форсом. И работал, разумеется, по 4к - по-другому и быть не может. А вот цитата про «не один и тот же брут-форс» относилась к обсуждению двух разных брут-форсов: первый по 1М алиасам для проряжения пула страниц, а второй - собственно, стандартный брут форс поиска эвикшен сета, который и есть «тот же самый, стандартный, по 4К, но при этом, никак к брут-форсу по 1м не относящийся». Собственно, SPOILER и объединяет эти 2 алгоритма, запуская их по очереди. По этому, выдирать из контекста фразы вы мастер, вот только противоречит они, при этом, друг другу не начинают. И если вас за подобные действия дебилоидом или тролем кто-то назвал, так этого ещё мало... Напоминаю, что вы пытались эти 2 алгоритма спихнуть в один, и от этого он, разумеется, стандартным быть тут же переставал, так как никто эвикшн сет не ищет страницами по 1м - это 2 разных, последовательно исполненных алгоритма. Один из которых - стандартный, а вот второй - новый, изюминка SPOILERа.

Не помню, где они меня об этом просили. Можно ссылку?

Да можно, можно: Spoiler — новая уязвимость в процессорах Intel (комментарий)

И я даже успел описать Spectre на пальцах. Но потом мне
сказали, что и meltdown описывается так же, но есть
некоторые «технические детали различий»

Серьёзно? А кто такое говорил? Или, может, это ваши фантазии? Там не «некоторые технические различия» были, а полное непонимание. И я вам даже указал на конкретную фразу из вашей цитаты википедии, над которой вам стоило подумать. Конкретную фразу, и наводящий вопрос к ней! Этого даже в детском саду бы хватило!

Вот на этом всё и остановилось.

Нет, остановилось много на чём, но только не на этом. Когда покажете публике, как вы meltdown-bnd применяете к отсутствующей bound, тогда, может, можно будет продвинуться, даже несмотря на тупняк с VIPT, тегами, эвикшн сетами, и всеми прочими терминами, значение которых вы, почему-то, решили спросить у меня:

Я, в принципе, мог бы продолжить диалог в стиле «что вы
называете термином евикшн сет», «что по-вашему значит PT в
VIPT», «что вы назвали 4к-алиасами», но в ответ я всё равно
получил бы «идите читайте документацию» и «в википедии всё
аписано».

Надоело, стул дымит. Пойду куплю нормальное кресло, а на
вас забью.

Кстати, а я тут вот чего подумал... Ведь боты-троли уже весьма неплохо развиты: https://www.techcult.ru/robots/6053-chatbot-lenni-trollit-telefonnyh-spamerov

А что мы видим здесь? Ни капли соображения, зато умение вырывать фразы из контекста (лексический анализ), сопоставлять совершенно несвязанные куски текста по совпадению ключевых слов, раскидывание огромного числа ссылок, если в них есть хоть что-то напоминающее обсуждаемую тему... Ни на какие мысле не наводит? А то смотрите, он ведь сейчас, за наш счёт, тест Тьюринга пройдёт, и что делать тогда будем? :)