2016-01-26 13 views
0

Я пытаюсь понять kcachegrind, там, похоже, не так много информации, например, в левом окне, что такое «Я», что такое «вкл.»? (см. 1 core).Нужна помощь в понимании kcachegrind

Я сделал некоторые слабые тесты масштабирования, коммуникации нет, поэтому я предполагаю, что это связано с промахами кеша. Но из того, что я вижу, существует такое же количество промахов данных как для 1 ядра, так и для 16 ядер, см.: 16 cores.

Единственное отличие, которое я вижу между 1 сердечником и 16 ядром, заключается в том, что на memcpy значительно меньше звонков на 16 ядер (что я могу объяснить). Но я все еще не могу понять, почему на одном ядре время выполнения составляет 0,62 секунды, а на 16 ядрах время выполнения приближается к 1 секунде. Каждый процессор выполняет ту же работу. Если кто-то может сказать мне, что искать в kcachegrind, это было бы потрясающе, это мой первый раз, когда я использовал kcachegrind и valgrind.

Редактировать: Мой код объединяет матрицы в сжатом формате строки. Он включает в себя цикл по элементам подматриц и использование memcpy для копирования значений в матрицу результатов. Вот код: - Я не могу опубликовать более 2 ссылок ... поэтому я отправлю его в комментарии.

Я только инициировал valgrind на самой петле, цикл также является тем, что делает разницу между временем выполнения 0,62 секунды и временем выполнения 1 секунды. Частью, которая занимает больше всего времени, является вызов memcpy (строка 37 в github gist ниже), когда я это прокомментирую, мой код выполняется менее чем за 0,2 секунды, хотя по-прежнему увеличивается от 1 до 16 ядер (около 30%).

Я бегу мой код на узле Haswell, который состоит из 24 ядер, (два процессора Intel® Xeon® E5-2690 v3)

Каждое ядро ​​имеет 5 Гб памяти.

+0

Вот код: https://gist.github.com/anonymous/fc32abc68c5b4b6d0986 – user302157

+0

И как этот однопоточный код работает через 16 ядер? Это всего лишь один поток, получающий контекстную коммутацию повсюду, или есть что-то еще, что вы не показывали? – Useless

+0

Матрицы автоматически распределяются. Таким образом, если я получу row_start, он получит только строку row_start для той части матрицы, которая находится на этом ядре. Точно так же, если я получу количество ненулевых (NNZ), он вернет NNZ только для записей этого ядра. В этом алгоритме нет необходимости обращаться к данным на других ядрах, поэтому он выглядит однопоточным. Однако каждая memcpy будет копировать разные данные в зависимости от того, на каком ядре они находятся. Однако, если я хочу получить доступ к части матрицы, которая находится на другом ядре, тогда мне придется вызывать вызовы MPI. – user302157

ответ

0

там, кажется, не так много информации, например, в левом окне, что такое «Я», что такое «вкл.»?

Поразительно, но это первый часто задаваемый вопрос в kcachegrind FAQ. В частности, из этой ссылке:

... это имеет смысл различать стоимость самой функции («Self стоимость») и стоимость, включая все называемые функции

(«включено» Стоимость [вкл.])

Теперь вы не показали какого-либо кода или дано даже намека о том, что делает ваша программа, но ...

от того, что я могу видеть, есть одно и то же количество промахов данных для как 1 сердечник, так и 16 сердечников ...

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

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

Но я до сих пор не могу понять, почему на одном ядре, то время выполнения 0.62 сек, в то время как на 16 ядер, время выполнения ближе к 1 второй

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

Если кто-то может сказать мне, что нужно искать в KCachegrind ...

Что вы пытаетесь найти? Что делает ваш код? Разве разница во времени все еще там, когда не работает под valgrind? Какие библиотеки вы используете, какую ОС и какую аппаратную платформу?

+0

Разница во времени есть, когда НЕ используется valgrind. При использовании valgrind разница во времени в значительной степени исчезает. Я просто пытаюсь найти разницу между 1 ядром и 16 ядрами - в частности, почему работает мой код на 16 ядрах, что приводит к 40% увеличению времени выполнения. – user302157

+0

Забыл упомянуть, нет вызовов в MPI и нет синхронизации. – user302157