Топология седьмого поколения процессоров Intel Core (бывшее кодовое название Kaby Lake), которые появятся в продаже в конце 2016 года. Фото: Intel
Группа исследователей из Университета Северной Каролины и компании Intel разработали технологию аппаратного ускорения CAF (Core to Core Communication Acceleration Framework), которая способна значительно ускорить обмен данными между ядрами процессора. Устранив это бутылочное горлышко, производители наконец-то смогут наращивать количество ядер в ЦП без экспоненциального роста служебного трафика между ними.
В выполнении параллельных программ самое сложное — обеспечить правильную координацию ресурсов, разделяемых между процессами. На современных процессорах синхронизация параллельного взаимодействия между ядрами осуществляется двумя методами: c помощью передачи сообщений и через разделяемую память.
В первом случае на каждом ядре запускается однопоточный процесс, который обменивается данными с другими процессами, работающими на других ядрах.
При взаимодействии через разделяемую память на каждом процессоре мультипроцессорной системы запускается поток исполнения, который принадлежит одному процессу. Потоки обмениваются данными через общий для данного процесса участок памяти. Количество потоков соответствует количеству процессоров.
Исследователи предлагают реализовать такую координацию ресурсов на аппаратном уровне. В реферате подготовленной научной работы они отмечают, что «взаимодействие через разделяемую память по своей природе включает инвалидации для соблюдения когерентности и промахи в кэше, из-за чего сильно возрастают накладные расходы и возникает большое количество [лишнего] сетевого трафика».
Многие важные задачи требуют большого обмена трафиком между ядрами, так что значительное увеличение накладных расходов сильно бьёт по производительности. Это касается и производительности вычислительного конвейера, который широко используется в программных решениях для эксплуатации параллелизма на уровне команд.
Аппаратное ускорение координирует работу ядер при параллельных вычислениях. Предлагаемая аппаратная координация ядер гораздо эффективнее, чем любые методы программной синхронизации, которые используются сейчас.
«Такой подход, который мы назвали фреймворком для ускорения коммуникации между ядрами (CAF), улучшает скорость обмена данными в 2-12 раз, — заявил Ян Солихин (Yan Solihin), профессор электротехники и вычислительной техники в Университете Северной Каролины и соавтор научной работы. — Другими словами, скорость выполнения — от начала до конца — как минимум вдвое больше».
В подготовленной научной работе авторы осуществили анализ оверхеда (излишнего сетевого трафика между ядрами), который возникает при синхронизации параллельных вычислений существующими программными методами. И предложили альтернативное решение.
Ключевой элемент нового фреймворка — аппаратный модуль для управления очередью Queue Management Device (QMD). Он способен выполнять простые вычислительные функции и аппаратно подключается к коммуникационной подсистеме, то есть к NoC (сеть на кристалле — мини-интернету внутри процессора).
Иллюстрация из статьи «Сеть на кристалле — мини-интернет внутри процессора»
Модуль QMD берёт на себя задачу управления очередью и синхронизации параллельного взаимодействия ядер, без каких-либо дополнительных программных инструкций на ядрах ЦП. Это как аппаратный маршрутизатор в сети.
Перспективная разработка важна в свете постоянного увеличения ядер на современных процессорах. Это вполне естественный процесс, поскольку рост тактовой частоты практически остановился в силу естественных физических ограничений. У производителей не остаётся другого выхода, кроме распараллеливания вычислений.
В таких условиях синхронизация параллельного взаимодействия между ядрами становится тем бутылочным горлышком, которое ограничивает производительность системы. При условии эффективной маршрутизации трафика между процессорными ядрами можно продолжить масштабирование архитектуры ЦП и создавать процессоры с десятками и сотнями ядер с почти линейным масштабированием производительности. Эффективная маршрутизация трафика между ядрами — ключевая технология, которая необходима для дальнейшего масштабирования многоядерной архитектуры ЦП.
Кроме многократного ускорения обмена данными между ядрами при синхронизации параллельных вычислений, модуль QMD может быть полезен при агрегировании данных с многочисленных ядер. Исследователи полагают, что он ускорит обработку некоторых базовых вычислительных операций до 15%.
Научная работа "CAF: Core to Core Communication Acceleration Framework" будет представлена на 25-й конференции по параллельным архитектурам и методам компиляции PACT '16, которая состоится 11-15 сентября 2016 года в Хайфе (Израиль).
Авторы изобретения — Ипэн Ван (Yipeng Wang, Университет Северной Каролины), Жэнь Ван (Ren Wang), Эндрю Хендрич (Andrew Herdrich) и Джеймс Цай (James Tsai) (все — Intel Corp.), а также ведущий автор научной работы — вышеупомянутый Ян Солихин (Yan Solihin) из Университета Северной Каролины и Национального научного фонда США.
Статья вошла в сборник докладов Proceedings of the 2016 International Conference on Parallel Architectures and Compilation, стр. 351-362, doi:10.1145/2967938.2967954. Сборник докладов, вероятно, раздадут участникам конференции и опубликуют в интернете.
Комментарии (51)
IvanT
08.09.2016 13:49+1Если бы не заголовок и контент статьи подумал бы, что это спутниковый снимок города. Дома, улицы, парки, даже парковки с авто в правой верхней части видны.
roboq6
08.09.2016 13:55У меня помнится в детстве была мысль «А что если взять схему какой-нибудь микросхемы и по аналогии с ней построить город?»
Kreastr
08.09.2016 13:59+3Научная работа «CAF: Core to Core Communication Acceleration Framework» будет представлена на 25-й конференции по параллельным архитектурам и методам компиляции PACT '16, которая состоится 11-15 сентября 2016 года в Хайфе (Израиль).
Статья вошла в сборник докладов Proceedings of the 2016 International Conference on Parallel Architectures and Compilation, стр. 351-362, doi:10.1145/2967938.2967954. Сборник докладов, вероятно, раздадут участникам конференции и опубликуют в интернете.
Конференционная статья не является надежным peer-reviewed источником. Стоит добавить в заголовок что-нибудь вроде "… предложили способ, который возможно ускорит..."
QuaziKing
08.09.2016 14:11+3«Ну слава богу, можно продолжать писать говно-код». (с) Не помню.
roboq6
08.09.2016 14:17Что лучше экономически, клепать слабые процессоры, заставляя программистов оптимизировать и вылизывать свой код, или же выпускать мощные процессоры, делая тщательную оптимизацию (под скорость) в большинстве случаев ненужной? С точки зрения рационального использования труда лучше второй вариант, ибо во втором варианте затрачивается меньше человеческого труда при достижении того же результата.
webkumo
08.09.2016 15:12+1Не, всё фигня. Проблема с количеством кадров на самом деле. Просто негде взять достаточное количество хороших программистов, чтобы была возможность пойти по первому пути.
roboq6
08.09.2016 15:41Если недостаток хороших кадров, то значит мало платят. А раз мало платят, то значит не так то уж они и нужны. А нужны они не так то уж сильно в силу второго варианта, зачем лишний раз нанимать гуру если с задачей справится кто-нибудь попроще?
david52522
08.09.2016 15:20А потом тебе говорят нечто в духе: У наших заказчиков рабочая конфигурация — это одноядерный Celeron 1.2 со встроенной видеокартой, полгига оперативки, винт на 40 гиг, и им нужно что бы некая процедура, которая даже на i7 с выносом части расчетов на GPU считается за 30-40 секунд у них считалась за 5. Иди, проявляй чудеса оптимизации, ты же можешь, тыжпрограммист, и вообще — тебе премия нужна или нет?
roboq6
08.09.2016 15:49Мне кажется в этом случае имеет смысл сделать градацию для стимуляции разработчика, чем ближе скорость к некому идеалу тем больше надбавка (или меньше пенальти), причём надбавка растёт (или пенальти уменьшается) экспоненциально. С одной стороны такой подход не заставляет разработчика достигать невозможного, но с другой стороны стимулирует как можно ближе подойти к этому самому невозможному.
qw1
09.09.2016 14:55Как определить предел? Один программист скажет: я тут уже всё перепробовал, все микро-оптимизации, профилировал загрузку конвеера процессора и кеш-промахи. Больше из этого не выжмешь. А другой программист возьмёт и заменит сортировку пузырьком на другую.
roboq6
09.09.2016 15:43Как определить предел?
А никак. Но собственно в этом и нет нужды при данном методе. Главное чтобы человек старался.qw1
09.09.2016 16:44То есть, платим не за результат, а за видимость деятельности.
roboq6
10.09.2016 05:40Нет, почему же, платим именно за результат. Если у нас есть несколько конкурирующих программистов, то больше денег получит тот, кто получит лучше результат.
qw1
10.09.2016 14:22Если программисты будут делать разные программы, то напрямую сравнить нельзя.
Значит, будет доля субъективизма: какая программа больше понравилась, ту и премировали. Но тут надо быть очень хорошим пользователем, т.к. можно награждать любимый «жанр» (для примера, я хорошо разбираюсь в текстовых редакторах и тот, который меня устроил, я наградил, а в музыкальных плеерах не разбираюсь, и каким бы плеер не был хорошим, мне этого не понять).
Если несколько соревнуются в написании одного и того же, это умножение расходов.
И ещё два момента:
1. Награждать придётся всю команду программистов, за конечный продукт. Оценить результат по компоненту сложно, т.к. зависит от условий, куда его поставят. Это размывает ответственность.
2. За бесплатно писать никто не будет, даже кривой код. Придётся платить среднее по рынку всем, и приз делать существенным (чтобы был смысл стараться стать победителем).А значит, г-нокодеры как писали г-но, так и будут его писать — платят же…roboq6
10.09.2016 14:59И что, всё вышеописанное должно меня как-то убедить что правильней требовать от программиста(ов) кровь из носу уложиться в некий произвольно заданный предел (который фиг знает достигаем или нет), как описал david52522?
Delics
08.09.2016 16:40+2Хуже всего другое:
когда подобная немыслимая оптимизация всё-таки будет проведена, никто и не поймет, насколько это было сложно. Воспримут как должное.david52522
08.09.2016 16:46+1Ну почему же? просто если ты это НЕ сделаешь — то останешься без премии, ведь тыжпрограммист и вообще «удругихвсеработает».
sumanai
08.09.2016 16:49+2Лучше запускать оптимизированный код на быстрых процессорах.
roboq6
08.09.2016 17:07Далеко не всегда. Чем сильней процессор — тем меньше будет экономический смысл в оптимизации кода под скорость (за исключением программ которые должны выжимать из процессора всю производительность до последней капли, вроде майнеров). Скажем если мы код оптимизируем, то программа будет выполняться за 1 наносекунду, а если нет — за 100 наносекунд. Овчинка выделки не стоит, это бесполезный префекционизм.
sumanai
08.09.2016 17:10+1Вроде так, но современный софт не радует, похоже, именно из-за этих мыслей.
roboq6
08.09.2016 17:16-1Ну раз не радует, то видимо Вы страдаете бесполезным префекционизмом. Если это так, то это проблема Ваша, причём психологическая, а не техническая.
sumanai
08.09.2016 19:11+2Не радует- это просто моё оценочное суждение. Не радует потому, что современный софт на современных ПК работает медленнее, чем старый софт на старых ПК. Не вижу в моих мыслях ни бесполезного перфекционизма, ни каких либо психологических проблем.
webkumo
08.09.2016 20:37А вы точно проводите адекватное сравнение? Не сравниваете, например vim с Idea?
sumanai
08.09.2016 22:14Нет конечно же.
Даже каталоги в проводнике в старых ОС щёлкаются быстрее.springimport
08.09.2016 22:32Не забывайте что помимо неоптимизированного кода есть еще функционал, которого в старых ОС было меньше.
sumanai
08.09.2016 22:53+1Или больше. WInXP запоминает расположение и размер всех окон индивидуально, начиная с Vista, эту возможность удалили.
webkumo
09.09.2016 09:53Или меньше — в Vista появилось «Aero». Не скажу, что мне этот функционал прям необходим, но то, что он требует на себя отдельных ресурсов — факт.
sumanai
08.09.2016 16:51То есть для использования этой оптимизации нужно специальным образом писать программы и компилировать их компилятором (когда там эти фишки до GCC докатятся)?
kahi4
08.09.2016 16:59Нет. Это одна из внутренних оптимизаций процессора, напрямую программисту не доступная, как и конвейер, например. Косвенно же это проявится при написании многопоточных приложений и прочих OpenMP, OpenCL и подобного, нацеленного на использование многоядерности.
old_bear
09.09.2016 23:51>>одна из внутренних оптимизаций процессора, напрямую программисту не доступная, как и конвейер, например
А как же, например, постоянные мысли про грамотное распределение кода по портам, которыми перманентно озабочены программирующие на asm-е или всякое там выравнивание на длину строки кэша и прочая борьба с конфликтами кэширования, которая и в более высокоуровневых языках бывает (выше asm-а, я имею ввиду)? На мой взгляд, это как раз и называется «специальным образом писать программы».qw1
10.09.2016 14:28Я думаю, тут будет как с введением второго набора исполнительных юнитов в конвеер. Любая случайно выбранная программа получает от этой оптимизации ускорение в 1.3-1.5 раз, но если мы хотим выжать теоретический максимум 2.0, нужна поддержка компилятора.
amartology
На фотографии — топология, а не микроархитектура. Микроархитектура — это вообще не о том.
dovzh
— Добро пожаловать в Общество зануд! Возьмите себе стул.
— Вообще-то, у этого, как вы выразились, стула, нет спинки, так, что технически это табуретка.
— Похоже, у нас новый председатель!
roboq6
А в чём разница между топологией и микроархитектурой?
kahi4
Микроархитектура — это набор внешних процесорных команд, доступных пользователю (программисту), ну и связанные с ним — какие есть регистры, где какие флаги и прочее, она же внутри транслируется на команды физической архитектуры (или микроархитектуры уровнем ниже), которая уже исполняется непосредственно на кристалле. Т.е. микроархитектура у intel — CISC, однако внутри, там, где это уже не доступно программисту в явном виде, RISC, а микроархитектура представляет из себя последовательность RISC-команд, соответствующих одной CISC-команде, вызванной программистом.
Грубо говоря, виртуальная машина нулевого уровня (очень очень грубо говоря словами Таненбаума).
Топология же — не более чем размещение на кристалле отдельных элементов — шин, ядер, памяти и прочего, что там есть (если точнее — способ размещения).
amartology
Не совсем так. То, что доступно программисту — это как раз архитектура, а ее физическая реализация — микроархитектура. То есть у Intel архитектура — CISC x86, а внутри нее микроархитектура RICS.
А у ARM соответственно есть архитектура, например ARM v8, которая может быть реализована, например, как микроархитектуры Cortex A57 или Cortex A53.
gxcreator
Это называется набор инструкций(ARMv8/x86) и собственно архитектура(Haswell/A57/Kryo)
beeruser
Вы всё перепутали.
Архитектура не определяет детали реализации.
Она описана в документе, называемом Architecture Reference Manual.
Например в случае ARM:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.set.architecture/index.html
Набор инструкций это лишь часть его.
А микроархитектура это как раз и есть конкретная _реализация_ архитектуры.
https://ru.wikipedia.org/wiki/Микроархитектура
kahi4
Ох, перепуталось в голове. Микрокод — доступные методы программисту, транслируемые в нативные. А микроархитектура — да. Спасибо за правку.
kosmos89
У нас это (x86, ARM) называли программистской архитектурой.
amartology
А топология — это физическое размещение элементов на кристалле.
P.S. Кстати, топология по-английски — layout, а то, что они называют topology — это блок-схема по-нашему.
RomanArzumanyan
Грубо говоря, топология — взаимное расположение элементов (например, топология сети «звезда»). Кристаллы двух процессоров с одной микроархитектурой могут иметь разную топологию. Например, 4х-ядерный настольный Core и 2х-ядерный мобильный Pentium в рамках одного поколения.
amartology
Нененене, топология сети и топология микросхемы — это вообще не взаимосвязанные вещи. Топология сети по-английски topology, а топология микросхемы — layout, но в России/СССР их почему-то стали называть одним и тем же словом.
RomanArzumanyan
Я и не утверждаю, что это одно и тоже. Привёл простую топологию сети в качестве примера — не приходит в голову пример простой топологии центрального процессора.
amartology
Потому что топология даже самого простого центрального процессора — это вот такая же вот картинка из сотен тысяч транзисторов и миллионов кусков металла, простой пример там привести совсем нельзя.
Хотяяя
https://en.wikipedia.org/wiki/Intel_8086#/media/File:Intel_8086_CPU_Die.JPG
Вот простая топология: Intel8086, всего-то 29 тысяч транзисторов)