Các cách trực quan hóa dữ liệu sự kiện để tìm kiếm các vấn đề về hiệu suất

Tôi đang cố gắng tối ưu hóa một ứng dụng MPI với mẫu truyền thông không đồng bộ cao. Mỗi cấp bậc có một danh sách những thứ cần tính toán và gửi tin nhắn khi cần thiết nếu đầu vào hoặc đầu ra nằm trên một thứ hạng khác nhau. Ngoài ra, mỗi cấp bậc được phân luồng (hiện có một luồng giao tiếp và 5 công nhân).

Tôi đã gắn mã với các bộ định thời xung quanh các phần mã hiệu suất quan trọng khác nhau, cung cấp cho tôi danh sách các bộ ba (bắt đầu, kết thúc, loại) cho mỗi luồng. Được vẽ theo cách rõ ràng, với thời gian là trục ngang, xếp hạng và luồng là dọc và màu sắc cho biết mỗi luồng đang làm gì, tôi nhận được một hình ảnh như thế này trong 16 cấp bậc với 6 luồng / xếp hạng:

Câu hỏi của tôi là: những cách khác để hình dung dữ liệu này có thể giúp giảm bớt các vấn đề về hiệu suất? Có ai có loại cốt truyện yêu thích mà họ sử dụng khi định hình các ứng dụng không đồng bộ không?

Tập dữ liệu này bị giới hạn ở chỗ nó không biết cấu trúc dataflow, nhưng tôi muốn tìm hiểu sâu hơn về nó càng tốt trước khi cố gắng thu thập một cái gì đó phức tạp hơn.

Hình ảnh không nén ở đây trong trường hợp bất cứ ai muốn nhìn xung quanh (không thể tải lên qua tuyến đường bình thường). Thật không may, Firefox không chấp nhận mặc dù tôi tin rằng nó hợp lệ, có thể vì đơn giản là nó quá lớn.

Tôi dành nhiều thời gian để viết và gỡ lỗi mã song song, cả với bộ nhớ chia sẻ và / hoặc bộ nhớ phân tán, nhưng không biết vấn đề cụ thể của bạn, tôi chỉ có thể cho bạn biết cái gì phù hợp nhất với tôi.

Biết những thói quen nào mất bao nhiêu thời gian là một điều quan trọng nếu bạn đang xem xét hiệu quả tính toán, nhưng nếu bạn lo lắng về hiệu quả song song, thì bạn nên lo lắng hơn về việc mã của bạn đang làm gì khi nó không thực hiện bất kỳ tính toán nào. Kiểu như lo lắng những gì bọn trẻ đang làm khi nó quá yên tĩnh ...

Vì bạn đang sử dụng một cách tiếp cận bộ nhớ chia sẻ / phân phối lai, tôi đoán rằng mã của bạn, trong các khoảng trống, đang chờ cuộc gọi MPI hoặc trên biến mutex / condition. Bạn cũng có thể kết thúc các cuộc gọi này trong bộ tính giờ và điều đó sẽ cho bạn hình dung rõ hơn về những gì đang làm bạn chậm lại, ví dụ nếu nó luôn luôn có cùng điều kiện hoặc luôn giống như MPI_REDUCEcác chủ đề của bạn bị mắc kẹt.

Một phần mềm tôi sử dụng khá thường xuyên là Bộ khuếch đại Intel Vtune XE . Nó có một tính năng / tùy chọn vẽ đồ họa đẹp mắt để hiển thị đồng thời luồng. Chương trình sẽ vẽ một cốt truyện rất giống với cốt truyện của bạn, nhưng khi một luồng chờ trên biến mutex hoặc biến điều kiện, nó sẽ vẽ một đường chéo từ luồng chờ, tại thời điểm nó bắt đầu chờ, đến luồng thực sự phát hành mutex hoặc được báo hiệu điều kiện nó đang chờ đợi, tại thời điểm nó được phát hành / báo hiệu. Điều này có thể khá lộn xộn, nhưng nó làm cho nút cổ chai xuất hiện ngay lập tức.

Cuối cùng, tôi cũng thu thập số liệu thống kê hàng loạt, ví dụ cho mỗi cuộc gọi mutex / signal / MPI, thời gian chờ trung bình và tối đa là bao nhiêu? Biểu đồ của thời gian chờ thu thập là gì? Mặc dù cốt truyện cung cấp cho bạn một cái nhìn tổng quan đẹp, nhưng nó có thể trở nên khá lộn xộn khi đi vào các chi tiết tốt.

Cuối cùng, một câu hỏi không nên đánh giá thấp: Làm thế nào để bạn thu thập thời gian của mình? Là bộ đếm thời gian của bạn không đủ xâm nhập để không ảnh hưởng đến mã của bạn? Tôi sử dụng số lệnh CPU bất cứ khi nào có thể, tức là RDTSCtrên các kiến ​​trúc x86. Điều này thường chỉ thêm một hướng dẫn duy nhất vào mã của bạn.

Đôi khi bạn có thể có được một cái nhìn khác về các vấn đề hiệu năng thông qua phân tích tài nguyên cấp cao: Có một tắc nghẽn liên quan như băng thông bộ nhớ không? Có phải mọi chủ đề công nhân làm cùng một lượng công việc? Dữ liệu này có thể được thu thập dễ dàng với ví dụ như từ bộ công cụ LIKWID của dự án mã LIKWID . Nếu hồ sơ đó tồn tại nhiều điểm nóng khác nhau, bạn có thể phải giải quyết từng điểm một. Cũng có thể có các vấn đề khác nhau, tùy thuộc vào số lượng chủ đề / quy trình được sử dụng.

Khi tôi gặp vấn đề trong một mạng gồm các quy trình không đồng bộ cao bị chi phối bởi các thông điệp hoặc sự kiện, tôi sử dụng một phương pháp không dễ dàng nhưng hiệu quả. Nó liên quan đến việc lấy các bản ghi thời gian của các quy trình, hợp nhất chúng vào dòng thời gian chung và theo dõi tiến trình của một số tin nhắn khi chúng kích hoạt các hoạt động, kích hoạt các tin nhắn tiếp theo. Điều tôi đang tìm kiếm là sự chậm trễ giữa thời gian nhận được tin nhắn và thời gian nhận được tin nhắn và hiểu lý do của sự chậm trễ. Khi một vấn đề được tìm thấy, nó đã được sửa chữa và quá trình được lặp lại. Bằng cách này, bạn có thể có được hiệu suất thực sự thỏa mãn.

Điều quan trọng là phải xem điều này khác với các phương pháp mà bạn đo lường, đo lường, đo lường như thế nào. Điều duy nhất đo lường có thể hình dung cho bạn biết là không nhìn vào đâu. Điều chỉnh hiệu suất thực sự đòi hỏi phải xem xét kỹ các chi tiết, từ góc độ thời gian. Những gì bạn đang tìm kiếm không phải là nơi dành thời gian, mà là nơi nó được sử dụng không cần thiết.

Chúc may mắn.