กระบวนทัศน์การเขียนโปรแกรม OpenCL สัญญาว่าจะปลอดค่าลิขสิทธิ์เปิดมาตรฐานสำหรับการคำนวณที่แตกต่างกัน เราควรลงทุนเวลาในการพัฒนาซอฟต์แวร์โดยใช้ OpenCL หรือไม่ ข้อเสียข้อดี?
คำตอบ:
คำถามกว้างเกินไปและคลุมเครือเกินกว่าจะตอบได้จริงๆ อย่างไรก็ตามฉันเห็นจุดที่โดดเด่นอย่างหนึ่งต่อ OpenCL จากมุมมองของการคำนวณทางวิทยาศาสตร์ซึ่งไม่ค่อยเน้น จนถึงขณะนี้ยังไม่มีความพยายามในการผลิตโอเพ่นซอร์สไลบรารีโครงสร้างพื้นฐานสำหรับ OpenCL ในขณะที่ CUDA มีตัวเลือกที่ยอดเยี่ยมหลายประการ:
ฉันเชื่อว่าสิ่งนี้จะส่งผลเสียหายอย่างมากต่อ OpenCL เนื่องจากผู้อำนวยความสะดวกในการนำไปใช้งานที่สำคัญคือห้องสมุดที่มีคุณภาพและเปิดกว้าง
OpenCL เทียบกับอะไร
หากคำถามคือ OpenCL กับ CUDA ฉันเห็นคำถามมากมายที่เขียนด้วยมือและดูเหมือนว่าฉันจะบ้าไปแล้ว มันไม่สำคัญ ซื่อสัตย์ เมล็ด - ที่ซึ่งความคิดหนักต้องไป - เหมือนจริงระหว่างสองภาษา คุณสามารถเขียนมาโครเพื่อให้บรรณาธิการที่คุณชื่นชอบทำ 99% ของงานเพื่อตีกลับระหว่าง OpenCL และ CUDA มันต้องเป็นเช่นนั้น พวกเขากำลังควบคุมระดับต่ำของฮาร์ดแวร์ประเภทที่คล้ายคลึงกันในที่สุด เมื่อคุณทราบวิธีการเขียนเมล็ดสำคัญใน {OpenCL, CUDA} แล้วมันเป็นเรื่องเล็กน้อยที่จะย้ายพวกเขาไปยัง {CUDA, OpenCL}
รหัสโฮสต์สำเร็จรูปที่คุณต้องเขียนก็เหมือนกัน แต่ CUDA ช่วยให้กรณีง่าย ๆ ได้ง่าย นั่นเป็นเหตุผลที่เราสอน CUDA ในศูนย์ของเรา คุณสามารถกระโดดเข้าไปเขียนโค้ดเคอร์เนลได้โดยตรงในขณะที่เราต้องใช้เวลา 1-2 ชั่วโมงของหลักสูตรของเราตลอดทั้งวันเพียงแค่อธิบายการเปิดตัวเคอร์เนลสำหรับ OpenCL
แต่ถึงแม้จะมีความแตกต่างก็ไม่สำคัญ เมื่อคุณเริ่มทำสิ่งที่ซับซ้อนมากขึ้น (เคอร์เนลแบบอะซิงโครนัสกับ gpus หลาย ๆ อัน) พวกเขาทั้งคู่ต่างก็มีความซับซ้อนไม่แพ้กันและคุณสามารถทำการแปลทีละบรรทัดจากที่หนึ่งไปอีกที่หนึ่งได้
ถ้าเป็น OpenCL เทียบกับแนวทางแบบ directive - OpenACCหรือHMPPหรืออะไรบางอย่าง - อาจเป็น (หวังว่า?) จะเป็นวิธีที่ดีในการเขียนโปรแกรมสถาปัตยกรรมประเภทนี้ในอนาคตซึ่งคุณจะได้รับ 90% ของประสิทธิภาพสำหรับ 10% ของงาน แต่ตัวเลือกใดที่จะ "ชนะ" ยังคงมีให้เห็นและฉันจะไม่แนะนำให้ใช้เวลามากในการทำงานกับคนเหล่านั้น
ดังนั้นฉันว่าระหว่าง CUDA หรือ OpenCL เลือกภาษาที่สะดวกสำหรับคุณและใช้และไม่ต้องกังวลเกี่ยวกับมันมากนัก ส่วนที่มีค่า - การค้นหาวิธีการแยกแยะปัญหาของคุณเป็นรหัส SIMD แบบขนานอย่างหนาแน่นสำหรับแกนประมวลผลขนาดเล็กที่มีหน่วยความจำน้อยมาก - จะพกพาได้ง่ายระหว่างโมเดลการเขียนโปรแกรม
หากคุณใช้ฮาร์ดแวร์ NVIDIA - และคุณอาจเป็น - ฉันมักจะแนะนำ CUDA - ประเด็นของ Matt Knepley เกี่ยวกับห้องสมุดนั้นเป็นเรื่องที่ไม่คาดคิด ถ้าคุณไม่ได้แล้ว OpenCL
คุณควรลงทุนเวลาในการพัฒนาซอฟต์แวร์โดยใช้OpenCL หรือไม่เป็นคำถามเดียวที่คุณสามารถตอบได้ หากดูเหมือนว่ามันมีศักยภาพในการแก้ปัญหาที่คุณเผชิญอยู่ในขณะนี้และไม่มีวิธีแก้ปัญหาแบบเปิดอื่น ๆ แนวทางการปฏิบัติที่ดีที่สุดของคุณน่าจะเป็นความเสี่ยงในการดำเนินโครงการขนาดเล็กด้วย
หากเป็นไปได้ด้วยดีคุณสามารถลองกับโครงการขนาดใหญ่และอื่น ๆ จนกว่าคุณจะสร้างความมั่นใจพอที่จะสร้างมาตรฐานให้กับมันหรือทิ้งมันไว้ในความโปรดปรานของโซลูชันอื่น ๆ (ซึ่งอาจเป็นโซลูชันที่เป็นกรรมสิทธิ์ของคุณเอง โซลูชันที่เป็นกรรมสิทธิ์อื่น)
สิ่งที่ยอดเยี่ยมเกี่ยวกับการเคลื่อนไหวของโอเพ่นซอร์สคือเนื่องจากคุณมีแหล่งที่มาคุณมีทุกสิ่งที่คุณต้องการเพื่อแยกโครงการหากจำเป็น แม้ว่าชุมชนจะไม่ให้สิ่งอำนวยความสะดวกตามที่คุณต้องการ แต่ก็ไม่มีอะไรที่จะหยุดยั้งการใช้สิ่งอำนวยความสะดวกเหล่านั้นด้วยตัวเอง นอกจากนี้หากคุณต้องการสิ่งอำนวยความสะดวกเหล่านั้นมีความเป็นไปได้ที่ชัดเจนว่าผู้ใช้รายอื่นอาจต้องการพวกเขาดังนั้นจะขอบคุณถ้าคุณสนับสนุนการเปลี่ยนแปลงเหล่านั้นกลับไปที่โครงการหลัก
ไม่เพียงแค่นั้น แต่ถ้าคุณทำให้ดีขึ้นจากมุมมองของคุณมันอาจทำให้คนอื่นดีขึ้นกระตุ้นให้พวกเขาส่งการปรับปรุงของตนเองและทำให้ซอฟต์แวร์ดีขึ้นสำหรับทุกคนในที่สุด
สุดท้ายใช่แล้วนี่เป็นคำตอบทั่วไปสำหรับคำถามทั่วไป ในการตอบคำถามให้ละเอียดยิ่งขึ้นเราจำเป็นต้องทราบว่าความกังวลของคุณต่อ OpenCL คืออะไร มันครบกําหนดหรือไม่? การสนับสนุนชุมชน? สะดวกในการใช้? เวลาที่จำเป็นในการเรียนรู้? ใช้เวลาในการพัฒนา? เปลี่ยนวิธีการของคุณ? เมื่อคุณถามเกี่ยวกับข้อดีและข้อเสียซึ่งผลิตภัณฑ์อื่น ๆที่คุณพยายามที่จะเปรียบเทียบ OpenCL เพื่อ ? คุณทำวิจัยอะไรมาแล้วบ้าง? คุณสมบัติใดที่คุณต้องการเพื่อรองรับสภาพแวดล้อมการประมวลผลที่แตกต่างกันของคุณ
PRO ใหญ่อย่างหนึ่งคือจำนวนผู้ขายที่อยู่เบื้องหลัง OpenCL ฉันมีประสบการณ์พอสมควรเกี่ยวกับเรื่องนี้ได้พบกับกลุ่มวิจัยที่ใช้เวลาและความพยายามในการพัฒนารหัส CUDA ที่ค่อนข้างซับซ้อนสำหรับระบบขับเคลื่อน NVIDIA หนึ่งปีต่อมาหลังจากพัฒนารหัสกลุ่มวิจัยได้เข้าถึงระบบที่มีขนาดใหญ่ขึ้นและเร็วขึ้นของเอเอ็มดี แต่พวกเขาไม่สามารถใช้งานได้เนื่องจากไม่มีทรัพยากร (คน) ในการแปลงรหัส
แม้ว่าชุดแกนหลักของฟีเจอร์ของ CUDA และ OpenCL จะเหมือนกันเกือบทั้งหมด (ตามที่ @JonathanDursi ชี้ให้เห็นอย่างชัดเจน) หากผู้พัฒนาดั้งเดิมไม่ใช่ผู้ที่ได้รับมอบหมายให้ทำหน้าที่ในการแปลงรหัสโครงการย้ายพอร์ตทั้งหมดอาจใช้เวลาค่อนข้างนาน
อย่างไรก็ตามมีความเข้ากันไม่ได้ระหว่าง CUDA และ OpenCL CUDA รองรับเทมเพลต c ++ ที่น่าสังเกตมากที่สุดในขณะที่ OpenCL ยังไม่รองรับอย่างเป็นทางการ แต่มีความพยายามที่ทำโดยเอเอ็มดีในการพัฒนาส่วนขยายไปยัง OpenCL ด้วยการสนับสนุนแม่แบบและอื่น ๆ c ++ คุณสมบัติข้อมูลเพิ่มเติมในโพสต์นี้จากเอเอ็มดี dev กลาง ฉันหวังว่าการแก้ไข OpenCL ในอนาคตอาจเพิ่มงานนี้
ณ จุดนี้ (ต้นปี 2012) ไลบรารีที่ยอดเยี่ยมที่ @MattKnepley ลิงก์ไปยังแหล่งข้อมูลปิดหรือใช้เทมเพลตดังนั้นจึงจะไม่สามารถใช้งานได้กับฮาร์ดแวร์อื่นที่ไม่ใช่ NVIDIA อย่างน้อยในเวลาเดียวกัน
สำหรับคนที่เรียนรู้การคำนวณด้วยคอมพิวเตอร์ฉันจะบอกว่า OpenCL C นั้นค่อนข้างยากเนื่องจากมีรายละเอียดมากมายที่เบี่ยงเบนความสนใจของผู้เรียนจากแนวคิดพื้นฐานขณะที่ CUDA นั้นง่ายกว่าและตรงไปตรงมา อย่างไรก็ตามมีเครื่องมือที่ทำให้ OpenCL เป็นเรื่องง่ายในการเรียนรู้และใช้งานเช่น PyOpenCL (python wrapper for opencl) ซึ่งนำ python sugar ทั้งหมดมาสู่ OpenCL (โปรดทราบว่า PyCUDA ยังมี) ตัวอย่างเช่นการสาธิต PyOpenCL สำหรับการเพิ่มสองอาร์เรย์อยู่ภายใต้ 25 บรรทัดและประกอบด้วย: การสร้างอาร์เรย์บนโฮสต์และอุปกรณ์การถ่ายโอนข้อมูลการสร้างบริบทและคิวเคอร์เนลวิธีสร้างและเรียกใช้เคอร์เนล รับผลลัพธ์จาก GPU และเปรียบเทียบกับจำนวนมาก (ดูลิงก์ด้านล่าง)
PyOpenCL - http://mathema.tician.de/software/pyopencl
PyCUDA - http://mathema.tician.de/software/pycuda
สำหรับโปรแกรมเมอร์ gpu ที่มีประสบการณ์ที่นี่ฉันเห็นด้วยกับ @JonathanDursi, CUDA และ OpenCL เป็นพื้นฐานเดียวกันและไม่มีความแตกต่างของนายกเทศมนตรีจริงๆ ยิ่งกว่านั้นการทำงานอย่างหนักของการพัฒนาอัลกอริธึมที่มีประสิทธิภาพสำหรับ GPU นั้นเป็นภาษาที่มีความเป็นอิสระอย่างมากและการสนับสนุน OpenCL จากผู้ขายและเอกสารนั้นเป็นผู้ใหญ่มากขึ้นกว่าเมื่อ 2 ปีก่อน จุดเดียวที่ยังคงสร้างความแตกต่างคือ NVIDIA ทำงานได้ดีมากกับการสนับสนุนชุมชน CUDA
OpenCL มีสิทธิประโยชน์เพิ่มเติมที่สามารถทำงานกับ CPU และได้รับการสนับสนุนโดย Intel และ AMD ดังนั้นคุณไม่จำเป็นต้องเปลี่ยนเฟรมเวิร์กอัลกอริทึมของคุณหากคุณต้องการใช้ประโยชน์จากคอร์ CPU ที่มีอยู่ ฉันไม่เห็นว่า OpenCL เป็นทางออกที่ดีที่สุดสำหรับแอพพลิเคชั่น CPU / multicore ที่มุ่งเน้นเดียวเนื่องจากเคอร์เนลที่ได้รับการเพิ่มประสิทธิภาพของ CPU อาจดูแตกต่างจากเคอร์เนลที่ปรับให้เหมาะสมของ GPU อย่างไรก็ตามในประสบการณ์ของฉันการพัฒนารหัสจะได้รับประโยชน์จากความสามารถในการทำงานบน CPU
ฉันคิดว่า OpenCL กำลังทุกข์ทรมานจากการขาด "แชมป์" ตัวอย่างเช่นหากคุณเข้าชมไซต์ NVIDIA ตอนนี้ (12/16/2011) คุณมีช็อตเด็ดสไตล์ "Ken Burns Effect" บนหน้าสแปลชที่เน้นด้านวิทยาศาสตร์ / อุตสาหกรรมของการคำนวณ GPU และ ~ 1 / ตัวเลือกการนำทางอันดับที่ 4 ของคุณชี้ไปยังสิ่งต่าง ๆ ที่อาจจะจบลงที่ CUDA ผู้ผลิตที่ขายเซิร์ฟเวอร์ "GPU GPU" และเวิร์คสเตชั่นกำลังขายโซลูชั่น NVIDIA
ข้อเสนอการแข่งขันจาก ATI นั้นผสมผสานกับเว็บไซต์ทั่วไปของ AMD ยากที่จะหาและไม่ได้ให้ความสำคัญอย่างมากในโซลูชันของบุคคลที่สาม วิธีแก้ปัญหาเหล่านั้นและความสามารถในการเขียนโปรแกรมแบบ OpenCL นั้นมีอยู่จริง แต่มันก็เป็นการรับรู้ - อย่างน้อยก็ในใจของฉัน แต่ในใจของคนอื่น ๆ ที่ฉันเคยพูดคุยด้วย ออกจากสนาม " ยกตัวอย่างเช่นคนที่ใช้ OS X อาจจะยุ่งเกินกว่าที่จะคาดเดาว่าเวิร์กสเตชันของ Apple จะมีอยู่ในปีนี้หรือไม่เพื่อให้พวกเขาเชื่อมั่นในการผลักดันการคำนวณของ OpenCL GPU
ปัจจัยที่สำคัญที่สุดคือ CUDA จะยังคงรองรับโดยฮาร์ดแวร์ของ NVIDIA เท่านั้น
ดังนั้นหากคุณต้องการสร้างซอฟต์แวร์ที่แข็งแกร่งและพกพาได้ OpenCL เป็นตัวเลือกเดียว ที่จริงแล้วคุณสามารถสร้างห้องสมุดที่ขับเคลื่อนโดย CUDA บางแห่งในปัจจุบันและหวังว่าพวกเขาจะได้รับการขยายผ่าน OpenCL เพื่อดึงรหัสของคุณในอนาคต