Как вы пользуетесь Multicore?

Question

Как человеку из мира HPC , пришедшему из мира корпоративной веб-разработки, мне всегда любопытно посмотреть, как разработчики в "реальном мире" используют преимущества параллельных вычислений. Это гораздо более актуально сейчас, когда все чипы собираются многоядерными , и это будет еще более актуально, когда на чипе тысячи ядер вместо нескольких.

Мои вопросы:

1. Как это влияет на ваш программный план?
2. Меня особенно интересуют реальные истории о том, как многоядерный процессор влияет на разные программные области, поэтому укажите в своем ответе, какие разработки вы делаете ( например, на стороне сервера, клиентские приложения, научные вычисления, и т.д.).
3. Что вы делаете со своим существующим кодом, чтобы использовать преимущества многоядерных машин, и с какими проблемами вы столкнулись? Используете ли вы OpenMP , Erlang , Haskell , CUDA , TBB , UPC или что-то еще?
4. Что вы планируете делать, когда уровни параллелизма продолжают расти, и как вы будете иметь дело с сотнями или тысячами ядер?
5. Если ваш домен не легко извлекает выгоду из параллельных вычислений, то объясните, почему это тоже интересно.

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

Обновление: Если вы ответите # 5, укажите, считаете ли вы, что все изменится, если будет больше ядер (100, 1000 и т. Д.), Чем вы можете обеспечить доступной пропускной способностью памяти (см. Как как пропускная способность становится все меньше и меньше на ядро). Вы все еще можете использовать оставшиеся ядра для своего приложения?

Answer 1

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

1. Multicore влияет на меня совсем не кроме как проблема исследования для компиляторов для поддержки других приложений. Но эти проблемы связаны, прежде всего, с системой времени выполнения, а не с компилятором.
2. При больших трудностях и затратах Дейв Вортман в 1990 году показал, что вы можете распараллелить компилятор, чтобы поддерживать занятость четырех процессоров . Никто из тех, кого я знаю, никогда не повторял эксперимент. Большинство компиляторов достаточно быстрые для запуска однопоточных. И гораздо проще запустить ваш последовательный компилятор параллельно с несколькими различными исходными файлами, чем сделать сам ваш компилятор параллельным. Для фильтрации спама обучение является по своей сути последовательным процессом . И даже старая машина может выучить сотни сообщений в секунду, так что даже большой корпус может быть изучен менее чем за минуту. Опять же, тренировка достаточно быстрая .
3. Единственный важный способ использования параллельных машин - это с использованием параллельного make . Это большое преимущество, и большие сборки легко распараллелить . Make делает почти всю работу автоматически. Единственное, что я могу вспомнить, - это использовать параллелизм для определения времени выполнения длинного студенческого кода, обрабатывая его на куче лабораторных машин, что я мог бы сделать с чистой совестью, потому что я только разбивал одно ядро ​​на машине, поэтому использовал только 1 / 4 ресурсов процессора. О, и я написал скрипт Lua, который будет использовать все 4 ядра при копировании файлов MP3 с помощью lame. Над этим сценарием было много работы, чтобы разобраться.
4. Я буду игнорировать десятки, сотни и тысячи ядер . Первый раз, когда мне сказали, что «параллельные машины приходят, вы должны подготовиться», был 1984 год. Тогда это было верно, и сегодня верно, что параллельное программирование - это область для высококвалифицированных специалистов . Единственное, что изменилось, это то, что сегодня производители заставляют нас платить за параллельное оборудование , хотим мы этого или нет. Но только потому, что аппаратное обеспечение оплачено, не означает, что его можно использовать бесплатно. Модели программирования ужасны, и заставить модель потока / мьютекса работать , не говоря уже о том, чтобы работать хорошо, дорогая работа, даже если оборудование бесплатно. Я ожидаю, что большинство программистов будут игнорировать параллелизм и спокойно заниматься своими делами. Когда опытный специалист придет с параллельной маркой или отличной компьютерной игрой, я буду тихо аплодировать и использовать их усилия. Если мне нужна производительность для моих собственных приложений, я сконцентрируюсь на сокращении выделения памяти и игнорирую параллелизм.
5. Параллелизм действительно сложно. Большинство доменов трудно распараллелить. Широко многократно используемое исключение, такое как параллельное изготовление, вызывает много радости.

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

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

Answer 2

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

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

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

Так что для меня многоядерный процесс сводится к следующим пунктам:

• У моих серверов меньше «процессоров», в то время как у каждого из них больше ядер (для меня это не большая разница)
• Такое же количество процессоров может выдерживать большее количество одновременных пользователей
• Когда узкое место в производительности кажется , а не результатом загрузки ЦП на 100%, это указывает на то, что я где-то плохо синхронизируюсь.

Answer 3

Я работаю в области медицинской визуализации и обработки изображений.

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

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

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

Ключ для нас заключается в том, чтобы не допустить узких мест параллелизма. Мы разрабатываем в .NET, что означает, что обновления пользовательского интерфейса должны выполняться из вызова Invoke для пользовательского интерфейса, чтобы основной поток обновлял пользовательский интерфейс.

Может быть, я ленивый, но на самом деле, я не хочу тратить слишком много времени на выяснение многих вещей, когда речь идет о распараллеливании таких вещей, как инверсия матриц и тому подобное. Многие действительно умные люди потратили много времени на то, чтобы сделать это быстро, как закись, и я просто хочу взять то, что они сделали, и назвать это. Что-то вроде CUDA имеет интересный интерфейс для обработки изображений (конечно, именно для этого он и предназначен), но он все еще слишком незрелый для такого вида программирования по принципу «включай и работай». Если у меня или другого разработчика будет много свободного времени, мы можем попробовать. Поэтому вместо этого мы просто воспользуемся OpenMP, чтобы ускорить нашу обработку (и это определенно входит в план развития на следующие несколько месяцев).

Answer 4

1. На данный момент - если честно, это мало на что влияет. Я больше на стадии подготовки, изучаю технологии и возможности языка, которые делают это возможным.
2. У меня нет одного конкретного домена, но я сталкивался с такими областями, как математика (где многоядерность необходима), сортировка / поиск данных (где полезно разделение и завоевание многоядерности) и требования к нескольким компьютерам (например, требование, чтобы вычислительная мощность резервной станции была использована для чего-либо).
3. Это зависит от того, на каком языке я работаю. Очевидно, что в C # мои руки связаны с еще не готовой реализацией Parallel Extensions, которая, похоже, повышает производительность, пока вы не начнете сравнивать те же алгоритмы с OpenMP (возможно, это не совсем справедливое сравнение). Так что в .NET это будет легкая поездка с некоторыми for & rarr; Parallel.For рефакторинги и т. П.
   Где все получается на самом деле интересно с C ++, потому что производительность, которую можно выжать из таких вещей, как OpenMP, ошеломляет по сравнению с .NET. Фактически, OpenMP меня сильно удивил, потому что я не ожидал, что он будет работать так эффективно. Ну, я думаю, у его разработчиков было достаточно времени, чтобы отшлифовать его. Мне также нравится, что он доступен в Visual Studio "из коробки", в отличие от TBB, за который вы должны заплатить.
   Что касается MPI, я использую PureMPI.net для небольших домашних проектов (у меня есть локальная сеть) дурачиться с вычислениями, которые одна машина не может принять. Я никогда не использовал MPI в коммерческих целях, но я знаю, что в MKL есть некоторые функции, оптимизированные для MPI, которые могут быть интересны для тех, кто в них нуждается.
4. Я планирую делать «легкомысленные вычисления», то есть использовать дополнительные ядра для предварительного вычисления результатов, которые могут быть или не быть необходимыми - конечно, с учетом оперативной памяти. Я также намереваюсь углубиться в дорогостоящие алгоритмы и подходы, с которыми машины большинства конечных пользователей сейчас не могут справиться.
5. Что касается доменов, не пользующихся параллелизацией ... ну, всегда можно что-то найти. Одна вещь, которой я * обеспокоен, - это приличная поддержка в .NET, хотя, к сожалению, я оставил надежду, что скорости, подобные C ++, могут быть достигнуты.

Answer 5

Пока что не более, чем более эффективная компиляция с make:

gmake -j

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

Answer 6

Я занимаюсь разработкой веб-приложений ASP.NET. В моем коде практически нет возможности использовать многоядерный процессор, однако IIS уже хорошо масштабируется для нескольких ядер / процессоров, создавая несколько рабочих потоков / процессов под нагрузкой.

Answer 7

У нас большой успех в параллелизме задач в .NET 4 с использованием F #. Наши клиенты требуют многоядерной поддержки, потому что они не хотят, чтобы их n-1 ядра простаивали!

Answer 8

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

Answer 9

Я сказал кое-что из этого в ответ на другой вопрос (надеюсь, это нормально!): Существует концепция / методология, называемая Поточное программирование (FBP), которая существует уже более 30 лет. и используется для обработки большей части пакетной обработки в крупном канадском банке. Он имеет реализации на основе потоков в Java и C #, хотя более ранние реализации были на основе волокон (C ++ и мэйнфрейм Assembler). Большинство подходов к проблеме использования преимуществ многоядерности включают попытки взять обычную однопоточную программу и выяснить, какие части могут выполняться параллельно. FBP использует другой подход: приложение с самого начала разработано с точки зрения множества компонентов «черного ящика», работающих асинхронно (представьте себе производственную линию сборки). Поскольку интерфейс между компонентами представляет собой потоки данных, FBP практически не зависит от языка и поэтому поддерживает приложения на разных языках и языки, специфичные для предметной области. Было обнаружено, что приложения, написанные таким образом, гораздо более удобны в обслуживании, чем обычные однопоточные приложения, и зачастую занимают меньше времени, даже на одноядерных компьютерах.

Answer 10

Мы создаем VivaMP анализатор кода для обнаружения ошибок в параллельных программах OpenMP.

VivaMP - это линейный статический анализатор кода C / C ++, предназначенный для индикации ошибок в параллельных программах на основе технологии OpenMP. Статический анализатор VivaMP значительно расширяет возможности существующих компиляторов, диагностирует любой параллельный код, который имеет некоторые ошибки или является возможным источником таких ошибок. Анализатор интегрирован в среду разработки VisualStudio2005 / 2008.

VivaMP - инструмент для OpenMP

32 ловушки OpenMP для разработчиков на C ++