LINUX.ORG.RU

Понимание широкой команды, VLIW

 ,


4

2

Лорчик, у меня тут вопрос возник, чисто теоретический.

Есть VLIW, архитектура e2k. Если посмотреть ассемблерный код, то команда там будет в фигурных скобках. Это и есть одна широкая команда.

Пример:

{
  nop 2
  istofd,3    %g17, %g18
}
{
  nop 7
  sdivs,5     %g17, %g16, %g16
}

В документации сказано, что одна такая широкая команда выполняется процессором за 1 такт. Справедливости ради, нужно заметить, что здесь ни слова про ядра. Просто сказано, что за один такт.

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

Поскольку e2k не содержит жуткого блока предсказаний, как на обычном х86_64 и не умеет распаралеливать команды сам. За него это делает компилятор. Вот для этого и нужна эта широкая команда - компилятор распаралелил, перетасовал команды и сказал как их надо выполнить.

А теперь вот вопрсик в связи с этим. Получается, что прогу для e2k придется пересобирать для разных e2k процессоров с разным числом ядер?

Допустим прога собрана для Эльбрус 8С, у которого 8 ядер. Значит в фигурных скобках будет много команд. Т.е. широкая команда будет ну очень широкой, широчайшей прям! А запустится ли этот получившийся бинарник, скажем на 4С, у которого только 4 ядра? А на 1С? В смысле без пересборки.

★★★★★

Ответ на: комментарий от Puzan

Будешь травить «колодцы» в металле?

Незнаю, что за «колодцы». Но высота (толщина слоя) не напрямую зависит от линейных (длина и ширина) размеров.

anonymous
()
Ответ на: комментарий от anonymous

Но высота (толщина слоя) не напрямую зависит от линейных (длина и ширина) размеров.

Так всё таки зависит? Ты путаешься в показаниях.

Puzan ★★★★★
()
Ответ на: комментарий от Puzan

Так всё таки зависит? Ты путаешься в показаниях.

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

нет? я гоню?

в общем по-моему у эльбруса круче, топлю за них.

anonymous
()
Ответ на: комментарий от anonymous

Очевидно, что можно делать и partial bt, примеров, правда, сходу не приведу.

Nvidia Denver, Carmel. У них простой аппаратный декодер и бинарная трансляция для горячего кода.

anonymous
()
Ответ на: комментарий от anonymous

Прям только одно сообщение. :)

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

(И процессор с таким кешем превращается из процессора общего назначения в процессор последовательного выполнения команд над последовательно поступающими данными)

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

anonymous
()
Ответ на: комментарий от anonymous

Я говорю, что некоторые измерения можно не менять (так же, как остальные).

Во-первых, ты сказал, что «не напрямую зависит», не юли.

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

Хватит уже тупить. Или зарегистрируйся, чтоб народ знал своих героев.

Puzan ★★★★★
()
Ответ на: комментарий от anonymous

но код горячий потому что он не был оптимизирован

Это неверное предположение. Код горячий по своей семантике, например какой-нибудь цикл 100 вложенности. И как ты код не оптимизируй, эта горячесть с него не уйдет, разве что ты не сможешь в компайл тайме посчитать результат его выполнения и свернуть его в константу.

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

Если ты исполняешь транслированный код вместо нативного, то и транслированный код можно дальше оптимизировать, про это есть в презентации.

жит выбрасывает всё что он наоптимизировал и начинает оптимизировать новые горячие места

По какой причине что-то будет удалено из code cache? Я бы предложил, что основные варианты это или инвалидация трансляции по разным причинам(страницу отмаппили или smc случился), или закончилось место, или коллизия по адресам.

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

Почему транслированный код не может быть горячим?

в общем по-моему у эльбруса круче, топлю за них.

У эльбруса круче что?

топлю за них.

uin, залогинься.

anonymous
()
Ответ на: комментарий от anonymous

Fair enough.[br] Но мое сердечко, конечно, принадлежит full system bt.

anonymous
()
Ответ на: комментарий от anonymous

Это неверное предположение. Код горячий по своей семантике, например какой-нибудь цикл 100 вложенности. И как ты код не оптимизируй, эта горячесть с него не уйдет, разве что ты не сможешь в компайл тайме посчитать результат его выполнения и свернуть его в константу.

ну или не оптимизирована та часть которая приводит к вызову этого цикла 100 вложенности.

всё таки компилятор - это вещь, а жит - это так, померяли температуру и прописали клизму.

или закончилось место

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

anonymous
()
Ответ на: комментарий от Puzan

Во-первых, ты сказал, что «не напрямую зависит», не юли.

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

невозможно не уменьшать высоту с уменьшением ширины.

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

В добавок высота слоя влияет на диэлектрические способности слоя. Так что высота задается независимо (чтобы удовлетворить твоим требованиям «скорости света» :) )

anonymous
()
Ответ на: комментарий от anonymous

ну или не оптимизирована та часть которая приводит к вызову этого цикла 100 вложенности.

Предлагаю привести конкретные примеры таких «неоптимизаций», из-за которых семантика исполняемой программы меняется, если я тебя правильно понял.

всё таки компилятор - это вещь, а жит - это так, померяли температуру и прописали клизму.

Если хочется сравнивать бетонные блоки и яблоки, не могу этому мешать.

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

Система профилирования исполняемого кода и система гиринга.

то жит должен сделать в этой ситуации если места под более горячее место не осталось?

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

anonymous
()
Ответ на: комментарий от anonymous

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

А ты какую предлагаешь?

Когда станет невозможно уменшать высоту, только тогда и уменьшат

Когда?

В добавок высота слоя влияет на диэлектрические способности слоя.

«В добавок» ты тупой. Во-первых: при чем тут диэлектрические свойства? Речь шла про сопротивление. Во-вторых: шта? Ты сморозил бред.

Puzan ★★★★★
()
Ответ на: комментарий от anonymous

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

Причем тут поддержка (количества) сообщений?

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

Скорее всего интел и амд экпериментально определили, что для x86 640 КБ 32 КБ (независмых данных) хватит всем. То есть, такой размер - архитектурное решение, а не влияние «скорости света».

Что там у эппла с arm, и какие архитектурные решения - я без понятия.

anonymous
()
Ответ на: комментарий от anonymous

Причем тут поддержка (количества) сообщений?

Вот и я не понимаю. Цитирую.

Большой размер кеша предполагает больше накладных раходов по синхронизации кешей, например.

Каких расходов, так и не узнали.

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

Что это за бред?

Скорее всего интел и амд экпериментально определили, что для x86 640 КБ 32 КБ (независмых данных) хватит всем. То есть, такой размер - архитектурное решение, а не влияние «скорости света».

Каких независимых? Ты вообще знаешь про протоколы поддержки когерентности кэшей (MOESI)? Как это связано с размером кэша?

anonymous
()
Ответ на: комментарий от Puzan

А ты какую предлагаешь?

Я предложил высоту не менять.

Когда?

Что когда? Толщина слоя напыления металла не зависит от длины и ширины (конкретого) проводника. Как там делают проводники из поликремния - без понятия, какое у них сопротивление - тоже без понятия.

«В добавок» ты тупой.

Так и думал, что придирешься к грамматике.

Во-первых: при чем тут диэлектрические свойства?

При том, что толщина слоев (металлов и диэлектриков) задается незавсисимо от длины и ширины полосок проводников.

Речь шла про сопротивление.

Вот именно высота слоя проводника не зависит от того какие проводники из него нарисуют (вытравят).

Ты сморозил бред.

Никто не запрещает. Как и тебе.

anonymous
()
Ответ на: комментарий от anonymous

К аких расходов, так и не узнали.

Ты вообще знаешь про протоколы поддержки когерентности кэшей (MOESI)?

Протокол сам по себе без штрафов подгрузит инвалидированные данные из памяти? Обеспечение работы протокола также бесплатно дается?

Еще один верующий в то, что кеш - это только хорошо, кеш промах - это программист криворук.

anonymous
()
Ответ на: комментарий от anonymous

Предлагаю привести конкретные примеры таких «неоптимизаций», из-за которых семантика исполняемой программы меняется, если я тебя правильно понял.

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

вообще любая динамическая система.

как в этой ситуации поступит жит?

anonymous
()
Ответ на: комментарий от anonymous

если все 3 промахи все последующие операции зависят от r3 ядро заполнит очередь исполнения в 97 микроопераций (те самые инструкции на лету) ядро заполнит очередь перед бэкендом будет ждать пока не завершатся все три обращения в память и ничего не делать Как здесь помогает OoOE? Жду подробного объяснения.

Ок, так и запишем: «частичное решение» курильщика работает только в особом, надуманном случае. Частичное решение здорового человека работает кроме особого надуманного случая.

Дай ссылку на исследование где написано про 95%.

Опять дурачка включил? Ну дай свою оценку, какая доля от обращений к памяти описывается предложенными тобой условиями. Напомню: это в условно выполняемом блоке, чтоб условие зависело от предыдущего доступа к памяти, а адрес доступа не зависел. На всякий случай укажу, стандартное if(ptr != nullptr) {... = *ptr;...} под это условие не подходит.

У тебя точно проблема с памятью! Цитирую.

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

И я у тебя, клоун, не спрашивал, зачем в ядре L1 и L2. Если человек пишет вопрос и тут же в следующем предложении даёт ответ, то это называется «риторический вопрос». Конкретно в данном случае ты просто пытаешься съехать с темы и не отвечать на тот, по которому ты слился.

У меня начался гомерический смех от твоего утверждения и я допустил опечатку, вместо L1i написал L1$.

Ты опять дурачка включил? Я не стал бы докапываться до опечатки. Меня поразила твоя готовность съехать с вопроса о безумном объёме L3 на сравнение кэшей L1. И ещё больше мне понравилось желание сравнить кэш L1 с другим L1 на основании того, что и там и там первый уровень. Видимо, если б в Intel решили назвать кэш декодированных операций L1, а тот, который сейчас называется L1 обозвали бы вторым уровнем, ты бы эппловские 256 килобайт с объёмом кэша декодированных операций сравнил бы. Я говорю, вся твоя местная аргументация просто дешёвый мухлёж.

От L1 требуется работа с минимальными задержками. В высокопроизводительных системах это соответствует 1 такту. При частоте 5 ГГц на такт отводиться 200 пикосекунд. За это время электромагнитная волна может пройти ~60 мм

Так, астанавись, клоун.

Вопрос не касается L1 вообще. И ты это знаешь, ты пару сообщений назад о задачах на 64 мегабайта тут вещал. Я всё-таки хотел бы получить от тебя очевидно истинный ответ, после чего назвать тебя дебилом, лезущим в спор от тупости и закончить с тобой.

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

Нет никаких особых причин, почему кэш первого уровня должен работать с задержкой в один такт. Вот просто нет и всё. Конечно, лучше если меньше, но можно и побольше. Увеличь латентность на 1 такт и время можно удвоить, до 400 пс, при этом количество транзисторов останется тем же (ну, по крайней мере у тебя в рачётах так), так что линейное расстояние с 50 вырастет до 250, в 5 раз больше, а если взять квадрат, то в 25 раз больше. И даже не факт, что софтварно этот дополнительный такт можно будет заметить.

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

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

А я тебе предложу не парить мозг и вернуться к L3 кэшам современных процессоров. Тем более, что по измерению ананда, общий на все ядра L2 кэш A12 имеет объём 8 мегабайт и латентность 8.8 нс, а у Zen 2 с 32мя мегабайтами, латентностью в 40 и частотой в 4.5 тоже где-то в районе 9нс получается, поэтому почему бы нам не взять и не сравнить эти похожие по характеристикам кэши и не задаться вопросом о причинах такого различия в объёмах?

khrundel ★★★★
()
Ответ на: комментарий от anonymous

как в этой ситуации поступит жит?

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

anonymous
()
Ответ на: комментарий от khrundel

Я не следил пристально за вашей дискуссией, но в чем предмет спора? И почему вы перешли к обсуждению кешей?[br]

anonymous
()
Ответ на: комментарий от anonymous

как в этой ситуации поступит жит?

Щас бы сложные, неоднозначные и потенциально дырявые алгоритмы прошивать в железе. Даже если не в железе, а в ring0. Вердикт: не надо.

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

Можно же формально доказать, что эти оптимизации не меняют семантику кода.

Кому доказать - сертифицирующему органу? Клиент-владелец может проверить прошивку? Формальное доказательство - это доказательство корректности модели, а не реального объекта.

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

Какие такие требования у экспериментальной поделки частной компании не уважающей opensource?

anonymous
()
Ответ на: комментарий от anonymous

экспериментальной поделки частной компании не уважающей opensource?

Я бы предложил пропустить этот лоровский булшит и иметь конструктивный диалог. Или не иметь его вовсе.

Кому доказать - сертифицирующему органу?

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

Формальное доказательство - это доказательство корректности модели, а не реального объекта.

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

Какие такие требования у экспериментальной поделки частной компании не уважающей opensource?

MISRA и что-то там еще? Я тут несведущ, увы, в процедуре сертификации по этим стандартам: не знаю, нужно ли им предоставлять исходники на ревью или же достаточно пройти набор тестов. В моей практике бывало всякое.

anonymous
()
Ответ на: комментарий от anonymous

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

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

Я тут несведущ

Я тоже. То есть разговор про требования не имеет никаких (формальных) оснований.

(Пусть знающие люди расскажут как за какие гешефты сертифицируются реальные объекты, которые могут самовозгораться, путают рекламные знаки со знаками остановки и тд и тп)

anonymous
()
Ответ на: комментарий от anonymous

Щас бы сложные, неоднозначные и потенциально дырявые алгоритмы прошивать в железе.

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

У формального доказателства есть проблема с тем, что это NP-полная задача.

Это все правда, да. Тут, скорее, стоит говорить о том, что теоретическая возможность сделать полностью доказанную систему есть, но мало кто будет тратить на это необходимые ресурсы(особенно с точки зрения бизнеса). Поэтому доказываться, наверняка, будут какие-то совсем критичные куски.
Насчет верификации оптимизаций можно, например, посмотреть сюда: https://github.com/AliveToolkit/alive2
Боттомлайн предложу такой: да, полностью доказанная система это утопичный миф, но средства для того, чтобы повысить ее надежность до какой-то степени - есть.
Не стоит забывать, что в nvidia над этим проектом трудятся, пожалуй, одни из самых лучших специалистов в области бинарной трансляции, поэтому они куда лучше представляют все сопутствующие проблемы и их возможные решения.

anonymous
()
Ответ на: комментарий от anonymous

Протокол сам по себе без штрафов подгрузит инвалидированные данные из памяти?

Не неси чушь. Зачем из памяти? Из нижнего уровня кэша, если он общий для всех ядер.

Обеспечение работы протокола также бесплатно дается?

Большой размер кеша предполагает больше накладных раходов по синхронизации кешей, например.

Повторяю вопрос в сотый раз. Как это связано с размером кэша?

anonymous
()
Ответ на: комментарий от khrundel

Ок, так и запишем: «частичное решение» курильщика работает …

Где подробное объяснение?

Ну дай свою оценку, какая доля от обращений …

Где ссылка на исследование?

Не-не-не, не надо мухлевать. Тот кусок, который ты процитировал, он касался твоей ошибки …

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

И я у тебя, клоун, не спрашивал, зачем в ядре L1 и L2. Если человек пишет вопрос и тут же в следующем предложении даёт ответ, то это называется «риторический вопрос».

Где здесь ответ?

Кэши вообще проблему не решают, от слова совсем. Ты не задумывался, почему делают 3 уровня кэша? Ладно L3, он общий на все ядра, типа для обмена данными сойдёт, но нафига в одном ядре иметь L1 и L2? Может быть потому, что уже задержки L2 слишком велики, чтоб их просто игнорировать? Чем там поможет нашлёпка из L4, задержки которой будут раз в 10 больше чем у L2?

Сплошные вопросы.

И ещё больше мне понравилось желание сравнить кэш L1 с другим L1 на основании того, что и там и там первый уровень.

Так это ты сравнил.

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

Клиника.

Нет никаких особых причин, почему кэш первого уровня должен работать с задержкой в один такт. Вот просто нет и всё. Конечно, лучше если меньше, но можно и побольше. Увеличь латентность на 1 такт и время можно удвоить, до 400 пс, при этом количество транзисторов останется тем же (ну, по крайней мере у тебя в рачётах так), так что линейное расстояние с 50 вырастет до 250, в 5 раз больше, а если взять квадрат, то в 25 раз больше. И даже не факт, что софтварно этот дополнительный такт можно будет заметить.

Если ты хочешь в производительность, то очень желательно. Открываешь instruction_tables и ищешь для Skylake задержку для инструкции mov r32/64,m. Она равна 2 тактам. Первый такт это генерация адреса, второй обращение в кэш. Заметишь влияние на том примере, который так хитро проигнорировал, если промахов не будет.

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

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

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

Удивительно! В этот раз ты всё понял, а раньше включал дурочка. А если у нас площадь увеличилась в 4 раза, то сколько времени надо волне, чтобы пройти по граням этой структуры?

А я тебе предложу не парить мозг и вернуться к L3 кэшам современных процессоров. Тем более, что по измерению ананда, общий на все ядра L2 кэш A12 имеет объём 8 мегабайт и латентность 8.8 нс, а у Zen 2 с 32мя мегабайтами, латентностью в 40 и частотой в 4.5 тоже где-то в районе 9нс получается, поэтому почему бы нам не взять и не сравнить эти похожие по характеристикам кэши и не задаться вопросом о причинах такого различия в объёмах?

L2/L3/L4/etc выдают ответ на запрос не за 1 такт, а в зависимости от размера структуры.

anandtech

~35 cycle to ~40 cycle

32 / 8 = 4           # соотношение размеров кэша
4 * 8.8 ns = 35 ns   # на основе задержки A12

Всё удивительно сходится.

anonymous
()
Ответ на: комментарий от anonymous

Я не следил пристально за вашей дискуссией, но в чем предмет спора? И почему вы перешли к обсуждению кешей?

Он отрицает ограничение скорости света.

anonymous
()
Ответ на: комментарий от anonymous

Цифра 150

Какая нахрен цифра, число. Пора прекращать с тобой общаться.

anonymous
()
Ответ на: комментарий от anonymous

Зачем из памяти? Из нижнего уровня кэша, если он общий для всех ядер.

Кеш - это не память? :)

Ты еще уровни (типы) памяти начни перечислять - регистры, кеши, оперативная, внешняя (от ssd до магнитных лент).

Повторяю вопрос в сотый раз. Как это связано с размером кэша?

Вот и напиши/нарисуй независящий от размера носителя данных(кеша) алгоритм (протокол) синхронизации данных на носителях. Сложность О(1) и по времени и по дополнительной памяти.

anonymous
()
Ответ на: комментарий от anonymous

Как это связано с размером кэша?

При этом ты @khrundel доказываешь про зависимость задержек от размера. Даже нашел объяснение этому - скорость света.

У тебя раздвоение личности или это разные анонимы?

anonymous
()
Ответ на: комментарий от anonymous

Кеш - это не память? :)

Не юли. Когда говорят про CPU кэш и память, то очевидно что под кэшем подразумевают L1-LN (обычно SRAM, быстро мало), а под памятью DDR (обычно DRAM, медленно много).

Ты еще уровни (типы) памяти начни перечислять - регистры, кеши, оперативная, внешняя (от ssd до магнитных лент).

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

Вот и напиши/нарисуй независящий от размера носителя данных(кеша) алгоритм (протокол) синхронизации данных на носителях. Сложность О(1) и по времени и по дополнительной памяти.

Цитирую.

Ты: И этот размер не зависит от частоты процессоров.

Я: Если он не зависит, то почему Intel и AMD не сделают такой же? Это положительно скажется на скорости вычислений. Но вместо этого они сделали тот самый L2. К L2 меньше требований по задержкам и его можно сделать больше и получать данные с задержкой в несколько таков.

Ты: Большой размер кеша предполагает больше накладных раходов по синхронизации кешей, например.

  1. Ассоциативность:

    • кол-во компараторов (сравнение параллельное O(1))
    • мультиплексор O(log N))
    • размер памяти (площадь) под теги/данные
  2. Кол-во сетов:

    • мультиплексор O(log N).
    • размер памяти (площадь) под теги/данные
  3. На строку приходится 3 бита для MOESI. Этот размер никак не меняется от размера/ассоциативности кэша.

  4. Сложность поддержания когерентности зависит от количества обрабатываемых сообщений по протоколу MOESI O(N).

Увеличивая только размер кэша, на MOESI тратится 3 бита на строку. Капля (~0.5%) в море на фоне остального (512 бит данные + 55 бит тег). Давай ответ с аргументами, а не как обычно «вы всё врёте».

Мне уже надоела эта игра в одни ворота.

anonymous
()
Ответ на: комментарий от anonymous

При этом ты @khrundel доказываешь про зависимость задержек от размера. Даже нашел объяснение этому - скорость света.

Пытаешься запутать следы?

anonymous
()
Ответ на: комментарий от anonymous

Лезть за недавно модифицированными данным в память не надо, они уже в кэше.

Они возможно есть в кеше нижнего уровня, обращение к которому больше чем обращение к текущему кешу.

И почему ты регистры процессора не считаешь кешем (памятью)?

По твоей логике лучше сделать большой регистровый файл (блок, или как там правильно). И чем больше, тем лучше. Что ты мелочишься на каких-то кешах?

И что только 3 отвечает за поддержание синхронности (достоверности, целостности, когерентности) данных в памяти? Данные не надо копировать, перемещать? «Пришло всего лишь одно сообщение» и нужные данные сами материализовались?

Ты спецом тупишь, или оправдываешь тупостью свой бред?

Давай ты лучше сперва на реальных фактических данных нарисуешь график «частота – размер l1».

Минимум из 10 точек, а не из 2.

Любитель экстраполировать по 2 точкам.

Потом будем строить теории заговора свидетелей скорости света.

anonymous
()
Ответ на: комментарий от anonymous

Они возможно есть в кеше нижнего уровня, обращение к которому больше чем обращение к текущему кешу.

И почему ты регистры процессора не считаешь кешем (памятью)?

Почему ты кэш не считаешь регистрами (памятью)?

По твоей логике лучше сделать большой регистровый файл (блок, или как там правильно). И чем больше, тем лучше. Что ты мелочишься на каких-то кешах?

Ты не сможешь, для рег. файла нужно много портов.

Ты спецом тупишь, или оправдываешь тупостью свой бред?

Давай ты лучше сперва на реальных фактических данных нарисуешь график «частота – размер l1».

Минимум из 10 точек, а не из 2.

Любитель экстраполировать по 2 точкам.

Потом будем строить теории заговора свидетелей скорости света.

Что и требовалось доказать. Аргументация отсутствует.

Басня голубь и шахматы

anonymous
()
Ответ на: комментарий от anonymous

Почему ты кэш не считаешь регистрами (памятью)?

Это я начал разделять разные виды памяти, стрелочник-экстраполятор?

Я как задаю вопрос: почему ты прицепился к L1 и незамечешь «более эффектное» увеличение регистров?

Давай, вперед, рисуй график зависимости количества регистров от частоты процессора. Там тоже поищем теории заговора скорости света.

Аргументация отсутствует.

Смысл аргуметировать твой бред.

anonymous
()
Ответ на: комментарий от anonymous

O(log N)

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

anonymous
()
Ответ на: комментарий от anonymous

Где подробное объяснение?

Какое объяснение? Да, в предложенном тобой варианте с кучей неудобных условий, ООО не сможет. А твоё «частичное решение» сможет ТОЛЬКО в предложенном тобой варианте с кучей условий. Понимаешь разницу? Твои часы показывают точное время 2 раза в сутки и ты называешь это «частичным решением», добавляя «зато если по твоим часам молотком, то они тоже сломаются».

Где ссылка на исследование?

А докУмент с круглой печатью тебе не подать? Давай, дай свою оценку. Можешь даже без исследований, клоун. Моя - менее 5%.

Где здесь ответ?

Я написал: в следующем предложении. Знаешь что такое «предложение»?

Так это ты сравнил.

Опять врёшь, клоун. Ты сравнивал размеры L1 кэшей, а я над тобой смеялся. И ты даже без подсказки не понял, почему я ржал, думал что из-за опечатки.

Если ты хочешь в производительность, то очень желательно. Открываешь instruction_tables и ищешь для Skylake задержку для инструкции mov r32/64,m. Она равна 2 тактам.

Ой дурак. Ну вышло бы поколение Spacelake, в котором задержка была бы равна 3м тактам. Разработка процессоров - это сплошные компромиссы. Вон, был Netburst, в котором на равной частоте старые программы работали медленнее, зато думали частотой взять. А до этого был Pentium, который на неперемешанном коде не мог второе исполняющее устройство заюзать. Ничто не помешает в какой-то момент поменять латентность, если посчитают что так будет лучше. Чувак, твои расчёты мало того, что к теме не относятся, они ещё и просто тупые.

Кроме того, в той же статье с ананда (https://www.anandtech.com/show/13392/the-iphone-xs-xs-max-review-unveiling-the-silicon-secrets/3) была таблица с латентностями арм-совместимых ядер. В ячейке с а12 там пусто, но для родных арм ядер там у load латентность в 4 такта. Возможно в этом причина разного размера L1 кэша, в том, что армовики решили, что протерпеть дополнительные 2 такта им норм, и они вместо 2хуровнего кэша внутри ядра запилили один, чуть-чуть помедленнее чем L1 у x86, но зато такой же большой как L2 у него же?

Удивительно! В этот раз ты всё понял

Понять тебя не трудно, тебе приходит простая, и часто идиотская мысль, а потом ты подгоняешь под неё расчёты и условия. Так было со спекулятивностью, сейчас вот подгоняешь под теорию «во всём виновата скорость света».

Чтоб было понятно: я не спорю с твоими рассуждениями. Я этого момента не знаю. Мне кажется, что сомнительно. Что на скорость кэша будет сильнее влиять сложность схемотехники кэша. У x86 в отличие от арма, строгий порядок памяти, так что, вероятно, кэш x86 может оказаться тупо более сложным на 1 бит из-за дополнительной логики инвалидации.

Всё удивительно сходится.

Да. А особенно удивительно, что сошлись у тебя 35 наносекунд с 35 циклами :).

Знаешь, была такая история, один французский учитель математики задал классу задачу, в стиле «на корабле везут 2 коровы и 90 гусей, сколько лет капитану». И полкласса ответило, что 45. Ну типа если перемножить коров и гусей, получится дофига, а если поделить, то примерно правдоподобное число. Ты, видимо, в той же школе учился.

khrundel ★★★★
()
Ответ на: комментарий от anonymous

Поправил. O(log2 N)

В военных условиях pi = 4, ой, то есть скорость света с = 2 (безразмерная величина)

Так держать. Продолжай «аргументировать».

anonymous
()
Ответ на: комментарий от i-rinat

O(log N)

Поправил. O(log2 N)

Продолжай «аргументировать».

Да ладно тебе, это же явно шутка.

Да ладно тебе. Шутки - это серъезная работа шута, в том числе меня.

anonymous
()
Ответ на: комментарий от khrundel

Какое объяснение? Да, в предложенном тобой варианте с кучей неудобных условий, ООО не сможет.

Выходит ООО тоже частичное решение.

А докУмент с круглой печатью тебе не подать? Давай, дай свою оценку. Можешь даже без исследований, клоун. Моя - менее 5%.

Я про 95% не заявлял, давай ссылку.

Ой дурак. Ну вышло бы поколение Spacelake, в котором задержка была бы равна 3м тактам. Разработка процессоров - это сплошные компромиссы. Вон, был Netburst, в котором на равной частоте старые программы работали медленнее, зато думали частотой взять. А до этого был Pentium, который на неперемешанном коде не мог второе исполняющее устройство заюзать. Ничто не помешает в какой-то момент поменять латентность, если посчитают что так будет лучше. Чувак, твои расчёты мало того, что к теме не относятся, они ещё и просто тупые.

Вот когда он выйдет, то и поговорим, а сейчас у Skylake L1d 32 Кбайт и с задержкой в 1 такт.

В ячейке с а12 там пусто, но для родных арм ядер там у load латентность в 4 такта. Возможно в этом причина разного размера L1 кэша, в том, что армовики решили, что протерпеть дополнительные 2 такта им норм, и они вместо 2хуровнего кэша внутри ядра запилили один, чуть-чуть помедленнее чем L1 у x86, но зато такой же большой как L2 у него же?

2 такта это с генерацией адреса, у ARM тоже сложная адресация. base + offset/reg/imm. На получение данных из кэша 1 такт.

Чтоб было понятно: я не спорю с твоими рассуждениями. Я этого момента не знаю. Мне кажется, что сомнительно. Что на скорость кэша будет сильнее влиять сложность схемотехники кэша. У x86 в отличие от арма, строгий порядок памяти, так что, вероятно, кэш x86 может оказаться тупо более сложным на 1 бит из-за дополнительной логики инвалидации.

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

Да. А особенно удивительно, что сошлись у тебя 35 наносекунд с 35 циклами :).

Вот тут я лоханулся, признаю. 8.8 нc это ~22 такта на 2.5 ГГц.

anonymous
()
Ответ на: комментарий от i-rinat

Да ладно тебе, это же явно шутка.

Какая задержка в мультиплексоре? Я без шуток, мне интересно. Я обычно слышал про O(log2 n).

https://cpb-us-e1.wpmucdn.com/blogs.ntu.edu.sg/dist/8/1266/files/2017/01/multiplexer-2n48vly.pdf

CONCLUSION

In this work, efficient in-memory schemes with O(log2 n) delay for multiplexer and priority multiplexers have beenproposed using 1S1R arrays.

anonymous
()
Ответ на: комментарий от i-rinat

Выпущена первая опытно-промышленная партия российского микропроцессора MultiClet MCp0411100101

Даешь 640x480 и игру «жизнь» (которая, вроде Тьюринг полная).

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.