Масштабирование многопоточных приложений на многоядерных машинах

Question

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

Какие ресурсы люди порекомендуют?

До сих пор я нашел колонку Саттера «Доктор Доббс» хорошим началом. Я только что получил «Искусство многопроцессорного программирования» и книгу О'Рейли о Intel Threading Building Blocks

Answer 1

Несколько других книг, которые будут полезны:

• Алгоритмы синхронизации и параллельное программирование
• Шаблоны для параллельного программирования
• Передача последовательных процессов С. А. Р. Хоара (классический, бесплатный PDF по этой ссылке)

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

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

Answer 2

Возможно, вы захотите проверить Google Performance Tools . Они выпустили свою версию malloc, которую они используют для многопоточных приложений. Он также включает в себя хороший набор инструментов для профилирования.

Answer 3

Как сказал бы Монти Пайтон «а теперь что-то совершенно другое» - вы можете попробовать язык / среду, в которой не используются потоки, а процессы и обмен сообщениями (без общего состояния). Одним из наиболее зрелых из них является erlang (и эта превосходная и забавная книга: http://www.pragprog.com/titles/jaerlang/programming-erlang). Может не совсем соответствовать вашим обстоятельствам, но вы все равно можете узнать множество идей, которые вы сможете применить в других инструментах .

Для других сред:

.Net имеет F # (для изучения функционального программирования). У JVM есть Scala (у которой есть актеры, очень похожие на Erlang, и это функциональный гибридный язык). Также есть фреймворк "fork join" от Doug Lea для Java, который выполняет большую часть тяжелой работы за вас.

Answer 4

Джеффри Рихтер сильно увлекается. В его книгах есть несколько глав, посвященных обсуждению потоков, и посмотрите его блог:

http://www.wintellect.com/cs/blogs/jeffreyr/default.aspx.

Answer 5

Распределитель во FreeBSD недавно получил обновление для FreeBSD 7. Новое называется jemaloc и, очевидно, гораздо более масштабируемо для нескольких потоков.

Вы не упомянули, какую платформу вы используете, поэтому, возможно, вам доступен этот распределитель. (Полагаю, Firefox 3 использует jemalloc даже в Windows. Поэтому порты должны где-то существовать.)

Answer 6

Я веду блог с параллельными ссылками, который может быть интересен:

http://concurrency.tumblr.com

Answer 7

Мне придется когда-нибудь проверять Hoard, Google Perftools и jemalloc. На данный момент мы используем scalable_malloc от Intel Threading Building Blocks, и он работает достаточно хорошо.

Что бы там ни было, мы используем C ++ в Windows, хотя большая часть нашего кода будет прекрасно компилироваться с gcc. Если нет веских причин для перехода на Redhat (основной дистрибутив Linux, который мы используем), я сомневаюсь, что это стоит головной боли / политической проблемы.

Я бы с удовольствием использовал Erlang, но сейчас есть много способов сделать это заново. Если подумать о требованиях, связанных с разработкой Erlang в телекоммуникационной среде, то они очень похожи на наш мир (электронная торговля). Книга Армстронга у меня в стопке:)

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

Answer 8

Посмотрите на Накопление , если вы занимаетесь большим количеством памяти.

Сверните свой собственный Список блокировок . Хороший ресурс здесь - он на C #, но идеи переносимы. Как только вы привыкнете к тому, как они работают, вы начинаете видеть другие места, где их можно использовать, а не только в списках.