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

Ответ 1

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

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

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

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

Ответ 2

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

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

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

Итак, для меня многоядерность в основном сводится к этим элементам:

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

Ответ 3

• На данный момент - это не влияет на это, если честно. Я больше на стадии подготовки, изучая технологии и особенности языка, которые делают это возможным.
• У меня нет одного конкретного домена, но я столкнулся с такими областями, как математика (где важна многоядерность), сортировка/поиск данных (где разделение и покорение на многоядерных процессорах полезно) и требования к нескольким компьютерам (например, требование о том, что для чего-то используется мощность обработки резервной станции).
• Это зависит от того, на каком языке я работаю. Очевидно, что в С# мои руки связаны с еще не готовой реализацией Parallel Extensions, которая, похоже, повышает производительность, пока вы не начнете сравнивать одни и те же алгоритмы с OpenMP (возможно, это не справедливое сравнение). Итак, на .NET это будет легкая поездка с некоторыми for → Parallel.For рефакторинги и т.д.
  Где вещи становятся действительно интересными с С++, потому что производительность, которую вы можете выжать из таких вещей, как OpenMP, ошеломляет по сравнению с .NET. Фактически, OpenMP удивил меня, потому что я не ожидал, что он будет работать так эффективно. Ну, я думаю, у его разработчиков было много времени, чтобы отполировать его. Мне также нравится, что он доступен в Visual Studio из коробки, в отличие от TBB, за которую вы должны платить.
  Что касается MPI, я использую PureMPI.net для небольших домашних проектов (у меня есть локальная сеть) обманывать с вычислениями, которые одна машина не может взять. Я никогда не использовал MPI в коммерческих целях, но я знаю, что у MKL есть некоторые оптимизированные MPI функции, которые могут быть интересны для всех, кто нуждается в них.
• Я планирую делать "легкомысленные вычисления", т.е. использовать дополнительные ядра для предвычисления результатов, которые могут потребоваться или могут не понадобиться. Разумеется, ОЗУ. Я также намерен углубиться в дорогостоящие алгоритмы и подходы, которые сейчас не могут обрабатывать большинство компьютеров конечных пользователей.
• Что касается доменов, не пользующихся параллелизацией... ну, всегда можно найти что-то. Одна вещь, о которой я говорю am, - это достойная поддержка в .NET, хотя, к сожалению, я отказался от надежды на то, что скорости, подобные С++, могут быть достигнуты.

Ответ 4

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

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

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

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

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

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

Ответ 5

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

Ответ 6

До сих пор не более, чем более эффективная компиляция с помощью make:

gmake -j

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

Ответ 7

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

Ответ 8

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

Ответ 9

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

Я также немного работаю с F #, чтобы ускорить работу с языковыми возможностями на многоуровневом уровне.

Ответ 10

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

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

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

32 OpenMP Traps для разработчиков на С++

Ответ 11

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

Ответ 12

Я считаю, что " Cycles - лучший друг инженеров".

Моя компания предоставляет коммерческий инструмент для анализа и очень большие программные системы на многих компьютерных языках. "Большой" означает 10-30 миллионов строк кода. Инструмент представляет собой набор инструментов для реинжиниринга программного обеспечения DMS (DMS для краткости).

Анализы (и даже преобразования) на таких огромных системах занять много времени: наши точки - на анализатор для C код занимает 90 часов процессора на x86-64 с 16 ГБ оперативной памяти. Инженеры хотят быстрее отвечать на запросы.

Следовательно, мы внедрили DMS в PARLANSE, параллельный язык программирования нашего собственного дизайна, предназначенный для использования мелкомасштабных многоядерных систем памяти.

Ключевыми идеями Parlanse являются: а) пусть программист выставляет parallelism, б) позволить компилятору выбрать, какую часть он может реализовать, c) переключение контекста на абсолютный минимум. Статические частичные заказы над вычислениями легко помочь достичь всех 3; Легко сказать, относительно легко измерить затраты, Легко для компилятора планировать вычисления. (Написание параллельной быстрой сортировки с этим тривиально).

К сожалению, мы сделали это в 1996 году:-( Последние несколько лет, наконец, были оправданием; Теперь я могу получить 8 основных машин в Fry за $1 тыс. и 24 основных машинах примерно по той же цене, что и небольшие автомобиль (и, вероятно, быстро упадет).

Хорошей новостью является то, что DMS сейчас довольно зрелая, и существует ряд ключевых внутренних механизмов в DMS, которые используют это, в частности целый класс анализаторов называют "атрибутными грамматиками", которые мы пишем, используя язык, специфичный для домена который НЕ является parlanse. DMS компилирует эти atrribute grammars в PARLANSE, а затем они выполняются параллельно. Наш фронт С++ end использует атрибутивные грамматики и составляет около 100K SLOC; он скомпилирован в 800K SLOC параллельного parlanse, который действительно работает надежно.

Теперь (июнь 2009), мы довольно заняты, делая DMS полезным, и не всегда хватает времени на использование parallelism Что ж. Таким образом, 90-часовые пункты - к анализу. Мы работаем над распараллеливанием этого и имеют разумную надежду на ускорение 10-20x.

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

Ответ 13

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

Это достаточно хорошо для нас.

Ответ 14

Теперь я могу отделить свою основную операционную систему от своей разработки/установки независимо от того, что мне нравится os, используя настройки виртуализации с помощью Virtual PC или VMWare.

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

Ответ 15

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

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

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

Ответ 16

Я использую и программирую на Mac. Grand Central Dispatch за победу. В обзоре Ars Technica о Snow Leopard есть много интересного, чтобы сказать о многоядерном программировании и где люди (или, по крайней мере, Apple) идут с он.

Ответ 17

Я решил использовать несколько ядер в реализации алгоритма DEFLATE. MArc Adler сделал что-то подобное в коде C с помощью PIGZ (parallel gzip). Я поставил философский эквивалент, но в библиотеке управляемого кода, в DotNetZip v1.9. Это не порт PIGZ, а аналогичная идея, реализованная самостоятельно.

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

Поскольку построение словаря требует интенсивного использования ЦП, DEFLATE является идеальным кандидатом для распараллеливания. Я применил подход Map + Reduce, где я делю входящий несжатый bytestreeam на набор меньших блоков (карта), скажем, по 64 тыс. каждый, а затем сжимаю их самостоятельно. Затем я объединяю результирующие блоки вместе (уменьшаю). Каждый блок 64k сжимается независимо, в отдельном потоке, независимо от других блоков.

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

Накладные расходы времени выполнения (cpu), связанные с управлением несколькими потоками, служебные данные памяти выполнения, связанные с буферами для каждого ада, и служебные данные данных, связанные с конкатенацией блоков. Таким образом, этот подход рассчитан только на более крупные потоки. В моих тестах, выше 512k, он может окупиться. Ниже этого лучше использовать последовательный подход.

DotNetZip поставляется как библиотека. Моя цель состояла в том, чтобы сделать все это прозрачным. Таким образом, библиотека автоматически использует дополнительные потоки, когда буфер превышает 512kb. Там ничего не нужно делать, чтобы использовать потоки. Он просто работает, и когда используются нити, он волшебным образом быстрее. Я думаю, что это разумный подход, который нужно использовать для большинства libbraries, потребляемых приложениями.

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

Ответ 18

Я работаю в С# с .Net Threads. Вы можете комбинировать объектно-ориентированную инкапсуляцию с управлением потоками.

Я прочитал несколько сообщений от Питера, которые рассказывают о новой книге Packt Publishing, и я нашел следующую статью на веб-странице публикации Packt:

http://www.packtpub.com/article/simplifying-parallelism-complexity-c-sharp

Я читал "Совместное программирование с Windows", книгу Джо Даффи. Теперь я жду "С# 2008 и 2005 Threaded Programming", книга Хиллара - http://www.amazon.com/2008-2005-Threaded- Программирование-начинающих/дп/1847197108/исх = pd_rhf_p_t_2

Я согласен с Шунди "Без серебряной пули"!

Ответ 19

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

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

Мы еще не разрабатываем DOS? Мы должны решать многоядерность или мы будем мертвы в течение многих лет.

Ответ 20

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

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

Ответ 21

• Как это влияет на вашу дорожную карту программного обеспечения?
  Это не так. Наши (как и почти все другие) приложения, связанные с бизнесом, отлично работают на одном ядре. Пока добавление большего количества ядер не значительно снижает производительность однопоточных приложений, мы счастливы

• ... реальные истории...
  Как и все остальные, параллельные сборки являются основным преимуществом, которое мы получаем. Компилятор Visual Studio 2008 С#, похоже, не использует больше одного ядра, что действительно отстойно

• Что вы делаете с существующим кодом, чтобы использовать многоядерные машины
  Мы можем изучить использование параллельных расширений .NET, если у нас когда-нибудь будет алгоритм, который можно распараллелить, но вероятность того, что это происходит на самом деле, тонкая. Наиболее вероятным ответом является то, что некоторые разработчики будут играть с ним ради интереса, но не намного больше.

• как вы будете иметь дело с сотнями или тысячами ядер?
  Голова → Песок.

• Если вашему домену нелегко воспользоваться параллельным вычислением, объясните, почему это тоже интересно.
  Клиентское приложение в основном перемещает данные, серверное приложение в основном полагается на SQL-сервер, чтобы сделать тяжелую работу

Ответ 22

Я использую многоядерную систему, используя C, PThreads и домашнюю brew реализацию Communicating Sequential Processes на платформе OpenVPX с Linux, используя планировщик набора исправлений PREEMPT_RT. Все это добавляет почти 100% загрузки процессора в несколько экземпляров ОС без использования времени процессора, используемого для обмена данными между процессорными картами в шасси OpenVPX и очень низкой задержкой. Также использовать sFPDP для объединения нескольких шасси OpenVPX вместе в одну машину. Я не использую внутренний DMA Xeon, чтобы уменьшить напряжение памяти внутри процессоров (DMA по-прежнему использует пропускную способность памяти за счет процессорных ядер). Вместо этого мы оставляем данные на месте и передаем их владельцам в CSP (так что это не похоже на философию библиотеки параллельных потоков данных .NET.).

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

2) Область программного обеспечения - эффективно Научные вычисления

3) Что мы делаем с существующим кодом? Постоянно разбивая его на части и перераспределяя его части по нитям, чтобы каждое ядро ​​максимизировалось, делая все возможное, не выполняя требования реального времени. Новое оборудование означает довольно много переосмысления (более быстрые ядра могут делать больше в заданное время, не хотят, чтобы они были использованы). Не так плохо, как кажется - основные подпрограммы очень модульные, поэтому их легко собирают в куски ниток. Хотя мы планировали взять на себя управление связью потоков от Linux, нам пока не удалось извлечь значительную дополнительную производительность. Linux очень хорош в получении данных и кода в более или менее одинаковом месте.

4) Фактически уже есть - общая машина уже добавляет до тысячи ядер

5) Параллельные вычисления необходимы - это система MISD.

Если это звучит как большая работа, это так. некоторые рабочие места требуют идти полным хогом, делая абсолютное большинство доступного оборудования и избегая почти всего, что является высоким уровнем. Мы находим, что общая производительность машины зависит от пропускной способности памяти процессора, а не от частоты ядра процессора, размера кеша L1/L2/L3.