กระบวนทัศน์การทำงานไม่แตกต่างกันมากเกินไปกับฮาร์ดแวร์พื้นฐานที่จะมีประสิทธิภาพโดยทั่วไป?

แรงบันดาลใจจากคำถามจาก SO: /programming/6623391/how-to-gain-control-of-a-5gb-heap-in-haskell

มันอาจเป็นการถกเถียงกันมานานเกี่ยวกับข้อดีและข้อเสียของ FP มากมาย แต่สำหรับตอนนี้ฉันต้องการ จำกัด ขอบเขตของ FP ที่มีประสิทธิภาพหลักสำหรับฮาร์ดแวร์ที่ทันสมัย

วิทยานิพนธ์:

กระบวนทัศน์การใช้งานหมายถึงความไม่สามารถเปลี่ยนแปลงได้และไร้สัญชาติ (?) แต่ฮาร์ดแวร์ที่เราเรียกใช้โปรแกรมการทำงานนั้นเป็นสถานะออโตมาต้าอัน จำกัด การแปลโปรแกรม 'ฟังก์ชั่นที่ใช้งานได้จริง' เป็น 'การแสดงสถานะฮาร์ดแวร์' ทำให้การควบคุมเพียงเล็กน้อยสำหรับโปรแกรมเมอร์ทำให้โอเวอร์เฮด (?) และ จำกัด การใช้ความสามารถของฮาร์ดแวร์

ฉันถูกหรือผิดในข้อความที่ถาม?

มันสามารถพิสูจน์ได้ว่า FP ทำ / ไม่ได้บอกถึงการลงโทษด้านประสิทธิภาพที่สำคัญของสถาปัตยกรรมคอมพิวเตอร์ที่มีวัตถุประสงค์ทั่วไปที่ทันสมัยหรือไม่?

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

มีความเข้าใจผิดอย่างมากในความไม่สามารถเปลี่ยนแปลงได้

ความไม่เปลี่ยนแปลงเป็นคุณลักษณะของซีแมนทิกส์ แต่มันไม่ได้หมายความถึงการเปลี่ยนแปลงในการนำไปใช้

ตัวอย่างง่ายๆคือการดำเนินการของความเกียจคร้าน

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

ครั้งแรกที่คุณจะถาม (ในภาษา) สำหรับค่าการคำนวณจะถูกดำเนินการจริงผลการประเมินและค่าที่มอบให้คุณ (หรือที่จับ)

นี่คือความโปร่งใสในความหมายของภาษาและสิ่งที่คุณรู้คือตัวแปรนี้ถูกผูกไว้กับค่า (หรือค่าในอนาคต) และเมื่อมันเสร็จแล้วคุณจะไม่สามารถเปลี่ยนค่าที่จะถูกส่งกลับ การแสดงหน่วยความจำพื้นฐานจะเปลี่ยนไป แต่คุณจะไม่รู้เกี่ยวกับมัน

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

ตอนนี้มันเป็นความจริงที่ภาษาที่ใช้งานได้จริงไม่เร็วเท่า C ++ อย่างไรก็ตามGo(ซึ่งค่อนข้างเป็น hype ภาพนิ่ง) ช้ากว่า Haskell หรือ Lisp และ C # Mono ( ต้นฉบับ )

เมื่อคุณเห็นว่า C ++ หรือ C ที่ไม่น่าเชื่อถือสามารถให้การแสดงเหล่านั้นแก่คุณได้อย่างไรคุณอาจต้องการปล่อยให้ไปสักระยะ

เมื่อคุณรู้ว่า Haskell เติบโตอย่างรวดเร็วในวันนี้และยังมีที่ว่างอีกมากสำหรับการเพิ่มประสิทธิภาพในคอมไพเลอร์ / รันไทม์ (GHC เพิ่งเปลี่ยนเป็น LLVM เมื่อเร็ว ๆ นี้เช่น Microsoft Research กำลังให้เงินสนับสนุนการปรับปรุงรันไทม์) คุณอาจเต็มใจที่จะ กำลังจะปรับปรุงในไม่ช้า

สนุก: การเล่นบนนิพจน์ปกติหรือวิธีที่ทีม Haskell สร้างตัวจับคู่นิพจน์ปกติที่มีประสิทธิภาพสูงกว่าre2ไลบรารี C จาก Google ในหลาย ๆ สถานการณ์

กระบวนทัศน์การทำงานมีประโยชน์ในการแยกสิ่งต่าง ๆ ในขอบเขตที่แคบ นี่เป็นสิ่งที่ดีจริงๆเมื่อพิจารณาว่าคอมพิวเตอร์วิวัฒนาการอย่างไร

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

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

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

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

ทุกคนที่จัดการกับระบบคู่ขนานที่ซับซ้อนรู้ว่าฉันกำลังพูดถึงอะไร

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

ฉันไม่ได้คำตอบจริงๆเพราะฉันไม่ทราบสถานะปัจจุบันหรือแม้กระทั่งว่ามันยากแค่ไหน แต่เพียงเพราะคอมไพเลอร์จะรับรองสิ่งเหล่านั้นจากอินพุตดังนั้นไม่จำเป็นต้องหมายความว่าเอาต์พุตจะมีพวกเขา . ในทางทฤษฎีแล้วคอมไพเลอร์ที่ฉลาดพอสามารถผ่านปัญหาเหล่านี้ได้ แต่ในทางปฏิบัติมันอาจมีอยู่เสมอ

อย่างไรก็ตามอีกวิธีในการดูคือดูประวัติของเครื่อง Lisp ถ้าฉันจำได้อย่างถูกต้องพวกเขาได้รับการออกแบบมาเพื่อแก้ไขปัญหาเดิมที่ Lisp มีกับความแตกต่างจากเครื่องในเวลานั้น ในที่สุดการพัฒนาเครื่องเหล่านี้ก็หยุดลงเนื่องจากเดสก์ท็อปเร็วพอที่จะทำให้ความไร้ประสิทธิภาพถูกกว่าอยู่เพื่อสนับสนุนเครื่องอื่น

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

ในตอนท้ายการเขียนโปรแกรมทั้งหมดเกี่ยวกับการแลกเปลี่ยนดังนั้นหนึ่งต้องเลือกสิ่งที่สำคัญกว่าสำหรับโครงการในมือ

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

ที่กล่าวมาเพื่อตอบคำถามของคุณเกี่ยวกับประสิทธิภาพฉันใช้ทั้ง Haskell และ Clojure และไม่ได้สังเกตเห็นปัญหาด้านประสิทธิภาพใด ๆ