ด้วยระบบคอมพิวเตอร์ที่เฉพาะเจาะจงเป็นไปได้หรือไม่ที่จะประเมินเวลาการทำงานที่แม่นยำของชิ้นส่วนรหัส

นี่คือรหัสชุดประกอบ

section .text
    global _start       ;must be declared for using gcc
_start:                     ;tell linker entry point
    mov edx, len    ;message length
    mov ecx, msg    ;message to write
    mov ebx, 1      ;file descriptor (stdout)
    mov eax, 4      ;system call number (sys_write)
    int 0x80        ;call kernel
    mov eax, 1      ;system call number (sys_exit)
    int 0x80        ;call kernel

section .data

msg db  'Hello, world!',0xa ;our dear string
len equ $ - msg         ;length of our dear string

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

ฉันสามารถอ้างอิงได้จากคู่มือของซีพียูที่ค่อนข้างดั้งเดิมซึ่งเป็นโปรเซสเซอร์ 68020 จากปี 1986: "การคำนวณรันไทม์ที่แน่นอนของลำดับของคำสั่งนั้นเป็นเรื่องยากแม้ว่าคุณจะมีความรู้ที่แม่นยำเกี่ยวกับการใช้โปรเซสเซอร์" ซึ่งเราไม่มี และเมื่อเทียบกับโปรเซสเซอร์ที่ทันสมัย CPU ที่เป็นแบบดั้งเดิม

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

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

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

ทั้งหมดในทั้งหมด: คาดเดาไม่ได้ทั้งหมด

คุณไม่สามารถทำสิ่งนี้โดยทั่วไปได้ แต่ในบางแง่มุมคุณสามารถทำได้มากและมีบางกรณีที่คุณต้องทำ

อาตาริ 2600 (หรืออาตาวิดีโอระบบคอมพิวเตอร์) เป็นหนึ่งในเร็วระบบโฮมวิดีโอเกมและได้รับการเปิดตัวครั้งแรกในปี 1978 ซึ่งแตกต่างจากระบบต่อมาในยุคของอาตาไม่สามารถที่จะให้อุปกรณ์เฟรมบัฟเฟอร์หมายความว่าซีพียูมี เพื่อเรียกใช้โค้ดที่ scanline ทุกครั้งเพื่อพิจารณาว่าจะผลิตอะไร - หากรหัสนี้ใช้เวลามากกว่า 17.08 microseconds เพื่อเรียกใช้ (ช่วง HBlank) กราฟิกจะไม่ถูกตั้งค่าอย่างเหมาะสมก่อนที่ scanline จะเริ่มวาดพวกเขา ถ้าโปรแกรมเมอร์ต้องการวาดเนื้อหาที่ซับซ้อนกว่าที่อาตาริอนุญาตตามปกติพวกเขาจะต้องวัดเวลาที่แน่นอนสำหรับคำแนะนำและเปลี่ยนการลงทะเบียนกราฟิกเมื่อลำแสงถูกวาดด้วยช่วง 57.29 ไมโครวินาทีสำหรับการสแกนทั้งหมด

อย่างไรก็ตาม Atari 2600 ก็เหมือนกับระบบอื่น ๆ อีกมากมายที่ใช้ 6502 นั้นมีคุณสมบัติที่สำคัญมากที่ช่วยให้สามารถจัดการเวลาได้อย่างระมัดระวังสำหรับสถานการณ์นี้: CPU, RAM, และสัญญาณทีวีทั้งหมดวิ่งออกจากนาฬิกาตามต้นแบบเดียวกัน นาฬิกา. สัญญาณทีวีวิ่งออกนาฬิกา 3.98 MHz แบ่งเวลาเป็นจำนวนเต็มของ "นาฬิกาสี" ที่จัดการสัญญาณทีวีและวงจรของนาฬิกา CPU และ RAM เป็นนาฬิกาสามสีทำให้นาฬิกาของ CPU เป็น การวัดเวลาที่แม่นยำเมื่อเทียบกับสัญญาณทีวีความคืบหน้าปัจจุบัน (สำหรับข้อมูลเพิ่มเติมเกี่ยวกับเรื่องนี้ให้ดูที่คู่มือของ Stella Programmer ที่เขียนขึ้นสำหรับตัวจำลอง Stella Atari 2600 )

สภาพแวดล้อมการทำงานนี้นอกจากนี้หมายความว่าคำสั่ง CPU ทุกตัวมีจำนวนรอบที่กำหนดซึ่งจะใช้ในทุกกรณีและผู้พัฒนา 6502 รายจำนวนมากเผยแพร่ข้อมูลนี้ในตารางอ้างอิง ตัวอย่างเช่นพิจารณารายการนี้สำหรับคำสั่งCMP(เปรียบเทียบหน่วยความจำกับแอคคูมูเลเตอร์) ที่นำมาจากตารางนี้ :

CMP  Compare Memory with Accumulator

     A - M                            N Z C I D V
                                    + + + - - -

     addressing    assembler    opc  bytes  cycles
     --------------------------------------------
     immediate     CMP #oper     C9    2     2
     zeropage      CMP oper      C5    2     3
     zeropage,X    CMP oper,X    D5    2     4
     absolute      CMP oper      CD    3     4
     absolute,X    CMP oper,X    DD    3     4*
     absolute,Y    CMP oper,Y    D9    3     4*
     (indirect,X)  CMP (oper,X)  C1    2     6
     (indirect),Y  CMP (oper),Y  D1    2     5*

*  add 1 to cycles if page boundary is crossed

ด้วยการใช้ข้อมูลทั้งหมดนี้อาตาริ 2600 (และนักพัฒนา 6502 คนอื่น ๆ ) สามารถระบุได้ว่ารหัสของพวกเขาใช้เวลานานแค่ไหนในการดำเนินการและสร้างกิจวัตรที่ทำในสิ่งที่พวกเขาต้องการและยังคงปฏิบัติตามข้อกำหนดจังหวะเวลาสัญญาณโทรทัศน์ของอาตาริ และเนื่องจากช่วงเวลานี้แน่นอนมาก (โดยเฉพาะอย่างยิ่งสำหรับคำแนะนำการเสียเวลาเช่น NOP) พวกเขายังสามารถใช้เพื่อปรับเปลี่ยนกราฟิกในขณะที่พวกเขากำลังวาด

แน่นอนว่าอาตาริ 6502 นั้นเป็นกรณีที่เฉพาะเจาะจงมากและทั้งหมดนี้เป็นไปได้เพียงเพราะระบบมีดังต่อไปนี้ทั้งหมด:

• นาฬิกาหลักที่ทำงานทุกอย่างรวมถึง RAM ระบบที่ทันสมัยมีนาฬิกาอิสระสำหรับ CPU และ RAM โดยที่นาฬิกา RAM มักจะช้ากว่าและทั้งสองไม่จำเป็นต้องซิงค์กัน
• ไม่มีแคชใด ๆ - 6502 เข้าถึง DRAM โดยตรงเสมอ ระบบที่ทันสมัยมี SRAM แคชที่ทำให้ยากต่อการทำนายสถานะ - ในขณะที่มันอาจเป็นไปได้ที่จะทำนายพฤติกรรมของระบบที่มีแคชมันยากกว่าแน่นอน
• ไม่มีโปรแกรมอื่นทำงานพร้อมกัน - โปรแกรมบนตลับหมึกมีการควบคุมระบบอย่างสมบูรณ์ ระบบที่ทันสมัยใช้หลายโปรแกรมพร้อมกันโดยใช้อัลกอริทึมการจัดตารางเวลาที่ไม่ได้กำหนดไว้ล่วงหน้า
• ความเร็วสัญญาณนาฬิกาช้าพอที่สัญญาณจะสามารถเดินทางข้ามระบบได้ทันเวลา ในระบบที่ทันสมัยด้วยความเร็วสัญญาณนาฬิกา 4 GHz (ตัวอย่าง) ใช้แสงโฟตอน6.67 รอบนาฬิกาในการเดินทางความยาวของมาเธอร์บอร์ดครึ่งเมตร - คุณไม่เคยคาดหวังว่าหน่วยประมวลผลที่ทันสมัยจะโต้ตอบกับสิ่งอื่นบนกระดาน ในรอบเดียวเนื่องจากใช้สัญญาณมากกว่าหนึ่งรอบเพื่อให้สัญญาณบนบอร์ดเข้าถึงอุปกรณ์ได้
• ความเร็วสัญญาณนาฬิกาที่กำหนดไว้อย่างดีซึ่งไม่ค่อยเปลี่ยนแปลง (1.19 MHz ในกรณีของ Atari) - ความเร็วของ CPU ของระบบที่ทันสมัยเปลี่ยนแปลงตลอดเวลาในขณะที่ Atari ไม่สามารถทำได้โดยไม่ส่งผลกระทบต่อสัญญาณทีวี
• รอบเวลาที่เผยแพร่ - x86 ไม่ได้กำหนดว่าจะต้องใช้เวลานานเท่าใด

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

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

แก้ไข 1:ในรุ่นก่อนหน้าของคำตอบนี้ฉันระบุว่า Atari 2600 ไม่มีทางแจ้งหน่วยประมวลผลว่ามันอยู่ที่ไหนในสัญญาณทีวีซึ่งบังคับให้โปรแกรมทั้งหมดนับและซิงโครไนซ์ตั้งแต่เริ่มต้น ความเห็นของฉันในความเห็นนี้เป็นจริงของระบบบางอย่างเช่น ZX Spectrum แต่ไม่เป็นความจริงของ Atari 2600 เนื่องจากมีการลงทะเบียนฮาร์ดแวร์ที่หยุด CPU จนกว่าจะเกิดช่วง blanking แนวนอนถัดไปเช่นเดียวกับ ฟังก์ชั่นเพื่อเริ่มช่วง blanking แนวตั้งที่จะ ดังนั้นปัญหาของการนับรอบจะถูก จำกัด ไว้ที่แต่ละ scanline และจะกลายเป็นที่แน่นอนถ้านักพัฒนาต้องการเปลี่ยนเนื้อหาเมื่อมีการวาดเส้นการสแกน

มีสองด้านที่เล่นอยู่ที่นี่

ตามที่ @ gnasher729 ชี้ให้เห็นว่าถ้าเรารู้คำแนะนำที่ถูกต้องในการดำเนินการมันยังคงเป็นการยากที่จะประมาณค่ารันไทม์ที่แน่นอนเพราะสิ่งต่าง ๆ เช่นแคชการทำนายสาขาการปรับขนาด ฯลฯ

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

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

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

การขัดจังหวะจะรบกวน timimg ชนิดนี้อย่างชัดเจน แต่เป็นไปได้ที่จะทำสิ่งต่าง ๆ โดยไม่ต้องใช้ตัวจัดการขัดจังหวะในการกำหนดค่า "โลหะเปลือย"

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

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

มันจะไม่ทำงานบนคอมพิวเตอร์ที่ทันสมัยหรือรหัสเช่นตัวอย่างของคุณ

ทำไมไม่ ต่อไปนี้คือบางสิ่งที่จะทำให้เวลาง่ายขึ้นและคาดเดาได้:

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

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

หากระบบปฏิบัติการของคุณใช้มัลติทาสกิ้งแบบ preemptive เธรดที่เรียกใช้รหัสนี้อาจสูญเสียเวลาในช่วงเวลาใดก็ได้

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

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

สิ่งนี้ค่อนข้างสัมผัสได้ แต่กระสวยอวกาศมีคอมพิวเตอร์ซ้ำซ้อน 4 เครื่องซึ่งขึ้นอยู่กับการซิงค์อย่างแม่นยำนั่นคือการจับคู่แบบรันไทม์

ความพยายามในการเปิดตัวครั้งแรกของกระสวยอวกาศถูกขัดถูเมื่อคอมพิวเตอร์ Backup Flight Software (BFS) ปฏิเสธที่จะประสานกับคอมพิวเตอร์ Avionics Software System (PASS) สี่เครื่อง รายละเอียดใน "แมลงได้ยินรอบโลก" ที่นี่ อ่านสิ่งที่น่าสนใจเกี่ยวกับการพัฒนาซอฟต์แวร์เพื่อให้เข้ากับวงจรของวัฏจักรและอาจทำให้คุณมีพื้นฐานที่น่าสนใจ

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

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

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