Как Вы используете в своих интересах Многоядерный?

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

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

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

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

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

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

Я могу теперь отделиться, моя основная операционная система от моей разработки / устанавливают то, что мне нравится OS с помощью vitualisation установки с Виртуальным ПК или VMware.

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

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

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

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

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

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

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

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

gmake -j

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

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

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

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

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

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

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

1. В данный момент - не влияет на него так очень, чтобы быть честным. Я нахожусь больше на 'этапе подготовки', узнавая о технологиях и функциях языка, которые делают это возможным.
2. у меня нет одного конкретного домена, но я встретился, домены как математика (где многоядерный важно), вид/поиск данных (где делят & завоюйте на многоядерном, полезно) и мультикомпьютерные требования (например, требование, чтобы вычислительная мощность резервной станции была используется для чего-то).
3. Это зависит, над каким языком я работаю. Очевидно, в C#, мои руки связываются еще готовой реализацией Параллельных Расширений, которая, действительно кажется, повышает производительность, пока Вы не начинаете сравнивать те же алгоритмы с OpenMP (возможно, не справедливое сравнение). Таким образом на.NET это будет легкой поездкой с [приблизительно 110] → Parallel.For рефакторинги и т.п..
   то, Где вещи становятся действительно интересными, с C++, потому что производительность, которую можно сжать из вещей как OpenMP, колеблется по сравнению с.NET. На самом деле OpenMP удивил меня много, потому что я не ожидал, что он будет работать так эффективно. Ну, я предполагаю, что у его разработчиков было много времени для полировки его. Мне также нравится этот, это доступно в Visual Studio out-of-the-box, в отличие от TBB, за который необходимо заплатить.
   Что касается MPI, я использую PureMPI.net для небольших домашних проектов (у меня есть LAN) дурачиться с вычислениями, которые не может вполне взять одна машина. Я никогда не использовал MPI коммерчески, но я действительно знаю, что MKL имеет некоторые MPI-оптимизированные функции, которые могли бы быть интересны посмотреть на для любого нуждающегося в них.
4. я планирую сделать 'несерьезное вычисление', т.е. использовать дополнительные ядра для предварительного вычисления результатов, которые могли бы или не могли бы быть необходимы - разрешение RAM, конечно. Я также намереваюсь копаться в дорогостоящих алгоритмах и подходах, которые прямо сейчас не могут обработать машины большинства конечных пользователей.
5. Что касается доменов, не извлекающих выгоду из распараллеливания... хорошо, можно всегда находить что-то. Одна вещь I касавшаяся, достойная поддержка в.NET, хотя, к сожалению, я оставил надежду, что могут быть достигнуты скорости, подобные C++.

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

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

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

Так для меня многоядерный в основном сводится к этим объектам:

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

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

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

VivaMP †“инструмент для Прерываний OpenMP

32 OpenMP Для Разработчиков C++

I said some of this in answer to a different question (hope this is OK!): there is a concept/methodology called Flow-Based Programming (FBP) that has been around for over 30 years, and is being used to handle most of the batch processing at a major Canadian bank. It has thread-based implementations in Java and C#, although earlier implementations were fiber-based (C++ and mainframe Assembler). Most approaches to the problem of taking advantage of multicore involve trying to take a conventional single-threaded program and figure out which parts can run in parallel. FBP takes a different approach: the application is designed from the start in terms of multiple "black-box" components running asynchronously (think of a manufacturing assembly line). Since the interface between components is data streams, FBP is essentially language-independent, and therefore supports mixed-language applications, and domain-specific languages. Applications written this way have been found to be much more maintainable than conventional, single-threaded applications, and often take less elapsed time, even on single-core machines.

Я считаю, что « Циклы - лучший друг инженеров ».

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Существуют накладные расходы на выполнение, связанные с управлением несколькими потоками, накладные расходы на память, связанные с буферами для каждого теада, и накладные расходы на данные, связанные с объединением блоков. Таким образом, этот подход окупается только для больших байт-потоков. В моих тестах, выше 512k, это может окупиться. Ниже этого, лучше использовать последовательный подход.

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

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

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

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

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

4. Как вы будете иметь дело с сотнями или тысячами сердечников?
   Глава -> Песок.

5. Если ваш домен не легко выиграет от параллельных вычислений, а затем объясняет, почему тоже интересно.
   Клиентское приложение в основном толкает данные, приложение сервера в основном полагается на SQL Server, чтобы сделать тяжелую лифтинг

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