Кэш – король быстродействия: нужен ли процессорам четвёртый уровень кэширования

Автор оригинала: Prickett Morgan
  • Перевод


Разрыв между быстродействием процессоров в общем смысле и быстродействием основной памяти DRAM, также в общем смысле, был проблемой в последние 30 лет – в этот период разрыв начал по-настоящему расти. И стоит честно сказать, что инженеры, разрабатывавшие как оборудование, так и программы, создавшие иерархию кэшей и ПО, способное воспользоваться её преимуществами, поступили просто гениально. Это одна из труднейших в реализации архитектур, когда-либо задуманных человеком.

Однако теперь, когда мы находимся на пороге появления постоянно расширяющейся иерархии памяти, когда начинает появляться энергонезависимая память типа Optane 3D XPoint (вариант памяти с изменением фазового состояния) в формате DIMM и SSD, а также новые протоколы (CXL, OpenCAPI, CCIX, NVLink и Gen-Z), возникает вопрос: не пора ли добавить серверам кэш четвёртого уровня? Поскольку от комплекса CPU зависит работа такого количества устройств – некоторые из которых расположены ближе, другие же дальше – логично задуматься над тем, не нужен ли нам ещё один уровень кэша, маскирующий задержки этих других видов памяти и увеличивающий пропускную способность всей системы.

Чтобы представить открывающиеся возможности, мы покопались в своей собственной памяти, а заодно пообщались с разработчиками архитектуры чипов из IBM, Intel, AMD и Marvell, чтобы понять, что они думают об использовании кэша L4 в серверах. Кэш L4, конечно, не новое слово в быстродействии, однако он и не так уж часто встречается в системных архитектурах.

Однако прежде нам стоит пробежаться по истории вопроса.

Добавление кэша первого уровня к процессорам, у которых в то время было всего одно ядро, в 1980-х стало компромиссом, добавляющим задержки в подсистемы памяти, одновременно снижающим среднюю задержку запросов данных и инструкций процессорами. Кэши L1 изначально находились во внешней SRAM, находившейся на материнских платах и подключавшейся к комплексу CPU-память. Такой кэш L1 находился очень близко к процессору, как в смысле тактовой частоты, так и в смысле физического пространства на плате, и давал возможность повысить загрузку CPU. Потом эти кэши разделили, чтобы в одном блоке можно было хранить часто используемые данные, а во втором – популярные инструкции, и это немного увеличило быстродействие. В какой-то момент увеличения тактовой частоты процессоров и соответствующего разрыва в быстродействии CPU и DRAM, были добавлены более жирные, но и более медленные кэши L2 (зато более дешёвые в пересчёте на пропускную способность), опять-таки сначала находившиеся вне корпуса CPU, а потом интегрированные в него. А когда в CPU начали добавлять всё больше и больше ядер, а также всё больше контроллеров DRAM для их загрузки, к иерархии добавили ещё более крупные блоки кэшей L3.

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

Крис Джианос, инженер чипов и архитектор из Intel, руководившей разработкой многих прошлых поколений процессоров Xeon, объясняет это так: «С каждым уровнем кэша нам обычно нужно, чтобы они выросли достаточно сильно по сравнению с предыдущим уровнем, чтобы всё это имело смысл, поскольку чтобы достичь заметного прироста быстродействия системы, нужно достичь достаточно интересной частоты успешных обращений. Если вы „попадаете“ в кэшированные данные всего в нескольких процентах случаев, это будет сложно заметить. Всё остальное затормаживает ваше быстродействие, и этот прирост будет незаметным. Поэтому требуются относительно большие кэши, и когда речь идёт о более высоких уровнях, нужны реально огромные кэши. Сегодня L2 измеряются мегабайтами, L3 измеряются десятками или сотнями мегабайт. Так что понятно, что если вы начинаете думать о кэше L4, то речь пойдёт уже о сотнях мегабайт, если не о гигабайтах. А такой размер определённо приведёт к их высокой стоимости. Нужно, чтобы сложились определённые условия, чтобы этот вариант стал интересным, и дешёвым он определённо не будет».

Инженеры из компании AMD, с которыми мы беседовали, пожелали остаться неизвестными потому, что они не хотели создать впечатление, что компания собирается добавить кэш L4 в линейку процессоров Epyc – и, если быть точным, AMD ничего такого и не обещала. Однако компания всё же признаёт, что это следующий очевидный шаг для рассмотрения, и, точно так же, как Intel, считает, что все инженеры размышляют о реализации кэша L4. По сути, AMD говорит, что компромиссы, связанные с уровнями кэшей и задержками подробно изучены как в промышленности, так и в научных кругах, и что с каждым новым уровнем, который оказывается больше и медленнее предыдущего, возникает компромисс увеличения общего пути к DRAM. Об этом говорит и Джианос из Intel, рассказывая о необходимости поиска баланса между успешными запросами к КЭШу и его объёмом.

IBM, конечно, добавляла кэш L4 к некоторым своим чипсетам X86 в 2000-х, а в 2010-х добавила L4 к чипсетам NUMA (неравномерный доступ к памяти) на мейнфреймах System z11. У процессора z11 четыре ядра, 64 КБ L1 кэш для инструкций и 128 КБ L1 кэш для данных, плюс 1,5 МБ L2 кэш для каждого из ядер и 24 МБ L3 кэш общего доступа для всех ядер. У чипсета NUMA для z10 было два банка по 96 МБ L4 кэша, то есть, 192 МБ в сумме. Выпустив z12, IBM урезала размер кэша L1 до 98 КБ на ядро, однако увеличила L2 кэш до 2 МБ на ядро, разделив его при этом на две части, для инструкций и для данных, как в случае с L1. Также она удвоила размер кэша L3 до 48 МБ для шести ядер, а размер кэша L4 был увеличен до 384 МБ для пары чипов в чипсете. При смене поколений процессоров System z объёмы кэшей росли, и у процессоров z15, анонсированных в сентябре, пара кэшей L1 будет весить по 128 КБ, пара кэшей L2 – по 4 МБ, а общий кэш L3 будет для 12 ядер иметь объём 256 МБ. Объём кэша L4 в каждом отсеке мейнфрейма составляет 960 МБ, а его общий объём для всей системы, состоящей из пяти отсеков, равняется 4,68 ГБ.

Как мы уже указывали ранее, у процессоров Power8 и Power9 память буферизована, а IBM добавила 16 МБ L4 кэша к каждому буферу Centaur, что составляет 128 МБ L4 кэша на сокет для 32-х планок памяти. У самых дешёвых машин с Power9 нет буфера памяти, а, следовательно, и кэша L4. Архитекторы, разрабатывавшие схему Power10, были заняты разработкой схемы для Power11, и потому не смогли ответить на наши вопросы, но Уильям Старк, управлявший разработкой Power10, нашёл для нас немного времени, и заметил следующее:

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

Именно так мы и думали. И, кстати, мы не утверждаем, что кэш L4 обязательно будет находиться в непосредственной близости от буферизированной памяти будущего DDR5 DIMM. Возможно, его лучше расположить между PCI-Express и кэшем процессора L3, а ещё лучше, в буферах памяти и между PCI-Express и кэшем процессора L3. Возможно, его для этого придётся поместить наверху контроллера I/O и памяти в будущей серверной архитектуре, что немного напоминает технологию Foveros от Intel.

На это возможно взглянуть и с другой точки зрения – допустим, у IBM была возможность менять размеры кристалла, и инженеры решили добавить кэш L4 к шине System z NUMA или к чипу буферизации памяти Power8 и Power9 не ради его самого, а просто потому, что у них оставалась ещё возможность добавить транзисторов после того, как все необходимые функции были реализованы. Иногда нам кажется, что количество ядер в процессорах Intel X86 зависит от размера кэша L3, который они могут себе позволить. Иногда кажется, что Intel назначает максимальный размер кэша L3 на один кристалл, и после этого кристаллы Xeon трёх разных размеров просто изготавливают по этим спецификациям – в последних поколениях у них по 10, 18 или 28 ядер на техпроцессе в 14 нм.

Всё это, конечно, чисто академические вопросы, однако они дают нам возможную мотивацию для IBM и других производителей чипсетов на добавление кэша L4. Это не просто может помочь в каких-то случаях, это просто довольно очевидная вещь. Думаем, что на таком монстре I/O, как мейнфрейм System z, кэш L4 без вопросов находится на своём месте и приносит пользу всем клиентам, увеличивая пропускную способность этих машин и позволяя им работать на 98-99% загрузке процессора, поскольку как количество ядер, так и масштабы NUMA в мейнфреймах в последнее время сильно подросли.

Нет причин для того, чтобы делать кэш L4 исключительно на встроенной DRAM (как делает IBM со своими чипами) или на базе куда как более дорогой SRAM – об этом нам напоминает Рабин Сугумар, архитектор чипов из компаний Cray Research, Sun Microsystems, Oracle, Broadcom, Cavium и Marvell:

«Наши кэши L3 уже достаточно большие, — говорит Сугумар. – Так что L4 в интересующем вас случае нужно делать по другой технологии. Возможно, eDRAM или даже HBM или DRAM. В данном контексте интересным вариантом выглядит реализация кэша L4 на основе HBM, и этот кэш решает не столько проблему задержки, сколько пропускной способности. Поскольку ёмкость HBM ограничена, а пропускная способность велика, мы можем получить определённую прибавку к скорости – и в некоторых специальных случаях мы действительно видим значительное увеличение пропускной способности». Сугумар добавляет, что для довольно большого количества применений наблюдается относительно большое количество «промахов» кэша. Однако нужно подсчитать – будет ли добавление очередного уровня кэша стоить того.

Ещё один возможный вариант использования чего-то наподобие кэша L4, говорит Сугумар, это использовать локальную DRAM в качестве кэша. «У нас не ведётся никаких подобных исследований в лаборатории, но допустим, у нас на чипе есть интерфейс с высокой пропускной способностью, соединенный с общей распределённой памятью где-то на другом конце шлейфа, на расстоянии от 500 нс до 1 мкc. Тогда один из вариантов использования будет создать кэш, перемещающий эти данные из общей распределённой памяти в локальную DRAM. Можно представить работу конечного автомата, управляющего этой памятью, поэтому большую часть времени обращения будут идти к локальной DRAM, и вы сможете минимизировать количество обращений к общей распределённой DRAM».

Нам этот вариант кажется очень интересной разновидностью NUMA. Кстати, Сугумар работал над распределённой памятью для высокоскоростных параллельных систем в Sun Microsystems ещё до того, как появилась энергонезависимая память. И одна из проблем с этими различными вариантами иерархии памяти заключалась в том, что если одна из них потеряется из-за отказа сети или шины, то вся машина упадёт. «В системах с распределённой памятью приходится обрабатывать отказы сети более элегантно, и это порождает множество сложностей при проектировании».

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

«В какой-то момент дополнительный уровень кэша станет неизбежностью, — говорит Джианос. – У нас появился первый уровень кэша, и в какой-то момент появился и второй. А потом мы, в конце концов, добавили третий. И когда-то у нас будет четвёртый. Вопрос только – когда и зачем. И мне кажется, что ваши наблюдения, касающиеся возможностей этого кэша, достаточно интересные. Но в Intel пока не решили, когда или зачем будут обнародовать такие вещи. Другие компании тоже изучают этот вопрос; было бы глупо не исследовать его. Рано или поздно это произойдёт, однако скоро это будет, или не очень – пока неясно».

Средняя зарплата в IT

111 111 ₽/мес.
Средняя зарплата по всем IT-специализациям на основании 6 844 анкет, за 2-ое пол. 2020 года Узнать свою зарплату
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 88

    +30

    бла бла бла


    вся статья о том, что кеш нам нужен, или не нужен, так нужен или нет, нет или да, да или нет, нужен или не нужен?

      +16
      Это просто еще один гуглоперевод ради гуглоперевода. Не ищите в нём смысл. Не найдете.
      +3
      Мда. Даже я, не про в этой теме, знаю больше случаев.

      1) інтел лет 5 назад уже обещала л4, так и не сделала

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

      3) интел второй год грозится положить ддр прямо над ядрами. По задержка получается тот-же л4

      4) по слухам амд эксперементирует над этим же, но для видеокарт. Собственно, они и первые с HBM
        +3
        1) інтел лет 5 назад уже обещала л4, так и не сделала
        Справедливости ради, L4 кеш у них таки был — на ноутбучных Crystall Well и Broadwell. Там он шел на отдельном чипе под IHS. Учитывая, что скорость у него была, как у нынешней хорошей DDR4, неплохо показывал себя как минимум в игрушках. Китайцы даже начали припаивать к ним подложки и продавать как процессоры в 1150 сокет, пока их со всех торговых площадок не поперли за сомнительное качество пайки этой самой подложки.
          0
          да, я прочитал ниже. Виноват. Исправлять уже поздно.

          Но мой поинт это не меняет. Было очень важно события по теме. Которое я помню, но не точно. А типа журналист его даже не упомянул.
            +2
            Процессоры Intel с Iris Pro использовали eDRAM видеоядра как кэш 4го уровня. Модели не ограничивались ноутбучным, были и ксеон и десктоп. Два три поколения вроде охватывали.
            i7-5775C
            image
              0
              Да, про Broadwell я написал — он не ноутбучный, просто не совсем корректно составил предложение, и не отделил его от Crystal Well.
                +2
                Производительность этого кеша объёмом 128 МБ незначительно превышает производительности памяти, т.е. он заметно медленнее L3. Но толк от него явно есть, как для процессора, так и для GPU. Ещё бы компиляторам рассказать о возможности использования большого объёма кеша.
                  0

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

                    0
                    А как быть с остальным софтом и ОС, которые будут периодически сбрасывать кэш, превращая его большой объём из преимущества в недостаток?
              +1
              DDR и DRAM — не синонимы
              +2
              Кажется, кэш L4 уже был в некоторых настольных процессорах Intel. Например i7-5775C имел 128 Мб eDRAM. Но с переходом на DDR4 наличие такого «относительно быстрого» дополнительного хранилище оказалось не очень то нужным. Возможно, нужны не новые уровни иерархии кэша, а скорее переход более быструю память и увеличения L3 (что уже делают AMD).
                0
                Кэш не для псп нужен, а для снижения задержек. В том же феноме 2 кэш l3 тормозной (~30 ГБ/с), но все же из-за 10нс от него есть толк, особенно в последних играх, которые он кое-как еще тянет. При этом сценарии использования происходит обращение ко множеству переменных, тут как и с накопителями, линейная скорость отходит на второй план, важнее iops.
                  0
                  Ну, у того же Crystall Well со скриншота выше задержки L4 не сильно ушли от задержек памяти DDR3. У процессоров Intel текущего поколения с хорошей памятью DDR4 они даже ниже.
                    +1
                    Так он и не для процессора предназначался, а для встроенной графики.
                      0
                      И туда и туда. eDRAM для Iris и L4 для cpu.
                0

                Если как они предлагают, делать кэш L4 в несколько гигабайт, то может вовсе обойтись без RAM, а целиком жить в кэше внутри процессора?

                  0
                  Так это же несколько гигов на все ядра/потоки, которых уже много, да и объем обрабатываемых данных растёт. Тут бы наоборот, довести скорость жестких до скорости RAM было бы интереснее)
                    +1

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

                      0

                      Это иллюзии.
                      Как только у вас мало что станет упираться в скорость ссд, то у вас начнут отмирать скриптовые языки — php, python, js, ruby.
                      Ибо проигрыш компилируемым языкам в реальных приложениях станет просто абсолютно не приличным.


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

                        +2

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

                          +3
                          Как только у вас мало что станет упираться в скорость ссд, то у вас начнут отмирать скриптовые языки — php, python, js, ruby.
                          Ни в коем разе не фанат ни одного из этих языков, но проблема зачастую а) в сетевом I/O б) в пользовательском вводе-выводе. Диск не грузится на 100% в подавляющем большинстве реальных приложений.
                          И вообще прочтённый в память скрипт не может тормозить из-за ССД, потому что он в памяти.
                          +1
                          Так сами же говорите, вначале грузим в оперативку. Если бы скорость SSD была сравнима с скоростью оперативки — вот тогда бы можно было бы ещё можно было без RAM обойтись, как предлагал человек выше, которому я отвечал.
                        0

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

                          0
                          Если они это сделают через 2+ года, к тому времени норма на ПК будет 64 ГБ на старших и 32 ГБ на младших системах (как сейчас 32 ГБ на старших и 16 ГБ на младших). Это значительно больше нескольких ГБ.
                            0
                            Сони экперементировала в этом направлении для ПС5. Пока не взлетело. Но часть наработок выйдет как экстремально быстрый ссд. Который хранит большую часть тех кешей (програмных) что раньше были в памяти.
                              0
                              Если программа и обрабатываемые данные достаточно компактные, то так и происходит уже сейчас, причем автоматически: данные к которым происходит обращение загружаются в кэш и все следующие разы читаются уже из него, пишется вообще все всегда в кэш. Вытесняются назад в память они только другими данными (которых еще нет в кэше). Если общий объем данных с которыми идет работа меньше объема кэша, то все они после первого цикла оказываются в кэше и вся работа дальше идет уже внутри него, а не через основную память.

                              Ничего дополнительно для этого в плане архитектуры делать не нужно.

                              Программы с компактным «ядром данных» сейчас уже почти не реагируют на скорость основной памяти — изменение ее скорости даже в 2-3 раза меняет общую скорость работы таких программ только на несколько %. Как раз потому что почти вся работа идет уже в кэшах процессора.

                              P.S.
                              Несколько ГБ внутри процессора не будет, это речь только L4 кэшах на других отдельных технологиях — типа чипа HBM памяти на одной подложке и под одной крышкой рядом с кристаллом процессора. Несколько ГБ обычного SRAM кэша внутрь процессора пока запихнуть невозможно. Даже текущие несколько десятков МБ кэша почти половину всех транзисторов в современных процессорах занимают. SRAM при наличии «лишних» транзисторов пойдет на дальнейшее увеличение объемов L2 и L3 кэшей.
                              0
                              ssd уже может ГБ/с. Ещё в 5-10 раз подрастёт и оперативка переползёт в процессор.
                                +2
                                ddr4 на 3200 сейчас это — 25600 МБ/c? А ddr5 уже через два года сколько даст?
                                SSD, конечно, хороши, но даже x10 будет медленнее DDR4 12800…
                                  0
                                  Сейчас 970 pro это ~3гб/сек. По слухам 980 pro ~7гб/сек. А еще есть raid 0 и pci 4.0.
                                    +1
                                    И случайное чтение/запись на уровне EDO RAM.
                                      0
                                      Причем еще весьма условно случайное — только при большом количестве параллельных потоков и очереди команд, что характерно разве что для сильно нагруженного сервера баз данных.
                                      Действительно случайное чтение у SSD раз в 10 медленнее, т.к. по задержкам доступа даже EDO RAM в сотни раз лучше SSD: меньше 100 наносекунд у EDO против нескольких десятков микросекунд у хороших NVMe SSD.
                                      0
                                      5-6 ГБ на PCIe 4.0 уже сейчас есть, вроде.
                                        +1
                                        Ну так и у оперативной памяти есть два канала)
                                        7 гб/сек — это на уровне ddr2 800? Так ведь 5-ая уже на подходе, а там может и каналов завезут побольше не только в серверные (мечты-мечты)
                                        Ок, давайте теперь задержки посмотрим)
                                          0
                                          3 гб/с это 300 бит/с.
                                          pci 4.0 не существует, есть PCI-E 4.0.
                                          Скорость SSD на PCI-E 3.0 4x упирается в 3,5 Гбайт/с, 7 Гбайт/с — предел для PCI-E 4.0 4x, который в 2020 году вряд ли будет достигнут.
                                      0

                                      Что-то мне не нравится эта пирамида, страшно подумать, как когерентность будет поддерживаться. С моего дивана кажется, что нужно снизить многозадачность на ядро/процессор, максимально перейти к NUMA и допилить предвыборку в компиляторах. Не вижу ничего ужасного, если ОС будет предоставлять аппаратный пул потоков, а на материнках рядом с памятью будет рядок Slot A.

                                        0
                                        Вопросы по теме:
                                        1. А почему ширина шины памяти до сих пор 64 бита, а не 512, как бывает у видеокарт?
                                        2. Почему процессорные кеши занимают намного больше места, чем ОЗУ?
                                          0
                                          А почему ширина шины памяти до сих пор 64 бита, а не 512, как бывает у видеокарт?
                                          А потому, что у GPU строго параллельный (по числу ядер) процесс выполнения, а CPU зачастую с отдельными байтиками ковыряется.
                                          Почему процессорные кеши занимают намного больше места, чем ОЗУ?
                                          А потому, что кеш — статическая память, каждая ячейка — триггер, минимум 6 транзисторов, а ОЗУ — динамическая память, 1 транзистор на ячейку.
                                            0
                                            а CPU зачастую с отдельными байтиками ковыряется.

                                            В любом случае, CPU читает-пишет данные кэш-линиями, а не отдельными байтами. А одна кэш линия в современных процессорах — это 64 байта, или 512 бит.

                                            +1
                                            1) Уже давно не бывает.
                                            2) Потому что статическая память, а не динамическая.
                                              +1
                                              Экономика. Развести шину 512 на материнке сильно дороже.
                                                0
                                                Ширина одной шины памяти 64 бита. А их сейчас обычно две в обычных компьютерах, а в серверах по 4 и больше (максимум на данный момент кажется 8), каждая по 64 бита.

                                                У ГПУ внутри обычно тоже не одна широкая шина на 512 бит, а несколько отдельных по 64 или 128 бит, просто для упрощения пишут общую сумму всех шин.
                                                Да и 512 бит даже в топовых ГПУ сейчас уже не применяется, 256-384 бита максимум. На младших моделях 128-192 бита.

                                                Почему уже выше написали — дорого и сложно на платах такое количество контактов и дорожек разводить так чтобы они друг другу и другим схемам на плате не мешали. Поэтому выпустив несколько моделей с 512бит шиной после этого от таких широких шин отказались.
                                                  0
                                                  Это Dual Channel и т.д.
                                                  Только вот ранее толку от него не было.
                                                  А вот в видяхах толк от большей разрядности шины памяти был.
                                                    +1
                                                    Если от Dual Channel в каком-то ПО нет толку, значит конкретно этому ПО высокая ПС памяти вообще не нужна в принципе. Потому что Dual Channel практически удваивает ПСП — если эффекта нет, значит она просто не нужна.
                                                      +2
                                                      Это Dual Channel и т.д.

                                                      И что же это по-вашему?
                                                      Каждый канал DIMM представляет свой контроллер памяти, точно так же как и для видеокарт.
                                                      Просто у видеокарты (к примеру) 16 контроллеров * 32 бит GDDR5, а у какого-нибудь EPYC — 8 каналов * 64 bit DDR4.
                                                      Что в обоих случаях даёт эффективную ширину 512-бит. HBM имеет широкую шину, но разницы тут нет принципиальной.

                                                      А вот в видяхах толк от большей разрядности шины памяти был.
                                                      Это зависит сугубо от задачи. Если вы обрабатываете скалярные данные, вам ПСП и ну нужна — вы её физически не сможете реализовать.
                                                      Используйте многопоточный код + SIMD — тогда и будет толк от ПСП.
                                                      0
                                                      HBM вроде вообще имеет ширину в 2048 бит. Он на почти всех радеонах и Titan V.
                                                        0
                                                        1024 бит на 1 стек HBM, стек это «пачка» или «стопка» из вертикально сложенных друг на друга кристаллов памяти упакованных в общий корпус — внешне выглядит как 1 кристалл.

                                                        А дальше в зависимости от количества этих самых стеков подключенных к процессору. От 1 до 4 в настоящий момент существуют варианты, так что от 1024 до 4096 бит суммарно.
                                                      0
                                                      если я правильно понял ddr5 позволяет прокладывать 2 канала на каждую плашку памяти. Так что возможно что появится 16 канальные наборы памяти — а это уже 1024бит.
                                                        +1
                                                        Откуда удвоение ширины? Те же самые 64 бита и 1 канал на модуль, даже количество контактов у модулей не меняется.
                                                        Единственное большое изменение в ddr 5 такое же как как и было во всех предыдущих версиях DDR — это очередное удвоение частоты шины и удвоение размера предвыборки данных, позволяющие данные по шине слать в удвоенном темпе при сохранении частоты работы самих микросхем памяти примерно на том же уровне. ПС станет еще больше, но и относительные задержки тоже в очередной раз вырастут.

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

                                                        Режим с 2 подканалами это просто логическая организация, когда вместо 1 канала в 64 бита его можно представить как 2 виртуальных канала по 32 бита. Но общая ширина и ПС не меняются от этого.
                                                      0
                                                      Сильная потребность в кэше (особенно в нижнем, который самый большой и медленный из всех) обусловлена тем, что много ядер одного процессора активно обращаются в общую для всех них оперативную память. Отсюда — несколько очевидных решений:
                                                      1. Изменить архитектуру процессора так, чтобы в нём было много регистров. Я думаю, 32 или 64 регистра общего назначения — нормально.
                                                      2. Изменить архитектуру процессора так, чтобы для разных режимов процессора (как правило, их два: user-space и kernel-space; по хорошему надо бы иметь отдельный interrupt-space) был свой набор регистров. Ну, user-space и kernel-space должны иметь общие регистры для обмена данными при системных вызовах; а вот для interrupt-space нужен полностью собственный набор регистров. Это избавит от необходимости сохранять регистры в память при переключении контекста. Впрочем, потребность в кэше это вряд ли снизит.
                                                      3. Изменить архитектуру процессора так, чтобы в нём был регистровый файл. С т.з. программ — это как бы оперативная память, но отдельная для каждого ядра; так что обращения в регистровый файл не приводят в обращению в оперативную память.
                                                      4. Изменить архитектуру компьютера, отказавшись от общей памяти для всех ядер. В каком-то смысле это эквивалентно увеличению скорости оперативной памяти — время отклика сохраняется, а вот скорость чтения/записи больших объёмов растёт примерно пропорционально количеству пулов памяти. Ну и количество коллизий при одновременном обращении нескольких ядер в память — тоже снизится.
                                                        –1
                                                        Изменить архитектуру процессора так, чтобы в нём было много регистров. Я думаю, 32 или 64 регистра общего назначения — нормально.

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

                                                          0
                                                          Уже сделано upload.wikimedia.org/wikipedia/commons/1/15/Table_of_x86_Registers_svg.svg
                                                          «Полезные» регистры — части с ZMM0-ZMM31, ST(0)-ST(7), и RAX-R15.
                                                            +1
                                                            «Физических» регистров сегодня в процессоре как раз примерно полсотни.

                                                            Проблема в другом — когда у вас много регистров у вас получается более «рыхлым» код.

                                                            Оптимум где-то между 16 и 32 регистрами (зависит от задач).
                                                              0

                                                              Что значит "рыхлый" код? Эту проблему не может решить компилятор, оптимально распределить регистры?

                                                                –1

                                                                Не-а, распределение регистров это NP-полная "задача упаковки".

                                                                  +3
                                                                  Каждый регистр у вас в инструкции же прописан.
                                                                  Больше регистров — больше длина инструкции и более сложная матрица процессора(который фактически коммутирует данные между регистрами хардверно)
                                                              +1
                                                              Изменить архитектуру процессора так, чтобы в нём было много регистров. Я думаю, 32 или 64 регистра общего назначения — нормально.

                                                              Давно уж сделано. ЕМНИП, в Эльбрусе вообще 192 архитектурных регистра.

                                                              Изменить архитектуру процессора так, чтобы для разных режимов процессора (как правило, их два: user-space и kernel-space; по хорошему надо бы иметь отдельный interrupt-space) был свой набор регистров. Ну, user-space и kernel-space должны иметь общие регистры для обмена данными при системных вызовах; а вот для interrupt-space нужен полностью собственный набор регистров. Это избавит от необходимости сохранять регистры в память при переключении контекста. Впрочем, потребность в кэше это вряд ли снизит.

                                                              Зачем такие сложности, если можно сделать регистровое окно поверх большего количества архитектурных регистров? Например, у Вас есть 128 физических регистров и хотите сделать окно в 32 регистра. Тогда нужно добавить команды циклического сдвига окна на +32 (call) и -32(return), простое переименование регистров (номер физического регистра = номер архитектурного + 32 * номер окна) и механизм вытеснения данных в память из этого регистрового файла при сдвиге окна на уже занятое место.

                                                              3 пункт вообще не понял: сами по себе регистровые файлы уже давно сделаны. Это те самые регистровые файлы, про которые Вы говорите, или нет?

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

                                                              Тоже не вполне понял. Вы имеете в виду сделать верхний уровень кэш-памяти приватным для каждого ядра?

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

                                                              Почему?

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

                                                              И опять-таки почему?
                                                                –1
                                                                Давно уж сделано. ЕМНИП, в Эльбрусе вообще 192 архитектурных регистра.
                                                                Ну так давно пора внедрять процессоры с большим количеством регистров вместо дурацкого *86.

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

                                                                Это те самые регистровые файлы, про которые Вы говорите, или нет?
                                                                Вариантов реализации регистрового файла много. Какие-то уже реализованы.

                                                                Изменить архитектуру компьютера, отказавшись от общей памяти для всех ядер.
                                                                Вы имеете в виду сделать верхний уровень кэш-памяти приватным для каждого ядра?
                                                                Нет. Я имею в виде — раздельную оперативную память (ту, котоорая сейчас DDR3 или типа того — DIMM-модули). Ну и надо сделать раздельные шины для доступа к этим модулям памяти.

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

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

                                                                При этом если направить запросы в разные модули памяти, то они могут отдавать или принимать данные параллельно. Поэтому предельная скорость растёт пропорционально количеству пулов памяти; а реально — ну, как повезёт.

                                                                Ну и количество коллизий при одновременном обращении нескольких ядер в память — тоже снизится.
                                                                И опять-таки почему?
                                                                Опять очевидно.

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

                                                                А ещё при раздельной памяти — не надо синхронизировать кэш. Это тоже заметный выигрыш по цене. Но плата за это — названа выше.
                                                                  +1
                                                                  Ну так давно пора внедрять процессоры с большим количеством регистров вместо дурацкого *86.

                                                                  Главное при этом — не добавлять новые команды в дополнение к существующим. Больше префиксов богу префиксов.


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


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

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


                                                                  Нет. Я имею в виде — раздельную оперативную память (ту, котоорая сейчас DDR3 или типа того — DIMM-модули). Ну и надо сделать раздельные шины для доступа к этим модулям памяти.

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


                                                                  Кстати, уже есть пример подобной организации памяти: Threadripper (ядро Zen) в NUMA-режиме. Правда, из Zen 2 этот режим выпилили, решив проблемы с масштабируемостью.


                                                                  При этом если направить запросы в разные модули памяти, то они могут отдавать или принимать данные параллельно. Поэтому предельная скорость растёт пропорционально количеству пулов памяти; а реально — ну, как повезёт.

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


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

                                                                    0
                                                                    Главное при этом — не добавлять новые команды в дополнение к существующим.
                                                                    Набор команд надо составлять заново.

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

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

                                                                    И это все равно не поможет преодолеть фундаментальное ограничение в виде задержки доступа к памяти.
                                                                    Если обращения в память редкие — на задержки можно наплевать.

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

                                                                    Допустим, у нас есть одно ядро с одним мегабайтом кэша. На типичной программе miss_rate=1%, при этом miss_time=10%, т.е. шина «процессор-память» занята 10% времени.
                                                                    Почему такая разница?
                                                                    Каким будет miss_time, если miss_rate=100%?

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

                                                                    Кстати, уже есть пример подобной организации памяти: Threadripper (ядро Zen) в NUMA-режиме.
                                                                    Это явно не оно. Это скорее отключение синхронизации кэшей — т.е. UMA:S (Uniform Memory Access: Separate). По методам работы в таком режиме — оно напоминает NonMA (раздельную память), но допускает динамическое перераспределение памяти (процедура сложная, но полезная), обмен данными через память (через динамическое перераспределение памяти), а также коллизии при одновременных hit_miss.

                                                                    Там современные процессоры уже умеют в многоканальный доступ.
                                                                    Если несколько ядер в одном чипе — то очень сложно сделать раздельные шины к разным модулям памяти. Коллизии при доступе к шине — остаются.

                                                                    раньше одно ядро могло использовать сразу несколько каналов
                                                                    А зачем ему это?

                                                                    Будущее, как мне кажется, за увеличением ширины шины — пока что тут есть куда расти.
                                                                    Вроде, наращивать количество дорожек уже некуда.
                                                                      +1
                                                                      От супескалярности следует отказаться. Ну или прописывать её явно, выделив в команде поле под это дело. При большом числе регистров — зависящие по данным команды можно разнести далеко.

                                                                      Что-то Itanium с таким подходом не взлетел.
                                                                      А суперскалярность — хорошее подспорье для предсказателя переходов. Конечно, вы можете это реализовать статически в compile-time, но в силу огромной сложности это будет менее эффективно.


                                                                      Если обращения в память редкие — на задержки можно наплевать.

                                                                      Тогда и общий доступ к памяти не будет проблемой.


                                                                      Вроде, наращивать количество дорожек уже некуда.

                                                                      HBM-память, SoC.

                                                                        0
                                                                        Конечно, вы можете это реализовать статически в compile-time, но в силу огромной сложности это будет менее эффективно.

                                                                        Скорее не из-за огромной сложности (реализовать аналог на самом процессоре сложнее, чем программно), а из-за недостаточности данных в статике. То есть предсказатель перехода в процессоре имеет больше данных, чем компилятор.
                                                                        А так да, это известная проблема VLIW.
                                                                          +2
                                                                          То есть предсказатель перехода в процессоре имеет больше данных, чем компилятор.
                                                                          Дело не в предсказателе переходов, а, банально, в частоте.

                                                                          Из-за которой «поход в память» — это целое событие, 300-400-500 тактов. Понятно, что большая часть идёт из кеша, только одно обращение из нескольких десятков реально идёт в память… но когда это происходит — суперскаляр перестраивает план вычислений, а VLIW ждёт. Долго ждёт.
                                                                            0
                                                                            Так мы ж говорим здесь о том, как замаскировать эти задержки, использовав время ожидания на что-нибудь другое. Я по инерции продолжал говорить про предсказатель переходов, хотя с моей стороны было правильнее переключиться на механизм OoO.
                                                                            Out-of-order действительно сам организует порядок исполнения операций, и пока одна команда ждёт данных, может запустить не зависящие от неё операции. При этом в динамике он знает, где какие адреса и потому знает, где будут конфликты => имеет больше свободы в размещении команд. Компилятор в данной ситуации имеет меньше свободы, так как вынужден использовать различные сложные варианты анализа адресов и консервативно оценивать возможность возникновения конфликтов. Поэтому в идеале in-order подход с явным параллелизмом проиграет out-of-order'у.
                                                                            В реальной же ситуации у нас кроме самого OoO/in-order начинают играть прочие факторы. Например, предподкачка данных или ограниченность буфера предвыборки команд в out-of-order. Ну и оптимизации размещения данных в памяти со стороны компилятора. Так что в реальном мире не настолько очевидно, кто кого и как обыгрывает.
                                                                              0
                                                                              При этом в динамике он знает, где какие адреса и потому знает, где будут конфликты
                                                                              Не знает. В том-то и дело, что не знает. Ни VLIW не знает, ни механизм OoO. Последнему, впрочем, это не нужно: он видит какие инструкции из «пула» можно исполнять (хотя бы и спекулятивно), а какие «застряли».

                                                                              Но в кеш он не смотрит и ему это не нужно. Все решения принимаются «пост-фактум». А для VLIW-компилятора это-таки нужно.

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

                                                                              В однопотоке VLIW «сливает» и достаточно сильно, увы.
                                                                                0
                                                                                Не знает. В том-то и дело, что не знает. Ни VLIW не знает, ни механизм OoO. Последнему, впрочем, это не нужно: он видит какие инструкции из «пула» можно исполнять (хотя бы и спекулятивно), а какие «застряли».

                                                                                Эээ, а как они тогда вообще работают с памятью, не зная адресов? Ну и Вы только что отказали OoO в возможности корректно обрабатывать как минимум конфликты типа write after read по одному и тому же адресу.

                                                                                Но в кеш он не смотрит и ему это не нужно. Все решения принимаются «пост-фактум». А для VLIW-компилятора это-таки нужно.

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

                                                                                В однопотоке VLIW «сливает» и достаточно сильно, увы.

                                                                                I need proof.
                                                                                ЕМНИП, в какой-то статье я читал, что однопоточно Эльбрус 1 ГГц был эквивалентен чему-то типа 2,6 ГГц Интела. Но это нужно гуглить.
                                                                                  +1
                                                                                  Эээ, а как они тогда вообще работают с памятью, не зная адресов?
                                                                                  Причём тут адреса? Речь идёт про наличие данных в кеше!

                                                                                  Ну и Вы только что отказали OoO в возможности корректно обрабатывать как минимум конфликты типа write after read по одному и тому же адресу.
                                                                                  write after read — это, вроде бы, вообще не конфликт. Может вы имеете в виду read after write? Да, на эту тему что-то вроде есть bypass'ы — но это всё равно не критично. Они только в последних поколениях появились.

                                                                                  Но имхо с достаточно хорошо отработавшими оптимизациями размещения данных в памяти и всякими предподкачками доля промахов кэша достаточно мала, чтобы не сильно потерять в производительности, предположив все данные лежащими в L1.
                                                                                  Вопрос в том, что такое «не сильно потерять в производительности». Раза в два — это «сильно» или «не сильно»?

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

                                                                                  В случае с ОоО — решение элементарно: если инструкция «залипла», то мы можем весь дальнейший план действий «пересчитать» — то, что от неё зависит — отложить, то что не за висит — продолжать исполнять.

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

                                                                                  ЕМНИП, в какой-то статье я читал, что однопоточно Эльбрус 1 ГГц был эквивалентен чему-то типа 2,6 ГГц Интела. Но это нужно гуглить.
                                                                                  Погуглите. И вчитаейтесь.

                                                                                  Потому что если взять картинки от МЦСТ, то там все проблемы видны очень отчётливо. То есть не сразу, но если подумать.

                                                                                  То есть на первый взгляд — всё как вы говорите. Частота ниже, эффективность — та же, всё зашибись, ща токо частоту поднять… А вот нетути. За счёт чего вы её собрались поднимать-то?

                                                                                  Посмотрите на процессоры из той таблички:
                                                                                  Intel ULV 1GHz:
                                                                                  техпроцесс — 130nm
                                                                                  транзисторов (на ядро) — 77 million
                                                                                  тепловыдедление (на ядро) — 7W

                                                                                  Эльбрус-2C+:
                                                                                  техпроцесс — 90nm
                                                                                  транзисторов (на ядро) ~100 million
                                                                                  тепловыдедление (на ядро) ~ 10W

                                                                                  В том-то и дело, что сравнение у МЦСТ — вполне честное (в смысле архитектуры — так-то Pentium на несколько лет раньше появился, но это уже не про архитектуру), но люди додумывают невесть что.

                                                                                  Да, у ОоО процессора частота — вдвое выше… ну и что? Если техпроцессы одинаковы и транзисторов требуется больше и тепловыделение у нас больше тоже, то… таки это слив, извините.

                                                                                  На плавучке — да, Эльбрус отыгрывается, но плавучка — это ныне вотчина GPU и TPU, там совсем другие числа получаются…
                                                                                    0
                                                                                    Причём тут адреса? Речь идёт про наличие данных в кеше!

                                                                                    Мы ж про конфликты говорили. А это неразрывно связано с адресами.
                                                                                    Впрочем, если Ваша речь — про наличие данных в кэше, то я и не возражал вроде…

                                                                                    write after read — это, вроде бы, вообще не конфликт. Может вы имеете в виду read after write? Да, на эту тему что-то вроде есть bypass'ы — но это всё равно не критично. Они только в последних поколениях появились.

                                                                                    Я имел в виду именно то, что написал. RAW (read after write) к теме разговора не относится. WAR — вполне однозначно конфликт: если поменять операции местами, то изменится результат read => изменится результат исполнения программы. И этот конфликт OoO обязан так или иначе решить.
                                                                                    Отдельно про байпассы: это ж седая древность. ЕМНИП, эти штуки ещё с самого появления конвейеров появились. Просто много байпассов в процессоре сложно делать, вот и ставят их только на самые перспективные в смысле ускорения пары стадий конвейера.

                                                                                    Вопрос в том, что такое «не сильно потерять в производительности». Раза в два — это «сильно» или «не сильно»?

                                                                                    Откуда данные про 2 раза?

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

                                                                                    Ваш вариант про предусмотреть всё такое, разумеется, не катит. Но ведь есть другие оптимизации, и я их даже перечислил.
                                                                                    Конечно, в идеальном исполнении с идеальным компилятором VLIW проиграет OoO. Но реально надо уже смотреть на конкретные реализации.
                                                                                      +1
                                                                                      WAR — вполне однозначно конфликт: если поменять операции местами, то изменится результат read => изменится результат исполнения программы. И этот конфликт OoO обязан так или иначе решить.
                                                                                      Нет там конфликта. Если вы запись спекулятивно сделаете — то это может не только на последующее чтение повлиять, но эти и другие процессоры могут «увидеть». Потому спекулятивная запись идёт в специальный буфер и старое значение в памяти не теряется.

                                                                                      Вопрос в том, что такое «не сильно потерять в производительности». Раза в два — это «сильно» или «не сильно»?
                                                                                      Откуда данные про 2 раза?
                                                                                      Ниоткуда — это ж просто вопрос. Что такое «сильно» для вас.

                                                                                      Конечно, в идеальном исполнении с идеальным компилятором VLIW проиграет OoO. Но реально надо уже смотреть на конкретные реализации.
                                                                                      Ну вот конкретно в конкретных реализациях — остался один Эльбрус. И то потому, что у них нет готового суперскаляра, чтобы свой VLIW выкинуть. Все остальные уже от VLIW отказались.

                                                                                      Как нам тут подсказывают — уже даже и в GPU отказались…
                                                                                  0
                                                                                  А с чего это GPU вдруг VLIW архитектурой стали? Они SIMD, причем очень широкие SIMD, но не VLIW.
                                                                                  Последнюю WLIW архитектуру в GPU похоронили ЕМНИП вместе c семейством AMD Radeon 6xxx (Northern Islands, 3е и последнее поколение VLIW архитекрутры AMD TeraScale 3), производство которого завершилось около 8 назад. Вроде с тех пор больше никто из крупных производителей графики с VLIW не экспериментировал.
                                                                                    0
                                                                                    Я не сказал «используются», я сказал «прижились».

                                                                                    Ну как вы же сами сказали — они таки реально выпускались и реально продавались обычным пользователям (не оборонке и не импортозаместителям) много лет и есть шанс, что ещё вернутся.
                                                                              0

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


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

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

                                                                                В смысле сложно? Если сделать в системе команд спекулятивные операции (а в VLIW Эльбрусе они есть — пруф), то это окажется не сложнее, чем в суперскаляре: оставшиеся механики отставки результата операции совпадают.
                                                                                  0
                                                                                  Судя по описанию — похоже на знаменитый Trace Cache.

                                                                                  На практике он оказался веьма неэффективным.
                                                                                    0
                                                                                    Никаким боком Trace Cache к спекулятивным операциям не относится: это средство ускорения выборки операций.

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

                                                                                      В Pentium 4 это частично делается вообще во время создания трассы, а частично — посредли конвеера. Вот тут исследовали чем всё это заканчивается.

                                                                                      С учётом того, что во VLIW шедулер — вообще где-то в компиляторе… стоит ожидать подобных же эффектов.
                                                                                  0
                                                                                  Я же имел в виду ещё и спекулятивное выполнение, когда процессор выполняет одновременно обе ветки кода, а затем одну отбрасывает.
                                                                                  Нету такого в современных процессорах, как это ни удивительно. Были попытки когда-то что-то такое сделать… но оказалось, что это банально невыгодно.
                                                                                    0
                                                                                    Ну вот разработчики Эльбрусов пишут что они таким все еще пользуются.

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

                                                                                    Хотя блоки аппаратной предвыборки данных вроде бы все еще могут смотреть обе ветви кода, но уже только с целью заранее на всякий случай подтащить данные из памяти в кэш, но не начиная исполнение побочную ветви кода до момента самого перехода.
                                                                      0
                                                                      1) Все релевантные архитектуры кроме х86 имеют 32 регистра.
                                                                      2) Поздравляю, вы изобрели ARM FIQ режим.
                                                                      3) Регистровый файл есть в любом процессоре :)
                                                                      4) Поздравляю, вы изобрели RAW/CELL/Epiphany (Parallella).

                                                                        0
                                                                        1) Не совсем понятно, что Вы подразумеваете под словом "релевантные архитектуры". Вроде, ARM-32 имеет всего 16 адресуемых регистров; и даже вместе с регистрами SWI/IRQ/FIQ там не набирается 32 штуки.

                                                                        2) Я его не изобретал. Я именно оттуда и взял идею.
                                                                        При этом, очевидно, я имею полное право агитировать за чужую идею.

                                                                        3) Вроде, ARM-32 не имеет регистрового файла.
                                                                        А что значит «в любом»? В восьмибитных процессорах разве есть регистровый файл?

                                                                        4) Я не понял, про что это Вы. Перечисленные слова слишком многозначны, не гуглятся.
                                                                          +1
                                                                          ARMv7 сейчас это удел микроконтроллеров и старых плат.
                                                                          Многие современные ARM чипы этот режим вообще не поддерживают.
                                                                          У ARMv8 и остальных RISC процессоров 31-32 регистра было изначально.

                                                                          А что значит «в любом»?
                                                                          ru.wikipedia.org/wiki/Регистровый_файл

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

                                                                          www.princeton.edu/~wentzlaf/documents/Taylor.2001.HotChips.Raw.pdf
                                                                          en.wikipedia.org/wiki/Cell_(microprocessor)
                                                                          www.parallella.org

                                                                          В этих (и других) процессорных архитектурах у каждого ядра есть локальная память, что позволяет им работать на полной скорости без снуп-трафика.
                                                                          С основной памятью работа ведётся через коммутатор/DMA.

                                                                      +2
                                                                      Любой кэш должен обеспечивать или контроль доступа к данным или гарантированный сброс кэша при переключении контекста. В противном случае будет очередная волна уязвимостей. Если сброс при смене контекста есть смысл делать на L1 и, быть может, L2, то для L3 и уж тем более L4 нужен контроль доступа. Реализовать его можно с помощью тегирования, хотя есть и иные способы. В любом случае это сильно усложнит реализацию кэшей и, следовательно, замедлит их работу и уменьшит полезную ёмкость. Но если этого не сделать, то о разграничении прав доступа на любом уровне можно забыть. И что-то мне подсказывает, что в погоне за скорость никто этого не будет делать.
                                                                        0
                                                                        Меня больше интересует широкополосная память на одном интерпозере с CPU, т.е.:
                                                                        — полоса существенно выше, чем доступ к основному объёму RAM (ширина шины, частота, задержки, протокол доступа, число каналов);
                                                                        — объём существенно больше, чем L3, минимум — раз в 10-100;
                                                                        — не обязательно делать именно классический кэш, но обязательно иметь более широкие аппаратные возможности доступа, чем к основному объёму RAM;
                                                                        — нахрен слоты/разъёмы, длинные линии и прочие гадости;
                                                                        — бонусом — существенно меньшее удельное потребление.

                                                                        Проблемы с классической оперативной памятью связаны с ограничениями при размещения оной на материнской плате:
                                                                        — ограниченная ширина шины, нужно соблюдать ЭМС (ширина дорожки и отступы и ещё дохрена всего), быстро растёт занимаемая площадь;
                                                                        — ограниченная макс. длина шины, нужно соблюдать ЭМС (потери, стабильность импеданса на ПП, помехи, и т.д.);
                                                                        — ограниченная мин. длина шины, т.к. размеры DIMM — огромны, даже 4 распаянных чипа нехило добавляют площади, длина дорожек тоже получается относительно большой;
                                                                        — увеличение числа слоёв ПП — дорого, могут быть проблемы с контролем и надёжностью.
                                                                        — с дальнейшим ростом частоты (- требований к ЭМС) рост сложности ПП будет расти намного быстрее
                                                                          0
                                                                          Если судить по слухам — никого из производителей широколосная (физичиски много линий) память не интересует.

                                                                          Сейчас идет адская борьба за размер и энергоэффективность. Широкие шины вредят и одному и другому. И амд и интелл работают над «умной памятью». Они пытаются теми или иными способами физически положить «будущие» данные как можно ближе к соотвествующему ядру. Тогда скорость шины между ядром и кешем уже вторичны.
                                                                            0
                                                                            Вы только что «изобрели» HBM память.

                                                                            Только бонуса в виде меньшего потребления энергии у нее нет, наоборот работа со сверхширокими шинами (у HBM это от 1024 бит и выше) съедает больше энергии несмотря на то что длина этих шин стала во много раз меньше.
                                                                            Все остальное присутствует.
                                                                              0
                                                                              Удельное потребление на бит-транзакций будет меньше при прочих равных, HBM — только один из возможных путей. Дорожки очень много рассеивают, с ростом частоты всё будет намного хуже. SDRAM в составе SoC иногда хорошо экономит бюджет. Но, хочется большего — расширенных аппаратных возможностей, не уверен, что в виде очередного кэша (L4) оно даст много профита, а вот как широкополосная оператива + доп. фичи, которых нет в классическом варианте поможет более эффективно организовать кэширование в самом софте, например.
                                                                            0
                                                                            Скорее смысле в L4 нет, поскольку есть разработки так называемых «чиплетов». Одна из статей здесь .
                                                                            Причина ввода кэшей историческая — малая скорость памяти в сравнении со скоростью самого процессора + их удаленность от CPU (изначально они были вне процессора), что приводило к потере в скорости передачи. Потому их стали вводить в сам процессор (и ближе и, в итоге, быстрее). Чиплеты (all-in-one) по сути нивелируют необходимость в L4.
                                                                              0
                                                                              А когда в CPU начали добавлять всё больше и больше ядер, а также всё больше контроллеров DRAM для их загрузки, к иерархии добавили ещё более крупные блоки кэшей L3.


                                                                              Я как бы намекаю, что L3 — это не изобретение архитектуры Bloomfield, Pentium EE ещё на 130 нм имел такой.

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

                                                                              Самое читаемое