एक विशिष्ट कंप्यूटर प्रणाली को देखते हुए, क्या विधानसभा कोड के एक टुकड़े के वास्तविक सटीक रन समय का अनुमान लगाना संभव है


23

यह असेंबली कोड का एक टुकड़ा है

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

एक विशिष्ट कंप्यूटर प्रणाली को देखते हुए, असेंबली कोड के एक टुकड़े के वास्तविक रन समय की सटीक भविष्यवाणी करना संभव है।


30
क्या "उस कंप्यूटर पर कोड चलाना और स्टॉपवॉच का उपयोग करना" एक वैध उत्तर है?
ड्रेकोनिस

4
मुझे संदेह है कि कोड के इस टुकड़े को निष्पादित करने में लगने वाला अधिकांश समय I / O की प्रतीक्षा कर रहा है। अलग-अलग निर्देशों को निष्पादित करने में लगने वाला समय कुछ अनुमानित है यदि आप कोड की मेमोरी लोकेशन और प्रोसेसर के बारे में सभी विवरण जानते हैं (जो आजकल बहुत जटिल हैं), लेकिन गति भी मेमोरी और डिस्क से प्रभावित होती है इसलिए आप ' d को उनके बारे में बहुत अधिक मात्रा में विवरण जानना होगा। इसलिए जब तक आप भौतिक घटनाओं पर विचार नहीं करते (जो कि समय को भी प्रभावित करते हैं), आप कह सकते हैं कि यह पूर्वानुमान है, लेकिन ऐसा करने के लिए अकल्पनीय रूप से कठिन है।
IllidanS4

4
यह अनुमान लगाना हमेशा संभव है ...
sudo rm -rf slash

3
क्या हॉल्टिंग की समस्या के कारण भी यह असंभव नहीं है? हम कुछ कोड के लिए साबित कर सकते हैं कि क्या यह रुक जाएगा, लेकिन हमारे पास एक एल्गोरिथ्म नहीं हो सकता है जो इसे सभी संभावित कोड के लिए निर्धारित करता है।
kutschkem

2
@ फाल्को दी गई प्रणाली की एक संपत्ति होगी। कुछ फ्रीस्टैंडिंग सी कार्यान्वयन में कोई ऑपरेटिंग सिस्टम नहीं है; जो सब चल रहा है वह एक मुख्य लूप है (या लूप भी नहीं; ;-)) जो इनपुट के लिए हार्डवेयर पतों से पढ़ा जा सकता है या नहीं भी।
पीटर -

जवाबों:


47

मैं केवल एक आदिम सीपीयू के मैनुअल से उद्धृत कर सकता हूं, 1986 के आसपास से 68020 प्रोसेसर: "निर्देशों के अनुक्रम के सटीक रनटाइम की गणना करना मुश्किल है, भले ही आपको प्रोसेसर कार्यान्वयन का सटीक ज्ञान हो"। जो हमारे पास नहीं है। और एक आधुनिक प्रोसेसर की तुलना में, वह सीपीयू आदिम था ।

मैं उस कोड के रनटाइम की भविष्यवाणी नहीं कर सकता, और न ही आप कर सकते हैं। लेकिन आप यह भी परिभाषित नहीं कर सकते हैं कि कोड के एक टुकड़े का "रनटाइम" क्या है, जब एक प्रोसेसर में बड़े पैमाने पर कैश होता है, और बड़े पैमाने पर आउट-ऑफ-ऑर्डर क्षमताएं होती हैं। एक विशिष्ट आधुनिक प्रोसेसर में "उड़ान में" 200 निर्देश हो सकते हैं, जो निष्पादन के विभिन्न चरणों में है। तो पहले अनुदेश बाइट को पढ़ने की कोशिश करने से लेकर अंतिम निर्देश को रिटायर करने तक का समय काफी लंबा हो सकता है। लेकिन अन्य सभी कामों के लिए वास्तविक देरी जो कि प्रोसेसर को करने की आवश्यकता होती है (और आमतौर पर है) बहुत कम हो सकता है।

बेशक ऑपरेटिंग सिस्टम पर दो कॉल करना पूरी तरह अप्रत्याशित है। आप नहीं जानते कि "लेखन को गतिरोध के लिए लिखना" वास्तव में क्या करता है, इसलिए आप समय का अनुमान नहीं लगा सकते।

और आप उस कंप्यूटर की घड़ी की गति को नहीं जान सकते हैं जिस समय आप कोड चलाते हैं। यह कुछ पावर सेविंग मोड में हो सकता है, हो सकता है कि कंप्यूटर ने घड़ी की गति को कम कर दिया हो क्योंकि यह गर्म हो गया है, इसलिए समान संख्या में घड़ी चक्र अलग-अलग समय ले सकते हैं।

सभी सभी में: पूरी तरह से अप्रत्याशित।


12
मुझे लगता है कि आपके निष्कर्ष बहुत मजबूत हैं। एक कार्यक्रम के "रनटाइम" को मापने के लिए विलंबता और थ्रूपुट सामान्य मीट्रिक हैं। इसके अलावा, आप बस "रनटाइम" की एक उपयुक्त परिभाषा पर व्यवस्थित हो सकते हैं। इसके अलावा, यदि आपके पास सिस्टम स्थिति, hw और sw का पूरा स्नैपशॉट है, और CPU इंटर्नल्स का एक सही ज्ञान है, तो आप रनटाइम का अनुमान लगा सकते हैं। इंटेल में वे शायद रनटाइम का अनुमान लगा सकते हैं, यहां तक ​​कि एसओ पर भी हम चक्र सटीकता के साथ विलंबता और विवादों का अनुमान लगा सकते हैं। इस मामले में, syscalls के अलावा, यह भी इतना मुश्किल नहीं है।
मार्गरेट ब्लूम

10
@MargaretBloom तब भी नहीं। मैं अपने फोन को ओवन के करीब रखता हूं, तापमान को प्रबंधित करने के लिए सीपीयू अंडरक्लॉक करता है, आपके रनटाइम का अनुमान अचानक बहुत कम है। और यहां तक ​​कि अगर आप चक्रों में गिनती करते हैं और syscalls नहीं करते हैं, तो अन्य थ्रेड्स और सीपीयू रैम की सामग्री के साथ अच्छी तरह से खेल सकते हैं, या वे आपकी मेमोरी को हार्ड ड्राइव में डंप कर सकते हैं, जबकि अप्रत्याशित परिस्थितियों के आधार पर, आपको स्वैप किया जाता है, शक्ति से लेकर। सर्ज हार्ड ड्राइव को इतना धीमा कर देता है कि एक प्रतिस्पर्धा वाले धागे को आपका समय बर्बाद करने के लिए पर्याप्त मेमोरी मिल जाती है, सभी तरह से थ्रेड को लुढ़कने के लिए सीधे देखते हैं कि कितना समय बर्बाद करना है।
जॉन ड्वोरक

6
इसके अलावा, "सिस्टम स्टेट, hw और sw का पूर्ण ज्ञान" एक बहुत लंबा ऑर्डर है, मेथिंक। पहले से "10 एमएस जोड़ें", और आप पहले से ही असंभव के लिए पूछ रहे हैं। और यदि आपके CPU के हार्डवेयर रैंडम नंबर जेनरेशन का कार्यान्वयन क्वांटम घटना (यह संभवतः करता है) का उपयोग करता है, और सीपीयू पर कुछ थ्रेड इसे कहते हैं, तो कंप्यूटर के चारों ओर ब्रह्मांड की पूर्ण स्थिति को जानने का भी नहीं, आपको बचाएगा। और MWI में, आप सही अनुमान भी नहीं लगा सकते हैं।
जॉन ड्वोरक

8
@ नोट: क्रिप्टोग्राफी में भी, "निरंतर-समय" वास्तव में बिल्कुल स्थिर का मतलब नहीं है - इसका मतलब यह है कि चल रहे समय में कोई व्यवस्थित बदलाव नहीं है जो गुप्त डेटा पर निर्भर करते हैं और इसके साथ सांख्यिकीय रूप से सहसंबद्ध हो सकते हैं। और व्यवहार में, यह अक्सर माना जाता है कि यदि कोड पथ लिया गया है और निष्पादित मेमोरी एक्सेस का पैटर्न गुप्त डेटा पर निर्भर नहीं है, और यदि विशिष्ट मात्रा में समय लेने के लिए जाने जाने वाले विशिष्ट निर्देशों से बचा जाता है (या उनके इनपुट के लिए मास्क किया गया है) उम्मीद है कि सहसंबंध को खत्म करना), यह शायद काफी अच्छा है। इसके अलावा, आपको वास्तव में इसे मापना होगा।
इल्मारी करोनेंन

2
एक 68020 एक जटिल जानवर है ... एक MCS51 का प्रयास करें ....
रैकेंडबॉमनमैन

30

आप इसे सामान्य रूप से नहीं कर सकते हैं, लेकिन कुछ इंद्रियों में, आप बहुत कुछ कर सकते हैं, और कुछ ऐतिहासिक मामले हैं जिनमें आपको वास्तव में होना था

अटारी 2600 (या अटारी वीडियो कंप्यूटर सिस्टम) जल्द से जल्द घर वीडियो गेम प्रणालियों में से एक था और प्रथम युग के बाद के प्रणालियों के विपरीत 1978 में जारी किया गया था, अटारी डिवाइस एक फ्रेम बफर देने के लिए खर्च नहीं उठा सकते, जिसका अर्थ है कि था सीपीयू प्रत्येक स्कैनलाइन पर कोड को चलाने के लिए यह निर्धारित करने के लिए कि क्या उत्पादन किया जाए - यदि इस कोड को चलाने के लिए (HBlank अंतराल) 17.08 microseconds लिया गया है, तो स्कैनलाइन शुरू करने से पहले ग्राफिक्स ठीक से सेट नहीं होंगे। इससे भी बदतर, अगर प्रोग्रामर अटारी को सामान्य रूप से अनुमति देने की तुलना में अधिक जटिल सामग्री खींचना चाहता था, तो उन्हें निर्देश के लिए सटीक समय को मापना था और ग्राफिक्स रजिस्टरों को बदलना होगा क्योंकि बीम को खींचा जा रहा था, जिसमें पूरी अवधि के लिए 57.29 माइक्रोसेकंड की अवधि थी।

हालांकि, अटारी 2600, 6502 पर आधारित कई अन्य प्रणालियों की तरह, एक बहुत ही महत्वपूर्ण विशेषता थी जो इस परिदृश्य के लिए आवश्यक सावधानीपूर्वक समय प्रबंधन को सक्षम करती थी: सीपीयू, रैम और टीवी सिग्नल सभी एक ही मास्टर के आधार पर घड़ियों को बंद कर देते थे। घड़ी। टीवी सिग्नल 3.98 मेगाहर्ट्ज की घड़ी से ऊपर चला गया, ऊपर के समय को "रंगीन घड़ियों" के एक पूर्णांक संख्या में विभाजित किया गया, जो टीवी सिग्नल को प्रबंधित करता था, और सीपीयू और रैम घड़ियों का एक चक्र बिल्कुल तीन रंग घड़ियों था, जो सीपीयू की घड़ी होने की अनुमति देता था। वर्तमान प्रगति टीवी सिग्नल के सापेक्ष समय का एक सटीक माप। (इस पर अधिक जानकारी के लिए, स्टेला अटारी 2600 एमुलेटर के लिए लिखे गए स्टेला प्रोग्रामर गाइड देखें )।

इसके अलावा, इस ऑपरेटिंग वातावरण का मतलब था कि प्रत्येक सीपीयू निर्देश में चक्रों की एक निर्धारित मात्रा होती थी, जो हर मामले में होती थी, और कई 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 डेवलपर्स) यह निर्धारित करने में सक्षम थे कि उनके कोड को निष्पादित करने में कितना समय लग रहा था, और रूटीन का निर्माण करने के लिए जो उन्हें चाहिए था और अभी भी अटारी के टीवी सिग्नल समय की आवश्यकताओं के अनुरूप है। और क्योंकि यह समय बहुत सटीक था (विशेषकर एनओपी जैसे समय बर्बाद करने वाले निर्देशों के लिए), वे ग्राफिक्स को संशोधित करने के लिए इसका उपयोग करने में सक्षम थे क्योंकि वे खींचे जा रहे थे।


बेशक, अटारी का 6502 एक बहुत ही विशिष्ट मामला है, और यह सब केवल इसलिए संभव है क्योंकि सिस्टम में निम्नलिखित सभी थे:

  • एक मास्टर घड़ी जिसमें रैम सहित सब कुछ चलता था। आधुनिक प्रणालियों में सीपीयू और रैम के लिए स्वतंत्र घड़ियां होती हैं, जिसमें रैम घड़ी अक्सर धीमी होती है और दो जरूरी नहीं कि सिंक में हों।
  • किसी भी प्रकार का कोई कैशिंग नहीं - 6502 ने हमेशा DRAM को सीधे एक्सेस किया। आधुनिक प्रणालियों में SRAM कैश होता है जो राज्य की भविष्यवाणी करना अधिक कठिन बनाता है - जबकि कैश के साथ सिस्टम के व्यवहार की भविष्यवाणी करना अभी भी संभव है, यह निश्चित रूप से अधिक कठिन है।
  • एक साथ चलने वाले कोई अन्य कार्यक्रम - कारतूस पर कार्यक्रम का सिस्टम पर पूर्ण नियंत्रण नहीं था। आधुनिक सिस्टम एक बार गैर-नियतात्मक समय-निर्धारण एल्गोरिदम का उपयोग करके कई कार्यक्रम चलाते हैं।
  • एक घड़ी की गति इतनी धीमी है कि सिग्नल समय पर सिस्टम में यात्रा कर सकते हैं। 4 गीगाहर्ट्ज की घड़ी की गति (उदाहरण के लिए) के साथ एक आधुनिक प्रणाली में, आधे मीटर की मदरबोर्ड की लंबाई की यात्रा करने के लिए यह 6.67 प्रकाश चक्र का एक फोटॉन लेता है - आप बोर्ड पर किसी और चीज के साथ बातचीत करने के लिए एक आधुनिक प्रोसेसर की उम्मीद नहीं कर सकते। केवल एक चक्र में, चूंकि यह उपकरण तक पहुंचने के लिए बोर्ड पर एक संकेत के लिए एक से अधिक चक्र लेता है।
  • एक अच्छी तरह से परिभाषित घड़ी की गति जो शायद ही कभी बदलती है (अटारी के मामले में 1.19 मेगाहर्ट्ज) - आधुनिक प्रणालियों के सीपीयू की गति हर समय बदलती है, जबकि एक अटारी टीवी सिग्नल को प्रभावित किए बिना ऐसा नहीं कर सकता था।
  • प्रकाशित चक्र समय - x86 यह निर्धारित नहीं करता है कि इसके किसी भी निर्देश को कितना समय लगता है।

ये सभी चीजें एक ऐसी प्रणाली बनाने के लिए एक साथ आईं, जहां निर्देशों का सेट तैयार करना संभव था, जिसमें सटीक समय लगता था - और इस एप्लिकेशन के लिए, ठीक यही मांग की गई थी। अधिकांश प्रणालियों में केवल इस डिग्री की सटीकता नहीं होती है क्योंकि इसके लिए कोई आवश्यकता नहीं होती है - गणना या तो तब की जाती है जब वे काम करते हैं, या यदि समय की एक सटीक राशि की आवश्यकता होती है, तो एक स्वतंत्र घड़ी की देखभाल की जा सकती है। लेकिन अगर ज़रूरत सही है (जैसे कि कुछ एम्बेडेड सिस्टम पर), यह अभी भी दिखाई दे सकता है, और आप इन वातावरण में चलाने के लिए आपका कोड कितनी देर तक सही ढंग से निर्धारित कर पाएंगे।


और मुझे बड़े पैमाने पर डिस्क्लेमर भी जोड़ना चाहिए कि यह सब केवल विधानसभा निर्देशों के एक सेट के निर्माण पर लागू होता है जो सटीक मात्रा में समय लेगा। यदि आप क्या करना चाहते हैं, तो इन वातावरणों में भी, विधानसभा के कुछ मनमाने टुकड़े ले सकते हैं, और पूछ सकते हैं कि "इसे निष्पादित करने में कितना समय लगता है?", आप स्पष्ट रूप से ऐसा नहीं कर सकते हैं - यही हाल्टिंग समस्या है , जो अयोग्य साबित हुई है।


EDIT 1: इस उत्तर के पिछले संस्करण में, मैंने कहा कि अटारी 2600 में प्रोसेसर के बारे में सूचित करने का कोई तरीका नहीं था, जहां यह टीवी सिग्नल में था, जिसने इसे शुरू से ही पूरे कार्यक्रम को गिनने और सिंक्रनाइज़ रखने के लिए मजबूर किया। जैसा कि टिप्पणियों में मुझे बताया गया है, यह ZX स्पेक्ट्रम जैसी कुछ प्रणालियों का सच है, लेकिन अटारी 2600 का सच नहीं है, क्योंकि इसमें एक हार्डवेयर रजिस्टर होता है जो सीपीयू को तब तक रोकता है जब तक कि अगले क्षैतिज ब्लैंकिंग अंतराल नहीं होता है, साथ ही साथ एक समारोह में शुरू होने पर ऊर्ध्वाधर कंबल अंतराल शुरू करने के लिए। इसलिए, चक्र की गणना की समस्या प्रत्येक स्कैनलाइन तक सीमित है, और केवल तभी सटीक हो जाती है जब डेवलपर सामग्री को बदलना चाहता है क्योंकि स्कैनलाइन को खींचा जा रहा है।


4
यह भी ध्यान दिया जाना चाहिए कि अधिकांश गेम पूरी तरह से काम नहीं करते हैं - आप वीडियो सिग्नल के बेमेल समय के कारण वीडियो आउटपुट में कई कलाकृतियों को देख सकते हैं, या तो प्रोग्रामर त्रुटि (सीपीयू समय के गलत अनुमान) के कारण या बस बहुत अधिक होने के कारण करने का काम। यह भी बहुत नाजुक था - यदि आपको बग को ठीक करने या नई सुविधाओं को जोड़ने की आवश्यकता है, तो आप समय-समय पर कभी-कभी अनजाने में समय को तोड़ देंगे। यह मजेदार था, लेकिन एक बुरा सपना भी था :) मुझे यकीन भी नहीं है कि अगर घड़ी की गति हमेशा सही थी - जैसे ओवरहीट, हस्तक्षेप आदि के तहत, लेकिन यह निश्चित रूप से दिखाता है कि यह तब भी कठिन था।
लुआण

1
अच्छा जवाब, हालाँकि मैं चाहता हूँ कि आप को नाईट्रिक के बारे में बताना चाहिए कि अटारी 2600 पर प्रत्येक निर्देश के लिए चक्रों की संख्या नहीं है। यह दो विशेषताएं हैं जो आपको ऐसा नहीं करने में मदद करने के लिए हैं: एक उलटी गिनती टाइमर जो आप शुरू करते हैं और फिर यह देखने के लिए सर्वेक्षण करें कि क्या यह 0 तक पहुंच गया है, और एक रजिस्टर जो सीपीयू को अगले क्षैतिज ब्लैंकिंग शुरू होने तक रोक देता है। ZX स्पेक्ट्रम जैसी कई अन्य डिवाइसों में ऐसा कुछ भी नहीं होता है, और आपको वास्तव में स्क्रीन पर जहां आप हैं, यह जानने के लिए ऊर्ध्वाधर ब्लरिंग के बाद खर्च किए गए हर एक चक्र को गिनना होगा।
मार्टिन विलकंस

1
मेरा तर्क है कि हॉल्टिंग की समस्या अटारी पर कड़ाई से लागू नहीं होती है। यदि आप अटारी की I / O क्षमताओं को बाहर करते हैं और इसे एक विशिष्ट कारतूस ROM में सीमित करते हैं, तो भंडारण की एक परिमित मात्रा है। जिस बिंदु पर आपके पास एक परिमित राज्य मशीन है, इसलिए उस पर कोई भी कार्यक्रम या तो रुकना चाहिए, या एक राज्य में प्रवेश करना चाहिए जो पहले दर्ज किया गया है, जिससे परिमित समय में एक सिद्ध अनंत लूप हो सकता है।
user1937198 19

2
@ user1937198 राज्य के 128 बाइट्स (इसके अलावा जो कुछ भी रजिस्टरों में है) अधिक है और ट्यूरिंग मशीन के सैद्धांतिक अनंत टेप के बीच अंतर करने के लिए पर्याप्त राज्य स्थान है, जो केवल सिद्धांत में एक अंतर है। नरक, हम व्यावहारिक रूप से एईएस कुंजी की तरह 128 बिट्स की खोज नहीं कर सकते हैं .... जब आप बिट्स जोड़ते हैं तो राज्य स्थान तेजी से बढ़ता है। यह मत भूलो कि समतुल्य 'को बाधित करता है; पड़ाव 'लगभग निश्चित रूप से संभव होता।
दान मिल्स

1
"यह हाल्टिंग समस्या है, जो असाध्य साबित हुई है। यदि आप इसमें भाग लेते हैं, तो आपको स्टॉपवॉच को तोड़ने और वास्तव में अपना कोड चलाने की आवश्यकता है।" - इसका कोई अर्थ नहीं निकलता। आप "वास्तव में" कोड के बजाय इसे चलाने के द्वारा ट्यूरिंग के प्रमाण को खाली नहीं कर सकते। यदि यह रुकता है, तो आप समय रोक सकते हैं, यह रुकने में कितना समय लेता है। यदि यह रुकता नहीं है, तो आप कभी भी निश्चित नहीं हो सकते हैं (सामान्य तौर पर) कि क्या यह भविष्य में रुकने वाला है, या हमेशा के लिए चलता है। असली या नकली स्टॉपवॉच के साथ भी यही समस्या है। कम से कम एक सिमुलेशन में आप लूपिंग के संकेतों के लिए आंतरिक स्थिति का अधिक आसानी से निरीक्षण कर सकते हैं।
बे्रग सिप

15

यहां खेलने के दो पहलू हैं

जैसा कि @ gnasher729 बताते हैं, यदि हम निष्पादित करने के सटीक निर्देशों को जानते हैं, तो कैशिंग, शाखा भविष्यवाणी, स्केलिंग, आदि जैसी चीजों के कारण सटीक रनटाइम का अनुमान लगाना अभी भी मुश्किल है।

हालांकि, स्थिति और भी खराब है। असेंबली के एक भाग को देखते हुए, यह जानना असंभव है कि कौन से निर्देश चलेंगे, या यह जानने के लिए कि कितने निर्देश चलेंगे। ऐसा चावल के प्रमेय के कारण होता है: यदि हम इसका ठीक-ठीक निर्धारण कर सकते हैं, तो हम उस जानकारी को हल करने की समस्या को हल करने के लिए उपयोग कर सकते हैं, जो असंभव है।

असेंबली कोड में जंप और शाखाएं हो सकती हैं, जो संभवतः किसी प्रोग्राम के पूर्ण ट्रेस को अनंत बनाने के लिए पर्याप्त हैं। निष्पादन समय के रूढ़िवादी सन्निकटन पर काम किया गया है , जो लागत शब्दार्थ या एनोटेट प्रकार प्रणाली जैसी चीजों के माध्यम से निष्पादन पर ऊपरी सीमा देता है। मैं विशेष रूप से विधानसभा के लिए कुछ से परिचित नहीं हूँ, लेकिन मुझे आश्चर्य नहीं होगा अगर ऐसा कुछ मौजूद था।


4
मेरा मतलब है, हाल्टिंग प्रॉब्लम सीधे यहां लागू होती है, क्योंकि अगर हम जानते थे कि रन टाइम हमें पता था कि यह रुकता है। यह भी तथ्य है कि कोई भी स्थिति नहीं है यहाँ भी मदद नहीं करता है, क्योंकि x86 में, movट्यूरिंग-कम्प्लीट
ब्लूराजा - डैनी पफ्लुघोफ्ट

7
चावल और हाल्टिंग समस्या मनमाने (किसी भी) कार्यक्रम के बारे में बयान हैं - लेकिन यहाँ ओपी ने प्रश्न में एक विशिष्ट कोड कोड निर्दिष्ट किया है। आप व्यक्तिगत या सीमित श्रेणियों के कार्यक्रमों के बारे में शब्दार्थ और पड़ाव गुण निर्धारित कर सकते हैं, है ना? यह सिर्फ इतना है कि कोई सामान्य प्रक्रिया नहीं है जो सभी कार्यक्रमों को कवर करती है।
डैनियल आर। कोलिन्स

2
हम निश्चित रूप से जान सकते हैं कि कौन सा निर्देश आगे चलेगा, जो हम नहीं बता सकते हैं यदि हम कभी हिट करते हैं sys_exitऔर इस तरह स्टॉपवॉच को रोकते हैं। यदि हम समाप्त करने वाले कार्यक्रमों पर रोक लगाते हैं, जो इस तरह के व्यावहारिक प्रश्न के लिए उचित है, तो जवाब वास्तव में हां है (दी गई है कि आपके पास कार्यक्रम शुरू करने से ठीक पहले, सिस्टम के राज्य, hw और sw की एक संपूर्ण स्नैपशॉट है)।
मार्गरेट ब्लूम

1
@ BlueRaja-DannyPflughoeft Mov ट्यूरिंग-पूर्ण है, लेकिन ओपी के पास यहां कोड के टुकड़े में नहीं है। लेकिन बिंदु के अलावा के वैसे भी है कि - intरों मनमाना कोड, मनमाने ढंग से मैं के लिए प्रतीक्षा निष्पादित कर सकते हैं / ओ संचालन आदि
Luaan

2

क्या "कंप्यूटर सिस्टम" का चुनाव माइक्रोकंट्रोलर को शामिल करने के लिए होगा? कुछ माइक्रोकंट्रोलर्स के पास बहुत ही पूर्वानुमानित निष्पादन समय होता है, उदाहरण के लिए 8 बिट PIC श्रृंखला में प्रति निर्देश चार घड़ी चक्र होते हैं जब तक कि एक अलग पते पर निर्देश शाखाएं, फ्लैश से पढ़ती हैं या एक विशेष दो-शब्द निर्देश है।

व्यवधान इस तरह के टाइमिमग को बाधित करेगा लेकिन "नंगे धातु" कॉन्फ़िगरेशन में एक बाधा हैंडलर के बिना बहुत कुछ करना संभव है।

असेंबली और एक विशेष कोडिंग शैली का उपयोग करके कोड लिखना संभव है जो निष्पादित करने के लिए हमेशा एक ही समय लगेगा। यह अब इतना सामान्य नहीं है कि अधिकांश PIC वेरिएंट में कई टाइमर हैं, लेकिन यह संभव है।


2

8-बिट कंप्यूटर के युग में, कुछ खेलों ने कुछ ऐसा ही किया। प्रोग्रामर वीडियो और ऑडियो हार्डवेयर के सटीक समय के साथ सिंक्रनाइज़ करने के लिए, सीपीयू की ज्ञात घड़ी गति और सीपीयू की ज्ञात गति के आधार पर निर्देशों को निष्पादित करने में लगने वाले समय की सटीक मात्रा का उपयोग करेंगे। उन दिनों में, डिस्प्ले एक कैथोड-रे-ट्यूब मॉनिटर था जो एक निश्चित दर पर स्क्रीन की प्रत्येक पंक्ति के माध्यम से चक्र करेगा और फॉस्फोर को सक्रिय या निष्क्रिय करने के लिए कैथोड रे को चालू और बंद करके पिक्सेल की उस पंक्ति को पेंट करेगा। क्योंकि प्रोग्रामर को वीडियो हार्डवेयर को यह बताने की आवश्यकता थी कि बीम के स्क्रीन के उस हिस्से तक पहुंचने से ठीक पहले क्या प्रदर्शित करना है, और बाकी कोड को जो भी समय बचा था, उसमें फिट कर दिया, उन्होंने कहा कि "बीम को चलाना।"

यह बिल्कुल किसी भी आधुनिक कंप्यूटर पर या आपके उदाहरण की तरह कोड के लिए काम नहीं करेगा।

क्यों नहीं? यहाँ कुछ चीजें हैं जो सरल, अनुमानित समय को गड़बड़ कर सकती हैं:

निष्पादन समय पर सीपीयू की गति और मेमोरी भ्रूण दोनों अड़चनें हैं। सीपीयू को तेजी से चलाना पैसे की बर्बादी है क्योंकि इसे निष्पादित करने के निर्देश प्राप्त हो सकते हैं, या मेमोरी स्थापित करने के लिए सीपीयू की तुलना में तेजी से बाइट्स दे सकते हैं। इस वजह से, पुराने कंप्यूटर दोनों एक ही घड़ी से चले गए। आधुनिक CPU मुख्य मेमोरी की तुलना में बहुत तेज चलते हैं। वे निर्देश और डेटा कैश होने से प्रबंधित करते हैं। अगर यह कभी भी कैश में नहीं है बाइट के लिए प्रतीक्षा करने की आवश्यकता है, तो सीपीयू अभी भी स्टाल करेगा। अगर वे पहले से ही कैश में नहीं हैं तो वही निर्देश बहुत तेजी से चलेंगे।

इसके अलावा, आधुनिक सीपीयू में लंबी पाइपलाइनें होती हैं। वे पाइपलाइन में अगले कई निर्देशों पर चिप का एक और हिस्सा प्रारंभिक कार्य करके अपने उच्च थ्रूपुट को बनाए रखते हैं। यह विफल हो जाएगा यदि सीपीयू को पता नहीं है कि अगला निर्देश क्या होगा, जो कि एक शाखा होने पर हो सकता है। इसलिए, सीपीयू सशर्त कूदने की भविष्यवाणी करने की कोशिश करते हैं। (आपके पास इस कोड स्निपेट में कोई भी नहीं है, लेकिन शायद इसमें गलत तरीके से सशर्त छलांग लगाई गई थी, जिसने पाइपलाइन को सीज कर दिया। इसके अलावा, उस पौराणिक उत्तर को जोड़ने के लिए अच्छा बहाना भी।) इसी तरह, सिस्टम जो कि int 80kash मोड में फंसने को कहते हैं। एक जटिल CPU सुविधा का उपयोग कर रहे हैं, एक अवरोध गेट, जो अप्रत्याशित देरी का परिचय देता है।

यदि आपका OS प्रीमेप्टिव मल्टीटास्किंग का उपयोग करता है, तो इस कोड को चलाने वाला धागा किसी भी समय अपना समय खो सकता है।

बीम को चलाना भी केवल इसलिए काम आया क्योंकि प्रोग्राम नंगे धातु पर चल रहा था और सीधे हार्डवेयर पर टकरा गया। यहां, आप int 80सिस्टम कॉल करने के लिए कॉल कर रहे हैं । यह ऑपरेटिंग सिस्टम पर नियंत्रण से गुजरता है, जो आपको कोई समय की गारंटी नहीं देता है। आप इसके बाद यह बताएं कि मैं / ओ एक मनमाना स्ट्रीम पर है, जिसे किसी भी डिवाइस पर रीडायरेक्ट किया गया हो सकता है। आपके लिए यह कहना बहुत अधिक अमूर्त है कि I / O कितना समय लेता है, लेकिन यह निश्चित रूप से निष्पादित निर्देशों पर खर्च किए गए समय पर हावी होगा।

यदि आप एक आधुनिक प्रणाली पर सटीक समय चाहते हैं, तो आपको एक देरी लूप शुरू करने की आवश्यकता है। आपको सबसे तेज़ पुनरावृत्तियों को सबसे धीमी गति से चलाना होगा, रिवर्स संभव नहीं हो सकता है। वास्तविक दुनिया में लोग ऐसा करने का एक कारण किसी हमलावर को क्रिप्टोग्राफिक जानकारी को लीक करने से रोकना चाहते हैं, जो समय के साथ दूसरों की तुलना में अधिक समय ले सकता है।


1

यह कुछ हद तक मूर्त है लेकिन अंतरिक्ष यान में 4 निरर्थक कंप्यूटर थे जो सटीक रूप से सिंक किए जाने पर निर्भर थे, अर्थात उनका रन-टाइम बिल्कुल मेल खाता था।

स्पेस शटल के पहले लॉन्च प्रयास की तब छानबीन की गई थी जब बैकअप फ्लाइट सॉफ्टवेयर (BFS) कंप्यूटर ने चार प्राथमिक एवियोनिक्स सॉफ्टवेयर सिस्टम (पास) कंप्यूटरों के साथ सिंक्रनाइज़ करने से इनकार कर दिया था। में "बग हर्ड दौर दुनिया" विवरण यहाँ । आकर्षक तरीके से पढ़ा गया कि साइकिल के लिए चक्र से मेल करने के लिए सॉफ़्टवेयर कैसे विकसित किया गया था और आपको दिलचस्प पृष्ठभूमि दे सकता है।


0

मुझे लगता है कि हम यहां दो अलग-अलग मुद्दों को मिला रहे हैं। (और हां, मुझे पता है कि यह दूसरों द्वारा कहा गया है, लेकिन मुझे उम्मीद है कि मैं इसे और अधिक स्पष्ट रूप से व्यक्त कर सकता हूं।)

पहले हमें स्रोत कोड से निर्देशों के अनुक्रम को प्राप्त करना होगा जो वास्तव में निष्पादित होता है (जिसे इनपुट डेटा के साथ-साथ कोड के ज्ञान की आवश्यकता होती है - आप कितनी बार एक लूप के दौर पर जाते हैं? एक परीक्षण के बाद कौन सी शाखा ली जाती है? )। रुकने की समस्या के कारण, निर्देशों का क्रम अनंत (गैर-समाप्ति) हो सकता है और आप इनपुट डेटा के ज्ञान के साथ हमेशा उस सांख्यिकीय को निर्धारित नहीं कर सकते।

निष्पादित किए जाने वाले निर्देशों का अनुक्रम स्थापित करने के बाद, आप तब निष्पादन समय निर्धारित करना चाहते हैं। यह निश्चित रूप से सिस्टम आर्किटेक्चर के कुछ ज्ञान के साथ अनुमान लगाया जा सकता है। लेकिन समस्या यह है कि कई आधुनिक मशीनों पर, निष्पादन का समय मेमोरी भ्रूण के कैशिंग पर निर्भर करता है, जिसका अर्थ है कि यह इनपुट डेटा पर उतना ही निर्भर करता है जितना कि निष्पादित निर्देशों पर। यह सशर्त शाखा गंतव्यों के सही अनुमान पर भी निर्भर करता है, जो फिर से डेटा निर्भर है। तो यह केवल एक अनुमान होने जा रहा है, यह सटीक नहीं है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.