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

Ответ 1

Связаны ли ваши программы с CPU?

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

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

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

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

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

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

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

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

Ответ 2

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

Ответ 3

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

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

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

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

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

Ответ 4

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

Ответ 5

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

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

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

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

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

Ответ 6

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

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

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

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

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

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

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

Ответ 7

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

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

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

Ответ 8

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

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

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

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

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

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

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

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

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

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

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

Ответ 9

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

Ответ 10

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

Ответ 11

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

Ответ 12

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

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

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

Ответ 13

Хорошо, так как я занимаюсь веб-разработкой в ​​ASP.Net, есть несколько областей, в которых я могу видеть многоядерность, играющую роль:

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

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

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

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

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

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

Ответ 14

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

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

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

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

Ответ 15

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

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

Ответ 16

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

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

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

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

Ответ 17

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

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

Ответ 18

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

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

Ответ 19

Ежедневно я не думаю о многоядерном программировании, но всегда на моем радаре.

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

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

Ответ 20

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