Tương lai của OpenCL?


22

Mô hình lập trình OpenCL hứa hẹn sẽ là một tiêu chuẩn mở miễn phí bản quyền cho điện toán không đồng nhất. Chúng ta có nên đầu tư thời gian của mình vào việc phát triển phần mềm dựa trên OpenCL không? Ưu / nhược điểm?


Trong CUDA bạn có thể mã khó hơn. Bạn có các lớp C ++, trong đó OpenCL chỉ hỗ trợ các cấu trúc. Vì vậy, CUDA trưởng thành hơn một chút. Nếu bạn không cần những thứ nâng cao, thì tôi sẽ chuyển sang OpenCL.
vanCompute

Câu trả lời:


19

Câu hỏi quá rộng và mơ hồ để thực sự được trả lời. Tuy nhiên, tôi thấy một điểm đáng chú ý so với OpenCL, từ quan điểm của điện toán khoa học, điều hiếm khi được nhấn mạnh. Cho đến nay, không có nỗ lực nào để tạo ra các thư viện cơ sở hạ tầng, nguồn mở cho OpenCL, trong khi CUDA có một số tùy chọn tuyệt vời:

Tôi tin rằng điều này sẽ thực sự gây tổn hại cho OpenCL vì một người hỗ trợ chính cho việc áp dụng là các thư viện mở, chất lượng cao.


3
Điểm thú vị; đặc biệt là bản thân giấy phép cho trình biên dịch CUDA hoàn toàn không mở (mà tôi cho rằng những kẻ này xây dựng trên đầu trang), trong khi (theo như tôi có thể tìm ra từ giấy phép) thì sẽ không có gì cản trở một lập trình viên đầy tham vọng ai muốn phát triển một giải pháp OpenCL mã nguồn mở hoàn toàn ...
Erik P.

2
@JackPoulson Tôi cũng đang bối rối vì thiếu thư viện OpenCL, nhưng lý do CUDA rất rõ ràng. Họ đã thực sự đặt các nguồn lực đằng sau việc thuê những người tuyệt vời và phát triển các thư viện hữu ích.
Matt Knepley

6
Thư viện được sinh ra và chết nhanh chóng; Tiêu chuẩn sống lâu và đau đớn.
mbq

6
ViennaCL , không thể bỏ qua.
Aron Ahmadia

4
@mbq Thư viện khoa học có tuổi thọ dài và ảnh hưởng lớn đến suy nghĩ cũng như thực hành. Chứng kiến ​​CHARMM, BLAS, RELAP, GEANT, v.v.
Matt Knepley

16

OpenCL vs gì?

Nếu câu hỏi là OpenCL vs CUDA, tôi thấy rất nhiều sự vặn vẹo về câu hỏi này, và nó có vẻ điên rồ với tôi. Nó không thành vấn đề. Thật thà. Các hạt nhân - nơi mà tất cả những suy nghĩ khó khăn phải đi - thực tế giống hệt nhau giữa hai ngôn ngữ; bạn có thể viết các macro cho trình soạn thảo yêu thích của mình để thực hiện 99% công việc để thoát giữa OpenCL và CUDA. Nó phải là như vậy; chúng kiểm soát mức độ thấp đối với các loại phần cứng khá giống nhau. Khi bạn đã tìm ra cách viết các hạt nhân quan trọng của mình trong {OpenCL, CUDA}, việc chuyển chúng thành {CUDA, OpenCL} là chuyện nhỏ.

Mã máy chủ soạn sẵn mà bạn phải viết cũng tương tự, nhưng CUDA giữ các trường hợp đơn giản. Đó là lý do tại sao chúng tôi dạy CUDA ở trung tâm của chúng tôi; bạn có thể nhảy thẳng vào viết mã hạt nhân, trong khi chúng ta phải dành 1-2 giờ cho khóa học dài ngày của chúng tôi chỉ để giải thích công cụ khởi chạy kernel cho OpenCL.

Nhưng ngay cả ở đó, sự khác biệt không quan trọng; một khi bạn bắt đầu làm những việc phức tạp hơn (hạt nhân không đồng bộ trên nhiều gpus), chúng đều phức tạp như nhau và một lần nữa bạn có thể thực hiện một bản dịch từng dòng từ người này sang người khác.

Nếu đó là OpenCL so với các cách tiếp cận dựa trên chỉ thị - OpenACC hoặc HMPP hoặc một cái gì đó - có lẽ (hy vọng?) Sẽ là cách tốt để lập trình các loại kiến ​​trúc này trong tương lai, nơi bạn có thể nhận được 90% hiệu suất cho 10% công việc. Nhưng lựa chọn nào sẽ "chiến thắng" vẫn còn được nhìn thấy và tôi không khuyên bạn nên dành nhiều thời gian để làm việc với những người đó.

Vì vậy, tôi muốn nói, giữa CUDA hoặc OpenCL, hãy chọn một ngôn ngữ thuận tiện cho bạn và sử dụng nó, và đừng quá lo lắng về nó. Phần có giá trị - tìm ra cách phân tách vấn đề của bạn thành mã SIMD song song ồ ạt cho các lõi nhỏ với rất ít bộ nhớ - sẽ dễ dàng di chuyển giữa các mô hình lập trình.

Nếu bạn đang sử dụng phần cứng NVIDIA - và có lẽ bạn là vậy - thì tôi thường khuyên dùng CUDA - quan điểm của Matt Knepley về các thư viện đã hết hạn. Nếu bạn không, thì OpenCL.


1
Bạn nói rằng sự khác biệt duy nhất là các hạt nhân, và các hạt nhân là như nhau, nhưng sau đó nói rằng bạn sử dụng CUDA vì nồi hơi đơn giản hơn. Tôi tình cờ đồng ý rằng bản tóm tắt trong CUDA đơn giản hơn, nhưng có những thư viện có thể trợ giúp với bản tóm tắt OpenCL, ví dụ code.google.com/p/clutilgithub.com/hughperkins/OpenCLHelper (từ chối trách nhiệm: OpenCLHelper là của riêng tôi)
Hugh Perkins

7

Bạn có nên đầu tư thời gian của mình vào việc phát triển phần mềm dựa trên OpenCL hay không là câu hỏi mà bạn chỉ có thể trả lời. Nếu có vẻ như nó có khả năng giải quyết các vấn đề bạn đang gặp phải ngay bây giờ và không có giải pháp mở nào khác, thì hành động tốt nhất của bạn có lẽ là mạo hiểm khi thực hiện một dự án nhỏ với nó.

Nếu mọi việc suôn sẻ, bạn có thể thử nó với các dự án lớn hơn và cứ thế cho đến khi bạn xây dựng đủ tự tin để chuẩn hóa nó, hoặc loại bỏ nó theo hướng có lợi cho một số giải pháp khác (có thể là giải pháp độc quyền của riêng bạn, một giải pháp mở khác hoặc thậm chí giải pháp độc quyền khác).

Điều tuyệt vời về phong trào nguồn mở là bởi vì bạn có nguồn bạn có mọi thứ bạn cần để rẽ nhánh dự án nếu cần thiết. Ngay cả khi cộng đồng không cung cấp cho bạn các phương tiện bạn cần, không có gì ngăn cản bạn tự mình thực hiện các cơ sở đó. Ngoài ra, nếu bạn muốn các cơ sở đó, có một khả năng khác biệt là những người dùng khác có thể muốn chúng, vì vậy sẽ đánh giá cao nếu bạn đóng góp những thay đổi đó cho dự án cốt lõi.

Không chỉ vậy, nhưng nếu bạn làm cho nó tốt hơn từ quan điểm của bạn, nó có thể làm cho nó tốt hơn cho những người khác, khuyến khích họ gửi những cải tiến của riêng họ và cuối cùng làm cho phần mềm tốt hơn cho mọi người.

Cuối cùng, có, đây là một câu trả lời khá chung chung cho một câu hỏi chung chung. Để trả lời đầy đủ hơn, chúng tôi cần biết mối quan tâm của bạn đối với OpenCL là gì. Có phải là sự trưởng thành? Sự đóng góp cho cộng đồng? Dễ sử dụng? Thời gian cần học? Thời gian phát triển? Thay đổi thủ tục của bạn? Khi bạn hỏi về Ưu và Nhược điểm, bạn đang cố gắng so sánh OpenCL với sản phẩm nào khác ? Bạn đã làm nghiên cứu gì? Những tính năng nào bạn cần để hỗ trợ môi trường điện toán không đồng nhất của bạn?


6

Một PRO lớn là số lượng nhà cung cấp đằng sau OpenCL. Tôi có một số kinh nghiệm về giai thoại này, đã gặp một nhóm nghiên cứu đã dành một lượng lớn thời gian và nỗ lực để phát triển mã CUDA khá phức tạp cho một hệ thống hỗ trợ NVIDIA. Một năm sau khi mã được phát triển, nhóm nghiên cứu đã truy cập vào hệ thống dựa trên AMD lớn hơn và nhanh hơn nhưng họ không thể sử dụng nó vì họ không có tài nguyên (con người) để chuyển mã.

Ngay cả khi bộ tính năng cốt lõi của CUDA và OpenCL gần như giống hệt nhau (như @JonathanDursi đã chỉ ra), nếu nhà phát triển ban đầu không phải là người được giao nhiệm vụ chuyển đổi mã, toàn bộ dự án porting có thể khá tốn thời gian.

Tuy nhiên, có một số sự không tương thích chính thức giữa CUDA và OpenCL. Đáng chú ý nhất là CUDA hỗ trợ các mẫu c ++ trong khi OpenCL chưa chính thức hỗ trợ chúng. Tuy nhiên, AMD đã nỗ lực để phát triển một phần mở rộng cho OpenCL với sự hỗ trợ cho các mẫu và các tính năng C ++ khác, thông tin thêm trong bài đăng này từ AMD dev centre . Tôi hy vọng bản sửa đổi OpenCL trong tương lai có thể thêm tác phẩm này.

Tại thời điểm này (đầu năm 2012), các thư viện tuyệt vời mà @MattKnepley liên kết là nguồn đóng hoặc sử dụng các mẫu, do đó, chúng sẽ không có sẵn cho phần cứng ngoài NVIDIA, ít nhất là trong thời gian đó.

Đối với ai đó đang học máy tính gpu, tôi sẽ nói rằng OpenCL C có thể khá khó khăn, vì có rất nhiều chi tiết khiến người học mất tập trung khỏi các ý tưởng cơ bản, trong khi CUDA thì đơn giản và dễ hiểu hơn. Tuy nhiên, có những công cụ giúp OpenCL đơn giản hơn để học và sử dụng như PyOpenCL (trình bao bọc python cho opencl) mang tất cả đường python vào OpenCL (lưu ý rằng cũng có PyCUDA). Chẳng hạn, bản demo PyOpenCL để thêm hai mảng chỉ dưới 25 dòng và nó bao gồm: tạo các mảng trên máy chủ và thiết bị, truyền dữ liệu, tạo bối cảnh và hàng đợi, kernel, cách xây dựng và thực thi kernel , nhận kết quả từ GPU và so sánh chúng với numpy (xem các liên kết bên dưới).

PyOpenCL - http://mathema.tician.de/software/pyopencl

PyCUDA - http://mathema.tician.de/software/pycuda

Đối với các lập trình viên gpu có kinh nghiệm, ở đây tôi đồng ý với @JonathanDursi, CUDA và OpenCL về cơ bản là giống nhau và thực sự không có sự khác biệt của thị trưởng. Hơn nữa, công việc khó khăn trong việc phát triển một thuật toán hiệu quả cho GPU là rất độc lập với ngôn ngữ và sự hỗ trợ OpenCL từ các nhà cung cấp và tài liệu giờ đã trưởng thành hơn nhiều so với 2 năm trước. Điểm duy nhất vẫn tạo ra sự khác biệt, đó là NVIDIA thực sự đang làm một số công việc tuyệt vời với sự hỗ trợ của họ cho cộng đồng CUDA.

OpenCL có thêm lợi ích là nó có thể chạy trên CPU và đã được Intel và AMD hỗ trợ. Vì vậy, bạn không cần thay đổi khung thuật toán nếu muốn tận dụng mọi lõi CPU có sẵn. Theo ý kiến ​​của tôi, OpenCL là giải pháp tốt nhất cho một ứng dụng hướng CPU / đa lõi đơn vì hạt nhân được tối ưu hóa CPU có thể trông khác biệt đáng kể so với hạt nhân được tối ưu hóa GPU. Tuy nhiên, theo kinh nghiệm của tôi, phát triển CODE có lợi từ việc có thể chạy trên CPU.


5

Tôi nghĩ OpenCL hiện đang bị thiếu một "nhà vô địch". Ví dụ: nếu bạn truy cập trang web NVIDIA ngay bây giờ (16/12/2011), bạn đã có một số bức ảnh kiểu "Hiệu ứng Ken Burns" trên trang giật gân tập trung vào khía cạnh khoa học / công nghiệp của điện toán GPU và ~ 1 / Thứ 4 trong số các tùy chọn điều hướng của bạn hướng bạn đến những thứ có thể sẽ kết thúc tại CUDA. Các nhà sản xuất bán máy chủ và máy trạm "tính toán GPU" đang bán các giải pháp NVIDIA.

Các ưu đãi cạnh tranh từ ATI được trộn lẫn với trang web AMD nói chung, khó tìm hơn và không được đề cao trong các giải pháp của bên thứ ba. Những giải pháp đó và khả năng thực hiện lập trình dựa trên OpenCL chắc chắn tồn tại, nhưng nó đã để lại một nhận thức - ít nhất là trong suy nghĩ của tôi, nhưng trong suy nghĩ của một số người khác mà tôi đã nói chuyện - rằng các nhà tài trợ doanh nghiệp lớn của nền tảng OpenCL đã " bỏ lĩnh vực này ". Những người sử dụng OS X chẳng hạn, có lẽ tất cả đều quá bận rộn suy đoán về việc liệu một máy trạm của Apple có tồn tại trong một năm để có niềm tin vào việc họ đẩy mạnh tính toán GPU OpenCL hay không.


4

Yếu tố quan trọng nhất là CUDA sẽ vẫn chỉ được hỗ trợ bởi phần cứng NVIDIA.

Do đó, nếu bạn muốn tạo ra phần mềm mạnh mẽ và di động, OpenCL là lựa chọn duy nhất. Nhiều nhất bạn có thể xây dựng xung quanh một số thư viện hiện đang được CUDA cung cấp và hy vọng chúng sẽ được mở rộng qua OpenCL trong tương lai kéo mã của bạn với nó.


Không rõ ràng chút nào. Chắc chắn có những tiêu chuẩn độc quyền đã trở nên mở sau khi nhiều người áp dụng chúng.
Matt Knepley

@MattKnepley Xin vui lòng, ngay cả NVIDA cũng không cố ép CUDA làm tiêu chuẩn; không đề cập đến việc ngay cả khi họ muốn, họ sẽ kết thúc với một cái gì đó về cơ bản giống với OpenCL.
mbq

1
Trong thực tế, nó có thể sẽ ngược lại. OpenCL cuối cùng sẽ chấp nhận tất cả những điều tốt đẹp từ CUDA (hầu hết trong số đó đã có, bạn nghĩ nó đến từ đâu?) Và loại bỏ những thứ đáng ghét hơn trong đó ngay bây giờ.
Matt Knepley
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.