Масштабирование многопоточных приложений на машинах мультис сердечником
http://www.cloudera.com/documentation/enterprise/5-5-x/topics/spark_python.html
Вы также можете проверить эту статью. Это очень хорошо описывает вашу проблему.
8 ответов
Несколько других книг, которые будут полезными:
- Алгоритмы синхронизации и параллельное программирование
- Шаблоны для параллельного программирования
- Передача последовательных процессов C. A. R. Hoare (классический, свободный PDF в той ссылке)
Кроме того, рассмотрите надежду меньше на совместное использование состояния между параллельными процессами. Вы масштабируетесь очень, намного лучше если можно избежать его, потому что Вы сможете распределить независимые единицы работы, не имея необходимость делать столько же синхронизации между ними.
Даже если необходимо совместно использовать некоторое состояние, посмотрите, можно ли разделить общее состояние от фактической обработки. Это позволит Вам сделать такую же большую обработку параллельно, независимо от интеграции завершенных единиц работы назад в общее состояние. Очевидно, это не работает, если у Вас есть зависимости среди единиц работы, но это стоит исследовать вместо того, чтобы просто предположить, что состояние всегда будет общим.
Вы могли бы хотеть проверить Инструменты Производительности Google. Они выпустили свою версию malloc, который они используют для многопоточных приложений. Это также включает хороший набор профильных инструментов.
Jeffrey Richter в поточную обработку много. У него есть несколько глав по поточной обработке в его книгах, и проверьте его блог:
Средство выделения в FreeBSD недавно получило обновление для FreeBSD 7. Новый называют jemaloc и является, по-видимому, намного более масштабируемым относительно нескольких потоков.
Вы не упоминали, какую платформу Вы используете, поэтому возможно, это средство выделения доступно Вам. (Я полагаю, что Firefox 3 использует jemalloc, даже на окнах. Таким образом, порты должны существовать где-нибудь.)
Как Монти Пайтон заявил бы "и теперь для чего-то совершенно другого" - Вы могли попробовать язык/среду, который не использует потоки, но процессы и обменивающийся сообщениями (никакое общее состояние). Один из самых сформировавшихся является erlang (и эта превосходная и забавная книга: http://www.pragprog.com/titles/jaerlang/programming-erlang). Может не точно относиться к Вашим обстоятельствам, но можно все еще изучить много идей, что Вы можете подавать заявку в других инструментах.
Для других сред:
.NET имеет F# (для изучения функционального программирования). JVM имеет Scala (который имеет агентов, очень как Erlang, и является функциональным гибридным языком). Также существует "платформа" соединения ветвления от Doug Lea для Java, который делает большую тяжелую работу для Вас.
Я буду иметь к Запасу контроля, Google Perftools и jemalloc когда-то. На данный момент мы используем scalable_malloc от Intel Threading Building Blocks, и он работает достаточно хорошо.
Что бы там ни было мы используем C++ в Windows, хотя большая часть нашего кода скомпилирует с gcc очень хорошо. Если нет неопровержимый довод для перемещения в Redhat (основной дистрибутив Linux, мы используем), я сомневаюсь, что это стоит проблемы головной боли / политической проблемы для перемещения.
Я хотел бы использовать Erlang, но там путь к очень здесь для восстановления его теперь. Если мы думаем о требованиях вокруг разработки Erlang в телекоммуникационной установке, очень похожего на наш мир (электронная торговля). Книга Armstrong идет мой для чтения стека :)
В моем тестировании для масштабирования из 4 ядер к 16 ядрам я учился ценить стоимость любой блокировки/конкуренции в параллельной части кода. К счастью у нас есть значительная часть, которая масштабируется с данными, но даже который не работал сначала из-за дополнительной блокировки и средства выделения памяти.
Смотрите на Запас при выполнении большого выделения памяти.
Блокировка самокрутки Бесплатный Список. Хороший ресурс здесь - это находится в C#, но идеи являются портативными. После того как Вы привыкаете к тому, как они работают, Вы начинаете видеть другие места, где они могут использоваться и не только в списках.
Я поддерживаю блог ссылки параллелизма, который может представлять продолжающийся интерес: