द्वारा जोड़ा गया: हैकर समाचार पर अच्छी चर्चा

गिटहब पर डेविड यू ने विभिन्न बाहरी इंटरफेस (फॉरेन फंक्शन इंटरफेसेस, एफएफआई ) के माध्यम से फ़ंक्शन कॉल के लिए एक दिलचस्प प्रदर्शन परीक्षण विकसित किया है।

उन्होंने एक साधारण सी फ़ंक्शन के साथ एक साझा ऑब्जेक्ट ( .so ) फ़ाइल बनाई। फिर उन्होंने बार-बार प्रत्येक एफएफआई के माध्यम से एक बार आयाम के साथ इस फ़ंक्शन को कॉल करने के लिए कोड लिखा।

C "FFI" के लिए, उन्होंने मानक डायनेमिक लिंकिंग का उपयोग किया, न कि dlopen() । यह अंतर बहुत महत्वपूर्ण है, क्योंकि यह वास्तव में परीक्षण के परिणामों को प्रभावित करता है। आप तर्क कर सकते हैं कि वास्तविक एफएफआई के साथ यह तुलना कितनी ईमानदार है, लेकिन यह अभी भी मापने के लिए दिलचस्प है।

सबसे आश्चर्यजनक बेंचमार्क परिणाम यह है कि LJJIT का FFI C की तुलना में काफी तेज है। यह एक साझा वस्तु फ़ंक्शन के लिए एक देशी सी कॉल की तुलना में लगभग 25% तेज है। बेंचमार्क C में कमजोर और गतिशील रूप से टाइप की गई स्क्रिप्टिंग भाषा कैसे आगे निकल सकती है? क्या परिणाम सही है?

वास्तव में, यह काफी तार्किक है। परीक्षण लिनक्स पर चलता है, इसलिए विलंब प्रक्रिया प्रक्रिया तालिका (पीएलटी) से आता है। मैंने सादे पुराने सी में प्रभाव प्रदर्शित करने के लिए एक बहुत ही सरल प्रयोग तैयार किया:

https://github.com/skeeto/dynamic-function-benchmark

यहाँ Intel i7-6700 (Skylake) पर परिणाम दिए गए हैं:

plt: 1.759799 ns/call
ind: 1.257125 ns/call
jit: 1.008108 ns/call

फ़ंक्शन कॉल के तीन अलग-अलग प्रकार हैं:

1. पीएलटी।
2. अप्रत्यक्ष फ़ंक्शन कॉल ( dlsym(3) माध्यम से dlsym(3) )
3. प्रत्यक्ष फ़ंक्शन कॉल (JIT संकलित फ़ंक्शन के माध्यम से)

जैसा कि आप देख सकते हैं, बाद वाला सबसे तेज़ है। यह आमतौर पर सी कार्यक्रमों में उपयोग नहीं किया जाता है, लेकिन यह जेआईटी संकलक की उपस्थिति में एक स्वाभाविक विकल्प है, जिसमें, जाहिर है, एलएलजेआईआईटी शामिल है।

मेरे बेंचमार्क में, empty() फ़ंक्शन को कहा जाता है:

 void empty(void) { } 

एक साझा वस्तु के लिए संकलन:

 $ cc -shared -fPIC -Os -o empty.so empty.c 

पिछली PRNG तुलना में , अलार्म बंद होने से पहले बेंचमार्क जितनी बार संभव हो, इस फ़ंक्शन को कॉल करता है।

प्रक्रिया लेआउट टेबल्स

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

ऐसी समस्या को कैसे हल करें? वैसे, कई विकल्प हैं।

उनमें से एक बाइनरी मेटाडेटा में हर कॉल को चिह्नित करना है। डायनेमिक रनटाइम बिल्डर तब हर कॉल पर सही पता सम्मिलित करता है । विशिष्ट तंत्र कोड मॉडल पर निर्भर करता है जिसका उपयोग संकलन के दौरान किया गया था।

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

दूसरी ओर, गतिशील कार्यों को लागू करने के ओवरहेड को समाप्त किया जा सकता है, जो जेआईटी जैसा प्रदर्शन देता है, जैसा कि बेंचमार्क में दिखाया गया है।

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

ईएलएफ बाइनरी सिस्टम पर, इस तालिका को प्रक्रिया लिंकेज टेबल (पीएलटी) कहा जाता है। PLT को वास्तव में सही नहीं किया गया है - इसे केवल शेष कोड के लिए रीड-ओनली प्रदर्शित किया जाता है। इसके बजाय, वैश्विक ऑफसेट तालिका (GOT) को सही किया गया है। PLT ठूंठ GOT से एक गतिशील फ़ंक्शन का पता पुनर्प्राप्त करता है और अप्रत्यक्ष रूप से उस पते पर कूदता है। फ़ंक्शन के पतों को लोड करने के लिए, इन GOT प्रविष्टियों को फ़ंक्शन के पते के साथ आरंभ किया जाता है, जो लक्षित वर्ण को ढूंढता है, उस पते के साथ GOT को अपडेट करता है, और फिर फ़ंक्शन पर जाता है। बाद में कॉल एक आलसी पता का उपयोग करते हैं।



पीएलटी का नुकसान एक गतिशील फ़ंक्शन को लागू करने का अतिरिक्त ओवरहेड है, जो कि बेंचमार्क में दिखाई देता है। चूंकि बेंचमार्क केवल फ़ंक्शन कॉल को मापता है, इसलिए अंतर काफी महत्वपूर्ण है, लेकिन व्यवहार में यह आमतौर पर शून्य के करीब है।

यहाँ बेंचमार्क है:

 /* Cleared by an alarm signal. */ volatile sig_atomic_t running; static long plt_benchmark(void) { long count; for (count = 0; running; count++) empty(); return count; } 

चूंकि empty() एक साझा ऑब्जेक्ट में है, कॉल पीएलटी के माध्यम से जाता है।

अप्रत्यक्ष गतिशील कॉल

गतिशील रूप से कॉल फ़ंक्शन के लिए एक और तरीका dlsym(3) चारों ओर घूमना है और कार्यक्रम में लक्ष्य फ़ंक्शन का पता प्राप्त करना है, उदाहरण के लिए, dlsym(3) माध्यम से।

 void *h = dlopen("path/to/lib.so", RTLD_NOW); void (*f)(void) = dlsym("f"); f(); 

यदि फ़ंक्शन पता प्राप्त होता है, तो लागत PLT के माध्यम से फ़ंक्शन कॉल से कम है। जीओटी के लिए स्टब और पहुंच का कोई मध्यवर्ती कार्य नहीं है। (सावधानी: यदि इस फ़ंक्शन के लिए प्रोग्राम में PLT रिकॉर्ड है, तो dlsym(3) वास्तव में एक स्टब एड्रेस वापस कर सकता है)।

लेकिन यह अभी भी एक अप्रत्यक्ष चुनौती है। पारंपरिक आर्किटेक्चर पर, प्रत्यक्ष फ़ंक्शन कॉल उनके तत्काल संबंधित पते को प्राप्त करते हैं। यही है, कॉल का उद्देश्य कॉल के बिंदु से कुछ हार्ड-कोडित ऑफसेट है। सीपीयू यह पता लगा सकता है कि कॉल बहुत पहले कहां जाएगी।

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

यहाँ बेंचमार्क है:

 volatile sig_atomic_t running; static long indirect_benchmark(void (*f)(void)) { long count; for (count = 0; running; count++) f(); return count; } 

इस बेंचमार्क को दिया गया फ़ंक्शन dlsym(3) का उपयोग करके निकाला जाता है, इसलिए कंपाइलर कुछ मुश्किल नहीं कर सकता है , जैसे कि इस अप्रत्यक्ष कॉल को डायरेक्ट में कनवर्ट करना।

यदि लूप बॉडी पर्याप्त रूप से रजिस्टरों की कमी का कारण है और जिससे स्टैक को पता दिया जाता है, तो यह बेंचमार्क भी PLT बेंचमार्क के साथ ईमानदारी से तुलना नहीं कर सकता है।

प्रत्यक्ष समारोह कॉल

पहले दो प्रकार के गतिशील फ़ंक्शन कॉल सरल और उपयोग करने में आसान हैं। डायनेमिक फ़ंक्शंस के लिए डायरेक्ट कॉल को व्यवस्थित करना अधिक कठिन है, क्योंकि उन्हें निष्पादन के दौरान कोड परिवर्तन की आवश्यकता होती है। मेरे बेंचमार्क में, मैंने डायरेक्ट कॉल जेनरेट करने के लिए एक छोटा JIT कंपाइलर साथ रखा।

चाल यह है कि x86-64 पर स्पष्ट संक्रमण 32-बिट हस्ताक्षरित ऑपरेंड (तत्काल हस्ताक्षरित) के कारण 2 जीबी सीमा तक सीमित हैं। इसका मतलब है कि JIT कोड को लक्ष्य फ़ंक्शन के लगभग बगल में रखा जाना चाहिए, empty() । यदि जेआईटी कोड को दो अलग-अलग गतिशील कार्यों को कॉल करना होगा, जिसे 2 जीबी से अधिक विभाजित किया जाएगा, तो दो प्रत्यक्ष कॉल करना असंभव है।

स्थिति को सरल बनाने के लिए, मेरा बेंचमार्क जेआईटी कोड के पते के सटीक या बहुत सावधान विकल्प के बारे में चिंतित नहीं है। लक्ष्य फ़ंक्शन का पता प्राप्त करने के बाद, यह केवल 4 एमबी घटाता है, इसे निकटतम पृष्ठ पर ले जाता है, थोड़ी मेमोरी आवंटित करता है और इसे कोड लिखता है। यदि सब कुछ वैसा ही किया जाता है, तो एक जगह की तलाश करने के लिए आपको स्मृति में कार्यक्रम के अपने स्वयं के प्रतिनिधित्व की जांच करने की आवश्यकता होती है, और यह एक साफ, पोर्टेबल तरीके से नहीं किया जा सकता है। लिनक्स को / के तहत वर्चुअल फ़ाइलों को पार्स करने की आवश्यकता होती है ।

यह मेरा जेआईटी मेमोरी आवंटन कैसा दिखता है। यह uintptr_t कास्टिंग के लिए उचित व्यवहार मानता है:

 static void jit_compile(struct jit_func *f, void (*empty)(void)) { uintptr_t addr = (uintptr_t)empty; void *desired = (void *)((addr - SAFETY_MARGIN) & PAGEMASK); /* ... */ unsigned char *p = mmap(desired, len, prot, flags, fd, 0); /* ... */ } 

दो पृष्ठ यहां खड़े हैं: एक लेखन के लिए, और दूसरा गैर-लेखन कोड के साथ। क्लोजर के लिए मेरी लाइब्रेरी की तरह , यहां नीचे का पेज राइट है और इसमें एक running वैरिएबल है जो अलार्म को रीसेट करता है। RIP के बारे में अन्य दो बेंचमार्क में एक फ़ंक्शन के रूप में प्रभावी पहुँच प्रदान करने के लिए यह पृष्ठ JIT कोड के बगल में होना चाहिए। शीर्ष पृष्ठ में यह असेंबली कोड है:

 jit_benchmark: push rbx xor ebx, ebx .loop: mov eax, [rel running] test eax, eax je .done call empty inc ebx jmp .loop .done: mov eax, ebx pop rbx ret 

call empty केवल गतिशील रूप से उत्पन्न निर्देश है, इसे रिश्तेदार पते में सही ढंग से भरना आवश्यक है (शून्य 5 निर्देश के अंत के सापेक्ष इंगित किया गया है):

  // call empty uintptr_t rel = (uintptr_t)empty - (uintptr_t)p - 5; *p++ = 0xe8; *p++ = rel >> 0; *p++ = rel >> 8; *p++ = rel >> 16; *p++ = rel >> 24; 

यदि empty() फ़ंक्शन सामान्य ऑब्जेक्ट में नहीं है, लेकिन एक ही बाइनरी फ़ाइल में है, तो यह अनिवार्य रूप से एक प्रत्यक्ष कॉल है जो कंपाइलर plt_benchmark() लिए उत्पन्न करेगा, यह मानते हुए कि किसी कारण से यह empty() में नहीं बना है।

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

कोई रहस्य नहीं

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