Tại sao bộ giải song song của tôi chậm hơn bộ giải tuần tự của tôi?


14

Tôi đã chơi xung quanh với PETSc và nhận thấy rằng khi tôi chạy chương trình của mình với nhiều hơn một quy trình thông qua MPI, nó dường như chạy chậm hơn ! Làm thế nào tôi có thể kiểm tra để xem những gì đang xảy ra?


Không đăng bài này như một câu trả lời vì nó thực sự là "cái gì" chứ không phải là "làm thế nào", nhưng tôi đã gặp vấn đề tương tự trong quá khứ do một đoạn mã được bảo vệ bằng mutex được truy cập từ nhiều luồng. Đôi khi bạn phải kiểm tra khóa tài nguyên được chia sẻ đằng sau hậu trường.
David Z

Câu trả lời:


13

Điều này có thể phát sinh từ các yếu tố kiến trúc :

Nếu cùng một băng thông bộ nhớ có sẵn cho cả một hoặc nhiều quá trình, thì bạn sẽ thấy hầu như không tăng tốc vì SpMV và các hoạt động đại số tuyến tính liên quan bị giới hạn băng thông bộ nhớ.

Nó cũng có thể là trường hợp mà chi phí liên lạc áp đảo bạn tính toán cục bộ. Ví dụ: trong các phương pháp lặp tuyến tính, chúng tôi khuyên bạn nên có ít nhất 10.000 ẩn số cho mỗi quy trình.

hoặc các yếu tố số :

Các điều kiện tiên quyết song song thường yếu hơn so với các đối tác nối tiếp của chúng. Ví dụ: khối Jacobi trở nên yếu hơn khi bạn sử dụng nhiều khối hơn. Vì vậy, bạn cần tính thêm thời gian dành cho các lần lặp tuyến tính thêm. Các điều kiện phi tuyến nói chung không hoạt động theo cách này, vì vậy các lần lặp Newton thường không đổi.


8

Bất cứ khi nào cố gắng song song một chương trình, bạn phải cân đối một số chi phí, nhưng chủ yếu là có

  • Chi phí chạy mỗi tính toán
  • Chi phí của bất kỳ thông tin liên lạc giữa các tính toán
  • Chi phí quản lý các tính toán đó

Nếu các tính toán của bạn song song lúng túng thì chi phí liên lạc sẽ rất thấp (chỉ đầu vào và đầu ra) và chi phí quản lý sẽ rất thấp.

Nếu bạn có sự phụ thuộc lẫn nhau giữa các tính toán, chi phí liên lạc có thể tăng lên đáng kể. Nếu bạn có một thuật toán phức tạp cần nhiều thời gian khác nhau để hoàn thành bất kỳ tính toán nào, thì độ phức tạp quản lý sẽ tăng lên, khi bạn cố gắng sử dụng hiệu quả các tài nguyên bạn có.

Như với bất kỳ hình thức tối ưu hóa, chìa khóa là điểm chuẩn. Nhìn vào cách nó hoạt động mà không cần MPI, cách nó thực hiện với MPI và một quá trình, sau đó xem cách nó chia tỷ lệ.

Nếu bạn đang chơi với CUDA, hãy thử cung cấp cho nó nhiều dữ liệu hơn. Một thử nghiệm ở đây đã dẫn đến một sự tăng tốc tiêu cực. Chúng tôi đã cung cấp cho nó dữ liệu gấp 1000 lần và phiên bản GP-GPU đã hoàn thành gần như cùng một lúc, trong khi phiên bản chạy trên CPU chính mất 1000 lần thời gian.


3

Tôi khuyên bạn nên làm như sau:

  • Tạo một hồ sơ về thời gian thực hiện mã của bạn, có và không song song. Nếu bạn nghi ngờ về cách thực hiện việc này, chúng tôi có thể giúp bạn nếu bạn mô tả mã của mình tốt hơn.

  • Bây giờ bạn có thể tập trung vào các phần chạy chậm hơn song song. Bạn nên lưu ý rằng giao tiếp giữa các quá trình có thể chậm. Giống như Mark và Sean đã chỉ ra, chỉ vì một vấn đề có thể được chia thành các luồng không có nghĩa là làm như vậy sẽ hiệu quả. Bạn phải nhìn sâu hơn vào nó. Nhưng nếu bạn cấu hình mã của mình, nó có thể giúp bạn tìm thấy bất kỳ lỗi nào hiện có. Theo quan điểm của tôi.

Nếu bạn giải thích những gì bạn đang làm chi tiết hơn, ví dụ với quy trình làm việc, ai đó có thể cung cấp cho bạn một lời giải thích tốt hơn.


@ketch: bạn nói đúng Xin lỗi và cảm ơn vì đã chú ý. Chỉnh sửa văn bản.
jbcolmenares
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.