เราสามารถสร้างข้อความทั่วไปเกี่ยวกับประสิทธิภาพของการแปลรหัสและการแปลรหัสได้หรือไม่?

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

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

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

เลขที่

โดยทั่วไปประสิทธิภาพของการใช้ภาษานั้นขึ้นอยู่กับปริมาณเงินทรัพยากรกำลังคนการวิจัยวิศวกรรมและการพัฒนาที่ใช้ไป

และโดยเฉพาะประสิทธิภาพของโปรแกรมเฉพาะนั้นขึ้นอยู่กับปริมาณของความคิดที่ใส่ลงในอัลกอริทึมเป็นหลัก

มีล่ามที่รวดเร็วมากบางตัวและคอมไพเลอร์บางตัวที่สร้างโค้ดช้ามาก

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

การวางนัยทั่วไปและสถานการณ์เฉพาะนั้นตรงกันข้าม

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

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

โดยทั่วไปแล้วโปรแกรมที่แปลแล้วนั้นช้ากว่าการเขียนโปรแกรมในภาษาที่เป็นโฮสต์ของล่ามประมาณ 2–10 เท่าโดยมีล่ามสำหรับภาษาแบบไดนามิกที่ช้ากว่า นี่เป็นเพราะโปรแกรมตีความต้องทำงานจริงทั้งหมด แต่ยังมีค่าใช้จ่ายการตีความ

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

เช่น Perl เป็นภาษาที่ตีความมุ่งเน้นไปที่การจัดการข้อความ โปรแกรม Perl ที่มีสำนวนที่ใช้การจัดการข้อความจะไม่ช้ากว่าโปรแกรม C มากนักและอาจมีประสิทธิภาพสูงกว่าโปรแกรม C ในบางกรณี (เป็นไปได้เนื่องจาก Perl ใช้การแทนสตริงที่แตกต่างกันและมีการเพิ่มประสิทธิภาพข้อความและ IO ที่เกี่ยวข้องต่าง ๆ ) อย่างไรก็ตามการทำตัวเลขซ้ำซ้อนใน Perl จะช้าอย่างไม่น่าเชื่อ การเพิ่มขึ้น++xเป็นคำสั่งการประกอบเพียงครั้งเดียว แต่เกี่ยวข้องกับทราฟฟิกตัวชี้และกิ่งไม้จำนวนมากสำหรับล่าม Perl ฉันเพิ่งย้ายสคริปต์ Perl ที่เชื่อมโยงกับ CPU ไปที่ C ++ และเพิ่มความเร็ว 7x – 20x ขึ้นอยู่กับระดับการปรับให้เหมาะสมของคอมไพเลอร์

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

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

เมื่อเลือกเทคโนโลยีประสิทธิภาพของภาษารันไทม์ในตัวมันเองนั้นไม่เกี่ยวข้องอย่างสมบูรณ์ มีความเป็นไปได้มากกว่าที่จะสำคัญว่าเทคโนโลยีมีข้อ จำกัด พื้นฐานบางอย่าง (งบประมาณของเราคือ $ x เราจะต้องสามารถส่งมอบได้ก่อน yyyy-mm-dd เราต้องตอบสนองความต้องการที่ไม่ใช้งานได้หลากหลาย) และมีราคาต่ำกว่า ต้นทุนรวมในการเป็นเจ้าของ (การผลิตผลของนักพัฒนา, ต้นทุนฮาร์ดแวร์, ต้นทุนโอกาสทางธุรกิจ, ความเสี่ยงของข้อบกพร่องและข้อ จำกัด ที่ไม่คาดคิดในเทคโนโลยี, ค่าบำรุงรักษา, ค่าฝึกอบรมและค่าจ้างงาน, ... ) เช่นในอุตสาหกรรมที่เวลาสู่ตลาดเป็นปัจจัยที่สำคัญที่สุดเทคโนโลยีที่มีผลงานการพัฒนาที่ดีที่สุดจะเหมาะสมที่สุด สำหรับองค์กรขนาดใหญ่ค่าบำรุงรักษาและค่าใช้จ่ายระยะยาวอาจน่าสนใจกว่า

คุณสามารถพูดบางอย่างเกี่ยวกับประสิทธิภาพของเทคโนโลยีที่รวบรวม / ตีความ แต่ก่อนอื่นคุณต้องกำหนด "ประสิทธิภาพ" หากคุณกำลังสร้างระบบสมองกลฝังตัวที่เรียบง่ายการคำนวณ "ประสิทธิภาพ" น่าจะเอนไปทางด้านการใช้หน่วยความจำของสิ่งต่าง ๆ ในขณะที่ระบบที่ซับซ้อนในการคำนวณใช้งานกับชุดข้อมูลขนาดใหญ่จะพบว่าตัวเองกำหนด "ประสิทธิภาพ" ในจำนวนการคำนวณต่อหน่วยเวลาตั้งแต่ค่าใช้จ่ายหน่วยความจำจาก JVM หรือ. NET จะน้อยมาก

เมื่อคุณตัดสินใจว่า "ประสิทธิภาพ" คืออะไรคุณสามารถพูดอะไรเช่น "เราจะมีวัตถุในหน่วยความจำ 50,000 ล้านล้านครั้งและตีความ techA เพิ่มอีก 8 ไบต์ต่อวัตถุสำหรับการจัดการภายในซึ่งเท่ากับค่าใช้จ่ายหน่วยความจำ 400GB เมื่อเปรียบเทียบกับ techB ซึ่งไม่ได้เพิ่มข้อมูลนี้ "

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

ด้านเทคนิคของบางสิ่งบางอย่างเช่นนี้เป็นเพียงส่วนเล็ก ๆ ของการตัดสินใจระหว่าง A และ B มีปัจจัยอื่น ๆ อีกมากมายที่ควรทราบ:

• มันเกี่ยวข้องกับค่าลิขสิทธิ์หรือไม่? ตัวอย่างเช่นคุณต้องจ่าย (จำนวนมาก) เพื่อใช้คลัสเตอร์ของเครื่อง SQL Server กับการใช้คลัสเตอร์ของเครื่อง PostgreSQL
• ฉันจะมีพนักงานที่คุ้นเคยกับเทคโนโลยี (กอง) และระบบนิเวศของมันได้อย่างไร ถ้าใช่พวกมันพร้อมใช้งานหรือไม่ ถ้าไม่ฉันจะจ้างได้ไหม ฉันต้องเสียค่าใช้จ่ายเท่าไหร่ หรือฉันจะฝึกอบรมสิ่งที่มีอยู่? ฉันต้องเสียค่าใช้จ่ายเท่าไหร่
• ลูกค้าต้องการอะไร อาจเป็นปัญหาได้บ่อยครั้ง
• เป็นเทคโนโลยีที่ฉันแนะนำให้พร้อมใช้งานสำหรับการผลิตหรือไม่ หรือมันเป็นเพียงแค่โฆษณาชวนเชื่อในปัจจุบันที่อาจจะตาย? (เช่นคิดว่า Node.js เมื่อมันออกมาครั้งแรก)
• เทคโนโลยีที่ฉันแนะนำมีความเหมาะสมกับสถาปัตยกรรมที่มีอยู่หรือสถาปัตยกรรมที่ฉันมีอยู่ในใจหรือไม่ หรือฉันต้องใช้เงินจำนวนมากด้วยการทำให้พวกเขาทำงานร่วมกันได้อย่างราบรื่นหรือไม่?
• และด้านอื่น ๆ อีกมากมายที่ขึ้นอยู่กับสถานการณ์เฉพาะของคุณ

อย่างที่คุณเห็นมีสิ่งมากมายที่ต้องพิจารณาเมื่อทำการตัดสินใจ

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

การประเมินผลบางส่วนเป็นกรอบแนวคิดที่เกี่ยวข้องกับล่ามและผู้แปล

เราสามารถสร้างข้อความทั่วไปเกี่ยวกับประสิทธิภาพของการแปลรหัสและการแปลรหัสได้หรือไม่?

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

แม้ในภาษาที่รวบรวมแบบดั้งเดิม (นั่นคือภาษาที่มีการใช้งานมักจะรวบรวม) เช่น C บางส่วนก็มักจะตีความ ยกตัวอย่างเช่นสตริงควบคุมรูปแบบของprintf (ที่กำหนดไว้ในมาตรฐานซี) เป็นมักจะ "ตีความ" (โดยห้องสมุดมาตรฐาน Cซึ่งมีprintf ฟังก์ชั่นการใช้เทคนิคการขัดแย้งตัวแปร) แต่บางคอมไพเลอร์ (รวมGCC ) จะสามารถ -in จำกัดเฉพาะ กรณี - เพื่อปรับให้เหมาะสมและ "คอมไพล์" ลงในการโทรระดับล่าง

และการใช้งานบางอย่างแม้ใน "ล่าม" กำลังใช้เทคนิคการรวบรวม JIT (ดังนั้นจึงต้องสร้างรหัสเครื่องตอนรันไทม์ ) กันตัวอย่างที่ดีคือluajit การใช้งานอื่น ๆ (เช่น Python, Ocaml, Java, Parrot, Lua) กำลังแปลซอร์สโค้ดเป็นbytecodeซึ่งจะถูกแปลความหมายนั้น

SBCLเป็นคอมไพเลอร์ "เสียงกระเพื่อม" ทั่วไปซึ่งแปลการโต้ตอบREPLทุกครั้ง(และการโทรไปยังevalฯลฯ ... ) เป็นรหัสเครื่อง ดังนั้นคุณรู้สึกว่ามันเป็นล่าม การใช้งาน JavaScript ส่วนใหญ่ในเบราว์เซอร์ (เช่นv8 ) ใช้เทคนิคการรวบรวม JIT

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

การติดตั้งอาจเร็วหรือช้าอย่างอิสระจากการใช้เทคนิค "คอมไพเลอร์" หรือ "ล่าม" ส่วนใหญ่

บางลักษณะภาษาชอบแนวทางการตีความ (และสามารถรวบรวมได้อย่างมีประสิทธิภาพผ่านการวิเคราะห์โปรแกรมทั้งหมด )

สำหรับปัญหาบางประเภทการออกแบบซอฟต์แวร์ด้วยวิธีการเขียนโปรแกรมแบบเมตาเอาต์กราฟิคนั้นคุ้มค่าและให้ความเร็วที่สำคัญ คุณสามารถจินตนาการว่าได้รับการป้อนข้อมูลบางอย่างโปรแกรมของคุณสร้างรหัสพิเศษแบบไดนามิกเพื่อประมวลผล สิ่งนี้อาจเป็นไปได้ด้วย C หรือ C ++ (อาจใช้ไลบรารี JIT บางตัวหรือสร้างรหัส C บางส่วนรวบรวมเป็นปลั๊กอินที่ได้รับการโหลดแบบไดนามิก)

ดูเพิ่มเติมที่เกี่ยวข้องนี้คำถามเกี่ยวกับงูหลามและว่า

สำหรับรหัสอย่างA = A + Bที่สามารถรวบรวมคำสั่งเครื่องหนึ่งหรือสองคำสั่งแต่ละรอบใช้จำนวนรอบที่แน่นอน ไม่มีล่ามสามารถทำสิ่งเดียวกันในจำนวนรอบนั้นด้วยเหตุผลง่ายๆ

ล่ามยังดำเนินการชุดคำสั่งของมันเอง (เรียกพวกเขาว่ารหัสไบต์, รหัส p, ภาษากลาง, อะไรก็ตาม) ทุกครั้งที่เห็นรหัสไบต์เช่นเพิ่มมันจะต้องค้นหามันอย่างใดและสาขาไปยังรหัสที่จะเพิ่ม

ต่อไปเวลาที่มันเห็นมันก็มีการทำซ้ำการค้นหานั้นเว้นแต่ว่ามันมีวิธีที่จะจำค้นหาก่อน หากไม่มีวิธีในการจดจำการค้นหาก่อนหน้านี้จะไม่มีสิ่งที่เราเรียกว่า "ล่าม" แต่เป็นคอมไพเลอร์ทันเวลาหรือ JITter

ในทางกลับกัน...

สำหรับรหัสเช่นcallSomeFunction( ... some args ...)มีการใช้จ่ายกี่รอบระหว่างการป้อนรหัสนั้นและปล่อยไว้ callSomeFunctionทั้งหมดขึ้นอยู่กับสิ่งที่เกิดขึ้นภายใน อาจเป็นเพียงไม่กี่และอาจเป็นล้านล้านแม้ว่าcallSomeFunctionจะรวบรวม หากเป็นจำนวนมากก็ไม่มีประโยชน์ที่จะพิจารณาการตีความค่าใช้จ่ายของรหัสบรรทัดนั้น - เงินอยู่ที่อื่น

โปรดจำไว้ว่าภาษาที่ตีความมีค่าของตัวเองเช่นไม่จำเป็นต้องรวบรวมพวกเขา (ตัวอย่างเช่น "การคอมไพล์" ของพื้นผิวไวยากรณ์เป็นรหัสไบต์ใช้เวลาเล็กน้อยใช้ R หรือ MATLAB เป็นต้น)

นอกจากนี้ยังมีความยืดหยุ่นที่จำเป็นสำหรับการเขียนโปรแกรมระดับอัจฉริยะ ในสังคมแห่งจิตใจของมินสกีบทที่ 6.4 ข -Brains มีโปรแกรม A ที่จัดการกับโลกและมีโปรแกรม B ที่จัดการกับโปรแกรม A และอาจมีระดับต่อไป โปรแกรมที่เขียนและจัดการโปรแกรมอื่นสามารถทำได้ง่ายขึ้นในระบบสื่อความหมาย

ในเสียงกระเพื่อมคุณสามารถเขียน(+ A B)เพื่อเพิ่ม A และ B แต่เมื่อมีการเขียนคุณมีทางเลือกที่จะเรียกใช้หรือไม่ นอกจากนี้คุณยังสามารถเขียน(eval (list '+ 'A 'B))สิ่งที่สร้างโปรแกรมแล้วดำเนินการ มันสามารถสร้างสิ่งที่แตกต่าง

เรื่องของโปรแกรมคือโปรแกรมอื่น สิ่งนี้ง่ายต่อการเขียนในภาษาที่ตีความ (แม้ว่าJörgชี้ให้เห็น Lisp รุ่นใหม่กว่าในขณะที่พวกเขามีการevalคอมไพล์ในการบินดังนั้นพวกเขาจึงไม่มีการลงโทษความเร็วในการตีความ)

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

ส่วนหนึ่งของเหตุผลคือภาษาที่ตีความต้องมีล่ามวน - ห่วงซึ่งอ่านคำสั่งเลือกการกระทำที่เหมาะสมที่จะใช้และดำเนินการ ในกรณีที่ดีที่สุดเช่นการตีความ Python หรือ Java bytecode (เหมือนJVM เก่า ) มันมีค่าใช้จ่ายเพียงไม่กี่คำสั่งและเล่นความเสียหายกับตัวทำนายสาขา - หากไม่มีตัวเลือกสุดท้ายคุณสามารถคาดหวังได้ว่าจะได้รับบทลงโทษอย่างมาก แม้แต่ JIT ที่โง่มากก็ควรเร่งความเร็วนี้อย่างมาก

ที่กล่าวว่าภาษาที่ตีความอาจโกง ตัวอย่างเช่น Matlab มีการปรับรูทีนที่เหมาะสมสำหรับการคูณเมทริกซ์และมีการเปลี่ยนแปลงเล็กน้อยคุณสามารถเรียกใช้โค้ดบน GPU (ข้อจำกัดความรับผิดชอบ: ฉันทำงานกับ nVidia - ความคิดเห็นใด ๆ ที่แสดงที่นี่เป็นของฉันและไม่ได้เป็นตัวแทนของนายจ้าง) ด้วยวิธีนี้คุณสามารถเขียนโค้ดระดับสูงขึ้นในระยะสั้นและมีประสิทธิภาพโดยไม่ต้องกังวลกับรายละเอียด - มีคนดูแลและใช้เวลาและทรัพยากรในการปรับให้เหมาะสมในภาษาระดับต่ำ ไม่มีสิ่งใดสืบทอดมาและมันไม่ได้ป้องกันตัวอย่างเช่น Matlab เพื่อ JIT โค้ด แต่บ่อยครั้งที่ไม่มีเหตุผลเนื่องจากค่าใช้จ่ายในการเรียกรูทีนระดับสูงนั้นน้อยมากเมื่อเทียบกับเวลาที่ใช้ในระดับต่ำ

TL; DR - โปรแกรมที่คอมไพล์มีประโยชน์ด้านประสิทธิภาพเหนือกว่าโปรแกรมที่ตีความ (สำหรับการเปรียบเทียบแอปเปิ้ลกับแอปเปิ้ลดูPyPy Speed ) อย่างไรก็ตามความเร็วของการปฏิบัติการนั้นเป็นเพียงส่วนหนึ่งของปัญหาและอาจไม่ได้มีส่วนช่วยในเรื่องความเร็วโดยรวม (หากใช้เวลาในไลบรารีเป็นส่วนใหญ่) นอกจากนี้การใช้งานมีความสำคัญ

สมมติฐานของคุณได้รับการพิสูจน์อย่างดีแม้ว่าจะเป็นข้อสมมติฐาน

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

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

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

แต่ในบางครั้งคุณอาจโดนไล่ออก มันเกิดขึ้นกับฉัน คุณตั้งสมมติฐานที่ดีและจากนั้นคุณพบว่าคุณไม่ได้คำนึงถึงความโง่เขลาของโลก

แต่ฉันไม่สามารถอธิบายได้เช่นเดียวกับการ์ตูน Dilbert ที่ฉันโปรดปรานตลอดกาล ไม่มีอะไรแสดงให้เห็นถึงอันตรายของการเป็นคนฉลาด

TL; DR: คุณควรพูดถูก แต่ตรวจสอบโลกแห่งความจริงในกรณีนี้

หากคุณไม่ได้ใช้สิ่งที่แปลกใหม่ปัญหาของคุณจะไม่เกี่ยวกับประสิทธิภาพของภาษาที่ถูกตีความ A และภาษาที่รวบรวม

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

นี่คือลิงค์เกี่ยวกับ regex ในภาษาต่างๆ คุณจะเห็นว่า regex มีการใช้งานที่ดีขึ้นในบางภาษาแม้ว่าจะรวบรวมหรือไม่: http://benchmarksgame.alioth.debian.org/u64q/performance.php?test=regexdna

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

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

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

เมื่อฉันต้องทำคำสั่งกวาดคล้ายกันเพื่อแสดงให้เห็นถึงการตัดสินใจที่ยิ่งใหญ่

ก่อนอื่นพวกเขาอาจไม่ต้องการเชื่อวิศวกรที่ถ่อมตนดังนั้นฉันจึงพบการทดสอบเปรียบเทียบและเปรียบเทียบพวกเขา มีคนจำนวนมากเกี่ยวกับจากคนเช่น Microsoft หรือมหาวิทยาลัยที่มีชื่อเสียง และพวกเขาจะพูดว่า: วิธี A อยู่ระหว่าง 3 ถึง 10 เท่าเร็วกว่าวิธี B ขึ้นอยู่กับตัวแปร X และ Y

ประการที่สองคุณอาจต้องการเรียกใช้เกณฑ์มาตรฐานของคุณเองหรืออาจใช้รหัสตัวแทนที่เป็นปัญหาหรือสิ่งที่คล้ายกันกับที่คุณมีอยู่แล้ว เรียกใช้ 1,000 ครั้งข้ามคืนเพื่อให้มีความแตกต่างที่วัดได้จริงๆ

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

ฉันจะยืนยันว่าภาษาแบบไดนามิกใด ๆ ที่มีข้อได้เปรียบกว่าคนที่รวบรวมแบบคงที่: "การเพิ่มประสิทธิภาพรันไทม์"

นั่นเป็นหนึ่งในเหตุผลที่ Java สามารถเร็วกว่า C ++

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

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

... ฉันยังระบุด้วยว่าเนื่องจากโปรแกรมสามารถเขียนได้หลายวิธีจึงเป็นไปได้ที่โปรแกรมที่เขียนด้วยเทคโนโลยี A อาจมีประสิทธิภาพสูงกว่าที่เขียนใน tech B.

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

นี่จะเป็นแนวทางของฉัน:

โดยทั่วไปแล้วล่ามจะถูกรวบรวมดังนั้นเทคโนโลยีที่ตีความทุกอย่างจะไม่มีอะไรอื่นนอกจากเทคโนโลยีที่รวบรวมหากมองในระดับต่ำ ดังนั้นเทคโนโลยีที่คอมไพล์มีมากขึ้นและมีความเป็นไปได้มากกว่าที่คุณจะไม่เคยแย่ลงถ้าคุณฉลาด (ซึ่งโดยทั่วไปคุณเป็น) ขึ้นอยู่กับว่ามีข้อมูลมากน้อยเพียงใดในเวลารวบรวมและข้อมูลที่มีอยู่ในรันไทม์เท่าไรและคอมไพเลอร์และล่ามนั้นดีเพียงใด แต่ในทางทฤษฎีแล้วมันควรจะมีประสิทธิภาพเท่า ๆ เพียงเพราะล่ามถูกประดิษฐ์โดยคอมไพเลอร์ ที่เป็นไปได้ไม่ได้หมายความว่าเป็นกรณีสำหรับ techs A และ B ของคุณ

ในทางปฏิบัติเพียงแค่บอกผู้ตรวจสอบเกี่ยวกับการวัดประสิทธิภาพทั้งหมดที่มีการเปรียบเทียบและรวบรวมระบบที่แปล จากนั้นขอให้เขาแนะนำล่ามที่จะทำให้ขั้นตอนวิธีเฉพาะของแอสเซมบลีที่เข้ารหัสของคุณดีที่สุด

หนึ่งอาจจะเพิ่มว่าคำสั่งทั่วไปใด ๆ ไม่ได้ช่วยเลยเมื่อเปรียบเทียบ techs A และ B ที่เฉพาะเจาะจงสองตัวการเลือก A และ B นั้นมีความสำคัญมากขึ้นกว่าที่พวกเขาตีความหรือเรียบเรียง