Trường hợp so với lõi khi sử dụng EC2

Làm việc trên các dự án thường có thể được gọi là dự án "dữ liệu trung bình", tôi đã có thể song song mã của mình (chủ yếu để lập mô hình và dự đoán trong Python) trên một hệ thống duy nhất ở mọi nơi từ 4 đến 32 lõi. Bây giờ tôi đang xem xét mở rộng các cụm trên EC2 (có thể là với StarCluster / IPython, nhưng cũng mở cho các đề xuất khác), và đã bị bối rối bởi cách điều hòa công việc phân phối trên các lõi trên một ví dụ so với các trường hợp trên một cụm.

Nó thậm chí còn thiết thực để song song giữa các phiên bản cũng như giữa các lõi trên mỗi phiên bản? Nếu vậy, bất cứ ai cũng có thể đưa ra một bản tóm tắt nhanh chóng về ưu điểm + nhược điểm của việc chạy nhiều phiên bản với một vài lõi so với một vài trường hợp có nhiều lõi? Có một quy tắc ngón tay cái nào để chọn tỷ lệ đúng của các thể hiện cho các lõi trên mỗi thể hiện không?

Băng thông và RAM là những mối quan tâm không hề nhỏ trong các dự án của tôi, nhưng thật dễ dàng nhận ra khi đó là những điểm nghẽn và điều chỉnh. Khó hơn nhiều, tôi tưởng tượng, để chuẩn hóa sự pha trộn đúng lõi cho các trường hợp mà không cần kiểm tra lặp lại, và các dự án của tôi thay đổi quá nhiều cho bất kỳ thử nghiệm đơn lẻ nào áp dụng cho mọi trường hợp. Cảm ơn trước và nếu tôi thất bại trong việc tìm kiếm cái này đúng cách, vui lòng chỉ cho tôi câu trả lời đúng ở một nơi khác!

Khi sử dụng IPython, bạn gần như không phải lo lắng về điều đó (với chi phí mất một số hiệu quả / chi phí truyền thông lớn hơn). Plugin IPython song song trong StarCluster theo mặc định sẽ khởi động một công cụ cho mỗi lõi vật lý trên mỗi nút (tôi tin rằng đây là cấu hình nhưng không chắc chắn ở đâu). Bạn chỉ cần chạy bất cứ thứ gì bạn muốn trên tất cả các công cụ bằng cách sử dụng api DirectView (map_sync, application_sync, ...) hoặc các lệnh ma thuật% px. Nếu bạn đã sử dụng song song IPython trên một máy, sử dụng nó trên một cụm không khác nhau.

Giải quyết một số câu hỏi cụ thể của bạn:

"cách điều hòa công việc phân phối trên các lõi trên một cá thể so với các thể hiện trên một cụm" - Bạn nhận được một công cụ cho mỗi lõi (ít nhất là); công việc được tự động phân phối trên tất cả các lõi và trên tất cả các trường hợp.

"Thậm chí có thực tế khi song song hóa giữa các phiên bản cũng như giữa các lõi trên mỗi phiên bản không?" - Có :) Nếu mã bạn đang chạy song song lúng túng (chính xác là cùng một thuật toán trên nhiều bộ dữ liệu) thì bạn hầu như có thể bỏ qua nơi một công cụ cụ thể đang chạy. Nếu lõi đòi hỏi nhiều giao tiếp giữa các động cơ, thì dĩ nhiên bạn cần cấu trúc nó để động cơ chủ yếu giao tiếp với các động cơ khác trên cùng một máy vật lý; nhưng loại vấn đề đó không phù hợp lý tưởng với IPython, tôi nghĩ vậy.

"Nếu vậy, bất cứ ai cũng có thể đưa ra một bản tóm tắt nhanh chóng về ưu điểm + nhược điểm của việc chạy nhiều trường hợp với một số lõi mỗi lần so với một vài trường hợp có nhiều lõi? Có quy tắc nào cho việc chọn tỷ lệ đúng của các trường hợp cho mỗi trường hợp không? " - Sử dụng các thể hiện c3 lớn nhất cho giới hạn tính toán và nhỏ nhất cho các vấn đề giới hạn băng thông bộ nhớ; đối với các sự cố liên quan đến thông báo, cũng sử dụng các trường hợp lớn nhất nhưng cố gắng phân vùng sự cố sao cho mỗi phân vùng chạy trên một máy vật lý và hầu hết các thông báo truyền đi đều nằm trong cùng một phân vùng. Các sự cố sẽ chạy chậm hơn đáng kể trên các trường hợp N tăng gấp bốn lần so với trên 2N đôi c3 là rất hiếm (một ví dụ nhân tạo có thể đang chạy nhiều bộ lọc đơn giản trên một số lượng lớn hình ảnh, trong đó bạn đi qua tất cả các hình ảnh cho mỗi bộ lọc thay vì tất cả các bộ lọc cho cùng hình ảnh).

Một nguyên tắc chung là không phân phối cho đến khi bạn phải. Thông thường sẽ hiệu quả hơn khi có N máy chủ có công suất nhất định so với máy chủ 2N có dung lượng bằng một nửa. Nhiều quyền truy cập dữ liệu sẽ là cục bộ và do đó nhanh trong bộ nhớ so với chậm trên mạng.

Tại một thời điểm nhất định, việc nhân rộng một máy trở nên không kinh tế vì chi phí của tài nguyên bổ sung quy mô nhiều hơn tuyến tính. Tuy nhiên điểm này vẫn còn cao đáng kinh ngạc.

Mặc dù vậy, trên Amazon nói riêng, tính kinh tế của từng loại trường hợp có thể thay đổi rất nhiều nếu bạn đang sử dụng các phiên bản thị trường giao ngay. Giá mặc định nhiều hơn hoặc ít hơn có nghĩa là cùng một lượng chi phí tài nguyên giống nhau bất kể loại thể hiện, có thể thay đổi rất nhiều; cá thể lớn có thể rẻ hơn máy nhỏ hoặc N cá thể nhỏ có thể rẻ hơn nhiều so với máy lớn có tài nguyên tương đương.

Một cân nhắc lớn ở đây là mô hình tính toán có thể thay đổi khá nhiều khi bạn chuyển từ một máy sang nhiều máy. Sự đánh đổi mà chi phí truyền thông gây ra có thể buộc bạn, ví dụ, áp dụng mô hình song song dữ liệu để mở rộng quy mô. Điều đó có nghĩa là một sự lựa chọn khác nhau của các công cụ và thuật toán. Ví dụ, SGD trông khá khác nhau trong bộ nhớ và trong Python so với MapReduce. Vì vậy, bạn sẽ phải xem xét điều này trước khi song song.

Bạn có thể chọn phân phối công việc trên một cụm, ngay cả khi một nút đơn và mô hình không phân phối làm việc cho bạn, vì độ tin cậy. Nếu một nút duy nhất thất bại, bạn mất tất cả các tính toán; một tính toán phân tán có khả năng phục hồi và hoàn thành chỉ là một phần của tính toán đã bị mất.

Tất cả mọi thứ được coi là bằng nhau (chi phí, CPU perf, v.v.) bạn có thể chọn trường hợp nhỏ nhất có thể chứa tất cả các tập dữ liệu của tôi trong bộ nhớ và thu nhỏ lại. Theo cách đó

• bạn đảm bảo không gây ra độ trễ không cần thiết do truyền thông mạng và
• bạn có xu hướng tối đa hóa băng thông bộ nhớ khả dụng cho các quy trình của mình.

Giả sử bạn đang chạy một số loại sơ đồ xác thực chéo để tối ưu hóa một số tham số meta của mô hình của bạn, gán cho mỗi lõi một giá trị để kiểm tra và chọn nhiều trường hợp cần thiết để bao phủ tất cả không gian tham số trong vài vòng mà bạn thấy phù hợp.

Nếu dữ liệu của bạn không vừa với bộ nhớ của một hệ thống, tất nhiên bạn sẽ cần phân phối qua các phiên bản. Sau đó, vấn đề là cân bằng độ trễ bộ nhớ (tốt hơn với nhiều trường hợp) với độ trễ mạng (tốt hơn với ít trường hợp hơn) nhưng với bản chất của EC2, tôi cá là bạn sẽ thường thích làm việc với một vài trường hợp béo.