Вы обеспокоены многоядерным? [закрытый]

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

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

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

Вещь, о которой я думал, большинство алгоритмов делить-и-побеждать, не в широком масштабе parallelizable? Каждое разделение должно быть в состоянии быть выполненным в двух отдельных потоках...

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

программирование Потока данных показывает некоторое обещание для относительно легкого решения многоядерной проблемы.

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

Как инди-разработчик игр я на самом деле очень взволнован по поводу этого. Несколько игр идут зависящие от ЦП в течение активных моментов. И почти все современные 3D игры являются очень налоговыми на аппаратных средствах. Многоядерный было законодательство страны для видео в течение прошлых нескольких лет. С некоторыми картами Nvidia в наше время, имеющими более чем 200 ядер.

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

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

Ближайшее время: Это не имеет большого значения, если Вы не сокрушительны свой Длительный срок процессора: Лучше станьте удобными с блокировками:)

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

Вполне аккуратная область CS.:)

Нет, я не волнуюсь.

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

Частично я нетерпелив относительно вещей перейти к сути дела, где это действительно стоит оптимизировать для многоядерного. Я не знаю то, что точные числа в данный момент, но кажется, что у половины наших клиентов есть одножильная машина, 49% имеют двухъядерный, и возможно 1% имеет четверку. Это означает, что многопоточность действительно не дает этому огромное увеличение производительности в большинстве случаев и следовательно не действительно стоит проводить много времени на.

Через несколько лет, когда среднее число могло бы быть четырехъядерным, там будет намного большим количеством случая для того, чтобы провести немного времени на умном коде многопоточности - который я думаю, будет хорошей вещью для нас разработчики. Все, в чем мы нуждаемся, для Intel и AMD, чтобы торопить и сделать больше из них...:-)

Ну, так как я делаю веб-разработку в ASP.NET, существует несколько областей, я видел многоядерное проигрывание роли:

1) Клиентский. Как чему-то может понравиться JavaScript, который будет оптимизирован для клиента, который имеет четырехъядерный ЦП если, именно это кто-то хочет использовать в выполнении чего-то как сортировка длинного списка данных. Толстые клиенты возвращаются с новыми версиями IE, Firefox, Safari и Chrome?

2) Серверная сторона на веб-сервере. В IIS и платформе .NET, которую это использует, как вещам нравится, когда использование справки PLINQ параллельное или параллельное программирование помогает ускорить обрабатывающие запросы? Какие виды настроек IIS могут быть сделаны, чтобы улучшить производительность и настроить ее на аппаратные средства?

3) Бэкенд Промежуточного программного обеспечения/DB. Как делает последний SQL SERVER MS или Oracle или дескриптор MySQL с помощью дополнительных ресурсов и многоядерного и мультисокет, например, если материнская плата квадратического сокета имеет четырехъядерные центральные процессоры в каждом сокете и что-то как Гиперпоточность на вершине существует 32 потока, которые могли работать сразу, который действительно отличается, чем одноядерный ЦП назад в дни.

, Кроме того, существует что-то, чтобы быть сказанным для многоядерных аспектов GPU, где Crossfire и SLI были началом, но теперь существует больше гибридных графических решений, что можно задаться вопросом, как это будет использоваться в будущем, например, Fusion AMD является одной идеей, что я не уверен, как хорошо это сделает, но это является последним, я слышал.

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

Они - просто мои текущие мысли и подвержены изменениям в любой момент.

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

, по моему скромному мнению, большинство преимуществ значительно-многоядерных прибыло бы от улучшений до базовых платформ (например, доступ к базе данных, IO, GUI и 3D инструментарии, и т.д.), и подавляющее большинство разработчиков извлечет выгоду прозрачно.

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

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

Никакой путь! Я - программист Clojure!: D

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

Ответ Dmckee корректен в самом узком смысле. Позвольте мне перефразировать в моих собственных словах здесь, неявно включая некоторые комментарии:

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

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

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

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

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

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

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

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

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

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

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

Поэтому, если Ваши текущие приложения не являются очень Зависящими от ЦП, я не волновался бы о параллелизации их. Если Вы находите, что имеете "кучу" мощности ЦП через несколько ядер, то смотрите на способы использовать ее в новых проектах.

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

На *отклоняют, старое доброе ветвление () является все еще хорошим способом пойти для многих вещей. Издержки не слишком плохи (да, я должен буду измерить это для поддержки моего БАКАЛАВРА НАУК однажды), особенно если Вы разветвите интерпретатор, затем генерируя набор задачи определенные данные в дочернем процессе.

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

, Но я не горький:-)

Пересмотр / комментарий:

Превосходный комментарий в другом месте о расстоянии до памяти. Я думал об этом вполне немного недавно также. Сборка "мусора" Марка-и-развертки действительно повреждает аспект "местности" выполнения процессов. GC M/S на 0 RAM состояния ожидания на старых 80286, возможно, казался безопасным, но это действительно причиняет боль на многоуровневой архитектуре кэширования. Возможно, ссылаясь рассчитывающий + ветвление/выход не является такой плохой идеей как реализация GC в некоторых случаях?

редактирование: Я приложил некоторые усилия к поддержке моего разговора здесь (результаты варьируются): http://roboprogs.com/devel/2009.04.html

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

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

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

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

, Но те из нас пишущий главным образом в C#, даже если мы пишем графический интерфейсы пользователя, мы должны обратить пристальное внимание на этот материал. GUI часто должен выполнять некоторую полезную операцию на любой модели, которую это представляет пользователю, и пользователь раздражается, когда они должны сидеть и ждать его для окончания. Они станут еще более раздраженными через несколько лет, когда они посмотрят на Диспетчер задач и видят, что приблизительно 3% их необычной новой машины с 32 ядрами используются.

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

Я не соглашаюсь с текущим принятым ответом.

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

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

Видят http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-183.html для хорошего обзора многоядерного и способа, которым направляются вещи. Важные пункты, которые, как они говорят, являются:

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

Просто примечание стороны: Если Ваше приложение имеет GUI и делает интенсивное вычисление, ВСЕГДА делайте свое интенсивное вычисление на отдельном потоке. Забывая делать это - то, почему графический интерфейсы пользователя замерзают.

Я программировал с потоками больше 15 лет теперь. Я не волнуюсь в малейшем

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