2013-05-15 21 views
16

Một đoạn mã mà mất hơn 1 phút trên dòng lệnh đã được thực hiện chỉ trong vài giây trong NVIDIA trực quan Profiler (chạy .exe cùng). Vì vậy, câu hỏi tự nhiên là tại sao? Có điều gì đó sai trái với dòng lệnh, hay Visual Profiler làm một cái gì đó khác nhau và không thực sự thực hiện tất cả mọi thứ như trên dòng lệnh?Tại sao mã CUDA chạy nhanh hơn rất nhiều trong NVIDIA Visual Profiler?

Tôi đang sử dụng CUBLAS, Thrust và cuRAND.

Ngẫu nhiên, có một sự chậm trễ đáng chú ý trong mã được biên dịch trên máy của tôi rất gần đây, thậm chí mã cũ trước đó đã chạy nhanh, do đó tôi nhận được sự nghi ngờ.

Cập nhật:

  • Tôi đã kiểm tra rằng tính sản lượng trên dòng lệnh và Visual Profiler là giống hệt - ví dụ: tất cả các mã cần thiết đã được chạy trong cả hai trường hợp.
  • Cá mập GPU chỉ ra rằng trạng thái hiệu suất của chúng tôi là không thay đổi tại P0 khi tôi chuyển từ dòng lệnh sang Visual Profiler.
  • Tuy nhiên, GPU sử dụng đã được báo cáo tại 0.0% khi chạy với trực quan Profiler, nhưng đã cao như 98% khi chạy off line lệnh.
  • Hơn nữa, đến nayít bộ nhớ hơn được sử dụng với Visual Profiler. Khi chạy khỏi dòng lệnh, trình quản lý tác vụ cho biết mức sử dụng 650-700MB bộ nhớ (tăng đột biến tại cuộc gọi cudaFree(0) đầu tiên). Trong Visual Profiler con số đó giảm xuống ~ 100MB.
+0

Đăng đoạn mã có thể giúp ích rất nhiều. –

+2

Vâng, đoạn mã được đề cập thực sự là một dự án trải rộng 15 tệp phụ thuộc lẫn nhau, vì vậy có thể nằm ngoài phạm vi của câu hỏi này. Tôi chỉ đơn giản là tự hỏi nếu có ai khác đã gặp phải hiện tượng Visual Profiler và đã có một lời giải thích cho nó. – mchen

+12

Các trình biên dịch CUDA (Nsight VSE, Visual Profiler, nvprof, và trình biên dịch dòng lệnh CUDA) đặt GPU ở trạng thái P cao nhất để đảm bảo các kết quả nhất quán. Điều này không nên tạo sự khác biệt nhiều hơn một vài phần trăm. Nguyên nhân nhiều khả năng là ứng dụng của bạn bị lỗi khi bạn chạy trình lược tả. Vui lòng xác nhận rằng ứng dụng của bạn chạy đến khi hoàn thành và không có lỗi nào xảy ra? –

Trả lời

0

Điều này không nên xảy ra. Tôi chưa bao giờ thấy bất cứ điều gì giống như nó; có lẽ một cái gì đó trong thiết lập của bạn.

0

Có thể là một số JIT-compile step bị bỏ qua bởi trình hồ sơ. Điều này có thể giải thích sự khác biệt trong việc sử dụng bộ nhớ. Thử tạo một fat binary?

3

Đây là một câu hỏi cũ, nhưng tôi vừa hoàn thành việc theo đuổi cùng một vấn đề (mặc dù nguyên nhân có thể không giống nhau).

Cụ thể: ứng dụng của tôi đạt được từ 900 đến 1100 khung hình (khởi chạy đồng bộ) mỗi giây khi chạy dưới NVVP, nhưng khoảng 100-120 khi chạy ngoài hồ sơ.

Nguyên nhân có vẻ như là thông báo trạng thái mà tôi đã in tới bảng điều khiển qua cout. Tôi đã có ý định này chỉ xảy ra khoảng một lần 100-200 khung hình. Thay vào đó, nó đã in thông báo trạng thái cho mọi khung hình và giao diện điều khiển IO trở thành nút cổ chai.

Chỉ in thông báo trạng thái mỗi 100 khung hình (mặc dù số tối ưu ở đây sẽ tùy thuộc vào ứng dụng của bạn), tốc độ khung hình tăng trở lại để khớp với những gì tôi thấy trong NVVP. Tất nhiên, điều này cũng có thể được xử lý trong một chuỗi CPU riêng biệt nếu loại phí trên không thể chấp nhận được trong hoàn cảnh của bạn.

NVVP phải chuyển hướng stdout đến bộ đệm trong của chính nó để nắm bắt đầu ra của ứng dụng (nó hiển thị trong tab bảng điều khiển). Dường như cơ chế của NVVP cho việc đệm hoặc xử lý đầu ra đó có chi phí thấp hơn đáng kể so với việc cho phép hệ điều hành xử lý trực tiếp. Có vẻ như NVVP đang lưu tất cả mọi thứ và hiển thị nó trong một chuỗi riêng biệt hoặc chỉ lưu một loạt đầu ra cho đến khi đạt đến một số ngưỡng, khi nó thêm bộ đệm vào tab điều khiển của riêng nó.

Vì vậy, lời khuyên của tôi sẽ là vô hiệu hóa mọi bảng điều khiển IO và xem liệu điều đó có ảnh hưởng đến mọi thứ hay không.

(Nó không giúp mà VS2012 từ chối hồ sơ ứng dụng CUDA của tôi. Nó sẽ được tốt đẹp để thấy rằng 80% thời gian thực hiện đã được chi cho giao diện điều khiển IO.)

Hope this helps!

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