58 Тем для обсуждения
197 Открытых обсуждений
21. ...Занимательная масштабируемость
Alexander Komarov (Intel) (5 пост(а)) 04.07.2007 09:11
На одном интересном сайте недавно появилась статья об диагностике проблем с масштабируемостью. Автор - Дэвид Левенталь, признанный специалист по низкоуровневым оптимизациям и производству коллекционного вина. Статья посвящена диагностике микроархитектурных проблем. У Intel Software College есть подробный курс на эту тему, с лабами, часа на 4. Но можно почитать и статью, которая объясняет некоторые самые важные тонкости.
Но так ли нужно понимание этих нетривиальных деталей, если приложение, например, перестает масштабироваться после добавления более 4 потоков? Часто все оказывается намного проще. Например, зимой я работал с серверным приложением, которое очень хорошо масштабировалось до 6 потоков, но при дальнейшем их увеличении производительность серьезно падала.
Intel Thread Profiler не помог выяснить проблему. Потоки были практически независимы. Микроархитектурных узких мест, описанных в статье выше, обнаружить не удалось. Дальнейший анализ при помощи Vtune показал, что серьезно возрастает время, проведенное в gettimeoftheday. В этой функции ядра вроде-бы и нет вызовов объектов синхронизации. К счастью, можно было не особенно вникать в детали реализации gettimeoftheday. Была возможность вызывать ее на порядок реже, увеличив число потоков до 8 (именно столько ядер в типовом современном двухпроцессорном сервере).
Не люблю рекламу пива Клинское, но приходится признать, что в некоторых вещах действительно сперва обойтись без понтов. (См. мой опыт с Thread Profiler и попытки отыскать низкоуровневые задержки.)
Удачной отладки!
Категории: Многоядерность, Разработка софта
Комментарии (1) 
По Philosopher в Декабрь 26th, 2007 в 07:52
согласен на 100% - лишние понты не приводят ни к чему, кроме неприятностей.