Khó khăn trong việc thực hiện song song Smalltalk là gì?

Question

Với mô hình lõi của các đối tượng là các công cụ tính toán độc lập (lưu trữ là các thể hiện vars, CPU là các phương thức lớp) trả lời các thông điệp được truyền từ một đến khác, có vẻ như Smalltalk sẽ phù hợp với việc xử lý song song số lõi. Tuy nhiên, đây là một lĩnh vực mà Smalltalk vẫn còn rất yếu, trả lời trên các tính năng đa nhiệm mô phỏng của riêng nó mà không khai thác khả năng phần cứng của bộ vi xử lý hiện đại.

Tại sao điều này? Các vấn đề chính là gì? Có phải sự biến đổi là chìa khóa, hay nó là cái gì đó cụ thể hơn cho Smalltalk?

Answer 1

Trước hết, hãy nhớ lại rằng GemStone chứng minh rằng Smalltalk có thể được mở rộng để hỗ trợ tính toán song song. Tất nhiên, câu hỏi vẫn còn bởi vì GemStone là một hệ thống rất tinh vi (suy nghĩ, ví dụ, trong Bộ sưu tập rác!) Và tất cả các phương ngữ khác không hành xử theo cách đó.

Tính toán song song yêu cầu mã an toàn chủ đề; nếu không các điều kiện chủng tộc sẽ xuất hiện mọi lúc. Vấn đề là làm cho luồng mật mã của Smalltalk sẽ thêm sự phức tạp ở khắp mọi nơi. Hãy xem xét ví dụ

OrderedCollection >> addLast: anObject 
    lastIndex = array size ifTrue: [self makeRoomAtLast]. 
    lastIndex := lastIndex + 1. 
    ^array at: lastIndex put: newObject 

Việc gián đoạn giữa các dòng mã này có thể khiến trạng thái nội bộ của người nhận không nhất quán. Tất nhiên, điều này cũng có thể xảy ra với việc thực thi không song song vì Smalltalk hỗ trợ gián đoạn. Tuy nhiên, cách Smalltalk sử dụng khả năng này được giới hạn trong các phần quan trọng không xảy ra thường xuyên và do đó bằng cách nào đó được kiểm soát.

Lý do tại sao việc thêm mã an toàn chủ đề không quá tự nhiên trong Smalltalk là trong Smalltalk, chúng tôi có một hình ảnh. Điều này có nghĩa rằng có rất nhiều đối tượng được chia sẻ bởi tất cả các quy trình, bao gồm tất cả các lớp, các phương thức được biên dịch, vv Bản chất động của Smalltalk, được sử dụng rộng rãi bởi hệ thống và các ứng dụng của nó.

Trong kinh nghiệm cá nhân của tôi, cách tốt để đạt được các khả năng đa lõi trong Smalltalk là khởi chạy các tiến trình OS khác nhau (các thể hiện hình ảnh không đầu) và điều phối chúng bằng các semaphores và quy trình Smalltalk. Theo cách tiếp cận này, mọi quá trình hệ điều hành được thể hiện trong hình ảnh chính (hình ảnh có giao diện người dùng) bằng quy trình Smalltalk. Giao tiếp giữa hình ảnh chính và các quy trình không đầu có thể dựa vào các ổ cắm (hoặc bất kỳ tính năng nào khác). Tất nhiên, bạn phải trả giá khi gỡ lỗi. Trong thực tế, bạn kết thúc truy tìm rất nhiều sự kiện trong các tệp nhật ký và mở các trình gỡ rối trong các quy trình "không đầu" cho đến khi bạn hiểu điều gì đã xảy ra. Nhưng có thể được thực hiện, không chỉ như một bản demo mà còn cho một sản phẩm "công nghiệp mạnh" thực sự.

Answer 2

Khó khăn? Không có

Chỉ cần khởi chạy nhiều phiên bản Pharo và yêu cầu chúng giao tiếp thông qua ổ cắm hoặc lưu dữ liệu cuối cùng của chúng vào một tệp chung. Hệ điều hành của bạn sẽ quản lý từng trường hợp và gửi nó để thực thi trong một lõi khác. OSProcess mô-đun cung cấp chức năng như vậy và đã được triển khai thành công như Hydra và RoarVM, vấn đề là không ai sử dụng chúng.

Thực ra điều khó khăn nhất của tính song song là làm cho mọi người sử dụng nó. Với các ứng dụng phần cứng ngày nay hiếm khi đạt tới 100% của một lõi đơn. Tôi đã hầu như không làm Pharo đi trên 10%.

Cũng giống như nhiều ngôn ngữ lập trình động lập trình Smalltalk là ngôn ngữ hiệu suất của nhà phát triển chứ không phải ngôn ngữ hiệu suất của ứng dụng.

Nếu bạn thực sự có vấn đề xử lý nặng như vậy, bạn nên sử dụng các ngôn ngữ như C và C++ là ngôn ngữ định hướng hiệu suất ứng dụng rất.Không chỉ theo cách của nó khó khăn hơn để sử dụng những ngôn ngữ đó nhưng ngay cả song song là rất khó để làm ngay cả với các thư viện bên phải. Phần cứng là thiết kế rất kỳ lạ khôn ngoan và có như một tấn gotchas bạn phải nhận thức được.

Và đây là lý do tại sao song song phù hợp với những ngôn ngữ lập trình đó tốt hơn. Tất nhiên bạn có thể làm cho các thư viện trong C/C++ và có Pharo hoặc smalltalks khác sử dụng chúng. Python thực hiện điều này. Python và Pharo khá giống nhau ở chỗ cả hai đều sử dụng GIL và có chuỗi màu xanh lá cây. Gotcha là bạn sẽ phải tham gia các chủ đề của bạn trở lại chủ đề chính để máy ảo có thể truy cập trực tiếp vào nó nhưng có những cách xung quanh như tôi đã nói, giao tiếp socket, đường ống, các tệp được ánh xạ bộ nhớ chia sẻ và nhiều hơn nữa.

Thư viện song song của Python đều dựa trên C/C++.

Chính song song là một chủ đề rất khó, ngay cả khi bạn có song song có thể là mã của bạn sẽ chậm như chạy trên một sợi đơn và lõi đơn. Nhưng đó là một vấn đề chung với hiệu suất ứng dụng, thời điểm bạn muốn sữa ra càng nhiều sức mạnh như bạn có thể bạn phải biết làm thế nào phần cứng hoạt động.

Bản thân phần cứng ngày nay là siêu phức tạp. Ngôn ngữ là ít quan tâm nhất của bạn.

Vì vậy, hoàn toàn có thể trong Smalltalk nhưng thẳng thắn không có nhiều người quan tâm đến nó. Tôi đã thấy các câu hỏi về tính song song trong danh sách gửi thư Pharo mà tôi thường xuyên 2 năm qua, có thể một hoặc hai lần. Và ngay cả đối với đồng thời nó rất hiếm hoi cho một người nào đó để đặt một câu hỏi về nó.