Вас беспокоит многоядерность?

Question

Это неоспоримо: многоядерные компьютеры здесь остаться.

Так вот: эффективное многоядерное программирование довольно сложно. Это не просто случай понимания pthreads.

Это спорно: свойство «разработчик на улице» нужно относиться к нему/себя с этими событиями.

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

Answer 1

Ваши программы обычно связаны с процессором?

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

Прохладный, а?

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

---

Из комментариев:

Предложения для улучшения ответа: дать грубое объяснение о том, как сказать, если ваша программа ЦП. - Earwicker

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

Итак, вам нужно знать, что делает ваша программа с момента на мгновение (и как занят машина ...) Чтобы узнать об Unix-подобных системах, запустите top. В окнах используется диспетчер задач (спасибо Roboprog).

На машине с нагрузкой менее 1 на ядро ​​(т. Е. На вашем настольном компьютере, когда вы ничего не делаете), процесс привязки к процессору будет постоянно иметь более 50% процессора (часто более 90% %). Когда средний уровень загрузки выше (т. Е. У вас есть три компиляции, SETI @ home и две одноранговые сети, работающие в фоновом режиме), процесс привязки процессора будет иметь большую часть (# of cores)/(load average).

Answer 2

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

Answer 3

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

Answer 4

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

Answer 5

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

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

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

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

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

Answer 6

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

Answer 7

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

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

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

Answer 8

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

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

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

3) Middleware/DB Back-end. Как обрабатываются последние MS-SQL Server или Oracle или MySQL с использованием дополнительных ресурсов как многоядерных, так и многосетевых, например. если на плате с четырьмя гнездами есть четырехъядерные процессоры в каждом сокете и что-то вроде Hyperthreading сверху, есть 32 потока, которые могут запускаться сразу, что в действительности сильно отличается от одного ядра процессора в те дни.

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

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

Это мои текущие мысли и могут быть изменены в любой момент.

Answer 9

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

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

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

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

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

Отличный комментарий в другом месте о расстоянии-память. Я думал об этом совсем недавно. Отметка и разметка мусора действительно наносит ущерб «локальности» аспекта запущенных процессов. M/S GC на 0 ОЗУ состояния ожидания на старом 80286 может показаться безвредным, но это действительно вредно для многоуровневых архитектур кэширования. Может быть, ссылка на подсчет + fork/exit не такая плохая идея, как реализация GC в некоторых случаях?

---

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

Answer 10

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

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

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

Answer 11

Нет, я не беспокоюсь.

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

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

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

Answer 12

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

Довольно аккуратная область CS. :)

Answer 13

Как инди-разработчик игр, я на самом деле очень взволнован. В течение активных игр несколько игр переходят на CPU. И почти все современные 3D-игры очень обременяют оборудование. Multicore был законом земли для видео в течение последних нескольких лет. С некоторыми картами nvidia, которые в настоящее время имеют более 200 ядер.

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

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

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

Answer 14

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

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

Answer 15

Я не согласен с принятым в настоящее время ответом.

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

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

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

• Скорость часов больше не увеличивается. Это более экономически выгодно для производства большего количества более медленных и простых ядер, чем небольшое количество быстрых процессоров.
• Память (чаще) далеко от CPU
• Через несколько лет, будет 1000s ядер в веб-серверах, 100s на рабочих столах. Поэтому планируйте масштаб вашего приложения (возможно, автоматически масштабируйте) до 100 или 1000 ядер. Это означает, что вы должны создать несколько независимых задач.
• Темы с трудом работают, поэтому лучше работать с «задачами».

Answer 16

Ни в коем случае! Я программист Clojure! : D

Answer 17

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

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

Answer 18

Я не думаю о многоядерном программировании, но он всегда находится на моем радаре.

Самая большая проблема, с которой я всегда сталкивался при параллельной обработке, - это определение того, что должно быть распараллелировано? Легко выделить поток для фонового процесса файла, но может ли процесс обработки файлов быть распараллелен?

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

Answer 19

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

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

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

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

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

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

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

Несмотря на это, есть веские основания для изучения основ многопоточного и, следовательно, многоядерного развития.

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

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

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

Answer 20

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