อาหารกลางวันฟรีมากกว่าหรือไม่ [ปิด]


12

ในบทความThe Free Lunch Is Overจากปี 2005 Herb Sutter ทำนายการปฏิวัติการเขียนโปรแกรมพร้อมกันว่าใหญ่เท่ากับการปฏิวัติเชิงวัตถุ การปฏิวัติครั้งนี้มีความสุขจริงๆในปี 2005 - 2013 หรือไม่?


ประเด็นสำคัญในบทความ:

  • ผู้ผลิตหน่วยประมวลผลหมดพื้นที่ด้วยวิธีการแบบดั้งเดิมส่วนใหญ่เพื่อเพิ่มประสิทธิภาพของ CPU แทนที่จะเพิ่มความเร็วสัญญาณนาฬิกาให้สูงขึ้นพวกเขาจะเปลี่ยนไปใช้สถาปัตยกรรมแบบไฮเปอร์เธรดและมัลติคอร์แทน

  • แอปพลิเคชันจะต้องพร้อมกันมากขึ้นหากต้องการใช้ประโยชน์จากปริมาณงานของ CPU อย่างเต็มที่

  • “ โอ้ประสิทธิภาพไม่สำคัญเท่าไหร่คอมพิวเตอร์ก็เร็วขึ้นเรื่อย ๆ ” คำสั่งจะผิด

  • ประสิทธิภาพและการเพิ่มประสิทธิภาพจะได้รับมากขึ้นไม่น้อยไปกว่าสิ่งสำคัญ ภาษาเหล่านั้นที่ให้ยืมเพื่อการปรับให้เหมาะสมอย่างหนักจะได้พบกับชีวิตใหม่ ผู้ที่ไม่จำเป็นต้องหาวิธีในการแข่งขันและมีประสิทธิภาพมากขึ้นและปรับให้เหมาะสม คาดว่าความต้องการที่เพิ่มขึ้นในระยะยาวสำหรับภาษาและระบบที่มุ่งเน้นประสิทธิภาพ

  • ภาษาและระบบการเขียนโปรแกรมจะถูกบังคับให้จัดการกับการทำงานพร้อมกันมากขึ้น เราจำเป็นต้องมีรูปแบบการเขียนโปรแกรมระดับสูงสำหรับการทำงานพร้อมกันมากกว่าภาษาที่มีให้ในวันนี้


15
โทรศัพท์ของคุณมีกี่คอร์?
แมตต์ D

6
Nokia 2700 ของฉันมีหนึ่งคอร์
cpp

5
@MattD ขออภัย แต่ทำไม "ถึงเวลาอัพเกรด" และจำนวนคอร์ในโทรศัพท์ของ cpp ต้องทำอย่างไร? คุณจะรู้ได้อย่างไรว่าโนเกีย 2700 นั้นไม่เพียงพอสำหรับความต้องการของเขา
Andres F.

2
ฉันจะพูดต่อไปเพื่อบันทึกโดยการสังเกตที่ไม่ใช่ทางวิทยาศาสตร์โดยสิ้นเชิงว่ามีการปฏิวัติในด้านฮาร์ดแวร์ของสิ่งต่าง ๆ แต่การปฏิวัติซอฟต์แวร์นั้นช้ามากเป็นพิเศษ การได้รับเครื่องมือการทำงานพร้อมกันที่มีคุณภาพสำหรับโปรแกรมเมอร์ทั้งหมดยังคงเป็นกิ๊กที่ยากลำบากและการทำงานพร้อมกันยังคงเป็นสิ่งที่พัฒนาขึ้นแม้นักพัฒนาแบบขนานที่มีประสบการณ์ในรูปแบบที่ยากต่อการทำซ้ำ
Jesse C. Slicer

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

คำตอบ:


23

ใช่ แต่มันก็ขึ้นอยู่กับ

คุณไม่สามารถคาดหวังที่จะเขียนขี้ปะติ๋ว , ที่มีประสิทธิภาพสูงซอฟแวร์โดยไม่ต้องทั้งการใช้ประโยชน์จากฮาร์ดแวร์แบบขนานและใช้เห็นพ้องเป็นเทคนิคโปรแกรมโครงสร้าง แต่ซอฟต์แวร์ส่วนใหญ่มีทั้งเรื่องไม่สำคัญและไม่มีประสิทธิภาพ แอปพลิเคชันบนเว็บไม่ได้ทำการบีบอัดจำนวนมากและแอพ CRUD ไม่มีอะไรเหมือนขีด จำกัด เวลาที่ยากสำหรับซอฟต์แวร์การจำลองและการแพทย์

ผู้พัฒนาเกมจำเป็นต้องให้ความสำคัญกับเรื่องนี้เป็นพิเศษเพราะเกมเป็นแอพพลิเคชั่นที่ใช้กันทั่วไปและมีความต้องการแบบเรียลไทม์อ่อน ปัญหาสำคัญในโทรศัพท์มือถือที่คุณต้องการบีบการประมวลผลและพลังงานให้ได้มากที่สุดเท่าที่จะเป็นไปได้จากชิปในตัวที่มีสองคอร์ CPU และ GPU ที่ใช้พลังงานต่ำ นั่นเป็นอีกเหตุผลหนึ่งที่นักพัฒนาจำนวนมากกำลังมองหา Haskell และรอภาษาอย่าง Rust เพื่อเติบโต - เราต้องการความปลอดภัยและประสิทธิภาพสำหรับฮาร์ดแวร์ที่ทันสมัย

ตั้งแต่ปี 2005 เราได้รับเครื่องมือใหม่และปรับปรุงเช่นชุดคำสั่ง OpenCL, CUDA, OpenMP และเวกเตอร์สำหรับการทำงานพร้อมกันและข้อมูลขนานในภาษาที่กำหนด อย่างไรก็ตามผู้มาใหม่ที่ได้รับการออกแบบมาตั้งแต่ต้นเพื่อทำสิ่งที่น่าสนใจอีกมากมายพร้อมกัน

รันไทม์ที่เกิดขึ้นพร้อมกันของ Haskell ช่วยให้ภาษาสามารถให้การสนับสนุนการขนานที่มีน้ำหนักเบา (ประกายไฟ) และ abstractions ที่เกิดขึ้นพร้อมกัน (เธรดช่องทางและการอ้างอิงที่ไม่แน่นอนที่ใช้ร่วมกัน) Go และ Rust ยังมีงานที่มีน้ำหนักเบา, Go โดยใช้ช่องและ Rust โดยใช้การส่งข้อความ

ระบบเหล่านี้มีความปลอดภัยของหน่วยความจำรันไทม์ของนักแสดงและการป้องกันแบบคงที่ต่อการแข่งขันบางประเภท การเปลี่ยนไม่ได้โดยค่าเริ่มต้นของ Haskell และ Rust ทำให้การจัดการพร้อมกันง่ายขึ้นสำหรับมนุษย์ในการจัดการ Erlang ได้ทำสิ่งนี้มาแล้วในยุค 80 แต่ความต้องการซอฟต์แวร์และความรู้ของเราเกี่ยวกับวิธีการออกแบบระบบการเขียนโปรแกรมก็ดีขึ้นเช่นกัน - ขอบคุณพระเจ้า

ในที่สุดภาษาที่มีอยู่มากมาย - ฉันจะไม่ตั้งชื่อ - พร้อมที่จะปฏิเสธเป็นตัวเลือกที่น่าเชื่อถือสำหรับการเขียนซอฟต์แวร์ใหม่ ภาระของพวกเขาที่มีความซับซ้อนและ abstractions การทำงานพร้อมกันที่ไม่ดีทำให้พวกเขาไม่เหมาะสมสำหรับการพิจารณาการใช้งานที่ทันสมัย เรากำลังรอทางเลือกที่เป็นผู้ใหญ่


2
ฉันไม่แน่ใจเกี่ยวกับการลดลงของบางภาษาฉันหวังว่าเราจะเห็นโค้ดที่เขียนโดยมุ่งเน้นที่การลดการพึ่งพาได้มากกว่าสิ่งอื่นใด ท้ายที่สุดมันไม่ได้เป็นภาษาที่ผิด แต่เป็นวิธีที่คุณใช้ และ "ผลไม้แขวนลอยต่ำ" ของการใช้งานนั้นไม่สอดคล้องกับมัลติเธรด / การทำงานพร้อมกันอีกต่อไป
Matt D

6
@MattD: ทั้งวิธีที่คุณใช้ภาษาและภาษานั้นอาจเป็นความผิดพลาด สมมติว่าโปรแกรมของคุณผิด คุณเป็นคนที่เขียนผิด แต่ภาษาไม่ได้ช่วยให้คุณเขียนถูกต้องและนั่นก็สำคัญมาก
Jon Purdy

6

นี่คือจุดข้อมูลน้อย ตัดสินใจด้วยตัวเองหากนับว่าเป็นการปฏิวัติ

ฮาร์ดแวร์แบบขนาน

ประมาณปี 2005 ทั้ง Intel และ AMD เริ่มผลิตซีพียูเดสก์ท็อป x86 2 หลัก (Pentium D และ Athlon 64) ด้วยความเร็วสัญญาณนาฬิกาประมาณ 3 GHz

ในปี 2549 PlayStation 3 ได้เปิดตัวพร้อมหน่วยประมวลผล Cell ที่มี 8 + 1 คอร์ที่ 3.2 GHz

ในปี 2549 GeForce 8 ซีรีส์เปิดตัว ประกอบด้วยจำนวนมาก (~ 100) ของ 'สตรีมโปรเซสเซอร์' ที่มีวัตถุประสงค์ทั่วไปซึ่งตรงข้ามกับหน่วยเฉพาะกราฟิก ประมาณปี 2550 มีการเผยแพร่ข้อมูลจำเพาะ CUDA 1.0 ซึ่งช่วยให้การคำนวณทั่วไปใช้กับฮาร์ดแวร์ NVidia แบบขนานจำนวนมาก

ตั้งแต่นั้นมามีแนวโน้มอย่างต่อเนื่อง

สมมติว่าในปี 2013 ทั้ง Intel และ AMD เสนอซีพียู 4, 8 และ 16 คอร์ด้วยความเร็วสัญญาณนาฬิกาที่สูงกว่าเพียง 4 GHz เล็กน้อย การออกแบบดูอัลคอร์และควอดคอร์เป็นเรื่องปกติสำหรับอุปกรณ์ที่ใช้พลังงานต่ำเช่นแล็ปท็อปและสมาร์ทโฟน

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

ซอฟต์แวร์

CUDA เปิดตัวในปี 2550 จากนั้น OpenCL ในปี 2551 อนุญาตให้ใช้ GPU แบบขนานอย่างหนาแน่นในการคำนวณทั่วไป (ไม่ใช่กราฟิก) ตัวแบบกลายเป็นที่นิยม บริษัท โฮสติ้งหลายแห่ง (เช่น Amazon) เสนอ GPU สำหรับงานคอมพิวเตอร์ทั่วไป

Goเปิดตัวในปี 2009 โดยมีเธรดที่มีราคาถูกมาก ("goroutines") และอนุญาตให้แสดงอัลกอริธึมพร้อมกันได้อย่างมีประสิทธิภาพสูง

ชุดเครื่องมือ Akkaเปิดตัวสำหรับ Java และ Scala ในปี 2009 ช่วยให้มีการทำงานพร้อมกันตามนักแสดง

Erlang (ภาษาพร้อมกันสูง) เห็นการใช้งานเพิ่มขึ้น

การเกิดพร้อมกันกับการเปรียบเทียบ

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

การประมวลผลแบบขนานอาจใช้ภาษาดั้งเดิมมากขึ้นและกรอบงานแบบขนานเช่น map-ลดหรือ MPC หรือ OpenMP สำหรับเฟรมเวิร์กดังกล่าวการมีหลายคอร์ในซีพียูคริสตัลเดียวกันนั้นไม่แตกต่างจากที่มีเพียงซีพียูในคลัสเตอร์เท่านั้น ความแตกต่างคือความเร็วส่วนใหญ่

ไม่มีอาหารกลางวันฟรี

ความเร็วของ CPU ยังคงอยู่ที่ระดับ 5 GHz ที่ระดับไฮเอนด์ ด้วยเทคโนโลยีที่ดีกว่าในสายตาเช่นกราฟีนทรานซิสเตอร์ความถี่อาจเพิ่มขึ้นอีกในอนาคต แต่อาจจะไม่ช้า

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.