ในโลกแห่งคอมพิวเตอร์ที่พัฒนาอย่างรวดเร็ว สตาร์ทอัพใหม่ชื่อ VectorWare ได้ปรากฏตัวขึ้นพร้อมคำอ้างที่กล้าหาญ: เรากำลังอยู่บนจุดเปลี่ยนพื้นฐานจากการพัฒนาซอฟต์แวร์ที่เน้น CPU ไปสู่ซอฟต์แวร์ GPU-native แม้การประกาศของบริษัทจะสร้างความสนใจอย่างมาก แต่ชุมชนนักพัฒนากำลังถกเถียงกันอย่างแข็งขันว่าวิสัยทัศน์นี้เป็นไปได้จริงหรือไม่ เมื่อพิจารณาจากข้อจำกัดของฮาร์ดแวร์และระบบนิเวศซอฟต์แวร์ในปัจจุบัน
ใจความหลัก: อนาคตที่ GPU มาก่อน
ข้อโต้แย้งพื้นฐานของ VectorWare คือ ในขณะที่เทคโนโลยีอย่าง AI และรถยนต์ขับเคลื่อนอัตโนมัติเป็นข่าวพาดหัว การเปลี่ยนแปลงทางเทคโนโลยีที่เกิดขึ้นจริงอยู่เบื้องหลังคือการย้ายจาก CPU ไปสู่ GPU ในฐานะเครื่องมือประมวลผลหลัก บริษัทเชื่อว่าซอฟต์แวร์ส่วนใหญ่ที่ใช้ GPU ในปัจจุบันไม่ได้เป็น native กับสถาปัตยกรรมนี้อย่างแท้จริง แต่เป็นซอฟต์แวร์ CPU ที่มีการเพิ่มความเร็วจาก GPU ติดตั้งเพิ่มเติมเท่านั้น ทางออกของพวกเขา? คือการสร้างซอฟต์แวร์ที่ GPU เป็นผู้ควบคุมตั้งแต่พื้นฐาน ไม่ใช่เพียงอุปกรณ์เสริมสำหรับการจัดการโดย CPU
บริษัทได้วาดภาพเปรียบเทียบทางประวัติศาสตร์ที่น่าสนใจ โดยวางตำแหน่งให้ GPU เป็นแพลตฟอร์มฮาร์ดแวร์ใหม่ที่เทียบเท่ากับพีซีในยุคเริ่มต้น โดยมี AI ทำหน้าที่เป็นแอปพลิเคชันสำคัญที่ทำให้ฮาร์ดแวร์นี้แพร่หลาย เช่นเดียวกับที่สเปรดชีตทำสำหรับคอมพิวเตอร์ส่วนบุคคล ใน analogy นี้ VectorWare ตั้งเป้าที่จะเป็น Microsoft ของยุคคอมพิวเตอร์ใหม่นี้
ความเคลือขแคลงของชุมชนและความเป็นจริงทางเทคนิค
แม้จะมีวิสัยทัศน์ที่ทะเยอทะยาน นักพัฒนาที่มีประสบการณ์ในการอภิปรายออนไลน์ได้ตั้งคำถามสำคัญเกี่ยวกับการนำไปปฏิบัติจริง ผู้แสดงความคิดเห็นหนึ่งคนสรุปความสับสนของชุมชนได้อย่างสมบูรณ์แบบ: หลังจากอ่านหน้านี้แล้ว ฉันยังไม่รู้ว่าพวกเขาต้องการพัฒนา GPU-native ware อะไร ความรู้สึกนี้สะท้อนถึงความไม่แน่ใจในวงกว้างเกี่ยวกับแอปพลิเคชันเฉพาะใดที่จะได้รับประโยชน์อย่างแท้จริงจากการเป็น GPU-native โดยสมบูรณ์ เทียบกับการเพียงเร่งความเร็วด้วย GPU
การอภิปรายได้เปิดเผยอุปสรรคทางเทคนิคหลายประการที่ VectorWare ต้องก้าวข้าม สถาปัตยกรรม GPU ในปัจจุบันมีข้อจำกัดพื้นฐานสำหรับการคำนวณทั่วไป ดังที่นักพัฒนาคนหนึ่งระบุ ฉันรู้สึกว่านี่เป็นเพราะสถาปัตยกรรมฮาร์ดแวร์ปัจจุบัน ไม่ใช่ความผิดของซอฟต์แวร์ การจัดการหน่วยความจำยังคงเป็นความท้าทายโดยเฉพาะ แม้จะมี unified memory นักพัฒนายังคงต้องจัดการ working sets ใน VRAM ด้วยตนเอง สร้างความซับซ้อนที่ไม่มีในการเขียนโปรแกรม CPU
ด้วยสถาปัตยกรรม GPU ในปัจจุบัน สิ่งนี้ดูเหมือนไม่น่าเป็นไปได้ เช่น คุณจะต้องมีเซลล์จำนวนมากที่มีอินพุตที่ตรงกันเกือบสมบูรณ์แบบก่อนที่แม้แต่การเดินทางไปกลับของบัส DMA จะคุ้มค่า
ความท้าทายทางเทคนิคที่ระบุโดยชุมชน:
- ข้อจำกัดในการจัดการหน่วยความจำ GPU
- ขาดมาตรฐาน GPU ISA
- ข้อจำกัดด้านสถาปัตยกรรมฮาร์ดแวร์
- ค่าโอเวอร์เฮดจากการส่งข้อมูลไปกลับผ่านบัส DMA
- ความต้องการในการจัดการ VRAM อย่างชัดเจน
ทีมงาน Rust และระบบนิเวศที่มีอยู่
ทีมงานทางเทคนิคของ VectorWare นำความน่าเชื่อถือมาอย่างมาก ประกอบด้วยอดีตสมาชิกทีม Rust compiler และผู้ดูแลโครงการเขียนโปรแกรม GPU ที่สำคัญ เช่น rust-gpu และ rust-cuda อย่างไรก็ตาม สิ่งนี้ได้จุดประกายความกังวลภายในชุมชนเกี่ยวกับอนาคตของโครงการโอเพ่นซอร์สที่สำคัญเหล่านี้ ผู้แสดงความคิดเห็นได้ตั้งคำถามว่าเครื่องมือที่สำคัญเหล่านี้อาจไม่ได้รับการบำรุงรักษาหรือไม่ ตอนที่ผู้สร้างกำลังดำเนินธุรกิจแล้ว
การอภิปรายยังได้เน้นย้ำว่ามีทางเลือกที่ใช้งานได้อยู่แล้วในระบบนิเวศ Rust นักพัฒนาได้กล่าวถึงการใช้โครงการอย่าง wGPU สำหรับกราฟิกส์ 3D, Ash สำหรับ Vulkan bindings และ Cudarc สำหรับการดำเนินการ CUDA kernel ที่ประสบความสำเร็จ นักพัฒนาคนหนึ่งแบ่งปันประสบการณ์เชิงบวกของพวกเขา: ฉันใช้ [Cudarc] มาแล้วสองสามปีและทำงานได้ดีเยี่ยม ฉันใช้มันสำหรับการ backtest ตลาดการเงิน สิ่งนี้ทำให้เกิดคำถามว่า VectorWare จะนำคุณค่าเฉพาะใดที่นอกเหนือจากเครื่องมือที่มีอยู่ที่成熟แล้ว
ทางเลือกอื่นๆ ในระบบนิเวศ Rust GPU ที่ถูกกล่าวถึง:
- wGPU: สำหรับกราฟิก 3D
- Ash: Vulkan bindings
- Cudarc: การรัน CUDA kernel
- rust-gpu: การสร้างโค้ด GPU แบบทดลอง
- rust-cuda: รองรับ CUDA สำหรับ Rust
แอปพลิเคชันเชิงปฏิบัติและการสาธิตที่กำลังจะมาถึง
เมื่อถูกกดดันให้ยกตัวอย่างที่เป็นรูปธรรม ตัวแทนของ VectorWare ได้สัญญาว่าจะมีการสาธิตในอีกไม่กี่สัปดาห์ข้างหน้า พวกเขาได้บอกเป็นนัยว่าซอฟต์แวร์มากกว่าที่คุณคิดสามารถทำงานบน GPU ได้เต็มที่ โดยเฉพาะกับการ์ดในดาต้าเซ็นเตอร์ แอปพลิเคชันที่มีศักยภาพที่กล่าวถึงรวมถึงฐานข้อมูลและ workloads อื่นที่ใช้ข้อมูลอย่างเข้มข้น ซึ่งความสามารถในการประมวลผลแบบขนานของ GPU สามารถให้ข้อได้เปรียบที่สำคัญ
บริษัทกำลังรับสมัครพนักงานอย่างแข็งขันในหลายบทบาทเฉพาะทาง ตั้งแต่วิศวกรรมแอปพลิเคชัน GPU-native ไปจนถึงการพัฒนา Linux kernel ซึ่งบ่งชี้ว่าพวกเขากำลังสร้างสแต็กที่ครอบคลุมแทนที่จะมุ่งเน้นที่แอปพลิเคชันเดียว วิธีการของพวกเขาดูเหมือนจะแก้ปัญหาที่หลายระดับ: ตั้งแต่งานคอมไพเลอร์ระดับต่ำไปจนถึงแอปพลิเคชันที่ผู้ใช้ใช้งาน
พื้นที่สำคัญในการจ้างงานของ VectorWare:
- วิศวกรรมแอปพลิเคชันแบบ GPU-native (ประสบการณ์ Rust + GPU/ML)
- วิศวกรรมคอมไพเลอร์และการออกแบบภาษา (ผู้มีส่วนร่วมในคอมไพเลอร์ Rust)
- วิศวกรรมกราฟิกส์ระดับ Userland (Rust + graphics APIs)
- วิศวกรรม Linux kernel (ไดรเวอร์ที่ใช้ Rust)
เส้นทางข้างหน้าสำหรับคอมพิวเตอร์ GPU-Native
การอภิปรายของชุมชนเผยให้เห็นทั้งความตื่นเต้นและความเคลือบแคลงที่มีสุขภาพดีเกี่ยวกับวิสัยทัศน์ที่ทะเยอทะยานของ VectorWare ในขณะที่นักพัฒนาตระหนักถึงศักยภาพทางทฤษฎีของซอฟต์แวร์ที่เน้น GPU มากขึ้น พวกเขากำลังรอเพื่อดูการนำไปปฏิบัติที่เป็นรูปธรรมที่แสดงให้เห็นถึงข้อได้เปรียบที่ชัดเจนเหนือแนวทางการเร่งความเร็วด้วย GPU ในปัจจุบัน
ความสำเร็จของวิสัยทัศน์ VectorWare อาจขึ้นอยู่กับแนวคิดใหม่ ๆ ที่ปฏิวัติน้อยลง และขึ้นอยู่กับการแก้ไขความท้าทายทางวิศวกรรมเชิงปฏิบัติที่ป้องกันการยอมรับการเขียนโปรแกรม GPU ในวงกว้างมากขึ้น ในขณะที่บริษัทกำลังเตรียมตัวที่จะแบ่งปันการสาธิตครั้งแรก ชุมชนนักพัฒนากำลังจับตาดูด้วยความสนใจอย่างมาก พร้อมที่จะประเมินว่า VectorWare สามารถทำตามสัญญาในการทำให้ซอฟต์แวร์ GPU-native รู้สึกธรรมดาแทนที่จะแปลกใหม่ได้หรือไม่
คำถามพื้นฐานยังคงอยู่: โลกพร้อมสำหรับซอฟต์แวร์ที่ GPU รับบทบาทนำหรือไม่? หรือการเร่งความเร็วด้วย GPU ที่จัดการโดย CPU จะยังคงครอบงำในอนาคตอันใกล้? มีเพียงการนำไปปฏิบัติที่ทำงานได้และข้อมูลประสิทธิภาพในโลกจริงเท่านั้นที่จะให้คำตอบ
อ้างอิง: Announcing VectorWare