ห้องสมุดคณิตศาสตร์สำหรับ OpenCL?

ฉันกำลังมองหาข้อมูลจากใครก็ตามที่พยายามใช้ OpenCL ในรหัสทางวิทยาศาสตร์ มีใครลองเวียนนาCLบ้างไหม? ถ้าเป็นเช่นนั้นจะเปรียบเทียบกับcusp ได้อย่างไร

OCLToolsเกี่ยวกับอะไร มันขึ้นอยู่กับสัญญาหรือไม่? ถ้าเป็นเช่นนั้นจะเป็นไปได้ไหมที่จะเริ่มเขียนเมล็ดทางคณิตศาสตร์ใน OpenCL?

ก่อนอื่นฉันอยากจะขอบคุณ Aron Ahmadia ที่ชี้ให้ฉันไปที่หัวข้อนี้

สำหรับ OpenCL ในโค้ดทางวิทยาศาสตร์: OpenCL นั้นหมายถึงเป็น API ระดับต่ำดังนั้นจึงจำเป็นอย่างยิ่งที่จะต้องปิดฟังก์ชันนี้ในบางวิธีเพื่อให้ได้ผลผลิตที่สมเหตุสมผล ยิ่งไปกว่านั้นทันทีที่มีการคำนวณหลายเมล็ดที่เกี่ยวข้องรหัสสามารถได้รับสกปรกมากถ้าเคอร์เนล OpenCL และหน่วยความจำจับต้องผ่านอย่างมากภายในแอปพลิเคชัน ฉันไม่รู้จัก OCLTools ดังนั้นฉันไม่สามารถพูดได้ว่ามีประโยชน์ในเรื่องนี้หรือไม่

สำหรับ ViennaCL: ฉันเป็นหัวหน้าของ ViennaCL ดังนั้นเมื่อไม่นานมานี้ฉันได้ทำงานกับห้องสมุด :-) ในต่อไปนี้ฉันจะรักษาร้องขอสำหรับการเปรียบเทียบกับยอดในขอบเขตขนาดใหญ่เล็กน้อยคือ ViennaCL เมื่อเทียบกับ CUDA ตามห้องสมุดคณิตศาสตร์ cusp และMAGMA มีเพียงการพิจารณาสถานะปัจจุบันแม้ว่าจะมีการพัฒนาอย่างต่อเนื่อง (อย่างน้อยก็ในด้านของเรา)

ฟังก์ชั่น MAGMA จัดเตรียมฟังก์ชัน BLAS สำหรับการฝึกอบรมที่หนาแน่นผ่านอินเทอร์เฟซฟังก์ชันตามปกติ ฟังก์ชั่นส่วนใหญ่นี้มาพร้อมกับ ViennaCL 1.2.0 โดยใช้ตัวดำเนินการโอเวอร์โหลดและน้ำตาลเชิงซ้อนอื่น ๆ

นักแก้ปัญหาซ้ำสามคนเดียวกัน (CG, BiCGStab, GMRES) มาพร้อมกับ cusp และ ViennaCL ชุด preconditioners แตกต่างโดดเด่น: Cusp ให้เส้นทแยงมุม SA-AMG และ Brondon preconditioners ต่าง ๆ ViennaCL นำเสนอ LU factorizations ที่ไม่สมบูรณ์นักสร้างเส้นทแยงมุมและรสชาติ AMG ที่หลากหลายและล่าสุด Sparse Approximate Inverse preconditioners ตามความรู้ของฉันผู้ที่มีเงื่อนไขเบื้องต้นทั้งหมดใช้ GPU โดยเฉพาะในขณะที่ ViennaCL อาศัยอยู่โดยเฉพาะในช่วงการติดตั้งการคำนวณที่ใช้ CPU ปัจจุบันจำนวนของรูปแบบเมทริกซ์กระจัดกระจายมีขนาดใหญ่กว่าในรูปแบบ: COO, CSR, DIA, ELL, HYB ในขณะที่ ViennaCL 1.2.0 มี COO และ CSR

มีคุณสมบัติเพิ่มเติมจำนวนมากที่มีให้กับ ViennaCL ซึ่งไม่ได้เป็นส่วนหนึ่งของ MAGMA หรือ cusp: ประเภทเมทริกซ์ที่มีโครงสร้าง (Circulant, Hankel, ฯลฯ ), การแปลงฟูริเยร์ที่รวดเร็ว, อัลกอริธึมเรียงลำดับ ประเภทจากไลบรารีอื่น ๆ

ประสิทธิภาพ. ชุดคุณลักษณะและการสนับสนุนฮาร์ดแวร์ที่มีขนาดใหญ่กว่าใน ViennaCL มักจะมาในราคาที่ต่ำกว่าเมื่อเทียบกับการใช้งานตาม CUDA ส่วนหนึ่งเป็นผลมาจากความจริงที่ว่า CUDA ได้รับการปรับแต่งให้เข้ากับสถาปัตยกรรมของผลิตภัณฑ์ NVIDIA ในขณะที่ OpenCL แสดงถึงการประนีประนอมที่สมเหตุสมผลระหว่างสถาปัตยกรรมแบบคอร์หลายแกนที่แตกต่างกัน

โดยรวมแล้ว ViennaCL ในปัจจุบันช้ากว่า MAGMA โดยเฉพาะที่ระดับ BLAS 3 เหตุผลคือความสนใจที่แตกต่างกันของ ViennaCL (เบาบางแทนที่จะเป็นพีชคณิตเชิงเส้นหนาแน่น) และทำให้การเพิ่มประสิทธิภาพใน MAGMA สูงขึ้น โดยเฉพาะอย่างยิ่งการดำเนินการ BLAS ระดับ 3 นั้นใน MAGMA เร็วกว่ามาก

ในทำนองเดียวกัน cusp ให้ประสิทธิภาพโดยรวมที่ดีขึ้นเล็กน้อยโดยทั่วไป อย่างไรก็ตามเนื่องจากการดำเนินการกระจัดกระจายเมทริกซ์มักจะแบนด์วิดท์หน่วยความจำ จำกัด ความแตกต่างมีขนาดเล็กมากและมักจะเล็กน้อยเมื่อเทียบกับการตั้งค่าข้อมูลและไม่ชอบ ตัวเลือกของตัวตั้งค่าล่วงหน้าและพารามิเตอร์มักจะมีผลกระทบต่อเวลาดำเนินการโดยรวมสูงกว่าความแตกต่างของประสิทธิภาพใด ๆ ในการคูณเมทริกซ์ - เวกเตอร์

พกพาสะดวก สำหรับความสามารถในการพกพาของฮาร์ดแวร์นั้น ViennaCL สามารถใช้ CPU และ GPU จากผู้ค้ารายใหญ่ทั้งหมดได้ด้วย OpenCL ในทางตรงกันข้าม cusp และ MAGMA พึ่งพา GPU NVIDIA ที่เหมาะสม

ViennaCL เป็นส่วนหัวเท่านั้นสามารถรวบรวมได้ในคอมไพเลอร์ C ++ ที่หลากหลายและจะต้องเชื่อมโยงกับไลบรารี OpenCL เท่านั้นหากจำเป็นต้องมีการรองรับ GPU ตามหลักการแล้วอัลกอริทึมทั่วไปใน ViennaCL ยังสามารถใช้งานได้โดยไม่ต้องเชื่อมโยง OpenCL ใด ๆ ในขณะที่ cusp และ MAGMA ต้องการคอมไพเลอร์ NVIDIA สำหรับการคอมไพล์และไลบรารี CUDA บนระบบเป้าหมายสำหรับการดำเนินการ MAGMA ยังต้องการไลบรารี BLAS ซึ่งบางครั้งอาจเป็นเรื่องยุ่งยากในการค้นหาหรือติดตั้งในระบบใหม่

API MAGMA จัดเตรียมอินเตอร์เฟสฟังก์ชัน BLAS สำหรับการใช้งาน BLAS อินเตอร์เฟส C ++ ของ cusp ยังใช้บางฟังก์ชันจาก BLAS แต่ไม่มีโอเปอเรเตอร์โอเวอร์โหลด เนื่องจากอินเทอร์เฟซส่วนใหญ่ใน ViennaCL นั้นคล้ายกับ Boost.uBLAS และมีน้ำตาลซินแทคติกเช่นโอเวอร์โหลดของผู้ปฏิบัติงานโดยเจตนา ViennaCL จึงตั้งใจจะใช้เช่น Boost.uBLAS ดังนั้นนอกเหนือจากการเรียกชุดปฏิบัติการและอัลกอริทึมที่กำหนดไว้ล่วงหน้าความตั้งใจของเราคือการเปลี่ยนจากการประมวลผลจาก CPU ไปเป็นรหัส GPU อย่างง่ายที่สุดเท่าที่จะทำได้แม้ว่าจะใช้อัลกอริทึมที่ไม่ได้มาตรฐานก็ตาม ในกรณีที่จำเป็นต้องใช้เคอร์เนล OpenCL โดยเฉพาะนอกจากนี้ยังมีกรอบการรวมเคอร์เนล OpenCL ของคุณเองใน ViennaCL ดังนั้น ViennaCL จึงมุ่งเน้นไปที่ผลผลิตสูงในแง่ที่ว่าเวลาที่จำเป็นสำหรับการดำเนินการขั้นตอนวิธีการใหม่ใน GPU จะลดลง การประหยัดเหล่านี้สามารถชดเชยค่าปรับประสิทธิภาพได้อย่างมาก (ถ้ามี) เทียบกับยอดและ MAGMA (มีการกล่าวถึงในการทดสอบหน่วยว่าเวลาการพัฒนาโค้ดเป็นทรัพยากรที่มีค่าในวิทยาศาสตร์)

มีประเด็นเกี่ยวกับอุดมการณ์หลายประการ (เช่น CUDA เทียบกับ OpenCL, อินเตอร์เฟส BLAS และโอเวอร์โหลดของโอเปอเรเตอร์) ตลอดการเปรียบเทียบของฉัน แต่การอภิปรายของพวกเขาอยู่นอกเหนือขอบเขตของคำถามเริ่มต้น

OpenCL สามารถใช้ได้อย่างไรก็ตามมีการขาด infrastracture เช่นไลบรารีคณิตศาสตร์มาตรฐานที่สำคัญที่มีส่วนประกอบพีชคณิตเชิงเส้นมาตรฐานที่ได้รับการปรับแต่งและส่วนประกอบเครื่องมือทำโปรไฟล์ที่ดีแม้ว่าจะมีปัญหาในการปรับปรุงอย่างมีนัยสำคัญสำหรับ GPU สิ่งนี้มีอยู่ใน CUDA ณ วันนี้และสามารถมีส่วนร่วมในความสำเร็จของ Nvidia ด้วยโมเดลการเขียนโปรแกรมนี้ อย่างไรก็ตาม OpenCL ดูเหมือนจะทัน (ช้า)

ทุกวันนี้ในฐานะที่เป็นจุดเริ่มต้นสำหรับการเขียนโปรแกรม GPU CUDA นั้นใช้ได้และถ้าจำเป็นก็ไม่มีอะไรที่ป้องกันไม่ให้ใช้ OpenCL เป็นทางเลือกเช่นการทำให้โค้ดพกพามากขึ้น โดยพื้นฐานแล้วโค้ดเคอร์เนลเดียวกันสามารถใช้ได้ทั้งใน CUDA และ OpenCL ดังนั้นจึงไม่ควรเป็นปัญหาหลักในการเปลี่ยนจาก CUDA เป็น OpenCL สิ่งนี้ได้รับการยืนยันจากประสบการณ์ของตัวเองที่ทดสอบสิ่งนี้ จากมุมมองประสิทธิภาพสามารถใช้เทคนิคการปรับให้เหมาะสมแบบเดียวกันและสำหรับคอมไพเลอร์โค้ดที่เกิดขึ้นพร้อมกันเล็กน้อยควรทำงานได้ดี (เช่นการยกเลิกการวนซ้ำเป็นต้น)