2016-07-11 33 views
5

Tôi đang sử dụng tensorflow với Titan-X GPU và tôi đã nhận thấy rằng, khi tôi chạy ví dụ CIFAR10, Volatile GPU-utilization là khá ổn định khoảng 30%, trong khi khi tôi đào tạo mô hình của riêng tôi, các Volatile GPU-utilization là xa ổn định, nó gần như luôn luôn là 0% và gai ở 80/90% trước khi trở lại 0%, hơn và hơn nữa.Tensorflow: GPU Utilization hầu như luôn ở 0%

Tôi nghĩ rằng hành vi này là do cách tôi đang cho dữ liệu vào mạng (tôi đã tìm nạp dữ liệu sau mỗi bước, mất một thời gian). Nhưng sau khi thực hiện một hàng đợi để nạp dữ liệu và tránh độ trễ giữa các bước, vấn đề vẫn tồn tại (xem bên dưới cho hệ thống xếp hàng).

Bất kỳ ý tưởng nào?

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) 
+0

Dữ liệu 'data.get_next_batch' có liên quan đến các hoạt động khác trong bao lâu? Nó có vẻ là chỉ chạy trên CPU, và nó có thể làm chậm đường ống. –

+0

Đối với một loạt các kích thước 128 'get_next_batch' mất khoảng 14 x nhiều thời gian hơn' sess.run (train_op) 'để chạy. Tuy nhiên, trước khi bắt đầu đào tạo, tôi nạp hàng đợi với các ví dụ hàng loạt 100 *, vì vậy ít nhất là lúc đầu tôi nên sử dụng một số GPU tốt, phải không? – BiBi

+0

Nếu việc đào tạo có tốc độ nhanh hơn tốc độ cho ăn, có thể hoạt động khử nước đang chờ đợi hầu hết thời gian, nghĩa là phần chạy GPU ('train_op') đợi chuỗi chạy CPU (cho' load_and_enqueue '). Tuy nhiên, tôi vẫn chưa rõ ràng về sự tương tác với 'min_after_dequeue'. Làm thế nào về chạy tất cả trên CPU (* tức là * không có thread), và xem nếu việc sử dụng mượt mà hơn? –

Trả lời

9

Sau khi thực hiện một số thử nghiệm, tôi đã tìm thấy câu trả lời để tôi đăng câu hỏi vì nó có thể hữu ích cho người khác.

Đầu tiên, get_next_batch chậm hơn khoảng 15x so với train_op (nhờ Eric Platon để chỉ ra điều này).

Tuy nhiên, tôi cho rằng hàng đợi đang được nạp tới capacity và chỉ sau khi khóa đào tạo được bắt đầu. Do đó, tôi nghĩ rằng ngay cả khi get_next_batch chậm hơn, hàng đợi sẽ ẩn độ trễ này, trong đầu ít nhất, vì nó giữ các ví dụ capacity và nó sẽ chỉ cần tìm nạp dữ liệu mới sau khi nó đạt đến số min_after_dequeue thấp hơn capacity và nó sẽ dẫn đến việc sử dụng GPU ổn định.

Nhưng thực tế, quá trình đào tạo bắt đầu ngay khi hàng đợi đạt đến các ví dụ min_after_dequeue. Do đó, hàng đợi đang được giải phóng ngay sau khi hàng đợi đạt đến các ví dụ min_after_dequeue để chạy train_op và do thời gian nạp hàng đợi chậm hơn 15x so với thời gian thực hiện train_op, số lượng phần tử trong hàng đợi giảm xuống dưới min_after_dequeue ngay sau lần lặp đầu tiên của số train_op và số train_op phải chờ hàng đợi để đạt được lại các ví dụ min_after_dequeue.

Khi tôi buộc train_op đợi cho đến khi hàng đợi được đưa lên đến capacity (với capacity = 100*batch) thay vì bắt đầu tự động khi nó đạt đến min_after_dequeue (với min_after_dequeue=80*batch), việc sử dụng GPU là ổn định cho như 10 giây trước khi trở lại 0 %, có thể hiểu được vì hàng đợi đạt đến ví dụ min_after_dequeue trong vòng chưa đầy 10 giây.

Các vấn đề liên quan