Tensorflow: использование GPU почти всегда на уровне 0%

Я использую tenorflow с графическими процессорами Titan-X и заметил, что при запуске примера CIFAR10Volatile GPU-utilization довольно постоянный около 30%, тогда как, когда я тренирую свою собственную модель,Volatile GPU-utilization далеко не устойчивый, он почти всегда равен 0% и достигает 80/90%, а затем возвращается к 0% снова и снова.

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

Любая идея?

batch = 128 # size of the batch
x = tf.placeholder("float32", [None, n_steps, n_input])
y = tf.placeholder("float32", [None, n_classes])

# with a capacity of 100 batches, the bottleneck should not be the data feeding
queue = tf.RandomShuffleQueue(capacity=100*batch,
                  min_after_dequeue=80*batch,
                  dtypes=[tf.float32, tf.float32],
                  shapes=[[n_steps, n_input], [n_classes]])
enqueue_op = queue.enqueue_many([x, y])
X_batch, Y_batch = queue.dequeue_many(batch)

sess = tf.Session()

def load_and_enqueue(data):
    while True:
        X, Y = data.get_next_batch(batch)
        sess.run(enqueue_op, feed_dict={x: X, y: Y})

train_thread = threading.Thread(target=load_and_enqueue, args=(data))
train_thread.daemon = True
train_thread.start()

for _ in xrange(max_iter):
    sess.run(train_op)
 BiBi13 июл. 2016 г., 17:50
Для партии размером 128get_next_batch занимает примерно в 14 раз больше времени, чемsess.run(train_op)  бежать. Однако перед началом обучения я наполняю очередь 100 * пакетными примерами, так что, по крайней мере, в начале у меня должно быть хорошее использование графического процессора, не так ли?
 BiBi14 июл. 2016 г., 14:59
Да, это так, спасибо. Я удалил свои комментарии и опубликую правильный ответ на мой вопрос. Еще раз спасибо за помощь мне разобраться.
 Eric Platon12 июл. 2016 г., 12:41
Как долгоdata.get_next_batch относительно других операций? Кажется, что это единственный процесс, работающий на процессоре, и он может замедлять конвейер.
 Eric Platon14 июл. 2016 г., 14:58
Таким образом, проблема, кажется, поняла сейчас. Решение, вероятно, заключается в предварительной обработке данных, чтобы кормление происходило быстрее или быстрее, чем обучение. Обратите внимание, что сложные модели могут быть намного медленнее ...
 Eric Platon13 июл. 2016 г., 23:24
Если обучение происходит на порядок быстрее, чем подача, возможно, что операция удаления из очереди ждет большую часть времени, то есть часть, запускаемая графическим процессором (train_op) ожидает запуска процессора (дляload_and_enqueue). Мне пока не ясно, каково взаимодействие сmin_after_dequeue, хоть. Как насчет запуска всего на процессоре (то есть нет темы), а посмотреть, будет ли использование более плавным?

Ответы на вопрос(1)

Решение Вопроса

я нашел ответ и опубликовал его, поскольку он может быть полезен для кого-то еще

Первый,get_next_batch примерно в 15 раз медленнее, чемtrain_op (спасибо Эрику Платону за указание на это).

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

Но на самом деле, обучение начинается, как только очередь достигаетmin_after_dequeue Примеры. Таким образом, очередь удаляется из очереди, как только очередь достигаетmin_after_dequeue примеры для запускаtrain_opи так как время подачи очереди в 15 раз медленнее, чем время выполненияtrain_opколичество элементов в очереди падает нижеmin_after_dequeue сразу после первой итерацииtrain_op иtrain_op должен ждать очереди сноваmin_after_dequeue Примеры.

Когда я заставляюtrain_op ждать, пока очередь не набьетcapacity (сcapacity = 100*batch) вместо автоматического запуска при достиженииmin_after_dequeue (сmin_after_dequeue=80*batch), использование графического процессора остается стабильным в течение примерно 10 секунд, а затем возвращается к 0%, что понятно, поскольку очередь достигаетmin_after_dequeue Пример менее чем за 10 секунд.

Ваш ответ на вопрос