Почему не гибридный выход из строя, массово параллельный?

Question

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

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

Что не так с гибридной моделью, где каждый ПК поставляется с одним или двумя «дорогими» суперскалярными вышедшими из строя ядрами и 32 или 64 «дешевыми» ядрами, но с тем же набором команд, что и у дорогих ядер и, возможно, на тот же кусок кремния? Операционная система будет знать об этой асимметрии и будет планировать неупорядоченные ядра в первую очередь с потоками с наивысшим приоритетом. Эта расстановка приоритетов может быть даже явно выставлена ​​программисту через OS API, но программист не будет вынужден заботиться о различии, если он / она не хочет контролировать детали планирования.

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

Answer 1

@ aikigaeshi спасибо, что упомянули мою статью. Я студент Йельского Патта и фактически первый автор статьи, озаглавленной ускоряющиеся критические секции. Мы придумали эту идею после многих исследований. На самом деле, я недавно выступил с докладом на отраслевой конференции по этому поводу. Вот мой взгляд после изучения в течение нескольких лет:

@ dsimcha, вопрос должен быть разбит на две части для хорошего анализа.

1. Нужна ли нам возможность запускать какой-то код быстрее остальных? Затем этот вопрос приводит к более простому вопросу: является ли некоторый код более критичным, чем остальные. Я определил критический код как любой код, для которого содержимое потоков. Когда поток борется за кусок кода, чтобы завершить выполнение, код, который ожидает поток, явно становится более критичным, потому что ускорение этого кода не только ускоряет поток, выполняющий код в настоящее время, но также ускоряет поток, ожидающий текущий поток закончить исполнение. Однопоточные ядра - отличные примеры, когда все потоки ожидают завершения одного потока. Критические секции - это еще один пример, когда все потоки, желающие войти в критическую секцию, должны ждать, пока любая предыдущая нить завершит критическую секцию. Выполнение такого критического кода быстрее, безусловно, является хорошей идеей, потому что, когда за код борются, он становится более критичным к производительности. Существуют и другие сценарии, такие как сокращение, дисбаланс нагрузки, проблемы с потоком заемщика, которые могут привести к критическому коду, и выполнение этого кода может помочь быстрее. Поэтому я решительно заключаю, что существует необходимость в том, что я называю асимметрией производительности.

2. Как мы можем обеспечить асимметрию производительности? Объединение больших и малых ядер в одной системе является одним из способов обеспечения этой асимметрии. Хотя это архитектура, которую я исследовал, следует провести много исследований, чтобы изучить другие способы обеспечения асимметрии. Масштабирование частоты, расстановка приоритетов запросов памяти от критических потоков, предоставление большего объема ресурсов критическому потоку - все возможные способы обеспечения асимметрии. Возвращаясь к архитектуре большого и малого ядра: мое исследование показало, что в большинстве случаев это выполнимо, поскольку накладные расходы по переносу задач на большое ядро ​​были компенсированы преимуществами, которые вы получили от ускорения критического кода. Я бы пропустил детали, но есть некоторые очень интересные компромиссы. Я призываю вас прочитать мои статьи или докторскую диссертацию для деталей.

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

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

Answer 2

W00t, что за отличный вопрос = D

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

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

Следующий хороший эксперимент. Попробуйте написать приложение, которое сильно использует процессор. Затем с помощью какого-либо другого приложения, такого как atsar, получите статистику пользовательского и системного времени. Теперь измените количество одновременных потоков и посмотрите, что происходит с системным временем. Графики данных могут помочь определить рост (не так =) бесполезной обработки.

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

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

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

Answer 3

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

Answer 4

Ваша идея очень похожа на планы AMD по Fusion.AMD интегрирует графический процессор в процессор.Прямо сейчас, это для их более медленных проектов с низким энергопотреблением, предназначенных для замены Intel Atom, но они переносят его в чипы для ноутбуков.

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

Эти блоки GPU не используют один и тот же набор команд, но учтите, что с встроенным в CPU графическим процессором сам компилятор может свободно использоватьэто так же, как если бы это был любой другой тип векторного типа инструкций MMX / SSE.

Возможный пример - цикл, выполняющий математические вычисления для вектора C ++ чисел с плавающей запятой.Компилятор с оптимизацией, установленной на AMD-Wh независимо, может написать машинный код для закрепления векторной памяти, вызвать программу GPU и дождаться результатов.

Это немного сложнее, чем то, что уже делает оптимизация автоматической векторизации для SSE: они загружают данные в регистр XMM, выполняют операцию и разделяют данные обратно из регистра.

Answer 5

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

http://scholar.google.com/scholar?q=heterogeneous+architectures&hl=en&btnG=Search&as_sdt=1%2C5&as_sdtp=on

Что не так с гибридной моделью, в которой каждый компьютер поставляется с одним или двумя «дорогими» суперскалярвышедшие из строя ядра и 32 или 64 «дешевых» ядра, но с той же инструкцией, что и у дорогих ядер, и, возможно, на том же куске кремния?

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