Предотвращение наверху

Чтобы получить точную меру нашей возможности решить линейные системы, мы должны удалить любой возможный источник издержек. Это включает получение текущего параллельного пула и временно отключение возможностей обнаружения мертвой блокировки.

p = gcp;
if isempty(p)
    error('pctexample:backslashbench:poolClosed', ...
        ['This example requires a parallel pool. ' ...
         'Manually start a pool using the parpool command or set ' ...
         'your parallel preferences to automatically start a pool.']);
end
poolSize = p.NumWorkers;
pctRunOnAll 'mpiSettings(''DeadlockDetection'', ''off'');'

Starting parallel pool (parpool) using the 'bigMJS' profile ... connected to 12 workers.

Функция сравнительного тестирования

Мы хотим протестировать матричного левого деления в сравнении с эталоном (\), а не стоимость ввода spmd блокируйтесь, время, которое требуется, чтобы создать матрицу или другие параметры. Мы поэтому разделяем генерацию данных от решения линейной системы и измеряем только время, которое требуется, чтобы сделать последнего. Мы генерируем входные данные с помощью 2D циклического блоком codistributor, когда это - самая эффективная схема распределения решения линейной системы. Наше сравнительное тестирование затем состоит из измерения времени, требуются все рабочие, чтобы завершить решение линейной системы A*x = b. Снова, мы пытаемся удалить любой возможный источник издержек.

function [A, b] = getData(n)
    fprintf('Creating a matrix of size %d-by-%d.\n', n, n);
    spmd
        % Use the codistributor that usually gives the best performance
        % for solving linear systems.
        codistr = codistributor2dbc(codistributor2dbc.defaultLabGrid, ...
                                    codistributor2dbc.defaultBlockSize, ...
                                    'col');
        A = codistributed.rand(n, n, codistr);
        b = codistributed.rand(n, 1, codistr);
    end
end

function time = timeSolve(A, b)
    spmd
        tic;
        x = A\b; %#ok<NASGU> We don't need the value of x.
        time = gop(@max, toc); % Time for all to complete.
    end
    time = time{1};
end

Выбор проблемного размера

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

Для времени расчеты для многих различных матричных размеров поэтому важно получить понимание какой "маленькое", "большое", и "слишком большое" среднее значение в этом контексте. На основе предыдущих экспериментов мы ожидаем:

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

Заметьте, что путем изменения проблемного размера согласно количеству рабочих, мы используем слабое масштабирование. Другие примеры сравнительного тестирования, такие как Простое Сравнительное тестирование PARFOR Используя Блэк джек и Сравнительное тестирование Независимых Заданий в Кластере, также используют слабое масштабирование. Когда те примеры тестируют расчетов параллели задачи в сравнении с эталоном, их слабое масштабирование состоит из создания количества итераций, пропорциональных количеству рабочих. Этот пример, однако, тестирует расчетов параллели данных в сравнении с эталоном, таким образом, мы связываем верхний предел размера матриц к количеству рабочих.

% Declare the matrix sizes ranging from 1000-by-1000 up to 45% of system
% memory available to each worker.
maxMemUsagePerWorker = 0.45*memoryPerWorker*1024^3; % In bytes.
maxMatSize = round(sqrt(maxMemUsagePerWorker*poolSize/8));
matSize = round(linspace(1000, maxMatSize, 5));

Сравнение эффективности: гигафлопы

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

Путем генерации графиков, таких как они, мы можем ответить на вопросы, такие как:

Учитывая матричный размер, функция сравнительного тестирования создает матричный A и правая сторона b однажды, и затем решает A\b многократно, чтобы получить точную меру времени это берет. Мы используем плавающее количество операций проблемы HPC, так, чтобы для n на n матрицы, мы считали операции с плавающей точкой как 2/3*n^3 + 3/2*n^2.

function gflops = benchFcn(n)
    numReps = 3;
    [A, b] = getData(n);
    time = inf;
    % We solve the linear system a few times and calculate the Gigaflops
    % based on the best time.
    for itr = 1:numReps
        tcurr = timeSolve(A, b);
        if itr == 1
            fprintf('Execution times: %f', tcurr);
        else
            fprintf(', %f', tcurr);
        end
        time = min(tcurr, time);
    end
    fprintf('\n');
    flop = 2/3*n^3 + 3/2*n^2;
    gflops = flop/time/1e9;
end

Выполнение сравнительных тестов

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

fprintf(['Starting benchmarks with %d different matrix sizes ranging\n' ...
         'from %d-by-%d to %d-by-%d.\n'], ...
        length(matSize), matSize(1), matSize(1), matSize(end), ...
        matSize(end));
gflops = zeros(size(matSize));
for i = 1:length(matSize)
    gflops(i) = benchFcn(matSize(i));
    fprintf('Gigaflops: %f\n\n', gflops(i));
end
results.matSize = matSize;
results.gflops = gflops;

Starting benchmarks with 5 different matrix sizes ranging
from 1000-by-1000 to 76146-by-76146.
Creating a matrix of size 1000-by-1000.
Analyzing and transferring files to the workers ...done.
Execution times: 1.038931, 0.592114, 0.575135
Gigaflops: 1.161756

Creating a matrix of size 19787-by-19787.
Execution times: 119.402579, 118.087116, 119.323904
Gigaflops: 43.741681

Creating a matrix of size 38573-by-38573.
Execution times: 552.256063, 549.088060, 555.753578
Gigaflops: 69.685485

Creating a matrix of size 57360-by-57360.
Execution times: 3580.232186, 3726.588242, 3113.261810
Gigaflops: 40.414533

Creating a matrix of size 76146-by-76146.
Execution times: 9261.720799, 9099.777287, 7968.750495
Gigaflops: 36.937936

Графический вывод эффективности

Мы можем теперь построить результаты и выдержать сравнение с ожидаемым графиком, показанным выше.

fig = figure;
ax = axes('parent', fig);
plot(ax, matSize/1000, gflops);
lines = ax.Children;
lines.Marker = '+';
ylabel(ax, 'Gigaflops')
xlabel(ax, 'Matrix size in thousands')
titleStr = sprintf(['Solving A\\b for different matrix sizes on ' ...
                    '%d workers'], poolSize);
title(ax, titleStr, 'Interpreter', 'none');

Если результаты сравнительного теста не так хороши, как вы можете ожидать, вот некоторые вещи рассмотреть:

Сравнение различных количеств рабочих

Мы теперь смотрим на то, как сравнить различные количества рабочих путем просмотра данных, полученных путем выполнения этого примера с помощью различных количеств рабочих. Эти данные получены в различном кластере из того выше.

Другие примеры, такие как Сравнительное тестирование Независимых Заданий в Кластере объяснили, что при сравнительном тестировании параллельных алгоритмов для различных количеств рабочих, каждый обычно использует слабое масштабирование. Таким образом, когда мы увеличиваем число рабочих, мы увеличиваем проблемный размер пропорционально. В случае матричного левого деления мы должны показать дополнительный уход, потому что эффективность деления зависит значительно от размера матрицы. Следующий код создает график эффективности в Гигафлопах для всех матричных размеров, которые мы протестировали с и все различные количества рабочих, когда это дает нам самое подробное изображение показателей производительности матричного левого деления в этом конкретном кластере.

s = load('pctdemo_data_backslash.mat', 'workers4', 'workers8', ...
         'workers16', 'workers32', 'workers64');
fig = figure;
ax = axes('parent', fig);
plot(ax, s.workers4.matSize./1000, s.workers4.gflops, ...
     s.workers8.matSize./1000, s.workers8.gflops, ...
     s.workers16.matSize./1000, s.workers16.gflops, ...
     s.workers32.matSize./1000, s.workers32.gflops, ...
     s.workers64.matSize./1000, s.workers64.gflops);
lines = ax.Children;
set(lines, {'Marker'}, {'+'; 'o'; 'v'; '.'; '*'});
ylabel(ax, 'Gigaflops')
xlabel(ax, 'Matrix size in thousands')
title(ax, ...
      'Comparison data for solving A\\b on different numbers of workers');
legend('4 workers', '8 workers', '16 workers', '32 workers',  ...
       '64 workers', 'location', 'NorthWest');

Первая вещь, которую мы замечаем при рассмотрении графика выше, состоит в том, что 64 рабочих позволяют нам решать намного большие линейные системы уравнений, чем возможно только с 4 рабочими. Кроме того, мы видим, что, даже если бы можно было бы работать с матрицей размера 60,000 60,000 на 4 рабочих, мы получили бы эффективность приблизительно только 10 гигафлопов. Таким образом, даже если бы у этих 4 рабочих была достаточная память, чтобы решить такую большую задачу, 64 рабочих, тем не менее, значительно превзошли бы их по характеристикам.

Смотря на наклон кривой для 4 рабочих, мы видим, что существует только скромное увеличение эффективности между тремя самыми большими матричными размерами. Сравнение этого с более ранним графиком ожидаемой эффективности A\b для различных матричных размеров мы приходим к заключению, что мы вполне близко к достижению пиковой производительности для 4 рабочих с матричным размером 7772 7772.

Смотря на кривую для 8 и 16 рабочих, мы видим, что эффективность понижается для самого большого матричного размера, указывая, что мы рядом или уже исчерпали доступную системную память. Однако мы видим, что увеличение эффективности между вторыми и третьими по величине матричными размерами очень скромно, указывая на какую-то устойчивость. Мы поэтому предугадываем, что при работе с 8 или 16 рабочими, скорее всего, не видели бы значительное увеличение Гигафлопов, если бы мы увеличили системную память и протестировали с большими матричными размерами.

Смотря на кривые для 32 и 64 рабочих, мы видим, что существует значительное увеличение эффективности между вторыми и третьими по величине матричными размерами. Для 64 рабочих между двумя самыми большими матричными размерами существует также значительное увеличение эффективности. Мы поэтому предугадываем, что у нас заканчивается системная память для 32 и 64 рабочих, прежде чем мы достигли пиковой производительности. Если это правильно, то добавление большей памяти компьютерам и позволило бы нам решать большие задачи и выполнять лучше в тех больших матричных размерах.

Ускорение

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

peakPerf = [max(s.workers4.gflops), max(s.workers8.gflops), ...
            max(s.workers16.gflops), max(s.workers32.gflops), ...
            max(s.workers64.gflops)];
disp('Peak performance in Gigaflops for 4-64 workers:')
disp(peakPerf)

disp('Speedup when going from 4 workers to 8, 16, 32 and 64 workers:')
disp(peakPerf(2:end)/peakPerf(1))

Peak performance in Gigaflops for 4-64 workers:
   10.9319   23.2508   40.7157   73.5109  147.0693

Speedup when going from 4 workers to 8, 16, 32 and 64 workers:
    2.1269    3.7245    6.7244   13.4532

Мы поэтому приходим к заключению, что получаем ускорение приблизительно 13,5 при увеличении числа рабочих 16 сгибов, движении от 4 рабочих к 64. Как мы отметили выше, график эффективности указывает, что мы можем смочь увеличить эффективность на 64 рабочих (и таким образом улучшить ускорение еще больше) путем увеличения системной памяти на кластерных компьютерах.

Используемый кластер

Эти данные были сгенерированы с помощью 16 двухпроцессорных, octa-базовых компьютеров, каждого с 64 Гбайт памяти, соединенной с GigaBit Ethernet. При использовании 4 рабочих они были всеми на одиночном компьютере. Мы использовали 2 компьютера для 8 рабочих, 4 компьютера для 16 рабочих, и т.д.

Перевключение обнаружения мертвой блокировки

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

pctRunOnAll 'mpiSettings(''DeadlockDetection'', ''on'');'

end

ans = 

  struct with fields:

    matSize: [1000 19787 38573 57360 76146]
     gflops: [1.1618 43.7417 69.6855 40.4145 36.9379]