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С? В смысле без пересборки.

★★★★★

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

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

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

А у тебя вообще не правда. Cortex A8 это был флагманский arm процессор в свое время.

Я не писал дифирамбы разным ядрам арма, я всего лишь указал, что из распространённых армов за всю историю, суперскалярные без внеочередного были и есть только на 2 команды. Не знаю на что ты там возражаешь, зачем приводишь пары для big.LITTLE.

И для x86 это так же характерно, in order суперскаляры все на запуск 2х команд. Так что твоё утверждение о том, что якобы компиляторы влёт раскидывают команды по суперскалярам не подтверждается практикой, скорее наоборот, видно что без OOO суперскаляры очень бедные, на две команды, причём часто второй порт неполноценный, только на подмножество команд и при добавлении уже третьего порта запуска экономия на OOO-логике теряет смысл.

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

Читай до просветления.

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

Как это поможет бороться с промахами мимо кэша видимо тебе одному ведомо.

Давай ты объяснишь. Вот есть некая программа, которая читает из памяти значение, потом выполняет с ним некоторую операцию. И вот компилятор. Положим, он даже с PGO и ему известно, что в 90% это будет попадание в L1 кэш, и в 10% промах и придётся ждать на 10 циклов дольше. И как твой компилятор со спекулятивным исполнением с этим справится?

Я вижу только 2 варианта, либо скажет, «фиг с ним, один раз из 10 можно подождать», либо предположит, что будет промах всегда и отодвинет загрузку от использования. Что вообще неплохо, если есть чем забить ожидание. Но где тут место для спекулятивного исполнения, я вообще не в курсах.

Или сгенерированный компилятором код восстановления.

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

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

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

Тогда не умничай и не учи остальных.

А я не учу, я просто сообщаю тебе: не взлетит. Никогда. Ну, не совсем никогда, но пока ИИ не научился программировать по цене 1000 строк кода за 1 ватт. А до этого проще нанять 10 джунов, чем пердолиться с Cell-подобной архитектурой.

Multithreading (MT) бывает разный.

Да. И в первую очередь программный. А вот при написании SMT всем более-менее понятно, что имеется в виду.

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

Разбор очередной порции бреда…

Чего читать-то? Там написано то же что и я написал, только добавлена спекулятивность на этапе компиляции из Эльбруса.

Ты писал следующее.

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

Спекулятивное выполнение — это выполнение с отложенным прерыванием, а не про условные инструкции (cmov в x86 или предикаты). Например, инструкция add r0, r1, r2 не генерирует прерываний, её можно выполнить без спекулятивного режима и если ветвления не будет, то просто проигнорировать результат. С ld [ r0 ], r1 такой трюк не прокатит, в этом случае необходимо спекулятивное выполнение.

Как это поможет бороться с промахами мимо кэша видимо тебе одному ведомо.

Если у тебя до и после ветвления есть чтение из памяти, то ты можешь спекулятивно выполнить второе в одной ШК с первым и получить задержку как с одним промахом, а не с двумя. PGO поможет определить необходимость перемещения чтения из памяти выше вычисления условия для ветвления.

int *a, *b;
...
int t;
if (c != 0) {
    t = *b + c;
}
*a = *a + 0x2;
 {
   ldw,2 %dr0, 0x0, %g16                # load a
   ldw,3,sm %dr1, 0x0, %g17             # load b spec-mode
 }
 {
   cmpesb,0 %r2, 0x0, %pred0            # c != 0
 }
 {
   adds,0 %g16, 0x2, %g16               # a + 0x2
   adds,3 %g17, %r2, %r5 ? ~ %pred0     # if c != 0 then b + c
 }
 { 
   stw,2 %dr0, 0x0, %g16                # store new a
 }

Давай ты объяснишь. Вот есть некая программа, которая читает из памяти значение, потом выполняет с ним некоторую операцию. И вот компилятор. Положим, он даже с PGO и ему известно, что в 90% это будет попадание в L1 кэш, и в 10% промах и придётся ждать на 10 циклов дольше. И как твой компилятор со спекулятивным исполнением с этим справится?

Тут не надо спекулятивное выполнение.

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

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

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

Ты про spatial locality данных (строка кэша), а я тебе про temporal locality данных (вместимость кэша).

  • «кэши 32 мегабайта делают для кэширования большего объёма данных ближе к ALU»
  • «кэши 32 мегабайта делают для повышения локальности/местности/близости данных к ALU большего объёма данных»

Cache_(computing):

Such access patterns exhibit temporal locality, where data is requested that has been recently requested already, and spatial locality, where data is requested that is stored physically close to data that has already been requested.

Да. И в первую очередь программный. А вот при написании SMT всем более-менее понятно, что имеется в виду.

Тогда это процессор с chip-level multiprocessing (CMP) или многоядерный процессор.

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

Спасибо тебе, анонимный товарищ, я побоюсь читать весь тот бред, на который ты отвечал, но твой ответ дополню.

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

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

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

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

PS. Очередной иксперд, не разобравшись даже в базовых понятиях весь тред засрал. ЛОР такой ЛОР

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

И тебе спасибо за дополнительное объяснение.

Я уже начал надламываться, вспоминал царя и ярлык «базворд»… Никогда бы не подумал…

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

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

Так как ты так и не ответил на мой пред. вопрос, подкину новый.

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

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

Нашёл у себя опечатку - оптимизация не dma, а dam, но не суть.

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

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

Далее тут возможны какие варианты: либо мы не попадаем на неспекулятивную операцию и просто забываем про все эти вычисления (например если вынесли их из неисполняемой ветки), либо мы получили диагностику на обычной операции. Это говорит о том что мы имеем ошибку в обычном потоке исполнения программы (например деление на 0 или выход за границу памяти). Тогда мы кидаем исключение на обработчик в ОС, после чего программа обычно ломается.

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

Так как ты так и не ответил на мой пред. вопрос, подкину новый.

Сорян, но тут не смогу много ответить т.к. это всё только на этапе базовых прикидок. Если в кратце, то в новый процессор добавлена возможность сбора трассы исполнения (адреса инструкций, во время которых происходят указанные события), что должно обеспечить сбор счётчиков с минимальными затратами. Соответственно, когда мы видим что у нас вырисовывается горячий участок, мы пытаемся его перекомпилировать и на ходу подменить. Про конкретные технические моменты (как и про JIT для C/C++ вообще) лучше будет говорить после появления первых публикаций по этим наработкам.

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

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

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

Это говорит о том что мы имеем ошибку в обычном потоке исполнения программы (например деление на 0 или выход за границу памяти). Тогда мы кидаем исключение на обработчик в ОС, после чего программа обычно ломается.

Аааа. Я думал, что page fault тоже откладывается. Теперь всё стало максимально понятно.

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

Хорошие новости. Размер этого буфера?

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

Спекулятивное выполнение — это выполнение с отложенным прерыванием, а не про условные инструкции (cmov в x86 или предикаты).

Фейспалм. Не, чувак, ты реально дурачок.

Ты хоть сам-то читал свою ссылочку? Сосредоточься и попробуй ещё раз. А то смешно получается, пишешь, что «разбираешь бред», сам даёшь ссылку не понимая о чём там.

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

Ты перепутал общий термин «спекулятивное выполнение» с названием флажка в архитектуре Эльбруса.

Тут не надо спекулятивное выполнение.

Что и требовалось доказать.

Всего 3 сообщения потребовалось чтоб доказать тебе очевидное, а именно что, цитирую «спекулятивность, PGO + JIT» не могут решить проблему непредсказуемости времени ожидания памяти.

«кэши 32 мегабайта делают для повышения локальности/местности/близости данных к ALU большего объёма данных»

Боюсь, ты и тут не прав. Во-первых, ты воспринимаешь «близость» как синоним «скорости доступа», что не всегда так, например, кэш на SATA SSD не ближе чем HDD. Во-вторых термин «локальность» не синоним «близости». Близость определяется относительно какой-то точки, CPU в нашем случае. А локальность - она относительно себя. Данные могут быть расположены на другом конце Земли, но при этом они будут оставаться локальными.

а я тебе про temporal locality данных (вместимость кэша).

И это тоже не то. Любая локалити - это свойство не железа, а алгоритма. Spatial locality обеспечивает отсутствие необходимости большого числа доступов для получения нужных данных. Temporal locality - это про то, что по возможности все дела с данным куском памяти следует делать за один присест, чтоб не вытягивать его в кэш много раз.

Размер кэша никак не может улучшить характеристики алгоритма. Ты, видимо, имеешь в виду, что большой кэш должен сгладить недостатки locality программы, но это во-первых, не точное употребление термина. Во-вторых, я сильно сомневаюсь, что средний размер кэша армов на ядро в разы меньше среднего размера кэша на ядро у десктопных x86 потому, что на мобилах работают лучшие программисты, которые умеют в локалити. Мне как-то кажется, что верно моё первое предположение, что вынуждены досыпать дофига кэшей потому что работают на частотах в 4 гигагерца и промах уж слишком больно бьёт по производительности.

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

Ты хоть сам-то читал свою ссылочку? Сосредоточься и попробуй ещё раз. А то смешно получается, пишешь, что «разбираешь бред», сам даёшь ссылку не понимая о чём там.

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

Я уже начинаю боятся за твоё психическое здоровье.

Всего 3 сообщения потребовалось чтоб доказать тебе очевидное, а именно что, цитирую «спекулятивность, PGO + JIT» не могут решить проблему непредсказуемости времени ожидания памяти.

Я тебе изначально написал, что частичное решение, а не полное.

Боюсь, ты и тут не прав. Во-первых, ты воспринимаешь «близость» как синоним «скорости доступа», что не всегда так, например, кэш на SATA SSD не ближе чем HDD. Во-вторых термин «локальность» не синоним «близости». Близость определяется относительно какой-то точки, CPU в нашем случае. А локальность - она относительно себя. Данные могут быть расположены на другом конце Земли, но при этом они будут оставаться локальными.

локальный

свойственный только определенному месту, распространяющийся на узкую область; не выходящий за определенные пределы; местный

Кэш более локальный/местный/близкий по отношению к CPU, чем SSD/HDD/random place in the universe. Так как скорость света ограничена, это даёт большую скорость, чем размещение данных в удалённом месте.

И это тоже не то. Любая локалити - это свойство не железа, а алгоритма. Spatial locality обеспечивает отсутствие необходимости большого числа доступов для получения нужных данных. Temporal locality - это про то, что по возможности все дела с данным куском памяти следует делать за один присест, чтоб не вытягивать его в кэш много раз.

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

Если задаче нужно 64 Мбайт, а кэш у тебя на 32, то у тебя ухудшается temporal locality, а следом и spatial locality. Увеличивая кэш до 64 Мбайт, ты поднимаешь temporal locality, а следом и spatial locality.

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

Прикинь, скорость света ограниченна в нашей вселенной, вот так поворот.

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

Я уже начинаю боятся за твоё психическое здоровье.

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

Вот нахрена ты тут создаёшь шум на тему особенностей работы эльбруса с прерываниями?

Нет, чувак, бредишь в этой теме только ты.

Я тебе изначально написал, что частичное решение, а не полное.

ЛОЛ, ну приведи пример этого частичного. Или нулевая часть это типа тоже часть? Вот OOO да, может частично решить проблему, ожидающая команда пропустит несколько других. Буфер ООО в современных процессорах велик, так что эти несколько могут быть довольно многими. Видишь, за два предложения я объяснил, как ООО частично решает. Ты можешь так объяснить? без портянок об особенностях, которые вынуждены были добавить в Эльбрус чтоб команды, способные зафейлиться, хорошо паковались?

Кэш более локальный/местный/близкий по отношению к CPU

Нет. Эти слова не синонимы. И нет, термин «локально» не употребляется в таком контексте.

Чувак, ты затупил, перепутал термин и запутал дискуссию. Со всеми бывает. Просто забей, не нужно упираться рогом и продолжать нести чушь. Всё, мы разобрались что ты хотел сказать. Я даже не буду смеяться над тобой. И я уже ответил тебе по существу. Не нужно нести бред про 64 мегабайта для задачи, просто перечитай что я тебе выше написал про свойство алгоритма. Считай, что эти 64 мегабайта - это свойство алгоритма, его локалити. Может потому что алгоритм плохой. А может потому что по-другому нельзя, не важно, это всё равно свойство алгоритма.

Если хочешь продолжать, возражай по существу. Я напомню: у мобильных армов и у десктопных x86 разный размер кэшей на ядро. Я объясняю это разными диапазонами возможных задержек, если выразить их в тактах. Более того, мне кажется, что это очевидное объяснение. И нет, твоё указание на ограниченность скорости света никак этому не возражает. Осталось только понять, ты согласен, что в современные декстопные CPU кладут много кэша именно потому, что латентность ожидания уж слишком велика, что никакие компиляторы с ней сделать ничего не могут и потому даже малоэффективный по Парето дополнительный кэш разработчикам CPU выгоднее чем, скажем, дополнительное АЛУ?

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

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

чем реальный архитектор

Реальные-авторитетные то все на дваче в /hw/ сидят, в толксах мужики, а в интелах только петухи и опущенные.

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

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

По-моему дурачка включаешь тут только ты.

Вот нахрена ты тут создаёшь шум на тему особенностей работы эльбруса с прерываниями?

У тебя проблемы с памятью?

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

Я тебе ответил.

Проблема частично решаема спекулятивным исполнением.

Далее.

ЛОЛ, ну приведи пример этого частичного. Или нулевая часть это типа тоже часть? Вот OOO да, может частично решить проблему, ожидающая команда пропустит несколько других. Буфер ООО в современных процессорах велик, так что эти несколько могут быть довольно многими. Видишь, за два предложения я объяснил, как ООО частично решает. Ты можешь так объяснить? без портянок об особенностях, которые вынуждены были добавить в Эльбрус чтоб команды, способные зафейлиться, хорошо паковались?

{
   ld ..   # ждём T1, от 3 до 100-130 тактов (если промах в кэш)
}
# branch
{
   ld ..   # ждём T2, от 3 до 100-130 тактов (если промах в кэш)
}
# итого от 6 до 200-260 тактов

Теперь спекулятивное выполнение.

{
   ld ..      # ждём T, от 3 до 100-130 тактов (если промах в кэш)
   ld,sm ..   # спекулятивно
}
# branch
...
# итого ожидание от 3 до 100 тактов

Помогло? Ещё как!

Чувак, ты затупил, перепутал термин и запутал дискуссию. Со всеми бывает. Просто забей, не нужно упираться рогом и продолжать нести чушь. Всё, мы разобрались что ты хотел сказать. Я даже не буду смеяться над тобой. И я уже ответил тебе по существу. Не нужно нести бред про 64 мегабайта для задачи, просто перечитай что я тебе выше написал про свойство алгоритма. Считай, что эти 64 мегабайта - это свойство алгоритма, его локалити. Может потому что алгоритм плохой. А может потому что по-другому нельзя, не важно, это всё равно свойство алгоритма.

Когда до тебя дойдёт, что мы говорим не про ПО, а про CPU?

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

Apple A12  L1$ 128 Кбайт, L1d 128 Кбайт, 2.5 ГГц
10900K     L1$  32 Кбайт, L1d  32 Кбайт, 5.2 ГГц

Карл! 2.5 ГГц vs 5.2 ГГц. 128 vs 32.

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

Кому спектр? Совершенно (бес)платно на всю ширину.

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

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

Задаётся 32-х битным числом

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

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

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

Это программно выделяемый буфер памяти в виртуальной области. Минимальный размер записи - двойное слово, т.е. если сбрасываем адрес инструкции, получаем~ (2^32 / 8) > 500 млн. записей. Адреса, кстати, виртуальные, сбрасываются.

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

Дык чё там с бустовыми корутинами-то? Почему их нет?

Что это и зачем? Ну и да, тут совсем не ко мне вопрос.

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

Это программно выделяемый буфер памяти в виртуальной области. Минимальный размер записи - двойное слово, т.е. если сбрасываем адрес инструкции, получаем~ (2^32 / 8) > 500 млн. записей. Адреса, кстати, виртуальные, сбрасываются.

Во, теперь я понял о чём речь. Сброс адресов идёт параллельно или используется один из АЛК?

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

Тогда у меня тоже вопрос: 128бит режим указателей (защищенный) он по факту то 32битный?

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

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

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

По факту он 64-х битный, просто у нас дополнительно появляются тэги с описанием данных. Внутри процессора (если это про регистры), мы начинаем квадро-регистры использовать. А чем вызван вопрос, может я не очень понимаю почему из-за него должна адресация в 32 бита уходить. Вот здесь, например, описана структура дескриптора:

  • iTag (3 бита) – тип массива (внутренний тег);
  • RW (2 бита) – права доступа к массиву;
  • Base (59 бит) – виртуальный адрес начала массива;
  • Size (32 бита) – размер массива (задается в бай‑тах);
  • Index (32 бита) – индекс адресуемого элемента (задается в байтах)
alexanius ★★
()
Ответ на: комментарий от alexanius

Тогда получается адреса 59 бит (64 - 5 бит под теги), а размер объекта/массива до 2Гб? Правильно?

И кстати да, про квадрорегистры и квадротипы в командах - они только в последних процессорах (8св, 16с) появились? Раньше то их вроде не было, или были?

uin ★★★
()
Последнее исправление: uin (всего исправлений: 1)
Ответ на: комментарий от khrundel

VLIW тупо не подходит под систему с непредсказуемыми задержками

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

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

Да, размер массива будет ограничен.

И кстати да, про квадрорегистры и квадротипы в командах - они только в последних процессорах (8св, 16с) появились? Раньше то их вроде не было, или были?

Есть разные типы квадрорегистров. Просто квадрорегистры для защищённого режима - это два соседних двойных регистра, а в новых версиях СК появились честные квадрорегистры

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

Насколько я знаю, Эльбрус широко использовался/используется для загоризонтных РЛС ПРО/СПРН. И там в первичной обработке РЛИ идет сплошной поток данных, абсолютно предсказуемый, т.е. идеальные условия для числодробилки. Причем там очень большое количество параллельных каналов, так что там Эльбрус очень даже в тему.

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

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

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

Теперь спекулятивное выполнение.

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

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

А с остальными 95%+ как быть?

Когда до тебя дойдёт, что мы говорим не про ПО, а про CPU?

А мне откуда было знать, про что ты хочешь рассказать, клоун? Ты написал бессмыслицу. Вместо того чтоб исправить, в течении нескольких сообщений доказывал, что нет, ты не перепутал. И я типа должен догадаться, что ты имеешь в виду не ПО, а CPU, и это при том, что ты выше мне нёс чушь про задачи, которым надо 64 мегабайта.

Apple A12 L1$ 128 Кбайт, L1d 128 Кбайт, 2.5 ГГц 10900K L1$ 32 Кбайт, L1d 32 Кбайт, 5.2 ГГц Карл! 2.5 ГГц vs 5.2 ГГц. 128 vs 32.

LOL. Слив засчитан.

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

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

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

Потому частично решаема.

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

В одной программе могут быть разные участки с разными паттернами и очерёдностью доступа в память. С последовательными зависимым обращением в память ты даже на OoOE ничего не сделаешь.

# если все 3 промахи
ld [ r0 ], r1   # запустит операцию, +100 тактов
ld [ r1 ], r2   # добавит в очередь, +100 тактов
ld [ r2 ], r3   # добавит в очередь, +100 тактов
# все последующие операции зависят от r3
# ядро заполнит очередь исполнения в 97 микроопераций (те самые инструкции на лету)
# ядро заполнит очередь перед бэкендом
# будет ждать пока не завершатся все три обращения в память и ничего не делать

Как здесь помогает OoOE? Жду подробного объяснения.

А с остальными 95%+ как быть?

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

А мне откуда было знать, про что ты хочешь рассказать, клоун?

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

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

нафига в одном ядре иметь L1 и L2

Чем там поможет нашлёпка из L4, задержки которой будут раз в 10 больше чем у L2?

Далее.

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

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

Твоё невежество поражает своими масштабами, а нежелание учиться новому — непомерной глупостью.

От L1 требуется работа с минимальными задержками. В высокопроизводительных системах это соответствует 1 такту. При частоте 5 ГГц на такт отводиться 200 пикосекунд. За это время электромагнитная волна может пройти ~60 мм, но на пути будут транзисторы. У транзисторов не нулевое время переключения и зависит от их размера и напряжения. У TSMC на 7nm, правда не знаю на каком напряжении, транзисторы переключаются со скоростью более 1 ТГц (будем считать ~1 пс). Если на критическом пути будет 150 транзисторов, то электромагнитной волне остаётся всего 50 пс (~15 мм) на распространение. Но она движется в микросхеме по очень заковыристому маршруту из-за логики составленной транзисторами, что дополнительно сказывается на размере структуры. Если понизить тактовую частоту в два раза, то 1 такт = 400 пс, критический путь = 150 пс, макс. длинна критического пути = 75 мм, но обычно ещё следует понижение напряжения. Повышение тактовой частоты неизбежно сказывается на размере структур и приводит к их упрощению. Проектирование микросхем — сложный процесс поиска оптимального баланса.

Касательно приведённых процессоров. Понятно, что они выполнены на разных фабриках и спроектированы для разных задач. При прочих равных получаем следующее:

l = 299792458e3                # скорость света мм/с

a12p = l * 400e-12 = ~120 мм   # путь для 2.5 ГГц, 400 пс
i9p  = l * 200e-12 = ~60 мм    # путь для 5 ГГц, 200 пс

# Так как структура двухмерная то
a12a = (a12p / 2) ** 2 = ~3595 мм2
i9a  = (i9p / 2) ** 2 = ~898 мм2

a12a / i9a = 4
128 / 32 = 4

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

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

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

Хотя, это тоже весьма условно.

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

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

Я больше интересуюсь архитектурными изысками, поэтому могут быть неточности. Благодарю за уточнение.

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

диэлектрическая проницаемость оксида кремния

И как он участвует в распространении электрического сигнала по проводникам?

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

И как он участвует в распространении электрического сигнала по проводникам?

А ведь верно. И тебе благодарность.

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

И как он участвует в распространении электрического сигнала по проводникам?

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

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

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

первый аноним

Это применимо ко всей цепочке провод - транзистор - провод или только к транзистору?

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

Это применимо ко всей цепочке провод - транзистор - провод или только к транзистору?

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

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

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

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

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

Тогда надо использовать диэлектрическую проницаемость кремния (а не оксида), которая составляет основную массу, окружающую проводники в микросхеме.

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

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

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

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

Я правильно понимаю…

Нуу, что-то похожее на правду в этом есть. Только ёмкость тоже нужно учитывать.

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

Нуу, что-то похожее на правду в этом есть. Только ёмкость тоже нужно учитывать.

Спасибо за информацию. Раньше я как-то не задумывался над этим.

Не получается ли, что чем больше транзисторов в цепи, тем сильнее это проявляется?

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

Не получается ли, что чем больше транзисторов в цепи, тем сильнее это проявляется?

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

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

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

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

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

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

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

Металл на воздух особо не понапыляешь

А что оксид кремния напыляют?

Оксид кремния - это между проводником и подложкой-кремнием, а не между проводниками.

Что там напыляют в многослойных микрохемах? Неужели оксид кремния? :)

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

Они будут замедлять распространение волны?

Из-за неоднородности диэлектрика такие взаимовлияния возможны, но они очень малы и ими можно пренебречь.

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

Вы хоть подписывайтесь.

Что там напыляют в многослойных микрохемах? Неужели оксид кремния? :)

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

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