Почему Torch использует ~ 700 МБ памяти графического процессора при прогнозировании в сети 1,5 МБ - PullRequest
1 голос
/ 11 апреля 2019

Я очень плохо знаком с Torch / CUDA и пытаюсь протестировать небольшую двоичную сеть (~ 1,5 МБ) из https://github.com/1adrianb/binary-face-alignment,, но у меня постоянно возникают проблемы с нехваткой памяти.

Я использую относительно слабый графический процессор (NVIDIA Quadro K600) с ~ 900 МБ графической памяти в 16.04 Ubuntu с CUDA 10.0 и CudNN версии 5.1.Так что меня не очень заботит производительность, но я подумал, что по крайней мере смогу запустить небольшую сеть для прогнозирования, по одному изображению за раз (особенно ту, которая предположительно нацелена на тех, «с ограниченными ресурсами»).

Мне удалось запустить код в автономном режиме и проверить, что потребление памяти составляет около 700 МБ, что объясняет причину сбоя сразу, когда у меня запущен X-сервер, который занимает около 250 МБ памяти графического процессора.

Я также добавил несколько журналов, чтобы посмотреть, как далеко main.lua я получу, и это вызов output:copy(model:forward(img)) на самом первом изображении, которому не хватает памяти.

Для справкиВот код main.lua вплоть до сбоя:

    require 'torch'
    require 'nn'
    require 'cudnn'
    require 'paths'

    require 'bnn'
    require 'optim'

    require 'gnuplot'
    require 'image'
    require 'xlua'
    local utils = require 'utils'
    local opts = require('opts')(arg)

    print("Starting heap tracking")
    torch.setheaptracking(true)

    torch.setdefaulttensortype('torch.FloatTensor')
    torch.setnumthreads(1)
    -- torch.

    local model
    if opts.dataset == 'AFLWPIFA' then
        print('Not available for the moment. Support will be added soon')
        os.exit()
        model = torch.load('models/facealignment_binary_pifa.t7')
    else
        print("Loading model")
        model = torch.load('models/facealignment_binary_aflw.t7')
    end
    model:evaluate()

    local fileLists = utils.getFileList(opts)
    local predictions = {}
    local noPoints = 68
    if opts.dataset == 'AFLWPIFA' then noPoints = 34; end
    local output = torch.CudaTensor(1,noPoints,64,64)
    for i = 1, #fileLists do

        local img = image.load(fileLists[i].image)
        local originalSize = img:size()

        img = utils.crop(img, fileLists[i].center, fileLists[i].scale, 256)
        img = img:cuda():view(1,3,256,256)
        output:copy(model:forward(img))

Итак, у меня есть два основных вопроса:

  1. Какие существуют инструменты для отладки использования памяти в torch?
  2. Каковы вероятные причины этого раздувания памяти?

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

1 Ответ

1 голос
/ 11 апреля 2019

То, что обычно занимает большую часть памяти, - это карты активации (и градиенты при обучении).Я не знаком с этой конкретной моделью и реализацией, но я бы сказал, что вы используете «поддельную» двоичную сеть;под fake Я имею в виду, что они по-прежнему используют числа с плавающей запятой для представления двоичных значений, поскольку большинство пользователей собираются использовать свой код на графических процессорах, которые не полностью поддерживают реальные двоичные операции.Авторы даже пишут в Разделе 5:

Производительность. Теоретически, заменяя все умножения с плавающей запятой на битовое XOR и используя SWAR (одиночная инструкция, несколько данныхв регистре) [5], [6] число операций может быть уменьшено до 32x по сравнению со сверткой на основе умножения.Однако в наших тестах мы наблюдали ускорения до 3,5 раз по сравнению с cuBLAS для умножения матриц, что соответствует результатам, описанным в [6].Отметим, что мы не проводили эксперименты на процессорах.Однако, учитывая тот факт, что мы использовали тот же метод для бинаризации, что и в [5], следует ожидать аналогичных улучшений с точки зрения скорости, порядка 58x: поскольку для оцениваемой сети требуется 0,67 секунды, чтобы выполнить прямой переход наi7-3820, использующий одно ядро, ускорение, близкое к x58, позволит системе работать в режиме реального времени.С точки зрения сжатия памяти, устраняя смещения, которые оказывают минимальное влияние (или не влияют вообще) на производительность, и группируя и сохраняя каждые 32 веса в одной переменной, мы можем достичь степени сжатия 39x по сравнению с единичнымПрецизионный аналог Torch.

В этом контексте небольшая модель (по количеству параметров или размеру модели в MiB) не обязательно означает низкий объем памяти.Вполне вероятно, что вся эта память используется для хранения карт активации с одинарной или двойной точностью.

...