По ту сторону закона Мура

    Слухи о смерти закона Мура ходили, сколько я себя помню. Рассуждения о том, что мы приближаемся к размерам атома и о том, что скоро вся затея станет нерентабельной, я слышал и 30, и 20, и 10 лет назад. Вот только инженеры раз за разом их опровергали. Именно инженерный гений сделал закон Мура одним из “самоисполняющихся пророчеств”.

    Не собираюсь рассуждать о том, достигла технология своего предела или еще нет. Несмотря на радиофизическое образование, я в ней разбираюсь очень условно. Желающим вникнуть могу посоветовать обратиться к недавнему обзору. Я же подпишусь под точкой зрения еще одного очень уважаемого мной мыслителя Боба Колвелла.

    image

    Teм временем чипмейкеры продолжают строить (ну или по крайней мере анонсировать) новые фабрики, работающие по новым технологиям. Значит, это все еще выгодно. По мне так “пациент скорее жив, чем мертв”. Mуровская экспансия остановится тогда, когда сервер с двумя процессорами произведенными по новой технологии станет дороже, чем сервер с 4мя произведенными по старой. А это пока далеко не так. Мне доводилось работать и с 4-head и даже с 8-head. Но они собираются на заказ и стоят как маленький самолет.

    Моя же задача сегодня рассказать о том как технология влияет на архитектуру и программирование. О том что нас ждет “по ту сторону закону Мура”. Ибо многие тенденции очевидны уже сейчас. Итак.

    Площадь (объем) кристалла – на вес золота. Транзисторы перестают “сжиматься”, а размер чипа ограничен. Соответственно, у количества элементов есть предел. Новые фантазии становится все тяжелее впихивать на кристалл. Напротив, возрастает цена компактности. Дизайнеры куда больше озабочены оптимизацией, чем инновациями. Соответственно, мы будем видеть все меньше новшеств на кристалле CPU или GPGPU. Возможно, даже софт придется меньше переписывать, хотя в последнее мне не верится.

    Дискретность. Поскольку размер, функционал и энергопотребление чипа ограничены, давайте же натыкаем как можно больше микросхем. Хороших и разных (взрывной рост акселераторов, предсказанный Колвеллом). Или одинаковых (symmetric multi-processing). Или вообще с перепрограммируемой логикой(FPGA). Каждый из этих сценариев имеет свои достоинства. Первый дает максимальную производительность на ватт для конкретной задачи. Второй –простоту программирования. Третий — гибкость. Какой сценарий реализуется – решит время. Как я люблю говорить, жизнь все покажет и всех рассудит. И ждать осталось уже недолго.

    Усложнение NUMA: Монокристаллы вымирают, уступая место чиплетам. Таким образом, производители увеличивают выход годного продукта. Кстати, “ялда” (yield) – процент годных чипов, это самая страшная тайна любого чипмейкера. Особенно, на ранних стадиях техпроцесса. Но такое “cклеивание” чипа из кусочков несет дополнительные сложности для программистов. Время коммуникаций между ядрами внутри чиплета и вне – разное. И это только один пример все усложняющейся структуры NUMA (Non-Uniform Memory Access). Другой – топология связей внутри чипа.(A eще – High Bandwidth Memory. A eще – дискретность. А –еще...) И все это надо будет принимать во внимание.

    Возрастающая роль uncore: Раз уж речь зашла о внутрипроцессорных коммуникациях упомяну еще об одной интересной тенденции. Если присмотреться к M&A активности лидеров рынка, то легко понять, что все гиганты делают одно и то же. Intel вкладывается в технологии Silicon Photonics и покупает Barefoot Networks. NVidia отвечает покупкой Mellanox. И не Infinibanda единого ради. Все понимают, что поле будущей битвы – внутри- и межпроцессорные соединения. И кто станет “царем горы” определят не instruction setы и какая-то сложная логика, а шины и коммутаторы.

    “Неповторимость”(точнее неповторяемость): Mне иногда приходится работать с большими ансамблями чипов. Это происходит, когда строится и запускается новый кластер для высокопроизводительных вычислений. И недавно я заметил одну интересную вещь. Если раньше чипы с одинаковй маркировкой были практически неотличимы, то теперь каждый из них имеет свой “характер” и “настроение”. У процессора есть встроенный механизм регулировки энергопотребления. Он зависит от того сколько ядер работает в данный момент, какие блоки задействуются, от температуры и тд и тп. И похоже, то как процессор потребляет и рассеивает энергию зависит еще от условий производства конкретной партии, от его положения в стойке и еще массы других неконтролируемых факторов. В результате я наблюдал девиации частоты (и производительности) ~15%. Разумеется, это приводит ко всякого рода имбалансам (MPI, OpenMP). И как с ними бороться пока не очень понятно. Разве что, делать распределение работы динамическим.

    И последнее — частота: Расти точно не будет. По многим причинам, среди которых энергопотребление, размер и тп. Рискну предположить, что частоту вообще надо понижать. Максимально безболезненным для single thread performance образом (то бишь есть улучшая архитектуру). Тут конечно пострадает любимый всеми маркетологами Linpack. Но система станет более сбалансированной и труд разработчиков железа облегчится. Ну а в реальных приложениях, чем меньше тактов намолотит процессор, ожидая данных от медленных устройств (памяти, сетки, диска) – тем лучше.

    Таким мне представляется компьютерный мир в пост-муровскую эпоху.
    А вы каким его видите?
    Huawei
    Компания

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

      0

      Есть и другая сторона этого вопроса. Ощущение от скорости работы на моем десктопе за последние 20 лет мало поменялись. А вот после накатывания очередной версии оси на то же железо падает в разы. Где то я слышал о карательных сговорах производителей железа и софта. Хотя отношение к этому как к чипированию у большинства. Типа ку-ку.

        0
        Wintel?:)
          0

          Не обязательно. Например кто и почему финансирует проекты опенсорсных систем? Ну а кто платит тот и заказывает.

            0
            Все понемножку. Как правило поделки, которые финансируются одним игроком не выживают. Ну а кто то как Red Hat вполне сам зарабатывает деньги.
              0

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

          +1
          Ощущение от скорости работы на моем десктопе за последние 20 лет мало поменялись.

          Да ладно вам! Вы уже просто видимо забыли эти загрузки винды по несколько минут, ожидания загрузки софта и «микро-лаги», адский хруст французской булки винтов. Нехватку оперативки, своп и снова адский хруст. У меня ощущения от работы поменялись просто кардинально.
            0
            сижу на пк 2005г(но конкретно я им пользуюсь с 2014, в основном для браузера и ютуба в 480р), 3 года назад почувствовал что начал работать медленно.

            Перешёл на винду 10, мне говорили что она быстрая. Винда 10 грузится по 10-15 минут, браузер ещё 3 минуты открывается. Когда открылся, не хватает озу, создается своп, снова всё тупит, а отклик винта иногда подмимается до 6к милисекунд. Поставил ссд, на него систему, браузер, нужные проги. докинул озу с 2 до 4гб. прекрасно работал со всем, что мне надо, 20-25секунд на загрузку винды до кликабельности ярлыков на рабочем столе. Даже гта5 запускается и дает 2фпс на минималках и с недогрузами. Недавно решил изучить юнити, и понял что комп безвозвратно устарел. Отдал его другу под сервер для чего то легкого, а сам перешёл на AM4 платформу на r3 1200, под будущий апгрейд.

            Честно от перехода с hdd на ssd эффекта больше чем от перехода с 775 на AM4, так что с вами согласен только про своп на hdd и хруст винтов, но если правильно всё настроить, то и его нет. Особенно на win XP, там и к озу гуманное отношение, в простое 120-150мб выжирает всего, а из-за этого до свопа сложнее довести, да и места на диске меньше занимает, и обращается к нему для своих нужд довольно редко, так что хруста или подвисаний из-за отклика дисков на XP нет.
          +1
          Мне кажется, что после закона мура будет революция в программировании. Возможности «пусть компилятор думает» все быстрее тают. При этом умение «понимать как работает все железо стека» уже давно утрачено из-за объема необходимых знаний.

          Мне кажется что вещи, которые сейчас драйвера и микрокод (те те кто свое железо превращает в условный распространенный апи/аби) станут плагинами для компилятора. И когда мы устанавливаем софт — он компилируется под конкретно наше железо и другой софт который уже стоит.

          Вместо менеджера пакетов — тоже будет какой-то компилятор, которые находит одинаковый код в разном софте и переиспользует это во всех нужных программах.
            0
            Как Java? Или при установке перекомпиляция все же требуется? А что если я меняю видеокарту? Г Надо пересобирать весь софт?
              +1
              Джава пыталась идти в этом направлении. Но ничего не вышло. Я не отрицаю огромный вклад в индустрию и достижения, в том числе по производительности.

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

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

              Процессор — уже очень давно не один инструмент. А сеть разных инструментов. И чтобы был быстрый результат, оно должно работать как хорошо настроенный ковеер на заводе. Каждый станок производит ровно столько (не больше не меньше) сколько может переработать следующий станок. То что ядра простаивают ожидая информации из памяти — лишь один из многочисленных примеров бутылочных горлышек в вычислениях.
                0
                И чтобы был быстрый результат, оно должно работать как хорошо настроенный ковеер на заводе. Каждый станок производит ровно столько (не больше не меньше) сколько может переработать следующий станок. То что ядра простаивают ожидая информации из памяти — лишь один из многочисленных примеров бутылочных горлышек в вычислениях.

                Ага. Вот поэтому я и говорил о понижении частоты. Без этого сбалансировать не очень то получается…
                  +2
                  не хотел я влазить в холивар за частоты.

                  Окай. Допустим Вы правы, я нет. Имеем «ковеерную частоту» и хреновый код, который не учитывает железо (те случайный). Асолютно все железо внутри компьютера — каждый чип, памаять, силикон и дорожка заточены под частоту Х.

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

                  В выборе как сбалансировать конвеер — железно или софтверно — выбирать надо софт. Потому что железная балансировка убьет прогресс. Человек просто физически не может сбалансировать сотни чипов (тысячи параметров) — этим должно заниматься эволюционный потомок компилятора.
                    0
                    Опять не понял. Зачем все затачивать под одну частоту?
                    Я тока говорил, что жизнь становится сложнее по мере того, как растет разрыв по скорости между процессором и памятью.
                    и насчет того что для балансировки надо выбирать софт тоже согласен. Но и это тоже становится все сложнее и сложнее.
                      +1
                      1) память сейчас сильно ускорится с выходом ДДР5 так что я думаю память догонит процессор

                      2)> Но и это тоже становится все сложнее и сложнее.

                      именно поэтому программирование должно совершить революцию, а не просто не программировать лучше.

                      Нам надо решить задачи, которые вообще не решаемы современными инструментами и подходами
                        0
                        память сейчас сильно ускорится с выходом ДДР5 так что я думаю память догонит процессор

                        Это хорошее замечание -догнать конечно не догонит, но жить станет определенно легче :)
                          0
                          5200 MT/s x2 канала. 4 в серверах.
                          Плюс новая технология раздельного доступа к банкам. Видимо они движутся в сторону создания нескольких каналов на одну планку.
                          0
                          именно поэтому программирование должно совершить революцию, а не просто не программировать лучше.

                          Да я уже даже готов согласиться. Только вот подумаю, сколько софта придется портировать и такая тоска меня берет… :)
                            0
                            Его надо переписывать только из-за 1) многопоточности 2) новых специализированных инструкций и ускорителей 3) новых виртуализаций и проблем с безопастностью
              0
              Мне кажется то что сейчас происходит с вебом — говорит о том, что скоро будут везде два ядра и средняя частота, а вот количество и частота оперативы вырастет невероятно
                +5
                Мне кажется, что практически все, что происходит с вебом на протяжении всей его истории — вообще не объясняется логикой с технической точки зрения, а имеет смысл лишь в контексте финансов и борьбы за монополию производителей браузеров.
                  0
                  А почему, если не секрет?
                  +1
                  Рискну предположить, что частоту вообще надо понижать.
                  Ну не знаю… Повышение частоты — это ведь практически пропорциональное повышение производительности. Никто просто так не будет пренебрегать подобной возможностью.
                    0
                    Да я понимаю что понижение частоты — это не очень реалистично. Только если удастся компенсировать за счет чисто железных оптимизаций.
                    Мне эта идея нравится с чисто логической точки зрения. Попытка сбалансировать IO и вычислительную мощность. Bytes/flops. Stream/Linpack.
                      0
                      А зачем их балансировать таким образом? Да, обычно программы упираются в IO, но иногда нужно и вычисления запустить какие-то. Зачем ужимать их скорость? Даже если появятся оптимизации архитектуры — слоган «новый процессор на 20% быстрее» звучит лучше чем «новый процессор такой же по скорости, зато на 20% экономичнее» и на десктопах, и на мобилках; разве что в серверном сегменте дела могут обстоять по-другому.
                        0

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

                          0
                          А разница между «новый процессор на 20% быстрее» и «новый процессор на 20% эффективнее»? Софистикой рекламщики играть давно уже умеют.
                            0
                            Смотрю щас на нашу поделку с короктими СИМДами (NEON) и бодрым взаимодействием с памятью. Байтов на флоп много. Программисту приятно и разработчику железа тоже. А вот пользователям и маркетологам — увы, по фигу :(
                              0
                              Но Вы же не будете утверждать, что в том же интеле или амд маркетологи упустят шанс? Это и отчасти их хлеб, а пустую горбушку есть нет охотников. Очень немалую часть покупателей составляют пользователи, так что не удивительно, что ориентируются на большинство.
                          +1
                          Если я правильно понимаю текущую ситуации, то в настоящее время есть два «бутылочных горлышка» это:
                          — отвод тепла от кристалла
                          — ограничение скорости информационного потока через интерфейсные выводы кристалла процессора (корпуса процессора)
                          Требуется так использовать ресурсы числа транзисторов и частоты дискретизации, что бы при этих ограничениях получить максимальную производительность, а уж что отрезать и расширять это уже вторично.
                          Мое мнение лучше максимально конвееризованное решение, дает больше гибкости и потенциала к большой производительности. Позволяет в широких пределах варьировать частоту и число транзисторов.
                        +2
                        Рискну предположить, что частоту вообще надо понижать.

                        Многие приложения всё ещё зависят от частоты.
                        На чипе нужны не только ядра с разной микроархитектурой (big.LITTLE), но и разные по назначению как у Esperanto Technologies.
                        Так что частоту нужно увеличивать, но только для определённых ядер.
                        Это то, что можно сделать не меняя программную модель.

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

                        Я же сторонник совсем иной архитектуры.
                        Тысячи небольших in-order RISC-ядер имеющих локальную scratchpad SRAM, работающие на 5+GHz + умный префетчер и кэш когерентный DMA.
                        В том же CELL, SPE запускали на 6-7ГГц при 90нм процессе. Но PowerPC ядро не могло работать на высокой частоте, да и чип бы расплавился при подведении большой мощности.
                        Думаю сейчас не нужно делать очень длинный конвейер чтобы добиться высокой частоты.
                        Scratchpad это более сложный вопрос.
                        Проблема scratchpad в том, что никто не смог преодолеть проблемы её менеджмента и потенциального роста. Даже в GPU не осилили.
                        Большая проблема такого подхода это программная модель. Фатальная ошибка дизайнеров CELL — была в ориентированности на язык C++. Ну нельзя такое программировать на низкоуровневыми языках. Точнее можно, но лишь приложив 10х усилий.

                        Как-то так, если не упарываться полноценными data flow архитектурами.

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

                        Дожить бы до неё.
                          0
                          Это потребует от программистов размышлений над каждой мелочью.При низкой частоте ядер можно рассчитывать только на широкий SIMD и надежду,
                          что всё будут делать именно на нём.
                          Такое ощущение, что думать над оптимизацией в любом случае придется сильно больше чем раньше. Я кстати даже не про симды — а про серверные приложения где поток ждет данные быстро обрабатывает их и засыпает.
                            +1
                            Тысячи небольших in-order RISC-ядер имеющих локальную scratchpad SRAM, работающие на 5+GHz + умный префетчер и кэш когерентный DMA.
                            Сделать первое не такая большая проблема. Гораздо большая проблема «накормить» эту машину данными. умный префетчер и кэш когерентный DMA. — хорошая затея осталось только сделать :) А как насчет внутрипроцессорной сети? Как эти ядра будут друг с другом коммуницировать?
                              +1
                              Сделать первое не такая большая проблема.

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

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

                              Обычный grid. Тут со времён RAW ничего особо лучше не придумать.
                              Префетчер должен посылать данные заранее к конкретному ядру.
                              Вот над чем нужно думать.
                              У меня пока нет ответов на все вопросы, но я и не занимался детальной проработкой.
                              Так, скорее пара мыслей крутится.
                              Но чтобы не оказаться с dead-on-arrival архитектурой, нужно идти строго от компилятора к железу, а не наоборот.

                              PS: Ставьте blockquote (кавычка сверху в редакторе) или хотя бы пробел между цитатой и своими словами — ничего же не понятно.
                                0
                                PS: Ставьте blockquote (кавычка сверху в редакторе) или хотя бы пробел между цитатой и своими словами — ничего же не понятно.

                                Просто попробовать blockquote
                                  0
                                  Обычный grid. Тут со времён RAW ничего особо лучше не придумать.
                                  Префетчер должен посылать данные заранее к конкретному ядру.
                                  Вот над чем нужно думать.
                                  У меня пока нет ответов на все вопросы, но я и не занимался детальной проработкой.
                                  Так, скорее пара мыслей крутится.


                                  Я боюсь, что этот грид будет или затычкой в системе или места занимать в 10 раз больше чем все эти ядра вместе взятые…
                                    0
                                    С чего бы гриду занимать много места? Его задача передать данные по адресу узла.
                                    en.wikichip.org/wiki/intel/microarchitectures/polaris
                                      0
                                      А когерентность кэшей? Или я не понимаю чего то?
                                        +1
                                        В моей схеме у ядер либо нет кэшей, либо максимум read-only кэши + специальные кэши для атомиков. Все коммуникации происходят через сообщения и атомики.
                                        Запись идёт или в память (в т.ч. в LLC), или между узлами напрямую без вовлечения механизмов соблюдения когерентности.
                                        Примерно таким мог быть CELL 2.
                                          0
                                          Ммм. Я боюсь в этой схеме какой нибудь OpenMP barrier будет просто чудовищно дорогим. Вопрос в том, можно ли как нибудь без них обойтись.
                                0
                                Думаю сейчас не нужно делать очень длинный конвейер чтобы добиться высокой частоты.
                                Для in-order точно не нужно
                                  +1
                                  Современная вычислительная парадигма (фон Нейман) родилась достаточно давно, росла и развивалась (реализовывались в кремнии потенциальные возможности), сейчас она стареет: прорывных и не реализованных возможностей уже нет и идет привязывание бантиков (костылей). Скоро она умрет и вот только от ее «детей» можно ожидать нового прорыва (увеличения производительности).
                                  Собирать 100-500 ядер на одном кристалле нет особого смысла: вычислительная парадигма фон Неймана не имеет такого понятия, как второй процессор и соответственно многопроцессорность это «костыль».
                                    0
                                    data flow — именно она и будет (человеческий мозг имеет примерно такую архитектуру).
                                      0
                                      Все data flow, которые я пока видел превращались в compiler driven architecture. И у меня сложилось ощущение, что они долго не живут…
                                        0
                                        Думаю проблема будет побеждена в момент когда программирование перейдет из парадигмы «выполни вот эту последовательность действий» в парадигму «нужен результат с вот таким набором и иерархией свойств». Будет что то типа ООС (Объектно Ориентированные Свойства).
                                        compiler driven architecture — как временный костыль очень подходит, только на программу нужно посмотреть немного с другой точки зрения (сейчас пытаюсь сформулировать в виде текста статьи).
                                          0
                                          ага. вот это интересно было бы почитать :)
                                          Только лучше не лонг рид :)
                                            0
                                            лонг рид — если это про размер текста, то спешу огорчить. Описание распределенного процессора занимает на порядок больший объем чем описание коммуникационной системы (110 страниц рукописного текста). Причешу вопросы коммуникаций и тогда за процессор возьмусь. Думаю будет поток мыслей под названием «Цифровое бессмертие: Вычислительный объем» и как результат минус 15-20 кармы ))))
                                              0

                                              Давайте помогу с написанием. У меня более или менее сносно получается формулировать мысли :)

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

                                            Но я сомневаюсь что скоро. Сперва функциональщина и тру-ООП (симула, ерланг, частично то что сейчас называют АОП) должно вытеснить императивное сишное-ООП
                                        0
                                        Какие реальные задачи Вы собираетесь выполнять на подобной архитектуре? Для однопоточных задач все равно будут использовать быстрые CPU, для многопоточных — GPU (которая SIMD, поэтому при прочих равных будет мощнее, чем независимые ядра). И как под нее программировать?
                                        0
                                        Нужно сломать слишком много стен в головах людей (ну или об головы).
                                        Думаю основной прогресс начнется тогда когда будут получены две технологии.
                                        1. Смогут разносить вычисления на разные кристаллы (без потери производительности — вы обещали прочитать, но вопросов или рецензии нет).
                                        2. Смогут победить последовательный образ мышления программиста или изменят парадигму программирования.
                                          0
                                          Ответил в личку. Давайте там продолжим на эту тему.
                                          Насчет наших последовательных мозгов — да Бабаян все время мне эту мысль задвигал :)
                                          +1
                                          Тут TSMC не согласна, что закон Мура при смерти.

                                          Дизайнеры куда больше озабочены оптимизацией, чем инновациями. Соответственно, мы будем видеть все меньше новшеств на кристалле CPU или GPGPU.

                                          Опять же в статье по ссылке, обратите внимание на все эти многослойные вещи, когда на одном кристалле и слои памяти, и слои вычислителей. Мне кажется, одна из тенденций, о которой можно упомянуть — это near-data computing. Эти слоеные пироги на кристалле позволяют не тягать данные через бутылочное горлышко интерфейса ОП и кэши.
                                            0
                                            Ну еще бы TSMC согласилась с этим. Эпоха перманентынх апгрейдов закончится и ее бизнес похудеет изрядно. Только ыот физические барьеры все сложнее преодолевать.
                                            А насчет near data — каков размер такой памяти?
                                              0
                                              А насчет near data — каков размер такой памяти?

                                              Это общее название подхода, а не технологии памяти, поэтому размер варьируется в широких пределах в зависимости от реализации.
                                              Примеров приведу несколько, во-первых, упомянутая вами HBM. Такую штуку сейчас добавляют в некоторые промышленные FPGA Xilinx и Altera/Intel. Объём HBM — 16 ГБ, пропускная способность — 460 ГБ/с. Т.е. плисина имеет быструю и ёмкую оперативу под рукой.
                                              Второй вариант, когда в качестве памяти выступает non-volatile memory, например Flash, а вычислители совмещаются с контроллерами Flash и реализуются например на FPGA, тогда объём памяти исчисляется терабайтами (см. проект Blue DBM). Это уже не слоёный пирог, но тоже near-data computing.
                                            +1
                                            «По ту сторону закона Мура» будет ровно то, что сейчас творится на рынке мобильных процессоров, которые и радо бы загнулись уже, но неадекватный спрос порождает такое же предложение.
                                            Поясню точнее — нужно больше производственной мощности, меньше тепловыделения/энергопотребления и самое важное — максимально оптимизированное ПО для этих задач.
                                            Я часто слышу истории про геймдейвов, когда им не хватает оперативки и решение " а давайте добавим ещё в требования". Когда системы упрутся в потолок (условно, скорее всего такого не будет никогда) придётся заниматься оптимизацией потребляемых ресурсов; вырезанием ненужных библиотек и краеугольным камнем станет поддержка многопоточности/распараллеливания процессов (если верить неким слухам, то скоро AMD сможет представить 4 потока на 1 ядро).
                                            Как было сказано, самое правильное решение — уменьшение рабочей частоты с сохранением производительности. Чем это можно добится? Как минимум задействовав несколько целевых ядер (как в мобильных телефонах), которые будут отвечать за свою узкую задачу. Или сделать реконфигурируемую систему — некий гибрид FPGA-CPU, с гибкостью первого и производительностью второго.
                                            Чего это позволит добится? Ну как минимум уменьшение энергопотребления (опять таки в телефонах это самая первая задача). Как максимум… Никто не задумывался, почему есть 32-х слойные памяти и нет 2-х слойных процессоров? потому что теплоотвод не позволяет. Если же получится уменьшить теплогенерацию, то почему бы не «наслоить» одно ядро на второе (тут снова Мур будет в силе) или ядро на память или… В общем перспектив очень много.
                                              0
                                              Да не только AMD думает про HT 4. Для каких то прилаг (где латентности нужно прятать) это помогает даже. Для HPC как правило HT отключают. Кста, подумал тут что это одна из тех фишек которые приближают СPU к GPU. Я как раз сейчас дкмаю про этот Fusion. Дойдут руки — напишу
                                                +1
                                                АМД планировала ХТ-4 в зен3 (этот год) но перенесла на зен4(следующий год).
                                                Однако учитывая рад других слухов мы можем получить зен3+ и зен4 перееедет уже на 2022.

                                                Так что «скоро» — относительно.

                                                Но к 2022 нас ждут удивительные открытия АРМ в десктопах, а возможно даже первые ласточки РИСК5.

                                                Вообще у нас уже есть ХТ-8 в ИБМ процессорах ПАВЕР. И в этом году выходит Павер10. Все идет к тому что либо Павер умрет, либо они очень резко изменятся.
                                                  0
                                                  Интел не отстанет. :) HT — это попытка прятать лаетнтности почти по той же схеме, по какой ее прячут GPGPU. В каком то смысле это шаг в правильном направлении. Только вот почти все HPC, которое я вижу ее отключает…

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

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