Узкое место в управлении памятью для параллелизма SMP

Question

На нескольких языках (в основном D и Java / Jython) я заметил, что параллельные программы без очевидного узкого места синхронизации часто плохо масштабируются до 4 или более ядер из-за узких мест управления памятью. Я знаю, что локальные распределители потоков смягчают эту проблему, но большинство реализаций сборщика мусора все еще должны остановить мир. Сборка мусора не смущает параллель (общее состояние должно обновляться слишком часто), поэтому использование параллельного сборщика не решает проблему полностью. В случае ручного управления памятью, даже если выделения в основном из локального распределителя потоков, память все равно должна быть освобождена, возможно, из потока, отличного от того, в котором она была выделена.

Существует ли какая-либо реализация языка / среды выполнения / malloc, для которой узкое место управления памятью в параллельности SMP является для всех практических целей решенной проблемой, но в то же время допускает традиционную многопоточность в разделяемом адресном пространстве?

Answer 1

Одним из улучшений в системе SMP был бы распределитель / сборщик с поддержкой NUMA, который, похоже, уже есть в Java: http://download -llnw.oracle.com / javase / 7 / docs / technotes / guides / vm / производительность усовершенствований, 7.html # NUMA

Answer 2

номер

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

Я удивлен, что вы обычно сталкиваетесь с этой проблемой только на 4 ядрах, в прошлом я использовал машины SGI Altix, на которых некоторые из моих кодов хорошо масштабировались до 256 ядер. Но неважно, является ли ваш код узким местом в 4 ядрах или моим в 256 или другим кодом в 2048 (если вы можете найти SMP с 2048 ядрами), узкое место всегда будет.