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

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

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

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

9.08.2008 15:42:17
8 ОТВЕТОВ
РЕШЕНИЕ

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

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

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

6
9.08.2008 22:13:12

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

3
9.08.2008 16:59:53

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

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

2
9.08.2008 23:55:47

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

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

1
9.08.2008 18:51:36

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

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

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

2
9.08.2008 23:56:46

Посмотрите на Hoard, если вы делаете много распределения памяти.

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

0
10.08.2008 13:45:43

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

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

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

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

0
10.08.2008 16:15:10

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

http://concurrency.tumblr.com

0
26.09.2008 12:07:21