Не на половину. Будет брать следующую виртуальную страницу.

... а если она не подходит по тегу, то см. Spoiler — новая уязвимость в процессорах Intel (комментарий) То есть, операционка должна будет следить, чтобы последовательно клались только такие адреса. Если же операционка не уследила - virtual coherency exception. Ну это как вариант. Придумать можно и другие реализации.

вообще может быть PIPT-ом.

И на что эта ссылка?

I think PIPT does not mean VIPT non-aliasing even
though their functionality is similar.
Isn't there any functionality difference?
And..in this case, isn't there any problems?

«Из стольких, сколько там адресов.» Откуда такая гарантия, что попыток по кол-ву адресов - хватит?

Это гарантия моего алгоритма: адреса добавляются в эвикшн сет до тех пор, пока не вытеснит.

Это ещё что за новая бредятина? У одного адреса из линии? А у остальных, типа, нет? Да шли бы вы, тупой троль.

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

Никто не создаст алиасы в вытисняемых адресах. Вы долбанулись.

И не надо. Они сами могут создаться, если кеш с алиасами, а эта же вытесняемая ячейка в другом процессе имела другой виртуальный адрес. См.пример про атаку из 2005го.

никто не мешает замапить один и тот же блок кода на разные вирт адреса, проекзекьютить его, чтобы запрефетчить в i-cache, а потом, в одном из этих блоков переписать его через d-cache. Та же самая проблема.

А, нет, это другая проблема, ведь это будет запись в d-cache, который уже без алиасов.

Термин «cache aliasing» относится только к алиасам в одном кеше. Проблема маппинга одинаковых адресов в разные кеши называется «cache coherence», и её мы ещё не обсуждали. Но она бывает при любом типе кеша, например, в многоядерных системах, где у каждого ядра свой кеш, и разные ядра работают с одной областью памяти.

Не на половину. Будет брать следующую виртуальную страницу. Но, в моём примере, это будет та же физическая страница, так как у меня 2 последовательные вирт страницы алиасятся на одну.

А что будет в линии, если следующей виртуальной страницы нет, если в неё ничего не смаплено?

а если она не подходит по тегу, то см. «операционка следит за тем, чтобы указанное выше условие всегда соблюдалось»

Ха, хорошая попытка! Позволяет выкрутиться из многих проблем. Но вопрос не только к операционке: а процессор-то что делать будет? Что реально будет в линии, и как процессор решит, что туда писать, куда она указывает, и можно ли использовать эти данные?

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

Очевидно, что проверяется это легко: если нашёл ту же линию - хорошо. Если ничего не нашёл по физ адресу - то это была не та линия.

Но как именно? Узнали физ.адрес, а дальше? Как зная физ.адрес мы определим, та ли это линия?

вообще может быть PIPT-ом.

И на что эта ссылка? ... вряд ли кто будет делать L1 как PIPT

На фразу:
> [kernel] printed like following
> 'CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache'
> actually, Samsung S5PV310(cortex-A9) has PIPT d-cache
То есть ядро пишет не тип кеша, а то, как оно с ним работает.

В мипсах, например... Ну и в xtensa

Xtensa же требует какой-нибудь page coloring от ОС, то есть там алиасы не создаются. Разве там есть аппаратный ресолв алиасов? А именно по MIPSам нашлось, что там для борьбы с L1-алиасами добавляли поля в L2. L2, очевидно, медленнее, чем L1, отсюда «небольшое» замедление («small difference in the clock rate you are able to achieve») и «some penalty for data cache accesses».

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

http://lkml.iu.edu/hypermail/linux/kernel/0610.2/2037.html

Кстати, в целом тот тред согласен со мной, и ещё менее лестно отзывается о создателях процессоров с алиасами и о том, что с ними надо сделать:

> Castration. That's the best solution. We don't want those people procreating.

Сравните с вашим «алиасы там неизбежны, достаточно просто посмотреть характеристики современных L1/L2 кешей».

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

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

А, нет, это другая проблема, ведь это будет запись в
d-cache, который уже без алиасов.

Уважаемый идиот, я вам специально дальше разжевал, что линии из i-cache, в таком сценарии, потом придётся флушить вручную. Так вот, если зафлушить только одну, а её алиасы оставить - будет ровно та же самая проблема. Но до вас не дошло... Увы.

А что будет в линии, если следующей виртуальной страницы
нет, если в неё ничего не смаплено?

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

Ха, хорошая попытка! Позволяет выкрутиться из многих
проблем.

Хотел сказать, что проблемы тут только у вас, так как вы лишь тупите, и до сих пор не признали слив по meltdown-bnd... Но, раз мозгов у вас нет, то и проблем нет тоже.

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

С тегом и так хранится куча служебных бит. В нашем случае потребуется 4 доп бита на линию, как я описал выше. Тут проблемы нет ни малейшей.

Очевидно, что проверяется это легко: если нашёл ту же
линию - хорошо. Если ничего не нашёл по физ адресу - то
это была не та линия.

Но как именно? Узнали физ.адрес, а дальше? Как зная
физ.адрес мы определим, та ли это линия?

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

На фразу:

От кого? Там что, пруфы есть? Давайте дальше ссылки на письма непонятно от кого.

Xtensa же требует какой-нибудь page coloring от ОС, то
есть там алиасы не создаются.

Но создать их можно. Кстати, кеш колоринг можно использовать и с аппаратным резолвингом алиасов. Просто чтобы их не плодить - всяко быстрее будет. Так что наличие или отсутствие аппаратного резолвинга никак из этого не выводится, да и не важно в данном случае. Важно, что биты индекса выходят за 12.

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

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

Сравните с вашим «алиасы там неизбежны, достаточно просто
посмотреть характеристики современных L1/L2 кешей».

И где же ошибка в этой моей фразе, о тупой троль? Разумеется, если размер превышает размер страницы помноженный на ассоциативность, то алиасы неизбежны. И как мне, интересно, сравнить эту очевидно верную фразу с высказываниями о кастрации? Мозгов у вас, видно, ни на грамм...

Кстати, из того форума непонятно, они собираются кастрировать тех, кто создаёт алиасы без аппаратного резолвинга, с ним, или и тех, и других? Думаю, только о первых шла речь. А у нас речь шла о любых алиасах, когда бит индекса выходит за 12.

линии из i-cache, в таком сценарии, потом придётся флушить
вручную.

Инвалидировать, а не флушить. На случай очередных придирок.

я вам уже тысячу раз объяснил, что в вытесняемых адресах алиасов не будет. Алиасы же вытесняющего адреса никого не волнуют. Эвикше сет нужен, чтобы одну из наших линий вытеснил атакуемый. Вы не понимаете ни хрена.

Действительно, не понимаю. То что вы описываете — это prime set, особый, частный случай эвикшн сета, используемый в атаке prime+probe. Он не подходит ни под моё определение, ни под то определение эвикшн сета, на которое ссылались вы. Да и конструируется он иначе, под конкретные процессоры с известным типом и механизмом работы кеша.

я вам специально дальше разжевал, что линии из i-cache, в таком сценарии, потом придётся флушить вручную... будет ровно та же самая проблема.

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

Тогда очевидно, что к этой части кеш линии вообще обращений не будет - MMU не пропустит.

У нас же обращение по вирт.адресу, ещё до ответа от MMU.

Тут особой проблемы то нет, единственное, придётся хранить, вместе с тегом, несколько доп битиков. Среди них - младший бит физ адреса для каждой из страниц

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

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

А вы сами-то читали? Я специально цитировал же. Там написано «нашёл по физ адресу», и я спросил как именно он искал по физ.адресу. Там этого нет, что перечитать-то?

От кого? Там что, пруфы есть? Давайте дальше ссылки на письма непонятно от кого.

Пруфы-то я и искал, когда нашёл это письмо. А «от кого» — это вы хорошо спросили. Там прямо в письме написано:
> Kukjin Kim <***@samsung.com>, Senior Engineer,
> SW Solution Development Team, Samsung Electronics Co., Ltd.

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

Смотря как сделан этот аппаратный ресолвинг. Он ведь срабатывает на каждый кеш мисс, не важно, есть алиасы или нет, он будет их искать, тратя процессорные ресурсы. Если бы это было хоть немного выгодно, то всякие intel/amd делали бы так в каждом процессоре.

С другой стороны кеш-колоринг тоже не бесплатный. Он тормозит выделение/освобождение, и создаёт очень сложные проблемы при высокой занятости памяти, когда заканчиваются страницы какого-то цвета. Из-за этого Линус издавна был против cache coloring, ведь это замедляло работу.

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

Так что наличие или отсутствие аппаратного резолвинга никак из этого не выводится, да и не важно в данном случае. Важно, что биты индекса выходят за 12.

За 12 выходят. Но не выходят за количество битов, которое в виртуальном адресе зависит от физического.

И так, я объяснил тупому тролю, что, в современных процах, полно кешей как с аппаратным резолвингом алиасов, так и без него?

Если «современными процессорами» считать не intel/amd, а умирающий mips и xtensa, то да, объяснил...

И где же ошибка в этой моей фразе, о тупой троль?

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

проблемы тут только у вас, так как вы лишь тупите, и до сих пор не признали слив по meltdown-bnd...

Доберёмся и до мелтдаунов. Мы почти закончили существующие темы. С алгоритмом вы, похоже, уже не спорите. Осталось только убедить вас, что в выдуманной архитектуре физ.адреса тоже совпадут.

ARM в ноутах

Oh, no!

Он не подходит ни под моё определение

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

ни под то определение эвикшн сета, на которое ссылались вы.

Это под какое же, если не секрет?

Почему именно вручную? Нормальные процессоры сами заботятся
о когерентности кеша.

То есть, по вашему, если создать алиасы в i-cache, как я описал выше, а потом переписать один из них через d-cache, то i-cache, без аппаратного резолвинга алиасов, тем не менее их все найдёт и проинвалидирует автоматически? Полагаю, пруфы можно и не пытаться просить? :)

У нас же обращение по вирт.адресу, ещё до ответа от MMU.

Тьфу ты, дурик, по чтению - да, а по записи - нет. :) А то дороговато будет «портить» кеш линию спекулятивно, а потом восстанавливать. Соответственно, даже никакие биты присутствия не понадобится. Префетчим всегда 2 последовательные физ страницы, спекулятивно их и отдаём. Когда физ адрес провалидирован через TLB, тогда, если не та страница - префетчим нужную...

Но «несколько доп битиков» делают тег длиннее и он
перестаёт совпадать.

Пуууфф... Вообще-то, я вам уже пытался намекнуть, что тег - это не только ключ поиска в CAM, которым является vhint или кусок физ адреса. По этому ключу находят структуру данных, где есть номер вея, и куча служебных бит о состоянии линии. Таким образом, добавив в эту структуру (а не к ключу! не к ключу поиска структуры!!! поймите уже хоть это!) туда 2 битика, мы ни коим образом не создадим 2 тега! Мы даже структуру данных тега при этом не увеличим, так как там резервных бит и так полно: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0464f/BABDIJAD...

Тег, при этом, не «перестаёт совпадать», так как ключ поиска у нас всё тот же, без бита 12! Что непонятно то?

О чём я и говорил в «совпадение тега гарантирует совпадение
физ.адресов»

Всё, о чём вы когла-либо говорили - не более, чем клоунада, увы. А вот сколько она будет продолжаться - непонятно.

Продолжение ниже...

А вы сами-то читали? Я специально цитировал же. Там написано
«нашёл по физ адресу», и я спросил как именно он искал по
физ.адресу.

Нет, прошлый вопрос звучал «Как зная физ.адрес мы определим, та ли это линия?», и на него я ответил. Если у вас теперь новый тупой вопрос, «как искал», то отвечаю: используя старшую часть физ адреса (от бита 13 и до конца) в качестве ключа поиска в CAM.

Там прямо в письме написано:

И что это доказывает? Некий SW Solution инженер спросил в списке рассылки, есть ли отличия у PIPT и aliasing VIPT. Очевидно, будь у него хоть малейшее отношение к HW Dev Team, он бы такую фигню в публичных рассылках не узнавал...

Не тормозит только кеш с высокой ассоциативностью без
алиасов.

Высокая ассоциативность, очевидно, тоже тормозит. Почему-то её обычно не делают больше 8.

За 12 выходят. Но не выходят за количество битов, которое
в виртуальном адресе зависит от физического.

При использовании cache coloring? А какое вообще отношение программный механизм - cache coloring - имеет к обсуждаемым нами аппаратным аспектам работы кеша? Опять тупой тролинг? Биты индекса выходят за биты размера страницы MMU - вот что важно с точки зрения аппаратуры. «алиасы тут неизбежны».

Если «современными процессорами» считать не intel/amd, а
умирающий mips и xtensa, то да, объяснил...

И для АМД нашёл, и для Интел (но с ним только для i-cache нашёл) - достаточно.

Ошибка не во фразе, а в оценке ситуации. По-вашему «алиасы
неизбежны»

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

Осталось только убедить вас, что в выдуманной архитектуре
физ.адреса тоже совпадут.

То есть, ваша клоунада и тупые вопросы приведут к убеждению меня в чём либо? Или, может, в один прекрасный день вы перестанете тупить, и начнёте уже «убеждать»? :) Даже не знаю, дождусь ли этого, или вас тут забанят раньше. :)

И для АМД нашёл, и для Интел (но с ним только для i-cache
нашёл)

И для арм, конечно, тоже.

Доберёмся и до мелтдаунов. Мы почти закончили существующие
темы.

Звучит как ультиматум... Хорошо, давайте я сделаю вид, что признал всю вашу чушь по предыдущим темам, и вы, наконец, откроете мне тайну мироздания о meltdown-bnd. :) Блин, с какими же укурками иногда приходится дело иметь...

и вы, наконец, откроете мне тайну мироздания о
meltdown-bnd. :)

Иначе я просто уеду на майские, и вы, наконец, добьётесь того состояния, когда ваши глупости окажутся последним письмом в этом триде. И будете радоваться, что вас, наконец, никто не изобличает. :) Ну так вот вам простейший способ: дня 3 подождите пока я уеду, и всё будет именно так. Сможете «победу» отпраздновать. :)

Так что, либо давайте meltdown-bnd, либо ваши глупости таки окажутся в этом триде последним письмом...

Всё, о чём вы когда-либо говорили - не более, чем клоунада,
увы.

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

Вот объяснял-объяснял про vhints, а в ответ «Благодарю за подробное объяснение. В общих чертах идея понятна. Кроме куска: ... Тогда как по части виртуального адреса мы находим физический тег?» Пиляяять... Ну отправил в википедию читать, чего второй раз объяснять то. Думал, прочитал. Но через пару дней: «почему vhint не указывает прямо на линию?» Пипец. Начинаю объяснять, что vhint - не указатель, а ключ поиска. Объясняю про САМ, про тег... А в ответ: «Это просто была мелкая оптимизация для вашей архитектуры.» Какая, к чёрту, оптимизация? Ну да пофиг, про ассоциативный массив ведь, вроде, понял: «Но у этого ассоциативного массива же есть значение. Вот оно и может указывать на линию.» - и то хлеб. Сойдёт, думал. Данные тега ведь и правда указывают на вэй - пускай думает, что на линию, разница не велика...

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

Это под какое же, если не секрет?

Вы давали ссылку на https://vwzq.net/papers/evictionsets18.pdf где в секции «III.A. Defining Eviction Sets» есть определение.

То есть, по вашему, если создать алиасы в i-cache, как я описал выше, а потом переписать один из них через d-cache, то i-cache, без аппаратного резолвинга алиасов, тем не менее их все найдёт и проинвалидирует автоматически? Полагаю, пруфы можно и не пытаться просить? :)

Пруфы чего? Причём тут вообще алиасы? Алиасы — в пределах одного кеша. Между кешами — это когерентность. Вы, вроде, сами и писали, что они по разному ресолвились.

Тьфу ты, дурик, по чтению - да, а по записи - нет. :)

А кто говорил про запись? Или читать из несмапленой страницы уже можно?

Соответственно, даже никакие биты присутствия не понадобится. Префетчим всегда 2 последовательные физ страницы, спекулятивно их и отдаём. Когда физ адрес провалидирован через TLB, тогда, если не та страница - префетчим нужную...

Тут я опять потерял мысль. Прямо дислексия какая-то. Ну сколько ж раз просил — напишите в числах. Давайте я начну...

Страница 4к. Вирт.адрес 0x12345678 в вирт.странице 0x12345000. Её физ.адрес 0xABCDE000. Что лежит в линии кеша? Какие «2 последовательные физ страницы»? 0xABCDE000 и 0xABCDF000? Какой тут будет тег и какие «доп битики»? Как процессор по вирт.адресу определит, какая половина линии «нужная»? Напишите числа, у вас ведь хорошо получалось...

По этому ключу находят структуру данных, где есть номер вея, и куча служебных бит о состоянии линии. Таким образом, добавив в эту структуру (а не к ключу! не к ключу поиска структуры!!! поймите уже хоть это!) туда 2 битика, мы ни коим образом не создадим 2 тега!

Вы ранее подтвердили, что у вас «по вирт.адресу находим кеш-сет и vhint, по vhint-у в кеш-сете находим тег, по тегу в наборе тегов кеш-сета находим вэй, по вэю - линию». Где и как в этой цепочке участвуют ваши «2 битика»? Опишите исправленную архитектуру.

используя старшую часть физ адреса (от бита 13 и до конца) в качестве ключа поиска в CAM.

На всякий случай уточню, во фразе «от бита 13» вы считаете биты от 0 или от 1?

Что ж мне по крупицам из вас ответы вытаскивать приходится... Сами свою же идею никак не опишете, а потом жалуетесь на «клоунаду».

И что это доказывает?

Это отвечает на ваш вопрос.

Некий SW Solution инженер спросил в списке рассылки, есть ли отличия у PIPT и aliasing VIPT. Очевидно, будь у него хоть малейшее отношение к HW Dev Team, он бы такую фигню в публичных рассылках не узнавал...

Этого он не спрашивал.

Высокая ассоциативность, очевидно, тоже тормозит. Почему-то её обычно не делают больше 8.

Она не тормозит — она электричество жрёт и процессор греет. Её сложно сделать так, чтобы она не жрала в 8 раз больше. Но как-то делают...

При использовании cache coloring? А какое вообще отношение программный механизм - cache coloring - имеет к обсуждаемым нами аппаратным аспектам работы кеша?

Но без cache coloring или аналога таким процессором не пользуются. Или что мы в таком случае обсуждаем?

Биты индекса выходят за биты размера страницы MMU - вот что важно с точки зрения аппаратуры. «алиасы тут неизбежны».

Алиасы «неизбежны», но тем не менее из-за кеш колоринга их нет. Странная «неизбежность»...

И для АМД нашёл, и для Интел (но с ним только для i-cache нашёл) - достаточно.

Не факт, что нашли. Пруфов вы не давали. Для интела я проверил — не подтвердилось, AMD у меня нет, проверить не могу. У вас есть? Проверили?

Кстати, вы считаете процессоры десятилетней давности «современными»? И, да, мы про aliasing problem, которая есть только при записи, которой нет в i-cache.

И для арм, конечно, тоже.

Там где PIPT-кеш?

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

Там не было условий, там было «достаточно просто посмотреть характеристики современных L1/L2 кешей». Оказалось не так и просто, до сих пор смотрим.

[1/2] Диалог с Woolf-ом: знаменитый Ryzen-баг, читерство AMD с Performance Bias и CPU-Z...

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

Обсуждение началось с моего обзора[#] терминов Spectre и Meltdown, в котором упоминалось, что к AMD линуксоиды относятся с осторожностью, так как у них на линуксах были проблемы и с видеокартами, "и с процессорами им случалось эпично облажаться, из-за чего компиляция на AMD падала или создавала нерабочий софт". Со ссылкой на:

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

[История с CPU-Z на Ryzen-ах]
В ответ Woolf написал, что это чушь, то были просто бракованные процы, которые AMD всем поменяли. Я сказал что есть и другие подтверждения, и дал ссылку[#] на то, как "CPU-Z сменили бенчмарк, когда обнаружили, что Ryzen его специально дурит". Woolf предположил, "бенчмарк от CPU-Z хорошо поддался одной из оптимизаций". На что я процитировал[#] авторов CPU-Z, которые не обнаружили такого ускорения в реальном софте. Тогда Woolf заявил, что у CPU-Z просто кривой код. Я согласился, добавив, что синтетические бенчмарки вообще гавно, но это ничего не меняет, ведь если ускоряется только тест, то выходит, что оптимизация и была нацелена на тест, а не на реальный софт.

[Оптимизация ускоряет тесты, а не реальные приложения]
Наконец Woolf написал, что разработчики теста «обосрались» и что «реальные приложения НЕ ИСПОЛЬЗУЮТ ограниченный набор ОДНИХ И ТЕХ ЖЕ ПРОСТЫХ математических операций, даже НЕ СЧИТЫВАЯ результат их выполнения». Этой фразой он подтвердил, что такая оптимизация нацелена не на «реальные приложения». И далее мы пытались найти, когда это может сработать в реальном коде. Была неплохая попытка[#] примера, но я проверил — такой пример либо оптимизируется компилятором, либо будет записан в память, и тогда не может ускоряться процессором. А код, который может ускоряться процессором[#], не мог возникнуть в реальном приложении. Мы так и не нашли примеров, когда такая оптимизация ускорила бы реальные приложения.

[История с «Performance Bias» для AMD]
Также я упомянул[#] другие случаи, когда производитель пытался надурить бенчмарки, например «Performance Bias» от AMD, где прямо в названии указали тесты, ускоряемые при выборе этих опций (CB15, Aida/Geekbench, CB11.5). Woolf написал[#] что это просто оверклокерские опции материнки, которые меняют «частоты и изменяют логику работы чипсета» (и ещё что-то странное про «Performance Bias с семейства Carrizo» но позже сам же уточнил[#], что это не то, я так и не узнал что он имел ввиду. Там же он писал, что AMD «при запуске 3DMARK ЗАМЕДЛЯЕТ видяшки», но не писал почему. Может, перегреваются...) И он же добавил, что AMD тут не причём, биос пишут не они.

Я пытался взывать к логике, мол, биос они не пишут, но дают микрокод, и "AMD могла дать разные микрокоды для разных бенчмарков". А если это оверклокинг, то там была бы одна опция «maximum performance», а не три опции под разные тесты, «нельзя же одним напряжением разгонять только CineBench11, а другим только CineBench15». Но логика не взывалась, и я явно перечислил[1], что известно о «Performance Bias» и на что он на самом деле влияет. На этом диалог и закончился.

Но параллельно мы обсудили ещё несколько тем...

[2/2] Диалог с Woolf-ом: что такое RISC и микрокод.

[Что такое RISC]

В процессе обсуждения Ryzen-баг сравнили с meltdown, и я отметил[#], что в AMD это баг, ведь он «валил обычные приложения», в отличие от Intel-а, в котором это просто особенность архитектуры, и «если они проделают те же проверки в другом порядке, то бага не будет».

Woolf парировал «То-то они не могут переписать микрокод для проверки значений в другом порядке», ведь «внутри процессоры уже давно имеют RISC-архитектуру»[#], и даже процитировал, что «сложные команды могут состоять из сотен, а для некоторых современных команд — из тысяч микроопераций».

В ответ я объяснил[2], что «RISC-архитектуры нет вообще», что RISC — это только набор инструкций, и даже современные «RISC-процессоры» ему не удовлетворяют. По сути, RISC-и вымерли. Если только не считать RISC-ами процессоры, где одну инструкцию можно условно разбить на несколько действий. Но тогда «всё в мире — RISC-процессоры, и ничего другого в мире не было никогда»[3].

[Микрокод]

В обсуждении RISC-ов Woolf написал[#], что «Микрокод это как раз то, что превращает RISC в CISC», и его структуру не раскрывают, ведь если её знать, то можно встраивать в микрокод зловредные операции. Причём «микрокод весит... тадамм - 2048 байт», и в него не впихнуть распознавание бенчмарков.

Я ответил[#], что как раз распознавание бенчмарка в 2к байт поместится, только вот «Инструкций тысячи. В 2048 байт не поместится даже их список. То есть либо там не 2048 байт, либо микрокод никого никуда не превращает, либо ни то ни другое».

Woolf попытался привести пример с умножением, и я объяснил[4], что умножение в 8086 было «microcoded» не потому, что там есть микроинтерпретатор каких-то команд, а потому что алгоритм был «закодирован в микропроцессоре в виде матрицы AND/OR-элементов». И на вопрос, как тогда L1TF правили микрокодом, я ответил, что его и не правили, просто «посоветовали чистить кеш на входе и выходе в SGX/VM».

ИТОГО. Мы обсудили, что описанная оптимизация AMD Ryzen-ов ускорить может только бенчмарки, и что производители вообще жульничают в тестах и демонстрациях, что современные процессоры внутри совсем не RISC-и, да и даже современные RISC-процессоры уже давно не RISC-и. А также вкратце обсудили, что может и чего не может делать микрокод.

Были и ещё некоторые мелочи, Berkeley RISC, 64-байта выводящие 3D-туннель, Intel-овский разгон процессора для демонстрации, бенчмарки винды до и после L1TF... Любопытные могут прочитать тред целиком — это всего одна страница от [0] до [1].

В целом, это был очень удачный тред развеивания мифов. Благодарю Woolf-а за участие.

[0] Начало диалога. Обзор Meltdown и Spectre.
[1] «Performance Bias» - это читерство для бенчмарков, и оно влияет не на частоты/напряжения, а на микрокод или скрытые регистры AMD CPU
[2] Термина «RISC-архитектура» нет, он ничего не значит. Были RISC-инструкции, но сейчас нет и их.
[3] Отличия инструкций от операций, как их считать, и что ещё можно назвать RISC-процессором
[4] Какой на самом деле микрокод и умножение в 8086

Зачем столько текста катать ради амуде шизиков? Воистину, мертвецы не знают, что они мертвы и как их окружающие от этого страдают. То же самое с амудунами.

Зачем столько текста катать ради амуде шизиков?

Ну почему же шизиков. Продукты AMD часто дешевле, чем у конкурентов. И если вы готовы потратить своё время, и сэкономить деньги, то AMD вам вполне может подойти.

Да и хорошие идеи у AMD тоже есть. Например, используемый всеми amd64.

где в секции «III.A. Defining Eviction Sets» есть
определение.

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

Пруфы чего? Причём тут вообще алиасы? Алиасы — в пределах
одного кеша.

Вот идиот, я же сто раз сказал, как создать алиасы в i-cache. Замапить один кусок кода в разные места, и заэкзекьютить каждый маппинг, чтобы запрефетчился. Сколько ж тупить можно?

А кто говорил про запись? Или читать из несмапленой
страницы уже можно?

Спекулятивно - да. Как мы знаем, все так и делают. :)

Какие «2 последовательные физ страницы»? 0xABCDE000 и
0xABCDF000?

Как вариант, я предложил спекулятивно брать 2 последовательные страницы. По этому, сначала именно так. Но в моём примере 2 последовательные вирт страницы мапят одну физ страницу, по этому, со временем, в одной линии будет дважды лежать 0xABCDE000, а в другой - дважды 0xABCDF000 (после прихода ответов от TLB).

Какой тут будет тег

Одинаковый (0xabcde000 для обеих линий).

и какие «доп битики»?

0 0 для первой линии, и 1 1 для второй.

Как процессор по вирт.адресу определит, какая половина
линии «нужная»?

Биты оффсета, как известно, напрямую из вирт адреса берутся. Соответственно, бит 12 и будет определять «нужную половину». Что непонятно то?

Где и как в этой цепочке участвуют ваши «2 битика»?

Я вам уже привёл даже ссылку на tag data. Вот там и лежат.

Опишите исправленную архитектуру.

Относительно чего исправленную? Её никто не правил.

На всякий случай уточню, во фразе «от бита 13» вы считаете
биты от 0 или от 1?

От 0.

Этого он не спрашивал.

I think PIPT does not mean VIPT non-aliasing even
though their functionality is similar.
Isn't there any functionality difference?
And..in this case, isn't there any problems?

Ещё враки будут? «non-aliasing», в случае АРМ, как мы уже знаем, означает и аппаратный резолвинг алиасов тоже.

Она не тормозит

Иди читай википедию уже...

However, increasing associativity more than four does not
improve hit rate as much

Но как-то делают...

Кто делает в L1 более 8 вэев?

Но без cache coloring или аналога таким процессором не
пользуются.

В i-cache - спокойно. Или, если это унифицированный кэш, то для инструкций, опять же, можно cache coloring не использовать. Алиасы в обоих случаях можно создать. Так что кеш колоринг - не панацея, и для нас главное, что биты индекса выходят за размер страницы MMU. И таких архитектур полно.

Не факт, что нашли. Пруфов вы не давали.

https://www.amd.com/system/files/TechDocs/43042.pdf

64-Kbyte 2-Way Associative ECC-Protected L1 Data Caches

Для интела я проверил — не подтвердилось

Ну да, проверять будет тот, кто считает, что кэш линию индекс выбирает. :)

И, да, мы про aliasing problem, которая есть только при
записи, которой нет в i-cache.

Во первых, есть. Во вторых, для АМД это и d-cache тоже. Для интела - не знаю, может быть только i-cache.

Там где PIPT-кеш?

Даже если верить вашему «пруфу», где чел спрашивает о различиях, так даже там он лишь пишет, что это конкретный чип самсунга так сделан. Я же вам давал пруфы от людей из ARM, ссылавшихся на лид архитектора. И на патент от того же АРМ. Поди по-лучше пруф, чем какой-то вопрос на форуме. Соответственно, вне зависимости от того, что делает самсунг, на АРМах алиасы есть, и, для d-cache, резолвятся аппаратно.

Там не было условий, там было «достаточно просто посмотреть
характеристики современных L1/L2 кешей»

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

Если у вас размер ВИПТа больше, чем размер страницы
помноженный на ассоциативность кеша, то алиасы там неизбежны.

Кто делает в L1 более 8 вэев?

Сам уже нашёл: ARM940T так делает. Но, при этом, не для увеличения размера кэша. И i-cache и d-cache там по 4К. БольшИх кэшей с высокой ассоциативностью пока не нашёл, а вот с алиасами - полно.

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

по тегу в наборе тегов кеш-сета находим вэй

Нет, по ключу тега (коим является кусок физ адреса либо vhint) находим tag data, а там номер вея.

Эй, анонимный пиздобол, где дальнейшие кривляния то? Где обещания показать на ошибки, убедить в чём-нибудь, про meltdown-bnd сказки рассказать? :) Чего, натупил и слинял? А ну вернись, гадёныш! Я с тобой ещё не закончил. :)