Tại sao MPI được coi là khó hơn bộ nhớ chia sẻ và Erlang được coi là dễ dàng hơn, khi cả hai đều thông điệp qua?

Question

Có rất nhiều sự quan tâm những ngày này trong Erlang như một ngôn ngữ để viết các chương trình song song trên đa lõi. Tôi đã nghe mọi người cho rằng mô hình truyền thông điệp của Erlang dễ lập trình hơn là các mô hình bộ nhớ chia sẻ chi phối như luồng.

Ngược lại, trong cộng đồng máy tính hiệu năng cao, mô hình lập trình song song thống trị là MPI, cũng thực hiện mô hình truyền thông điệp. Nhưng trong thế giới HPC, mô hình thông điệp này thường được coi là rất khó để lập trình và mọi người cho rằng các mô hình bộ nhớ được chia sẻ như OpenMP hoặc UPC dễ dàng hơn để lập trình.

Có ai biết tại sao có một khác biệt trong nhận thức về thông điệp đi qua so với bộ nhớ chia sẻ trong thế giới CNTT và HPC? Có phải do một số khác biệt cơ bản trong cách Erlang và MPI thực hiện truyền thông điệp làm cho thông điệp kiểu Erlang truyền qua dễ dàng hơn nhiều so với MPI không? Hay có lý do nào khác?

Answer 1

Tôi đồng ý với tất cả các câu trả lời trước đây, nhưng tôi nghĩ điểm mấu chốt không được làm hoàn toàn rõ ràng là một lý do khiến MPI có thể được coi là khó và Erlang dễ dàng là kết hợp của mô hình với miền.

Erlang dựa trên khái niệm bộ nhớ cục bộ, thông báo không đồng bộ và trạng thái chia sẻ được giải quyết bằng cách sử dụng một số dạng cơ sở dữ liệu toàn cục mà tất cả các chuỗi có thể truy cập. Nó được thiết kế cho các ứng dụng không di chuyển toàn bộ nhiều dữ liệu xung quanh, và điều đó không phải là vụ nổ ra một nút riêng biệt 100k cần phối hợp.

MPI được dựa trên bộ nhớ cục bộ và thông điệp đi qua và dành cho các sự cố khi di chuyển dữ liệu xung quanh là phần chính của miền. Máy tính hiệu suất cao là rất nhiều về việc lấy số liệu cho một vấn đề, và chia nó ra giữa một loạt các tài nguyên tính toán. Và đó là một công việc khá khó khăn trong một hệ thống truyền thông điệp vì dữ liệu phải được phân phối một cách rõ ràng với sự cân bằng trong đầu. Về cơ bản, Bộ KH & ĐT có thể được xem như là một sự truy cập đáng buồn mà bộ nhớ chia sẻ không mở rộng. Và nó đang nhắm mục tiêu tính toán hiệu suất cao trải rộng trên 100k bộ vi xử lý trở lên.

Erlang không cố gắng đạt được hiệu suất cao nhất có thể, thay vì phân hủy một vấn đề song song tự nhiên thành các chuỗi tự nhiên của nó. Nó được thiết kế với một loại nhiệm vụ lập trình hoàn toàn khác so với MPI. Vì vậy, Erlang là tốt nhất so với pthreads và các giải pháp chủ đề không đồng nhất khác địa phương, chứ không phải là MPI mà thực sự nhằm vào một vấn đề rất khác nhau (và một mức độ nào đó vốn khó khăn hơn) thiết lập.

Answer 2

Về MPI vs OpenMP/UPC: MPI buộc bạn cắt vấn đề thành từng phần nhỏ và chịu trách nhiệm di chuyển dữ liệu xung quanh. Với OpenMP/UPC, "tất cả dữ liệu là có", bạn chỉ cần phải dereference một con trỏ. Ưu điểm của MPI là 32-512 cụm CPU rẻ hơn nhiều so với 32-512 CPU đơn. Ngoài ra, với MPI chi phí là trả trước, khi bạn thiết kế các thuật toán. OpenMP/UPC có thể ẩn các độ trễ mà bạn sẽ nhận được khi chạy, nếu hệ thống của bạn sử dụng NUMA (và tất cả các hệ thống lớn đều làm) - chương trình của bạn sẽ không mở rộng và sẽ mất một lúc để tìm hiểu lý do.

Answer 3

Song song trong Erlang vẫn còn khá khó thực hiện. Bằng cách đó tôi có nghĩa là bạn vẫn phải tìm ra cách chia nhỏ vấn đề của mình, nhưng có một vài điều nhỏ giúp giảm bớt khó khăn này khi so sánh với một số thư viện MPI trong C hoặc C++.

Đầu tiên, vì thông điệp qua Erlang là một tính năng ngôn ngữ hạng nhất, đường cú pháp làm cho nó dễ dàng hơn.

Ngoài ra, thư viện Erlang đều được xây dựng xung quanh thông điệp của Erlang. Cấu trúc hỗ trợ này giúp bạn tăng cường vào vùng đất song song. Hãy xem components of OTP như gen_server, gen_fsm, gen_event. Đây là những cấu trúc rất dễ sử dụng có thể giúp chương trình của bạn trở nên song song.

Tôi nghĩ rằng tính linh hoạt của thư viện chuẩn sẵn có khác biệt với thông điệp của erlang đi qua các triển khai MPI khác, không thực sự là bất kỳ tính năng cụ thể nào của ngôn ngữ.

Answer 4

Tôi nghĩ rằng nó có liên quan đến tâm trí khi bạn lập trình với MPI và khi bạn đang lập trình với Erlang. Ví dụ, MPI không được tích hợp sẵn trong ngôn ngữ trong khi Erlang có hỗ trợ tích hợp để truyền thông điệp. Một lý do khác có thể là ngắt kết nối giữa chỉ gửi/nhận tin nhắn và giải pháp phân vùng vào các đơn vị thực thi đồng thời.

Với Erlang, bạn buộc phải suy nghĩ trong một khung lập trình chức năng nơi dữ liệu thực sự nén từ cuộc gọi hàm đến hàm gọi - và nhận là một hành động hoạt động giống như một cấu trúc bình thường trong ngôn ngữ. Điều này cho phép bạn kết nối chặt chẽ hơn giữa tính toán bạn thực sự thực hiện và hành động gửi/nhận tin nhắn.

Với MPI, mặt khác, bạn buộc phải suy nghĩ đơn thuần về thông điệp thực sự đi qua nhưng không thực sự phân hủy công việc. Khung suy nghĩ này đòi hỏi phần nào chuyển đổi ngữ cảnh giữa viết giải pháp và cơ sở hạ tầng nhắn tin trong mã của bạn.

Thảo luận có thể tiếp tục nhưng quan điểm chung là nếu cấu trúc cho thông điệp được chuyển vào ngôn ngữ lập trình và mô hình mà bạn đang sử dụng, thường là cách tốt hơn để thể hiện giải pháp so với được "tacked on" hoặc tồn tại dưới dạng tiện ích bổ sung cho ngôn ngữ (dưới dạng thư viện hoặc tiện ích mở rộng).

Answer 5

Có ai biết tại sao có sự khác biệt như vậy trong nhận thức truyền tin nhắn so với bộ nhớ dùng chung trong thế giới CNTT và HPC? Có phải do một số khác biệt cơ bản trong cách Erlang và MPI thực hiện truyền thông điệp làm cho thông điệp kiểu Erlang truyền qua dễ dàng hơn nhiều so với MPI không? Hay có lý do nào khác?

Lý do chỉ đơn giản là song song và đồng thời. Erlang được lai tạo cho lập trình đồng thời. HPC là tất cả về lập trình song song. Đây là những mục tiêu liên quan nhưng khác nhau.

Lập trình đồng thời rất phức tạp bởi luồng kiểm soát không xác định lớn và độ trễ thường là mục tiêu quan trọng. Việc sử dụng cấu trúc dữ liệu bất biến của Erlang giúp đơn giản hóa việc lập trình đồng thời.

Lập trình song song có luồng điều khiển đơn giản hơn nhiều và mục tiêu là tất cả về tổng thông lượng tối đa và không phải là độ trễ. Sử dụng bộ nhớ cache hiệu quả là quan trọng hơn nhiều ở đây, điều này làm cho cả cấu trúc dữ liệu không thay đổi và Erlang phần lớn không phù hợp. Việc chia sẻ bộ nhớ chia sẻ vừa dễ xử lý vừa tốt hơn trong ngữ cảnh này. Trong thực tế, kết hợp bộ nhớ cache đang cung cấp thông báo tăng tốc phần cứng cho bạn.

Cuối cùng, ngoài những khác biệt về mặt kỹ thuật đó cũng là một vấn đề chính trị. Các Erlang guys đang cố gắng để đi xe hype đa lõi bằng cách giả vờ rằng Erlang có liên quan đến đa lõi khi nó không phải là. Đặc biệt, họ đang chào hàng khả năng mở rộng tuyệt vời vì vậy nó là điều cần thiết để xem xét hiệu suất tuyệt đối là tốt. Erlang quy mô dễ dàng từ hiệu suất tuyệt đối kém trên một lõi đến hiệu năng tuyệt đối kém trên bất kỳ số lõi nào.Như bạn có thể hình dung, điều đó không gây ấn tượng với cộng đồng HPC (nhưng nó phù hợp với nhiều mã đồng thời).

Answer 6

Thông thường đồng thời trong HPC có nghĩa là làm việc với lượng lớn dữ liệu. Loại song song này được gọi là data parallelism và thực sự dễ thực hiện hơn bằng cách sử dụng cách tiếp cận bộ nhớ chia sẻ như OpenMP, bởi vì hệ điều hành sẽ xử lý những thứ như lên lịch và sắp xếp các tác vụ, mà sẽ phải tự thực hiện nếu sử dụng mô hình truyền thông điệp.

Ngược lại, Erlang được thiết kế để đối phó với task parallelism gặp phải trong các hệ thống điện thoại, nơi các đoạn mã khác nhau phải được thực hiện đồng thời với số lượng giới hạn giao tiếp và yêu cầu mạnh mẽ về khả năng chịu lỗi và phục hồi.

Mô hình này tương tự như hầu hết mọi người sử dụng PThread. Nó phù hợp với các ứng dụng như máy chủ web, trong đó mỗi yêu cầu có thể được xử lý bởi một luồng khác nhau, trong khi các ứng dụng HPC thực hiện khá nhiều điều tương tự với lượng dữ liệu khổng lồ cũng phải được trao đổi giữa các công nhân.

Answer 7

Bài viết này thực sự giải thích rõ ràng, Erlang là tốt nhất khi chúng tôi gửi các mẩu dữ liệu nhỏ arround và MPI hoạt động tốt hơn trên nhiều thứ phức tạp hơn. Cũng Mô hình Erlang là dễ hiểu :-)

Erlang Versus MPI - Final Results and Source Code