Là lập trình chức năng nhanh hơn trong đa luồng vì tôi viết những thứ khác nhau hoặc bởi vì mọi thứ được biên dịch khác nhau?

Tôi đang đi sâu vào thế giới lập trình chức năng và tôi tiếp tục đọc ở mọi nơi rằng các ngôn ngữ chức năng tốt hơn cho các chương trình đa luồng / đa lõi. Tôi hiểu cách ngôn ngữ chức năng làm rất nhiều thứ khác nhau, chẳng hạn như đệ quy , số ngẫu nhiên vv nhưng tôi dường như không thể tìm ra nếu đa luồng là nhanh hơn trong một ngôn ngữ chức năng bởi vì nó được biên soạn khác nhau hoặc vì tôi viết nó khác nhau.

Ví dụ, tôi đã viết một chương trình bằng Java thực hiện một giao thức nhất định. Trong giao thức này, hai bên gửi và nhận cho nhau hàng ngàn tin nhắn, họ mã hóa các tin nhắn đó và gửi lại chúng (và nhận chúng) nhiều lần. Như mong đợi, đa luồng là chìa khóa khi bạn giao dịch ở quy mô hàng ngàn. Trong chương trình này không có khóa liên quan .

Nếu tôi viết cùng một chương trình trong Scala (sử dụng JVM), việc triển khai này có nhanh hơn không? Nếu đúng thì tại sao? Có phải vì phong cách viết? Nếu đó là do phong cách viết, thì bây giờ Java bao gồm các biểu thức lambda, tôi không thể đạt được kết quả tương tự khi sử dụng Java với lambda? Hay là nhanh hơn vì Scala sẽ biên dịch mọi thứ khác nhau?

Lý do mọi người nói các ngôn ngữ chức năng tốt hơn cho xử lý song song là do thực tế là chúng thường tránh trạng thái đột biến. Trạng thái có thể thay đổi là "gốc rễ của mọi tội lỗi" trong bối cảnh xử lý song song; chúng làm cho nó thực sự dễ dàng chạy vào các điều kiện chủng tộc khi chúng được chia sẻ giữa các quy trình đồng thời. Giải pháp cho các điều kiện cuộc đua sau đó liên quan đến các cơ chế khóa và đồng bộ hóa, như bạn đã đề cập, gây ra chi phí thời gian chạy, vì các quá trình chờ nhau sử dụng tài nguyên được chia sẻ và độ phức tạp thiết kế lớn hơn, vì tất cả các khái niệm này có xu hướng lồng sâu trong các ứng dụng như vậy.

Khi bạn tránh trạng thái có thể thay đổi, nhu cầu đồng bộ hóa và cơ chế khóa sẽ biến mất cùng với nó. Bởi vì các ngôn ngữ chức năng thường tránh trạng thái có thể thay đổi, chúng tự nhiên hiệu quả và hiệu quả hơn để xử lý song song - bạn sẽ không có thời gian chạy của các tài nguyên được chia sẻ và bạn sẽ không có sự phức tạp trong thiết kế thường xảy ra.

Tuy nhiên, đây là tất cả sự cố. Nếu giải pháp của bạn trong Java cũng tránh được trạng thái có thể thay đổi (được chia sẻ cụ thể giữa các luồng), thì việc chuyển đổi nó sang ngôn ngữ chức năng như Scala hoặc Clojure sẽ không mang lại bất kỳ lợi ích nào về hiệu quả đồng thời, vì giải pháp ban đầu đã không có chi phí gây ra bởi các cơ chế khóa và đồng bộ.

TL; DR: Nếu một giải pháp trong Scala hiệu quả hơn trong xử lý song song so với giải pháp trong Java, thì đó không phải là do cách mã được biên dịch hoặc chạy qua JVM, mà thay vào đó vì giải pháp Java đang chia sẻ trạng thái có thể thay đổi giữa các luồng, hoặc gây ra các điều kiện chủng tộc hoặc thêm chi phí đồng bộ hóa để tránh chúng.

Sắp xếp cả hai. Nó nhanh hơn vì dễ viết mã của bạn theo cách dễ biên dịch nhanh hơn. Bạn sẽ không nhất thiết phải có sự khác biệt về tốc độ bằng cách chuyển đổi ngôn ngữ, nhưng nếu bạn đã bắt đầu với một ngôn ngữ chức năng, có lẽ bạn đã thực hiện đa luồng với nỗ lực lập trình ít hơn rất nhiều . Đồng thời, lập trình viên dễ dàng mắc lỗi phân luồng sẽ tốn tốc độ trong một ngôn ngữ bắt buộc và khó nhận ra những lỗi đó hơn rất nhiều.

Lý do là các lập trình viên bắt buộc thường cố gắng đặt tất cả các mã khóa, không có khóa vào một hộp nhỏ nhất có thể, và thoát nó càng sớm càng tốt, trở lại thế giới đồng bộ, dễ biến đổi của họ. Hầu hết các lỗi làm bạn mất tốc độ đều được thực hiện trên giao diện biên đó. Trong ngôn ngữ lập trình chức năng, bạn không phải lo lắng nhiều về việc mắc lỗi trên ranh giới đó. Hầu hết các mã gọi của bạn cũng là "bên trong hộp", có thể nói như vậy.

Lập trình hàm không tạo ra các chương trình nhanh hơn, như một quy luật chung. Những gì nó làm là để lập trình song song và đồng thời dễ dàng hơn . Có hai chìa khóa chính cho việc này:

1. Việc tránh trạng thái đột biến có xu hướng làm giảm số lượng những điều có thể sai trong một chương trình, và thậm chí còn nhiều hơn trong một chương trình đồng thời.
2. Việc tránh các nguyên thủy đồng bộ hóa dựa trên bộ nhớ và khóa có lợi cho các khái niệm cấp cao hơn có xu hướng đơn giản hóa đồng bộ hóa giữa các luồng mã.

Một ví dụ tuyệt vời của điểm # 2 là trong Haskell chúng tôi có một sự phân biệt rõ ràng giữa song song xác định so với đồng thời không xác định . Không có lời giải thích nào tốt hơn việc trích dẫn cuốn sách tuyệt vời Lập trình song song và đồng thời của Simon Marlow trong Haskell (trích dẫn từ Chương 1 ):

Một chương trình song song là một chương trình sử dụng nhiều phần cứng tính toán (ví dụ: một số lõi xử lý) để thực hiện tính toán nhanh hơn. Mục đích là đi đến câu trả lời sớm hơn, bằng cách ủy thác các phần khác nhau của tính toán cho các bộ xử lý khác nhau thực thi cùng một lúc.

Ngược lại, concurrency là một kỹ thuật cấu trúc chương trình, trong đó có nhiều luồng điều khiển. Về mặt khái niệm, các luồng điều khiển thực thi trên cùng một lúc; đó là, người dùng thấy tác dụng của chúng xen kẽ. Cho dù họ thực sự thực hiện cùng một lúc hay không là một chi tiết thực hiện; một chương trình đồng thời có thể thực thi trên một bộ xử lý thông qua thực thi xen kẽ hoặc trên nhiều bộ xử lý vật lý.

Ngoài ra, Marlow còn đề cập đến khía cạnh quyết định :

Một sự khác biệt có liên quan là giữa các mô hình lập trình xác định và không xác định . Một mô hình lập trình xác định là một mô hình trong đó mỗi chương trình chỉ có thể cho một kết quả, trong khi đó mô hình lập trình không xác định thừa nhận các chương trình có thể có kết quả khác nhau, tùy thuộc vào một số khía cạnh của việc thực hiện. Các mô hình lập trình đồng thời nhất thiết là không xác định bởi vì chúng phải tương tác với các tác nhân bên ngoài gây ra các sự kiện vào thời điểm không thể đoán trước. Tuy nhiên, Nondeterminism có một số nhược điểm đáng chú ý: Các chương trình trở nên khó khăn hơn đáng kể để kiểm tra và lý do.

Để lập trình song song, chúng tôi muốn sử dụng các mô hình lập trình xác định nếu có thể. Vì mục tiêu chỉ là đi đến câu trả lời nhanh hơn, chúng tôi thà không làm cho chương trình của chúng tôi khó gỡ lỗi hơn trong quá trình. Lập trình song song xác định là tốt nhất của cả hai thế giới: Kiểm tra, gỡ lỗi và lý luận có thể được thực hiện trên chương trình tuần tự, nhưng chương trình chạy nhanh hơn với việc bổ sung thêm bộ xử lý.

Trong Haskell, các tính năng song song và đồng thời được thiết kế xung quanh các khái niệm này. Cụ thể, những ngôn ngữ khác nhóm lại thành một bộ tính năng, Haskell chia thành hai:

• Các tính năng quyết định và thư viện cho song song .
• Các tính năng và thư viện không xác định cho đồng thời .

Nếu bạn chỉ đang cố gắng tăng tốc một tính toán thuần túy, xác định, thì việc có sự song song xác định thường giúp mọi việc dễ dàng hơn nhiều. Thường thì bạn chỉ cần làm một cái gì đó như thế này:

1. Viết một hàm tạo ra một danh sách các câu trả lời, mỗi câu trả lời rất tốn kém để tính toán nhưng không phụ thuộc nhiều vào nhau. Đây là Haskell, vì vậy các danh sách lười biếng giá trị của các yếu tố của chúng không thực sự được tính toán cho đến khi người tiêu dùng yêu cầu chúng.
2. Sử dụng thư viện Chiến lược để sử dụng song song các phần tử danh sách kết quả của hàm của bạn trên nhiều lõi.

Tôi thực sự đã làm điều này với một trong những chương trình dự án đồ chơi của tôi vài tuần trước . Thật là tầm thường khi song song hóa chương trình, điều quan trọng tôi phải làm là, thực tế, thêm một số mã có nghĩa là "tính toán các yếu tố của danh sách này song song" (dòng 90) và tôi đã tăng được thông lượng gần như tuyến tính trong một số trường hợp thử nghiệm đắt tiền hơn của tôi.

Chương trình của tôi có nhanh hơn nếu tôi sử dụng các tiện ích đa luồng dựa trên khóa thông thường không? Tôi rất nghi ngờ như vậy. Điều gọn gàng trong trường hợp của tôi đã nhận được rất nhiều tiếng vang từ rất ít. và không có rủi ro về điều kiện chủng tộc. Và điều đó, tôi sẽ khẳng định, là cách chính mà lập trình chức năng cho phép bạn viết các chương trình "nhanh hơn".

Trong Haskell, sửa đổi theo nghĩa đen là không thể nếu không có các biến có thể sửa đổi đặc biệt thông qua thư viện sửa đổi. Thay vào đó, các hàm tạo các biến họ cần cùng lúc với các giá trị của chúng (được tính toán một cách lười biếng) và rác được thu thập khi không còn cần thiết.

Ngay cả khi bạn cần các biến sửa đổi, bạn thường có thể nhận được bằng cách sử dụng một cách tiết kiệm và cùng với các biến không thể thay đổi. . hiệu suât khôn ngoan.

Điều này làm cho sự song song trong Haskell trở nên dễ dàng rất nhiều thời gian, và trên thực tế, những nỗ lực đang được thực hiện để làm cho nó tự động. Đối với mã đơn giản, sự song song và logic thậm chí có thể được tách ra.

Ngoài ra, do thực tế là thứ tự đánh giá không thành vấn đề trong Haskell, trình biên dịch chỉ tạo ra một hàng đợi những thứ cần đánh giá và gửi chúng đến bất kỳ lõi nào có sẵn, vì vậy bạn có thể tạo ra một loạt các "luồng" không thực sự trở thành chủ đề cho đến khi cần thiết Thứ tự đánh giá không quan trọng là đặc trưng của độ tinh khiết, thường đòi hỏi phải lập trình chức năng.

Đọc thêm về tính
song song trong Haskell (HaskellWiki)
Lập trình đồng thời và đa lõi trong lập trình song song và "Haskell thế giới thực"
trong Haskell của Simon Marlow