Ý nghĩa của thời gian đầu vào đồng thời của luồng trong đầu ra profiler là gì?

Question

Tôi thực sự đánh giá cao nếu ai đó có trải nghiệm tốt về Bộ khuếch đại Intel VTune cho tôi biết về điều này.

Gần đây tôi đã nhận được báo cáo phân tích hiệu suất từ ​​những người khác đã sử dụng Bộ khuếch đại Intel VTune chống lại chương trình của tôi. Nó cho biết, có thời gian trên cao trong khu vực đồng thời của luồng.

Ý nghĩa của Thời gian trên cao là gì? Họ không biết (hỏi tôi), tôi không có quyền truy cập vào Bộ khuếch đại Intel VTune.

Tôi có ý tưởng mơ hồ. Chương trình này có rất nhiều cuộc gọi chủ đề giấc ngủ vì pthread condition là không ổn định (hoặc tôi đã làm xấu) trong nền tảng mục tiêu vì vậy tôi thay đổi nhiều thói quen để làm việc trong giao diện vòng lặp như dưới đây:

while (true) 
{ 
    mutex.lock(); 
    if (event changed) 
    { 
     mutex.unlock(); 
     // do something 
     break; 
    } 
    else 
    { 
     mutex.unlock(); 
     usleep(3 * 1000); 
    } 
} 

này có thể được gắn cờ là Overhead Thời gian?

Bạn có lời khuyên nào không?

---

tôi tìm thấy sự giúp đỡ tài liệu về Overhead Time từ trang web của Intel. http://software.intel.com/sites/products/documentation/hpc/amplifierxe/en-us/win/ug_docs/olh/common/overhead_time.html#overhead_time

Trích:

thời gian trên cao là một khoảng thời gian bắt đầu với việc phát hành của một tài nguyên chia sẻ và kết thúc với việc tiếp nhận nguồn tài nguyên đó. Lý tưởng nhất, thời gian Overhead time rất ngắn vì nó làm giảm thời gian mà một thread phải đợi để có được một tài nguyên. Tuy nhiên, không phải tất cả thời gian CPU trong một ứng dụng song song có thể được chi cho việc thực hiện tải công việc thực. Trong trường hợp khi thời gian chạy song song (khối xây dựng luồng Intel®, OpenMP *) được sử dụng không hiệu quả, một phần đáng kể thời gian có thể được sử dụng trong thời gian CPU lãng phí thời gian chạy song song ở mức đồng thời cao. Ví dụ, điều này có thể dẫn đến mức độ phân chia công việc thấp trong các thuật toán song song đệ quy: khi kích thước tải công việc trở nên quá thấp, chi phí cho việc phân chia công việc và thực hiện công việc vệ sinh trở nên đáng kể.

Vẫn còn khó hiểu .. Có thể nó có nghĩa là "bạn đã thực hiện khóa không cần thiết/quá thường xuyên"?

Answer 1

Xin lỗi, tôi không phải là chuyên gia về pthread hoặc Bộ khuếch đại Intel VTune, nhưng có, khóa một mutex và mở khóa nó có thể được tính là thời gian trên cao.

Khóa và mở khóa các mutex có thể được thực hiện dưới dạng cuộc gọi hệ thống, mà trình thu thập thông tin có thể chỉ một lần theo luồng trên không.

Answer 2

Tôi không quen với vTune nhưng có một sự chuyển đổi trên hệ điều hành trên không giữa các chủ đề. Mỗi khi một luồng dừng và một tải khác trên một bộ xử lý, bối cảnh luồng hiện tại cần phải được lưu trữ để nó có thể được phục hồi khi luồng tiếp theo chạy và ngữ cảnh của luồng mới cần được phục hồi để nó có thể xử lý.

Sự cố có thể là do bạn có quá nhiều luồng và do đó bộ vi xử lý dành phần lớn thời gian chuyển đổi giữa chúng. Các ứng dụng đa luồng sẽ chạy hiệu quả nhất nếu có cùng số luồng với bộ xử lý.

Answer 3

Tôi cũng không phải là một chuyên gia về điều đó, mặc dù tôi đã cố sử dụng pthread một chút.

Để chứng minh sự hiểu biết của tôi về thời gian trên không, chúng ta hãy lấy ví dụ về một chương trình đơn luồng đơn giản để tính toán một khoản tiền mảng:

for(i=0;i<NUM;i++) { 
    sum += array[i]; 
} 

Trong một đơn giản [thực hiện một cách hợp lý] đa luồng phiên bản đó mã, mảng có thể được chia thành một mảnh cho mỗi chủ đề, mỗi chủ đề giữ tổng của riêng nó, và sau khi các chủ đề được thực hiện, tổng được tổng hợp.

Trong phiên bản đa luồng được viết rất kém, mảng có thể được chia nhỏ như trước và mỗi chuỗi có thể atomicAdd thành tổng số toàn cầu.

Trong trường hợp này, việc bổ sung nguyên tử chỉ có thể được thực hiện bởi một luồng tại một thời điểm. Tôi tin rằng thời gian trên không là thước đo thời gian tất cả các chủ đề khác chi tiêu trong khi chờ đợi để tự mình thực hiện atomicAdd của riêng mình (bạn có thể thử viết chương trình này để kiểm tra xem bạn có chắc chắn).

Tất nhiên, nó cũng tính đến thời gian cần để đối phó với việc chuyển đổi các ẩn dụ và các mutex xung quanh. Trong trường hợp của bạn, nó có thể có nghĩa là một lượng đáng kể thời gian được dành cho các bên trong của mutex.lock và mutex.unlock.

Tôi đã song song một phần mềm cách đây một thời gian (sử dụng pthread_barrier) và gặp sự cố mất nhiều thời gian hơn để chạy các rào cản so với chỉ sử dụng một chuỗi. Hóa ra là vòng lặp phải có 4 rào cản trong nó đã được thực hiện một cách nhanh chóng, đủ để làm cho chi phí không đáng giá.