Lập trình cho bộ xử lý di động của PS3 đòi hỏi điều gì?

Question

Lập trình cho Bộ xử lý Cell trên PS3 khác với chương trình cho bất kỳ bộ xử lý nào khác được tìm thấy trên máy tính để bàn thông thường?

Loại mô hình lập trình, kỹ thuật và thực hành nào được sử dụng để sử dụng đầy đủ tiềm năng của Bộ xử lý di động?

Tất cả các bài viết tôi nghe về phát triển PS3 đều thảo luận, "Học cách lập trình trên Bộ xử lý di động". Điều này thực sự có nghĩa là gì ngoài một số tay vẫy tay?

Answer 1

Ngoài tất cả mọi thứ mà George đề cập, SPU thực sự được coi là bộ xử lý vector trực tuyến tốt hơn. Chúng hoạt động tốt nhất khi bạn có một thuật toán hoạt động trên các chuỗi dữ liệu số, có thể được cấp thông qua bộ nhớ hạn chế của SPU thông qua DMA, thay vì SPU nạp một đoạn bộ nhớ, cố gắng hoạt động trên nó, thấy rằng nó cần để theo một con trỏ đến một nơi nào đó bên ngoài bộ nhớ của nó, hãy tải rằng, tiếp tục, tìm một số khác, v.v.

Vì vậy, việc lập trình cho chúng không phải là một mô hình đơn giản về đồng thời và chủ đề; nó giống như tính toán số học hoặc tính toán khoa học hiệu suất cao. Nó cũng là truy cập bộ nhớ không đồng bộ được đưa đến một cực đoan. Ngoài ra, mọi bộ xử lý đều theo thứ tự với đường ống sâu, do đó, lập trình viên phải nhận thức rõ hơn về các mối nguy hiểm dữ liệu và các bong bóng lệnh và tất cả các tối ưu hóa vi mô mà chúng tôi được thông báo cho trình biên dịch "nên" xử lý cho chúng tôi (nhưng nó thực sự không). Những thứ như các nhánh bị lỗi, tải-hit-cửa hàng, nhớ cache, vv làm tổn thương nhiều hơn so với một bộ xử lý không theo thứ tự có thể sắp xếp thứ tự các hoạt động xung quanh để ẩn các độ trễ đó.

Ví dụ cụ thể, hãy xem blog của Mike Acton CellPerformance. Mike là người yêu thích sự hài lòng của cô trong chương trình kinh doanh, và anh ấy đã thực sự kiếm được những câu hỏi về vấn đề này.

Answer 2

Phần Cell của PS3 bao gồm 6 bộ xử lý SPU. Họ có 256 KB bộ nhớ không chia sẻ và được kết nối thông qua một vòng tốc độ cao cho phép DMA giữa nhau và bộ xử lý máy chủ PowerPC. Chúng không được pipelined hoặc cache. Điều này làm cho nó khá khác với x86 đa lõi với bộ nhớ chia sẻ, pipelining và bộ nhớ đệm. Ngoài ra, các bộ vi xử lý SPU không sử dụng cùng một bộ hướng dẫn như PowerPC vì vậy bạn đã có một số bất đối xứng ở đó.

Tóm lại, chương trình đa luồng, bộ nhớ chia sẻ thông thường của bạn sẽ không chỉ rơi vào Ô mà không có một số công việc (với báo trước rằng khoa học máy tính làm việc chăm chỉ để làm cho các máy khác nhau giống nhau tự động hóa quá trình).

Ở mức cao, chương trình sẽ cần phải được chia thành các tác vụ phù hợp với giới hạn bộ nhớ cứng của Ô. Chúng có thể chạy song song và mỗi tác vụ phụ có thể được sắp xếp theo trình tự của một bộ xử lý Cell có sẵn. Ở mức độ thấp, trình biên dịch (hoặc trình lập trình assembly) sẽ cần phải làm việc chăm chỉ hơn để tạo ra mã chạy nhanh trên một bộ xử lý - không có thủ thuật thời gian chạy để làm cho mọi thứ diễn ra nhanh hơn. Lý thuyết cho rằng các tính năng thân thiện với lập trình viên/biên dịch này có chi phí silicon và tốc độ có thể được chi tiêu tốt hơn cho bạn nhiều SPU nhanh hơn. Tất nhiên, bạn không nhận được nhiều SPU hơn trên PS3 nhưng trong trường hợp chung bạn sẽ nhận được nhiều SPU hơn cho mỗi số bóng bán dẫn có sẵn trên chip.

Answer 3

Hoàn toàn đồng ý với George Philips và Crashworks. Điều duy nhất tôi muốn thêm là lập trình SPU về cơ bản là về quản lý công việc. Để tận dụng tối đa SPU, bạn cần giữ cho chúng đánh dấu và cho kết quả ngược lại. Không có điểm nào trong việc có một SPU nhai qua một số quá trình xử lý phức tạp nếu bạn phải ngồi và chờ kết quả cho một khung và phần còn lại của các SPU của bạn đang ở chế độ chờ.Vì vậy, làm thế nào bạn phân phối công việc của bạn đòi hỏi rất nhiều suy nghĩ và điều này có một tác động lớn về cách bạn chunk lên dữ liệu của bạn.

Answer 4

"Tất cả các bài viết tôi nghe về phát triển PS3 đều thảo luận, 'Học cách lập trình trên Bộ xử lý di động'. Điều này thực sự có ý nghĩa gì ngoài một số bàn tay vẫy tay? "

Vâng, những thứ bạn phải đối phó với trên SPUs ...

• hoạt động nguyên tử (lock-free style try-loại bỏ).
• Phân biệt rõ ràng giữa các vùng bộ nhớ. Bạn phải biết con trỏ trỏ đến vùng bộ nhớ nào hoặc bạn sẽ vặn mọi thứ lên.
• Không có sự phân biệt phần cứng được thực thi giữa dữ liệu và mã. Điều này thực sự là một điều thú vị, bạn có thể thiết lập tải mã động và về cơ bản dòng chương trình con vào và ra. Tự sửa đổi mã là có thể nhưng không nhất thiết thực tế trên SPU.
• Thiếu phần cứng hỗ trợ gỡ lỗi.
• Kích thước bộ nhớ bị giới hạn.
• Truy cập bộ nhớ nhanh.
• Bộ hướng dẫn được cân bằng về các hoạt động SIMD.
• Điểm nổi "gotchas".

Bạn lý tưởng muốn giữ SPUs làm công việc hữu ích mọi lúc, nhưng thực sự rất khó khăn. Không chỉ là chúng không phù hợp để xử lý một số loại vấn đề, nhưng thường di chuyển một hệ thống có hiệu quả trên SPU có thể liên quan đến việc thiết kế lại hoàn toàn. Việc gỡ lỗi các vấn đề có thể dễ dàng nắm bắt trên PPU đôi khi có thể mất nhiều ngày trên SPU.

Tôi nghĩ khi mọi người sử dụng cụm từ "học cách lập trình ô", chúng chủ yếu là vẫy tay. Bạn có thể tìm hiểu các khái niệm cơ bản trong một tuần, thách thức đến trong việc cố gắng áp dụng kiến ​​thức đó vào mã thực ... thường đã tồn tại và không có dạng phù hợp để sử dụng trên SPU.