x86 32-बिट मशीन कोड (लिनक्स सिस्टम कॉल के साथ): 106 105 बाइट्स
चेंजलॉग: फास्ट संस्करण में एक बाइट को बचाया क्योंकि एक ऑफ-बाय-वन स्थिरांक फीब (1 जी) के लिए परिणाम नहीं बदलता है।
या एक 18% धीमी (Skylake पर) संस्करण के लिए 102 बाइट (का उपयोग करते हुए mov
/ sub
/ cmc
के बजाय lea
/ cmp
भीतरी पाश में, कम से कैरी-बाहर और रैपिंग उत्पन्न करने के लिए 10**9
के बजाय2**32
)। या आंतरिक-सबसे अधिक लूप में कैरी-हैंडलिंग में एक शाखा के साथ ~ 5.3x धीमे संस्करण के लिए 101 बाइट्स। (मैंने 25.4% ब्रांच-मिसप्रिक्ट रेट मापा है!)
या 104/101 बाइट्स यदि एक प्रमुख शून्य की अनुमति है। (यह आउटपुट के 1 अंक को हार्ड-कोड स्किप करने के लिए 1 अतिरिक्त बाइट लेता है, जो कि फाइब (10 ** 9) के लिए आवश्यक होता है)।
दुर्भाग्य से, TIO के NASM मोड -felf32
को कंपाइलर फ्लैग में अनदेखा किया गया है। यहाँ एक लिंक वैसे भी है मेरे स्रोत के साथ , टिप्पणियों में सभी प्रयोगात्मक विचारों की गड़बड़ी के साथ।
यह एक संपूर्ण कार्यक्रम है । यह Fib के पहले 1000 अंकों (10 ** 9) को प्रिंट करता है, इसके बाद कुछ अतिरिक्त अंक (जिनमें से कुछ गलत हैं) कुछ कचरा बाइट्स (एक नई पंक्ति शामिल नहीं) द्वारा पीछा करते हैं। अधिकांश कचरा गैर-एएससीआईआई है, इसलिए आप इसके माध्यम से पाइप करना चाहते हैं cat -v
। यह मेरे टर्मिनल एमुलेटर (KDE konsole
) को नहीं तोड़ता , हालाँकि। "कचरा बाइट्स" Fib (999999999) का भंडारण कर रहे हैं। मेरे पास पहले से था-1024
एक रजिस्टर था, इसलिए उचित आकार की तुलना में 1024 बाइट प्रिंट करना सस्ता था।
मैं सिर्फ मशीन-कोड (मेरे स्थिर निष्पादन योग्य के टेक्स्ट सेगमेंट का आकार) की गिनती कर रहा हूं, न कि फुलाना जो इसे ईएलएफ निष्पादन योग्य बनाता है। ( बहुत छोटे ईएलएफ निष्पादन संभव हैं , लेकिन मैं उस से परेशान नहीं होना चाहता था)। यह बीएसएस के बजाय स्टैक मेमोरी का उपयोग करने के लिए छोटा हो गया, इसलिए मैं किसी भी मेटाडेटा पर निर्भर नहीं होने के बाद से बाइनरी में कुछ और नहीं गिनने का औचित्य साबित कर सकता हूं। (स्ट्रिप्ड स्टैटिक बाइनरी का उत्पादन सामान्य तरीके से 340 बाइट ईएलएफ निष्पादन योग्य बनाता है।)
आप इस कोड से एक फ़ंक्शन बना सकते हैं जिसे आप सी से कॉल कर सकते हैं। स्टैक पॉइंटर को बचाने / पुनर्स्थापित करने के लिए कुछ बाइट्स खर्च होंगे (शायद एमएमएक्स रजिस्टर में) और कुछ अन्य ओवरहेड, लेकिन स्ट्रिंग के साथ वापस आकर भी बाइट्स बचाएं। मेमोरी में, write(1,buf,len)
सिस्टम कॉल करने के बजाय । मुझे लगता है कि मशीन कोड में गोल्फिंग से मुझे कुछ सुस्त कमाई करनी चाहिए, क्योंकि किसी और ने भी किसी भाषा में देशी विस्तारित-परिशुद्धता के बिना उत्तर नहीं दिया है, लेकिन मुझे लगता है कि इस का एक फ़ंक्शन संस्करण अभी भी 120 बाइट्स के बिना होना चाहिए पूरे गोल्फ को फिर से। चीज़।
कलन विधि:
जानवर बल a+=b; swap(a,b)
, केवल प्रमुख> = 1017 दशमलव अंक रखने के लिए आवश्यक के रूप में छोटा। यह मेरे कंप्यूटर (या 322.47 बिलियन क्लॉक साइकल + - 0.05%) पर 1min13s में चलता है (और कोड आकार के कुछ अतिरिक्त बाइट्स के साथ कुछ% तेज हो सकता है, या लूप ट्रोलिंग से बहुत बड़े कोड आकार के साथ 62 से नीचे हो सकता है।) चतुर गणित, बस कम ओवरहेड के साथ एक ही काम करना)। यह @ AndersKaseorg के पायथन कार्यान्वयन पर आधारित है , जो मेरे कंप्यूटर (4.4GHz Skylake i7-6700k) पर 12min35s में चलता है। किसी भी संस्करण में कोई भी L1D कैश मिस नहीं है, इसलिए मेरा DDR4-2666 कोई फर्क नहीं पड़ता।
पायथन के विपरीत, मैं विस्तारित-सटीक संख्याओं को एक प्रारूप में संग्रहीत करता हूं जो दशमलव अंकों को कम कर देता है । मैं 32-बिट पूर्णांक में 9 दशमलव अंकों के समूहों को संग्रहीत करता हूं, इसलिए एक पॉइंटर ऑफ़सेट कम 9 अंकों को डिस्कनेक्ट करता है। यह प्रभावी रूप से 1 बिलियन का आधार है, जो कि 10. की शक्ति है (यह शुद्ध संयोग है कि इस चुनौती को 1 बिलियन फिबोनासी संख्या की आवश्यकता है, लेकिन यह मुझे दो बाइट्स बनाम दो अलग-अलग स्थिरांक से बचाता है।)
GMP शब्दावली के बाद , विस्तारित-सटीक संख्या के प्रत्येक 32-बिट चंक को "लिम्ब" कहा जाता है। जोड़ते समय कैरी-आउट को 1e9 के मुकाबले तुलना के साथ मैन्युअल रूप से जेनरेट करना होता है, लेकिन फिर इसे सामान्य रूप से अगले अंग के लिए सामान्य ADC
निर्देश के इनपुट के रूप में उपयोग किया जाता है । (मुझे भी [0..999999999]
2 ^ 32 ~ = 4.295e9 के बजाय मैन्युअल रूप से रेंज में लपेटना होगा। मैं इस शाखा को lea
+ के साथ करता हूं cmov
, तुलना से कैरी आउट परिणाम का उपयोग करके।)
जब आखिरी अंग गैर-शून्य कैरी-आउट का उत्पादन करता है, तो बाहरी लूप के अगले दो पुनरावृत्तियों को सामान्य से 1 अंग अधिक पढ़ा जाता है, लेकिन फिर भी उसी स्थान पर लिखते हैं। यह memcpy(a, a+4, 114*4)
1 अंग द्वारा दाएं-शिफ्ट करने के समान है, लेकिन अगले दो अतिरिक्त छोरों के हिस्से के रूप में किया जाता है। यह हर ~ 18 पुनरावृत्तियों में होता है।
आकार की बचत और प्रदर्शन के लिए भाड़े:
जब मैं जानता हूं कि lea ebx, [eax-4 + 1]
इसके बजाय सामान्य सामान । और ऐसे स्थानों पर उपयोग करना जहां केवल सुस्ती का प्रभाव पड़ता है।mov ebx, 1
eax=4
loop
LOOP
adc
आंतरिक लूप में बफ़र की शुरुआत के लिए लिखते समय, हम जिस बिंदु से पढ़ते हैं, उसे ऑफसेट करके 1 अंग द्वारा मुक्त करें । हम से पढ़ते हैं [edi+edx]
, और लिखते हैं [edi]
। तो हम गंतव्य के लिए पढ़ने-लिखने की ऑफसेट प्राप्त कर सकते हैं edx=0
या कर सकते हैं 4
। हमें लगातार 2 पुनरावृत्तियों के लिए ऐसा करने की आवश्यकता है, पहले दोनों को ऑफसेट करना, फिर केवल dst को ऑफसेट करना। हम esp&4
बफ़र्स के सामने पॉइंटर्स को रीसेट करने से पहले 2 के मामले को देखते हैं (उपयोग कर रहे हैं &= -1024
, क्योंकि बफ़र्स संरेखित हैं)। कोड में टिप्पणी देखें।
लिनक्स प्रक्रिया-स्टार्टअप वातावरण (एक स्थिर निष्पादन योग्य के लिए) अधिकांश रजिस्टरों को शून्य करता है, और नीचे स्टैक-मेमोरी शून्य esp
/ होती rsp
है। मेरा कार्यक्रम इसका लाभ उठाता है। इसके एक कॉल करने योग्य फ़ंक्शन संस्करण में (जहां अनलॉकेटेड स्टैक गंदा हो सकता है), मैं शून्य मेमोरी के लिए बीएसएस का उपयोग कर सकता हूं (बिंदुओं को स्थापित करने के लिए शायद 4 और बाइट्स की कीमत पर)। ज़ीरोइंग edx
2 बाइट ले जाएगा। X86-64 सिस्टम V ABI इनमें से किसी की भी गारंटी नहीं देता है, लेकिन लिनक्स का कार्यान्वयन शून्य (कर्नेल से बाहर सूचना-लीक से बचने के लिए) करता है। एक गतिशील रूप से जुड़ी प्रक्रिया में, /lib/ld.so
पहले चलता है _start
, और रजिस्टरों को गैर-शून्य छोड़ देता है (और स्टैक पॉइंटर के नीचे स्मृति में कचरा)।
मैं रखने -1024
में ebx
छोरों के उपयोग के बाहर के लिए। bl
आंतरिक छोरों के लिए एक काउंटर के रूप में उपयोग करें , जो शून्य में समाप्त होता है (जो कि निम्न बाइट है -1024
, इस प्रकार लूप के बाहर उपयोग के लिए स्थिर को बहाल करता है)। Intel हैसवेल और बाद में लो-रजिस्टरों के लिए आंशिक-पंजीकरण विलय दंड नहीं है (और वास्तव में उन्हें अलग से नाम भी नहीं देते हैं) , इसलिए पूर्ण रजिस्टर पर निर्भरता है, जैसे एएमडी पर (यहां समस्या नहीं है)। यह नेहेलम और इससे पहले का भयानक होगा, हालांकि विलय के समय आंशिक-रजिस्टर स्टाल हैं। ऐसी और भी जगहें हैं जहाँ मैं आंशिक reg लिखता हूँ और फिर पूरा-पूरा पाठ पढ़ता हूँ बिना xor
-oooing के या एकmovzx
, आमतौर पर क्योंकि मुझे पता है कि कुछ पिछले कोड ने ऊपरी बाइट्स को शून्य कर दिया था, और फिर से एएमडी और इंटेल एसएनबी-परिवार पर ठीक है, लेकिन इंटेल प्री-सैंडीब्रिज पर धीमा है।
मैं 1024
stdout ( sub edx, ebx
) को लिखने के लिए बाइट्स की संख्या के रूप में उपयोग करता हूं , इसलिए मेरा कार्यक्रम फिबोनाची अंकों के बाद कुछ कचरा बाइट प्रिंट करता है, क्योंकि mov edx, 1000
अधिक बाइट की लागत होती है।
adc ebx,ebx
EBX = CF प्राप्त करने के लिए EBX = 0 के साथ (इस्तेमाल नहीं) , 1 बाइट बनाम setc bl
।
dec
/ jnz
एक adc
लूप के अंदर adc
इंटेल सैंडीब्रिज और बाद में झंडे पढ़ने पर आंशिक-फ्लैग स्टाल के बिना सीएफ को संरक्षित करता है । यह पहले के सीपीयू पर खराब है , लेकिन स्काईलेक पर AFAIK मुक्त है। या सबसे कम, एक अतिरिक्त ऊप।
नीचे दी esp
गई मेमोरी का उपयोग विशाल रेड-ज़ोन के रूप में करें । चूंकि यह एक पूर्ण लिनक्स प्रोग्राम है, इसलिए मुझे पता है कि मैंने कोई सिग्नल हैंडलर स्थापित नहीं किया है, और इसके अलावा कुछ भी नहीं होगा जो कि उपयोगकर्ता-स्पेस स्टैक मेमोरी को अनलिमिटेड रूप से बंद कर देगा। अन्य OSes पर ऐसा नहीं हो सकता है।
(1 हॉप / सामयिक स्टैक-सिंक यूओपी) के बजाय (हसवेल / स्काईलेक पर 2 उफ, आइवीबी पर 3 और पहले एग्नर फॉग के निर्देश तालिकाओं के अनुसार ) का उपयोग करके यूओपी समस्या बैंडविड्थ को बचाने के लिए स्टैक-इंजन का लाभ उठाएं । IIRC, इस रन-टाइम को लगभग 83 सेकंड से 73 तक गिरा दिया। मैं शायद एक इंडेक्सिंग एड्रेसिंग मोड के साथ उपयोग करने से समान गति प्राप्त कर सकता हूं , जैसे कि src और dst बफ़र्स के बीच ऑफ़सेट रखती है। (यह आंतरिक लूप के बाहर कोड को और अधिक जटिल बना देगा, जिसमें स्वैपिंग आर्क के भाग के रूप में ऑफ़सेट रजिस्टर को नकारना होगा और फिबोनाची पुनरावृत्तियों के लिए dst।) अधिक के लिए नीचे "प्रदर्शन" अनुभाग देखें।pop eax
lodsd
mov
mov eax, [edi+ebp]
ebp
कहीं भी मेमोरी में stc
स्टोर करने के बजाय पहले पुनरावृत्ति को एक कैरी-इन (एक बाइट ) देकर अनुक्रम शुरू करें 1
। टिप्पणियों में प्रलेखित अन्य समस्या-विशिष्ट सामग्री के बहुत सारे।
NASM लिस्टिंग (मशीन-कोड + स्रोत) , के साथ उत्पन्न nasm -felf32 fibonacci-1G.asm -l /dev/stdout | cut -b -28,$((28+12))- | sed 's/^/ /'
। (तब मैंने टिप्पणी की गई सामग्री के कुछ ब्लॉकों को हाथ से हटा दिया, इसलिए लाइन नंबरिंग में अंतराल है।) प्रमुख स्तंभों को बाहर निकालने के लिए ताकि आप इसे YASM या NASM में खिला सकें, उपयोग करें cut -b 27- <fibonacci-1G.lst > fibonacci-1G.asm
।
1 machine global _start
2 code _start:
3 address
4 00000000 B900CA9A3B mov ecx, 1000000000 ; Fib(ecx) loop counter
5 ; lea ebp, [ecx-1] ; base-1 in the base(pointer) register ;)
6 00000005 89CD mov ebp, ecx ; not wrapping on limb==1000000000 doesn't change the result.
7 ; It's either self-correcting after the next add, or shifted out the bottom faster than Fib() grows.
8
42
43 ; mov esp, buf1
44
45 ; mov esi, buf1 ; ungolfed: static buffers instead of the stack
46 ; mov edi, buf2
47 00000007 BB00FCFFFF mov ebx, -1024
48 0000000C 21DC and esp, ebx ; alignment necessary for convenient pointer-reset
49 ; sar ebx, 1
50 0000000E 01DC add esp, ebx ; lea edi, [esp + ebx]. Can't skip this: ASLR or large environment can put ESP near the bottom of a 1024-byte block to start with
51 00000010 8D3C1C lea edi, [esp + ebx*1]
52 ;xchg esp, edi ; This is slightly faster. IDK why.
53
54 ; It's ok for EDI to be below ESP by multiple 4k pages. On Linux, IIRC the main stack automatically extends up to ulimit -s, even if you haven't adjusted ESP. (Earlier I used -4096 instead of -1024)
55 ; After an even number of swaps, EDI will be pointing to the lower-addressed buffer
56 ; This allows a small buffer size without having the string step on the number.
57
58 ; registers that are zero at process startup, which we depend on:
59 ; xor edx, edx
60 ;; we also depend on memory far below initial ESP being zeroed.
61
62 00000013 F9 stc ; starting conditions: both buffers zeroed, but carry-in = 1
63 ; starting Fib(0,1)->0,1,1,2,3 vs. Fib(1,0)->1,0,1,1,2 starting "backwards" puts us 1 count behind
66
67 ;;; register usage:
68 ;;; eax, esi: scratch for the adc inner loop, and outer loop
69 ;;; ebx: -1024. Low byte is used as the inner-loop limb counter (ending at zero, restoring the low byte of -1024)
70 ;;; ecx: outer-loop Fibonacci iteration counter
71 ;;; edx: dst read-write offset (for "right shifting" to discard the least-significant limb)
72 ;;; edi: dst pointer
73 ;;; esp: src pointer
74 ;;; ebp: base-1 = 999999999. Actually still happens to work with ebp=1000000000.
75
76 .fibonacci:
77 limbcount equ 114 ; 112 = 1006 decimal digits / 9 digits per limb. Not enough for 1000 correct digits, but 114 is.
78 ; 113 would be enough, but we depend on limbcount being even to avoid a sub
79 00000014 B372 mov bl, limbcount
80 .digits_add:
81 ;lodsd ; Skylake: 2 uops. Or pop rax with rsp instead of rsi
82 ; mov eax, [esp]
83 ; lea esp, [esp+4] ; adjust ESP without affecting CF. Alternative, load relative to edi and negate an offset? Or add esp,4 after adc before cmp
84 00000016 58 pop eax
85 00000017 130417 adc eax, [edi + edx*1] ; read from a potentially-offset location (but still store to the front)
86 ;; jz .out ;; Nope, a zero digit in the result doesn't mean the end! (Although it might in base 10**9 for this problem)
87
88 %if 0 ;; slower version
;; could be even smaller (and 5.3x slower) with a branch on CF: 25% mispredict rate
89 mov esi, eax
90 sub eax, ebp ; 1000000000 ; sets CF opposite what we need for next iteration
91 cmovc eax, esi
92 cmc ; 1 extra cycle of latency for the loop-carried dependency. 38,075Mc for 100M iters (with stosd).
93 ; not much worse: the 2c version bottlenecks on the front-end bottleneck
94 %else ;; faster version
95 0000001A 8DB0003665C4 lea esi, [eax - 1000000000]
96 00000020 39C5 cmp ebp, eax ; sets CF when (base-1) < eax. i.e. when eax>=base
97 00000022 0F42C6 cmovc eax, esi ; eax %= base, keeping it in the [0..base) range
98 %endif
99
100 %if 1
101 00000025 AB stosd ; Skylake: 3 uops. Like add + non-micro-fused store. 32,909Mcycles for 100M iters (with lea/cmp, not sub/cmc)
102 %else
103 mov [edi], eax ; 31,954Mcycles for 100M iters: faster than STOSD
104 lea edi, [edi+4] ; Replacing this with ADD EDI,4 before the CMP is much slower: 35,083Mcycles for 100M iters
105 %endif
106
107 00000026 FECB dec bl ; preserves CF. The resulting partial-flag merge on ADC would be slow on pre-SnB CPUs
108 00000028 75EC jnz .digits_add
109 ; bl=0, ebx=-1024
110 ; esi has its high bit set opposite to CF
111 .end_innerloop:
112 ;; after a non-zero carry-out (CF=1): right-shift both buffers by 1 limb, over the course of the next two iterations
113 ;; next iteration with r8 = 1 and rsi+=4: read offset from both, write normal. ends with CF=0
114 ;; following iter with r8 = 1 and rsi+=0: read offset from dest, write normal. ends with CF=0
115 ;; following iter with r8 = 0 and rsi+=0: i.e. back to normal, until next carry-out (possible a few iters later)
116
117 ;; rdi = bufX + 4*limbcount
118 ;; rsi = bufY + 4*limbcount + 4*carry_last_time
119
120 ; setc [rdi]
123 0000002A 0F92C2 setc dl
124 0000002D 8917 mov [edi], edx ; store the carry-out into an extra limb beyond limbcount
125 0000002F C1E202 shl edx, 2
139 ; keep -1024 in ebx. Using bl for the limb counter leaves bl zero here, so it's back to -1024 (or -2048 or whatever)
142 00000032 89E0 mov eax, esp ; test/setnz could work, but only saves a byte if we can somehow avoid the or dl,al
143 00000034 2404 and al, 4 ; only works if limbcount is even, otherwise we'd need to subtract limbcount first.
148 00000036 87FC xchg edi, esp ; Fibonacci: dst and src swap
149 00000038 21DC and esp, ebx ; -1024 ; revert to start of buffer, regardless of offset
150 0000003A 21DF and edi, ebx ; -1024
151
152 0000003C 01D4 add esp, edx ; read offset in src
155 ;; after adjusting src, so this only affects read-offset in the dst, not src.
156 0000003E 08C2 or dl, al ; also set r8d if we had a source offset last time, to handle the 2nd buffer
157 ;; clears CF for next iter
165 00000040 E2D2 loop .fibonacci ; Maybe 0.01% slower than dec/jnz overall
169 to_string:
175 stringdigits equ 9*limbcount ; + 18
176 ;;; edi and esp are pointing to the start of buffers, esp to the one most recently written
177 ;;; edi = esp +/- 2048, which is far enough away even in the worst case where they're growing towards each other
178 ;;; update: only 1024 apart, so this only works for even iteration-counts, to prevent overlap
180 ; ecx = 0 from the end of the fib loop
181 ;and ebp, 10 ; works because the low byte of 999999999 is 0xff
182 00000042 8D690A lea ebp, [ecx+10] ;mov ebp, 10
183 00000045 B172 mov cl, (stringdigits+8)/9
184 .toascii: ; slow but only used once, so we don't need a multiplicative inverse to speed up div by 10
185 ;add eax, [rsi] ; eax has the carry from last limb: 0..3 (base 4 * 10**9)
186 00000047 58 pop eax ; lodsd
187 00000048 B309 mov bl, 9
188 .toascii_digit:
189 0000004A 99 cdq ; edx=0 because eax can't have the high bit set
190 0000004B F7F5 div ebp ; edx=remainder = low digit = 0..9. eax/=10
197 0000004D 80C230 add dl, '0'
198 ; stosb ; clobber [rdi], then inc rdi
199 00000050 4F dec edi ; store digits in MSD-first printing order, working backwards from the end of the string
200 00000051 8817 mov [edi], dl
201
202 00000053 FECB dec bl
203 00000055 75F3 jnz .toascii_digit
204
205 00000057 E2EE loop .toascii
206
207 ; Upper bytes of eax=0 here. Also AL I think, but that isn't useful
208 ; ebx = -1024
209 00000059 29DA sub edx, ebx ; edx = 1024 + 0..9 (leading digit). +0 in the Fib(10**9) case
210
211 0000005B B004 mov al, 4 ; SYS_write
212 0000005D 8D58FD lea ebx, [eax-4 + 1] ; fd=1
213 ;mov ecx, edi ; buf
214 00000060 8D4F01 lea ecx, [edi+1] ; Hard-code for Fib(10**9), which has one leading zero in the highest limb.
215 ; shr edx, 1 ; for use with edx=2048
216 ; mov edx, 100
217 ; mov byte [ecx+edx-1], 0xa;'\n' ; count+=1 for newline
218 00000063 CD80 int 0x80 ; write(1, buf+1, 1024)
219
220 00000065 89D8 mov eax, ebx ; SYS_exit=1
221 00000067 CD80 int 0x80 ; exit(ebx=1)
222
# next byte is 0x69, so size = 0x69 = 105 bytes
इसमें से कुछ और बाइट्स को गोल्फ में रखने के लिए शायद जगह है, लेकिन मैंने पहले ही 2 दिनों में इस पर कम से कम 12 घंटे बिताए हैं। मैं गति का त्याग नहीं करना चाहता, भले ही यह तेजी से अधिक से अधिक हो और इसमें गति को कम करने के तरीकों को छोटा बनाने के लिए जगह हो । पोस्ट करने के लिए मेरे कारण का हिस्सा यह दिखा रहा है कि मैं कितनी तेजी से एक जानवर-बल asm संस्करण बना सकता हूं। यदि कोई वास्तव में न्यूनतम आकार के लिए जाना चाहता है, लेकिन शायद 10x धीमा (उदाहरण के लिए 1 अंक प्रति बाइट), इसे शुरुआती बिंदु के रूप में कॉपी करने के लिए स्वतंत्र महसूस करें।
परिणामी निष्पादन योग्य (से yasm -felf32 -Worphan-labels -gdwarf2 fibonacci-1G.asm && ld -melf_i386 -o fibonacci-1G fibonacci-1G.o
) 340B (छीन लिया गया) है:
size fibonacci-1G
text data bss dec hex filename
105 0 0 105 69 fibonacci-1G
प्रदर्शन
इनर adc
लूप स्काईलेक पर 10 फ़्यूज़-डोमेन यूप्स है (+1 स्टैक-सिंक यूओपी हर ~ 128 बाइट्स), इसलिए यह स्किलेक पर एक ~ 2.5 चक्र पर इष्टतम फ्रंट-एंड थ्रूपुट (स्टैक-सिंक यूओपीस की अनदेखी) के साथ जारी कर सकता है । क्रिटिकल-पाथ लेटेंसी 2 साइकल है, adc
-> cmp
- -> अगली इरिगेशन की adc
लूप-एग्जिस्टेन्सी चेन के लिए, इसलिए टोंटी को फ्रंट-एंड इश्यू लिमिट ~ ~ 2.5 साइकल प्रति इटरएशन होना चाहिए।
adc eax, [edi + edx]
निष्पादन बंदरगाहों के लिए 2 अप्रयुक्त-डोमेन uops है: लोड + ALU। यह डिकोडर्स (1 फ्यूज्ड-डोमेन यूओपी) में माइक्रो-फ़्यूज़ होता है, लेकिन इश्यू स्टेज में 2 फ़्यूज़्ड-डोमेन यूओपी को अन-लेमिनेट करता है, क्योंकि इंडेक्स एड्रेसिंग मोड के कारण, यहां तक कि हैसवेल / स्काईलेक पर भी । मैंने सोचा कि यह माइक्रो- add eax, [edi + edx]
फ्यूज्ड रहेगा , जैसे करता है, लेकिन हो सकता है कि इंडेक्सिंग मोड्स को माइक्रो-फ्यूज्ड इंडेक्स करते हुए यूओपी के लिए काम न करे, जिसमें पहले से ही 3 इनपुट (झंडे, मेमोरी और डेस्टिनेशन) हों। जब मैंने इसे लिखा था, तो मैं सोच रहा था कि इसका प्रदर्शन नकारात्मक नहीं होगा, लेकिन मैं गलत था। ट्रंकेशन से निपटने का यह तरीका हर बार आंतरिक लूप को धीमा कर देता है, चाहे edx
0 या 4 हो।
स्टोर को समायोजित करने edi
और उपयोग edx
करने के लिए dst के लिए रीड-राइट ऑफसेट को हैंडल करना अधिक तेज़ होगा । तो adc eax, [edi]
/ ... / mov [edi+edx], eax
/ के lea edi, [edi+4]
बजाय stosd
। हसवेल और बाद में एक अनुक्रमित स्टोर को माइक्रो-फ्यूज्ड रख सकते हैं। (सैंडब्रिज / आईवीबी इसे अनलिमिटेड करेगा, भी।)
इंटेल हैसवेल पर और इससे पहले, adc
और cmovc
2c लेटेंसी के साथ 2 यूओपी हैं । ( adc eax, [edi+edx]
अभी भी हैसवेल पर अन-लेमिनेटेड है, और 3 फ्यूज़्ड-डोमेन उफ़ के रूप में समस्या है)। Broadwell और बाद में सिर्फ FMA (Haswell) से अधिक के लिए 3-इनपुट UOPs, प्रदान कर सकते हैं adc
और cmovc
, (और कुछ अन्य बातें) एकल-UOP निर्देश की तरह वे एक लंबे समय के लिए एएमडी पर किया गया है। (यह एक कारण है कि एएमडी ने लंबे समय तक विस्तारित-सटीक जीएमपी बेंचमार्क में अच्छा प्रदर्शन किया है।) वैसे भी, हैसवेल का इनर लूप 12 यूओपी (+1 स्टैक-सिंक यूओपी कभी-कभार) होना चाहिए, जिसमें फ्रंट-एंड टोंटी ~ 3c प्रति के साथ है। यह सबसे अच्छा मामला है, स्टैक-सिंक उप्स को अनदेखा करना।
एक लूप के अंदर pop
संतुलन के बिना उपयोग करने का push
मतलब है कि लूप एलएसडी (लूप स्ट्रीम डिटेक्टर) से नहीं चल सकता है , और हर बार आईडीक्यू में यूओपी कैश से फिर से पढ़ना होगा। यदि कुछ भी हो, तो यह स्काईलेक पर एक अच्छी बात है, क्योंकि 9 या 10 यूओपी लूप हर चक्र में 4 यूओपी पर काफी समस्या नहीं देता है । यह शायद यही कारण है कि जगह का हिस्सा है lodsd
के साथ pop
इतना मदद की। (एलएसडी यूओपी को लॉक नहीं कर सकता है क्योंकि यह स्टैक-सिंक यूओपी डालने के लिए जगह नहीं छोड़ेगा ।) (बीटीडब्लू, एक माइक्रोकोड अपडेट एलएसडी को पूरी तरह से स्काइलेक और स्काइलेक-एक्स पर एक इरेटा को ठीक करने में अक्षम करता है। मैंने इसे मापा था। उस अद्यतन को प्राप्त करने से पहले ऊपर।)
मैंने इसे हैसवेल पर प्रोफाइल किया, और पाया कि यह 381.31 बिलियन क्लॉक साइकल में चलता है (सीपीयू फ्रीक्वेंसी की परवाह किए बिना, क्योंकि यह केवल एल 1 डी कैश का उपयोग करता है, मेमोरी का नहीं)। फ्रंट-एंड इश्यू थ्रूपुट प्रति घड़ी 3.72 फ्यूज्ड-डोमेन यूओपी, बनाम 3.70 स्काइलेक के लिए था। (लेकिन निश्चित रूप से प्रति चक्र निर्देश 2.87 से 2.42 से नीचे था, क्योंकि adc
और cmov
हसवेल पर 2 यूओपी हैं।)
push
बदलने के लिए stosd
शायद उतना मदद नहीं करेगा, क्योंकि adc [esp + edx]
हर बार स्टैक-सिंक यूओपी को ट्रिगर किया जाएगा। और एक बाइट की लागत के लिए होगा std
तो lodsd
दूसरी दिशा में चला जाता है। ( mov [edi], eax
/ lea edi, [edi+4]
को बदलने के stosd
लिए एक जीत है, 100M iters के लिए 32,909Mcycles से 100M iters के लिए 31,954Mcycles पर जा रहा है। ऐसा लगता है कि stosd
3-uops के रूप में डिकोड करता है, स्टोर-एड्रेस / स्टोर-डेटा के साथ माइक्रो-फ़्यूज़ नहीं, इसलिए push
+ स्टैक-सिंक यूओपी अभी भी की तुलना में तेज हो सकता है stosd
)
114 अंगों के 1G पुनरावृत्तियों के लिए ~ 322.47 बिलियन चक्रों का वास्तविक प्रदर्शन स्काइलेक पर तेजी से 105B संस्करण के लिए आंतरिक लूप के पुनरावृत्ति 2.824 चक्रों तक काम करता है । ( ocperf.py
नीचे उत्पादन देखें)। यह स्थिर विश्लेषण की भविष्यवाणी की तुलना में धीमा है, लेकिन मैं बाहरी लूप के ओवरहेड और किसी भी स्टैक-सिंक उप्स को अनदेखा कर रहा था।
के लिए पूर्ण काउंटर branches
और branch-misses
दिखाते हैं कि आंतरिक लूप बाहरी लूप के अनुसार एक बार गलत करता है (अंतिम पुनरावृत्ति पर, जब इसे नहीं लिया जाता है)। वह भी अतिरिक्त समय के हिस्से के लिए।
मैं बनाने भीतरी सबसे पाश महत्वपूर्ण मार्ग के लिए 3-चक्र विलंबता है, का उपयोग करके कोड आकार को बचा सकता है mov esi,eax
/ sub eax,ebp
/ cmovc eax, esi
/cmc
(2 + 2 + 3 + 1 = 8 बी) के बजाय lea esi, [eax - 1000000000]
/ cmp ebp,eax
/ cmovc
(6 + 2 + 3 = 11B )। cmov
/ stosd
महत्वपूर्ण मार्ग बंद है। (इंक्रीमेंट-ईडी यूओपी stosd
स्टोर से अलग-अलग चल सकता है, इसलिए प्रत्येक पुनरावृत्ति एक छोटी निर्भरता श्रृंखला को बंद कर देती है।) यह ईबीपी इनिट निर्देश को बदलने से एक और 1 बी को बचाने के लिए उपयोग करता lea ebp, [ecx-1]
है mov ebp,eax
, लेकिन मुझे पता चला कि गलत होनाebp
परिणाम नहीं बदला। यह एक अंग को लपेटने और उत्पादन करने के बजाय बिल्कुल ठीक == 1000000000 होने देगा, लेकिन यह त्रुटि हम की तुलना में धीमी गति से फैलती है (जैसे) बढ़ता है, इसलिए यह अंतिम परिणाम के अग्रणी 1k अंक को बदलने के लिए नहीं होता है। इसके अलावा, मुझे लगता है कि जब हम बस जोड़ रहे हैं, तो त्रुटि खुद ही सही हो सकती है, क्योंकि इसे बिना अतिप्रवाह के रखने के लिए एक अंग में कमरा है। यहां तक कि 1G + 1G एक 32-बिट पूर्णांक को अतिप्रवाह नहीं करता है, इसलिए यह अंततः ऊपर की तरफ झुक जाएगा या दूर हो जाएगा।
3 सी विलंबता संस्करण 1 अतिरिक्त यूओपी है, इसलिए फ्रंट-एंड इसे स्काइलेक पर प्रति 2.75 सी चक्र में जारी कर सकता है, केवल बैक-एंड की तुलना में थोड़ा तेज इसे चला सकता है। (हैसवेल पर, यह 13 यूओपी कुल होगा क्योंकि यह अभी भी उपयोग करता है adc
और cmov
, और 3.25c प्रति फ्रंट-एंड पर टोंटी)।
व्यवहार में यह स्काईलेक पर 1.18 धीमी (प्रति अंग 3.34 चक्र) के बजाय 3 / 2.5 = 1.2 का एक कारक चलाता है, जो कि मैंने सामने के अंत की अड़चन को लेटेंसी टोंटी के साथ बदलने के लिए भविष्यवाणी की थी, बस स्टैक-सिंक के बिना आंतरिक लूप को देखकर। UOPs। चूंकि स्टैक-सिंक यूओपी केवल तेजी से संस्करण को नुकसान पहुंचाता है (विलंबता के बजाय फ्रंट-एंड पर अड़चन), इसे समझाने के लिए ज्यादा समय नहीं लगता है। जैसे 3 / 2.54 = 1.18।
एक अन्य कारक यह है कि 3 सी विलंबता संस्करण आंतरिक लूप को छोड़ने पर होने वाली गड़बड़ी का पता लगा सकता है जबकि महत्वपूर्ण पथ अभी भी निष्पादित कर रहा है (क्योंकि फ्रंट-एंड बैक-एंड से आगे निकल सकता है, जिससे आउट-ऑफ-ऑर्डर निष्पादन लूप चलता है- काउंटर uops), इसलिए प्रभावी गलत दंड कम है। उन फ्रंट-एंड साइकिल को खोने से बैक-एंड को पकड़ने में मदद मिलती है।
यदि यह उस के लिए नहीं था, तो हम शायद cmc
carry_out -> edx और esp offsets की शाखा रहित हैंडलिंग के बजाय बाहरी लूप में एक शाखा का उपयोग करके 3c संस्करण को गति दे सकते हैं । एक डेटा निर्भरता के बजाय एक नियंत्रण निर्भरता के लिए शाखा-भविष्यवाणी + सट्टा निष्पादन, अगले पुनरावृत्ति को adc
लूप चलाना शुरू कर सकता है, जबकि पिछले आंतरिक लूप से उफ़ अभी भी उड़ान में थे। शाखा रहित संस्करण में, आंतरिक लूप में लोड पतों में adc
पिछले अंग के आखिरी से CF पर डेटा निर्भरता होती है ।
फ्रंट-एंड पर 2 सी लेटेंसी इनर-लूप वर्जन की अड़चनें हैं, इसलिए बैक-एंड काफ़ी ऊपर रहता है। यदि बाहरी-लूप कोड उच्च-विलंबता था, तो फ्रंट-एंड आंतरिक लूप के अगले पुनरावृत्ति से उफ़ जारी करने से आगे निकल सकता है। (लेकिन इस मामले में बाहरी-लूप सामान में ILP और कोई उच्च-विलंबता सामान नहीं है, इसलिए बैक-एंड में कैच-अप शेड्यूलर में यूओपीएस के माध्यम से चबाने शुरू करने के लिए बहुत पकड़ नहीं है उनके इनपुट तैयार हो जाते हैं)।
### Output from a profiled run
$ asm-link -m32 fibonacci-1G.asm && (size fibonacci-1G; echo disas fibonacci-1G) && ocperf.py stat -etask-clock,context-switches:u,cpu-migrations:u,page-faults:u,cycles,instructions,uops_issued.any,uops_executed.thread,uops_executed.stall_cycles -r4 ./fibonacci-1G
+ yasm -felf32 -Worphan-labels -gdwarf2 fibonacci-1G.asm
+ ld -melf_i386 -o fibonacci-1G fibonacci-1G.o
text data bss dec hex filename
106 0 0 106 6a fibonacci-1G
disas fibonacci-1G
perf stat -etask-clock,context-switches:u,cpu-migrations:u,page-faults:u,cycles,instructions,cpu/event=0xe,umask=0x1,name=uops_issued_any/,cpu/event=0xb1,umask=0x1,name=uops_executed_thread/,cpu/event=0xb1,umask=0x1,inv=1,cmask=1,name=uops_executed_stall_cycles/ -r4 ./fibonacci-1G
79523178745546834678293851961971481892555421852343989134530399373432466861825193700509996261365567793324820357232224512262917144562756482594995306121113012554998796395160534597890187005674399468448430345998024199240437534019501148301072342650378414269803983873607842842319964573407827842007677609077777031831857446565362535115028517159633510239906992325954713226703655064824359665868860486271597169163514487885274274355081139091679639073803982428480339801102763705442642850327443647811984518254621305295296333398134831057713701281118511282471363114142083189838025269079177870948022177508596851163638833748474280367371478820799566888075091583722494514375193201625820020005307983098872612570282019075093705542329311070849768547158335856239104506794491200115647629256491445095319046849844170025120865040207790125013561778741996050855583171909053951344689194433130268248133632341904943755992625530254665288381226394336004838495350706477119867692795685487968552076848977417717843758594964253843558791057997424878788358402439890396,�X\�;3�I;ro~.�'��R!q��%��X'B �� 8w��▒Ǫ�
... repeated 3 more times, for the 3 more runs we're averaging over
Note the trailing garbage after the trailing digits.
Performance counter stats for './fibonacci-1G' (4 runs):
73438.538349 task-clock:u (msec) # 1.000 CPUs utilized ( +- 0.05% )
0 context-switches:u # 0.000 K/sec
0 cpu-migrations:u # 0.000 K/sec
2 page-faults:u # 0.000 K/sec ( +- 11.55% )
322,467,902,120 cycles:u # 4.391 GHz ( +- 0.05% )
924,000,029,608 instructions:u # 2.87 insn per cycle ( +- 0.00% )
1,191,553,612,474 uops_issued_any:u # 16225.181 M/sec ( +- 0.00% )
1,173,953,974,712 uops_executed_thread:u # 15985.530 M/sec ( +- 0.00% )
6,011,337,533 uops_executed_stall_cycles:u # 81.855 M/sec ( +- 1.27% )
73.436831004 seconds time elapsed ( +- 0.05% )
( +- x %)
उस गणना के लिए 4 रनों से अधिक का मानक-विचलन है। दिलचस्प है कि यह ऐसे दौर में कई निर्देश चलाता है। यह 924 बिलियन कोई संयोग नहीं है। मुझे लगता है कि बाहरी लूप कुल 924 निर्देश चलाता है।
uops_issued
एक फ़्यूज़-डोमेन काउंट (फ्रंट-एंड इश्यू बैंडविड्थ के लिए प्रासंगिक) है, जबकि uops_executed
एक अप्रयुक्त-डोमेन काउंट (निष्पादन बंदरगाहों को भेजे गए उफ़ की संख्या) है। माइक्रो-फ्यूजन 2 अप्रयुक्त-डोमेन यूपीएस को एक फ्यूज्ड-डोमेन यूओपी में पैक करता है, लेकिन मूव -एलिमिनेशन का मतलब है कि कुछ फ्यूज्ड-डोमेन यूओपी को किसी निष्पादन पोर्ट की आवश्यकता नहीं है। यूओपी और फ्यूज्ड बनाम अप्रयुक्त डोमेन की गिनती के बारे में अधिक के लिए जुड़ा हुआ प्रश्न देखें। ( एगॉन फॉग के इंस्ट्रक्शन टेबल और उर्क गाइड और एसओ x86 टैग विकी में अन्य उपयोगी लिंक भी देखें )।
एक और रन से अलग-अलग चीजों को मापना: L1D कैश मिस पूरी तरह से महत्वहीन हैं, जैसा कि एक ही दो 456B बफ़र्स को पढ़ने / लिखने के लिए अपेक्षित है। आंतरिक लूप शाखा एक बार बाहरी लूप (जब यह लूप को छोड़ने के लिए नहीं ली जाती है) के अनुसार गलत हो जाती है। (कुल समय अधिक है क्योंकि कंप्यूटर पूरी तरह से निष्क्रिय नहीं था। संभवत: अन्य तार्किक कोर कुछ समय में सक्रिय था, और अधिक समय व्यवधान में खर्च किया गया था (चूंकि उपयोगकर्ता-अंतरिक्ष-मापा आवृत्ति 4.400GHz से नीचे थी)। या कई कोर अधिक समय से सक्रिय थे, अधिकतम टर्बो को कम करना। मैंने यह cpu_clk_unhalted.one_thread_active
देखने के लिए ट्रैक नहीं किया कि क्या एचटी प्रतियोगिता एक मुद्दा था।)
### Another run of the same 105/106B "main" version to check other perf counters
74510.119941 task-clock:u (msec) # 1.000 CPUs utilized
0 context-switches:u # 0.000 K/sec
0 cpu-migrations:u # 0.000 K/sec
2 page-faults:u # 0.000 K/sec
324,455,912,026 cycles:u # 4.355 GHz
924,000,036,632 instructions:u # 2.85 insn per cycle
228,005,015,542 L1-dcache-loads:u # 3069.535 M/sec
277,081 L1-dcache-load-misses:u # 0.00% of all L1-dcache hits
0 ld_blocks_partial_address_alias:u # 0.000 K/sec
115,000,030,234 branches:u # 1543.415 M/sec
1,000,017,804 branch-misses:u # 0.87% of all branches
मेरा कोड अच्छी तरह से राइज़ेन पर कम चक्रों में चल सकता है, जो प्रति चक्र 5 यूओपी जारी कर सकता है (या 6 जब उनमें से कुछ 2-यूओपी निर्देश हैं, जैसे एवाईएक्स 256 बी सामान राइजेन पर)। मुझे यकीन नहीं है कि इसके फ्रंट-एंड के साथ क्या होगा stosd
, जो कि राइजन (इंटेल के समान) पर 3 यूओपी है। मुझे लगता है कि इनर लूप के अन्य निर्देश स्काइलेक और सभी सिंगल-यूओपी के समान हैं। (सहित adc eax, [edi+edx]
, जो स्काईलेक पर एक फायदा है)।
यह संभवतः काफी छोटा हो सकता है, लेकिन शायद 9x धीमा, अगर मैंने संख्याओं को 1 दशमलव अंक प्रति बाइट के रूप में संग्रहीत किया । साथ ले जाने cmp
और समायोजित करने cmov
का कार्य समान होगा, लेकिन काम 1/9 वां करें। बाइट प्रति 2 दशमलव अंकों (आधार-100, एक साथ नहीं 4 बिट बीसीडी धीमी गति सेDAA
) होगा भी काम करते हैं, और div r8
/ add ax, 0x3030
एक 0-99 बाइट मुद्रण क्रम में दो ASCII अंक में बदल जाता है। लेकिन 1 अंक प्रति बाइट की आवश्यकता नहीं है div
, बस लूपिंग और 0x30 जोड़ना है। अगर मैं बाइट्स को प्रिंटिंग ऑर्डर में स्टोर करता हूं, तो यह 2 लूप को वास्तव में सरल बना देगा।
64-बिट पूर्णांक (64-बिट मोड में) में 18 या 19 दशमलव अंकों का उपयोग करने से यह लगभग दो बार तेजी से चलेगा, लेकिन सभी REX उपसर्गों के लिए और 64-बिट स्थिरांक के लिए महत्वपूर्ण कोड-आकार का खर्च होगा। 64-बिट मोड में 32-बिट अंग pop eax
इसके बजाय का उपयोग करने से रोकता है lodsd
। मैं अभी भी उपयोग करके REX उपसर्गों से बच सकते हैं esp
एक गैर सूचक खरोंच रजिस्टर के रूप में (के उपयोग की अदला-बदली esi
और esp
), के बजाय का उपयोग कर r8d
एक 8 वीं रजिस्टर के रूप में।
यदि कॉल करने योग्य-फ़ंक्शन संस्करण बनाते हैं, तो 64-बिट में कनवर्ट करना और r8d
सहेजना / पुनर्स्थापित करने की तुलना में सस्ता हो सकता है rsp
। 64-बिट भी एक-बाइट dec r32
एन्कोडिंग का उपयोग नहीं कर सकता (क्योंकि यह एक REX उपसर्ग है)। लेकिन ज्यादातर मैंने dec bl
2 बाइट्स का उपयोग करके समाप्त किया । (क्योंकि मेरे पास ऊपरी बाइट्स में एक स्थिरांक है ebx
, और केवल आंतरिक छोरों के बाहर इसका उपयोग करते हैं, जो काम करता है क्योंकि स्थिर की कम बाइट है 0x00
।)
उच्च प्रदर्शन संस्करण
अधिकतम प्रदर्शन (कोड-गोल्फ नहीं) के लिए, आप आंतरिक लूप को अनियंत्रित करना चाहते हैं, इसलिए यह अधिकतम 22 पुनरावृत्तियों पर चलता है, जो कि शाखा-भविष्यवाणियों के लिए अच्छा प्रदर्शन करने के लिए पर्याप्त रूप से लिया गया / नहीं लिया गया पैटर्न है। मेरे प्रयोगों में, mov cl, 22
इससे पहले कि एक .inner: dec cl/jnz .inner
लूप में बहुत कम गलतफहमी हो (जैसे 0.05%, इनर लूप के प्रति पूर्ण भाग से कम), लेकिन mov cl,23
गलत लूप 0.35 से 0.6 गुना प्रति इनर लूप है। 46
विशेष रूप से बुरा है, गलत तरीके से ~ 1.28 गुना प्रति इनर-लूप (100M बाहरी-लूप पुनरावृत्तियों के लिए 128M बार)। 114
गलत तरीके से एक बार आंतरिक लूप के अनुसार, जैसा कि मैंने फाइबोनैचि लूप के हिस्से के रूप में पाया था।
मैं उत्सुक हो गया और इसे आज़माया, आंतरिक लूप को 6 के साथ एक %rep 6
(क्योंकि यह 114 समान रूप से विभाजित करता है) को नियंत्रित करता है। कि ज्यादातर शाखा-मिसेस को समाप्त कर दिया। मैंने edx
नकारात्मक बनाया और इसे mov
स्टोर के लिए एक ऑफसेट के रूप में इस्तेमाल किया , ताकि adc eax,[edi]
माइक्रो-फ्यूज्ड रह सके। (और इसलिए मैं बच सकता था stosd
)। मैं खींच लिया lea
अद्यतन करने के लिए edi
से बाहर %rep
ब्लॉक, तो यह केवल 6 दुकानों प्रति एक सूचक अद्यतन करता है।
मुझे बाहरी लूप में सभी आंशिक-रजिस्टर सामान से भी छुटकारा मिला, हालांकि मुझे नहीं लगता कि यह महत्वपूर्ण था। यह बाहरी एडी के अंतिम एडीसी पर निर्भर नहीं होने के कारण सीएफ के लिए थोड़ा मदद कर सकता है, इसलिए कुछ इनर-लूप की शुरुआत हो सकती है। बाहरी लूप कोड को शायद थोड़ा और अधिक अनुकूलित किया जा सकता है, क्योंकि neg edx
मैंने जो आखिरी काम किया था, xchg
सिर्फ 2 mov
निर्देशों के साथ बदलने के बाद (क्योंकि मेरे पास पहले से ही 1 था), और 8-बिट को छोड़ने के साथ डिप चेन को फिर से व्यवस्थित करना। सामान रजिस्टर करें।
यह सिर्फ फाइबोनैचि लूप का NASM स्रोत है। यह मूल संस्करण के उस भाग के लिए एक ड्रॉप-इन प्रतिस्थापन है।
;;;; Main loop, optimized for performance, not code-size
%assign unrollfac 6
mov bl, limbcount/unrollfac ; and at the end of the outer loop
align 32
.fibonacci:
limbcount equ 114 ; 112 = 1006 decimal digits / 9 digits per limb. Not enough for 1000 correct digits, but 114 is.
; 113 would be enough, but we depend on limbcount being even to avoid a sub
; align 8
.digits_add:
%assign i 0
%rep unrollfac
;lodsd ; Skylake: 2 uops. Or pop rax with rsp instead of rsi
; mov eax, [esp]
; lea esp, [esp+4] ; adjust ESP without affecting CF. Alternative, load relative to edi and negate an offset? Or add esp,4 after adc before cmp
pop eax
adc eax, [edi+i*4] ; read from a potentially-offset location (but still store to the front)
;; jz .out ;; Nope, a zero digit in the result doesn't mean the end! (Although it might in base 10**9 for this problem)
lea esi, [eax - 1000000000]
cmp ebp, eax ; sets CF when (base-1) < eax. i.e. when eax>=base
cmovc eax, esi ; eax %= base, keeping it in the [0..base) range
%if 0
stosd
%else
mov [edi+i*4+edx], eax
%endif
%assign i i+1
%endrep
lea edi, [edi+4*unrollfac]
dec bl ; preserves CF. The resulting partial-flag merge on ADC would be slow on pre-SnB CPUs
jnz .digits_add
; bl=0, ebx=-1024
; esi has its high bit set opposite to CF
.end_innerloop:
;; after a non-zero carry-out (CF=1): right-shift both buffers by 1 limb, over the course of the next two iterations
;; next iteration with r8 = 1 and rsi+=4: read offset from both, write normal. ends with CF=0
;; following iter with r8 = 1 and rsi+=0: read offset from dest, write normal. ends with CF=0
;; following iter with r8 = 0 and rsi+=0: i.e. back to normal, until next carry-out (possible a few iters later)
;; rdi = bufX + 4*limbcount
;; rsi = bufY + 4*limbcount + 4*carry_last_time
; setc [rdi]
; mov dl, dh ; edx=0. 2c latency on SKL, but DH has been ready for a long time
; adc edx,edx ; edx = CF. 1B shorter than setc dl, but requires edx=0 to start
setc al
movzx edx, al
mov [edi], edx ; store the carry-out into an extra limb beyond limbcount
shl edx, 2
;; Branching to handle the truncation would break the data-dependency (of pointers) on carry-out from this iteration
;; and let the next iteration start, but we bottleneck on the front-end (9 uops)
;; not the loop-carried dependency of the inner loop (2 cycles for adc->cmp -> flag input of adc next iter)
;; Since the pattern isn't perfectly regular, branch mispredicts would hurt us
; keep -1024 in ebx. Using bl for the limb counter leaves bl zero here, so it's back to -1024 (or -2048 or whatever)
mov eax, esp
and esp, 4 ; only works if limbcount is even, otherwise we'd need to subtract limbcount first.
and edi, ebx ; -1024 ; revert to start of buffer, regardless of offset
add edi, edx ; read offset in next iter's src
;; maybe or edi,edx / and edi, 4 | -1024? Still 2 uops for the same work
;; setc dil?
;; after adjusting src, so this only affects read-offset in the dst, not src.
or edx, esp ; also set r8d if we had a source offset last time, to handle the 2nd buffer
mov esp, edi
; xchg edi, esp ; Fibonacci: dst and src swap
and eax, ebx ; -1024
;; mov edi, eax
;; add edi, edx
lea edi, [eax+edx]
neg edx ; negated read-write offset used with store instead of load, so adc can micro-fuse
mov bl, limbcount/unrollfac
;; Last instruction must leave CF clear for next iter
; loop .fibonacci ; Maybe 0.01% slower than dec/jnz overall
; dec ecx
sub ecx, 1 ; clear any flag dependencies. No faster than dec, at least when CF doesn't depend on edx
jnz .fibonacci
प्रदर्शन:
Performance counter stats for './fibonacci-1G-performance' (3 runs):
62280.632258 task-clock (msec) # 1.000 CPUs utilized ( +- 0.07% )
0 context-switches:u # 0.000 K/sec
0 cpu-migrations:u # 0.000 K/sec
3 page-faults:u # 0.000 K/sec ( +- 12.50% )
273,146,159,432 cycles # 4.386 GHz ( +- 0.07% )
757,088,570,818 instructions # 2.77 insn per cycle ( +- 0.00% )
740,135,435,806 uops_issued_any # 11883.878 M/sec ( +- 0.00% )
966,140,990,513 uops_executed_thread # 15512.704 M/sec ( +- 0.00% )
75,953,944,528 resource_stalls_any # 1219.544 M/sec ( +- 0.23% )
741,572,966 idq_uops_not_delivered_core # 11.907 M/sec ( +- 54.22% )
62.279833889 seconds time elapsed ( +- 0.07% )
यह उसी Fib (1G) के लिए है, जो 73 सेकंड के बजाय 62.3 सेकंड में समान आउटपुट का उत्पादन करता है। (273.146G चक्र, बनाम 322.467G। चूंकि L1 कैश में सब कुछ हिट है, कोर घड़ी चक्र वास्तव में हम सभी को देखने की जरूरत है।)
बहुत कम कुल uops_issued
गिनती पर ध्यान दें, गिनती के नीचे अच्छी तरह से uops_executed
। इसका मतलब है कि उनमें से कई माइक्रो-फ़्यूज़ किए गए थे: फ़्यूज़्ड डोमेन (इश्यू / आरओबी) में 1 यूओपी, लेकिन अप्रयुक्त डोमेन (शेड्यूलर / एक्ज़ीक्यूटिव यूनिट्स) में 2 यूओपी। और उस मुद्दे / नाम बदलने की अवस्था में कुछ को समाप्त कर दिया गया था (जैसे mov
रजिस्टर की नकल, या xor
-रोजिंग, जिसे जारी करने की आवश्यकता है लेकिन निष्पादन इकाई की आवश्यकता नहीं है)। हटाए गए यूओपी दूसरे तरीके से गिनती को असंतुलित कर देंगे।
branch-misses
1G से ~ 400k तक नीचे है, इसलिए अनियंत्रित होकर काम किया। resource_stalls.any
अब महत्वपूर्ण है, जिसका अर्थ है कि फ्रंट-एंड अब अड़चन नहीं है: इसके बजाय बैक-एंड पीछे हो रहा है और फ्रंट-एंड को सीमित कर रहा है। idq_uops_not_delivered.core
केवल उन चक्रों को गिना जाता है जहाँ सामने का छोर ऊप्स डिलीवर नहीं करता था, लेकिन बैक-एंड स्टाल नहीं था । यह अच्छा है और कम है, कुछ सामने वाले बाधाओं का संकेत है।
मजेदार तथ्य: अजगर संस्करण अपने आधे से अधिक समय को जोड़ने के बजाय 10 से विभाजित करता है। ( 2 के एक कारक से अधिक इसे गति के a/=10
साथ प्रतिस्थापित करना a>>=64
, लेकिन परिणाम बदल देता है क्योंकि द्विआधारी ट्रंकेशन! = दशमलव ट्रंकेशन।)
मेरे asm संस्करण निश्चित रूप से इस समस्या के आकार के लिए विशेष रूप से अनुकूलित है, लूप पुनरावृत्ति-के साथ हार्ड कोडित है। यहां तक कि एक मनमानी-सटीक संख्या को शिफ्ट करने से यह कॉपी हो जाएगा, लेकिन मेरा संस्करण सिर्फ अगले दो पुनरावृत्तियों के लिए एक ऑफसेट से पढ़ सकता है ताकि इसे छोड़ सकें।
मैंने अजगर संस्करण (आर्क लिनक्स पर 64-बिट python2.7) को संकलित किया:
ocperf.py stat -etask-clock,context-switches:u,cpu-migrations:u,page-faults:u,cycles,instructions,uops_issued.any,uops_executed.thread,arith.divider_active,branches,branch-misses,L1-dcache-loads,L1-dcache-load-misses python2.7 ./fibonacci-1G.anders-brute-force.py
795231787455468346782938519619714818925554218523439891345303993734324668618251937005099962613655677933248203572322245122629171445627564825949953061211130125549987963951605345978901870056743994684484303459980241992404375340195011483010723426503784142698039838736078428423199645734078278420076776090777770318318574465653625351150285171596335102399069923259547132267036550648243596658688604862715971691635144878852742743550811390916796390738039824284803398011027637054426428503274436478119845182546213052952963333981348310577137012811185112824713631141420831898380252690791778709480221775085968511636388337484742803673714788207995668880750915837224945143751932016258200200053079830988726125702820190750937055423293110708497685471583358562391045067944912001156476292564914450953190468498441700251208650402077901250135617787419960508555831719090539513446891944331302682481336323419049437559926255302546652883812263943360048384953507064771198676927956854879685520768489774177178437585949642538435587910579974100118580
Performance counter stats for 'python2.7 ./fibonacci-1G.anders-brute-force.py':
755380.697069 task-clock:u (msec) # 1.000 CPUs utilized
0 context-switches:u # 0.000 K/sec
0 cpu-migrations:u # 0.000 K/sec
793 page-faults:u # 0.001 K/sec
3,314,554,673,632 cycles:u # 4.388 GHz (55.56%)
4,850,161,993,949 instructions:u # 1.46 insn per cycle (66.67%)
6,741,894,323,711 uops_issued_any:u # 8925.161 M/sec (66.67%)
7,052,005,073,018 uops_executed_thread:u # 9335.697 M/sec (66.67%)
425,094,740,110 arith_divider_active:u # 562.756 M/sec (66.67%)
807,102,521,665 branches:u # 1068.471 M/sec (66.67%)
4,460,765,466 branch-misses:u # 0.55% of all branches (44.44%)
1,317,454,116,902 L1-dcache-loads:u # 1744.093 M/sec (44.44%)
36,822,513 L1-dcache-load-misses:u # 0.00% of all L1-dcache hits (44.44%)
755.355560032 seconds time elapsed
(परेंस) संख्या में कितने समय के लिए पूर्ण काउंटर का नमूना लिया जा रहा था। जब एचडब्ल्यू समर्थन से अधिक काउंटरों को देखता है, तो विभिन्न काउंटरों और एक्सट्रपलेट्स के बीच परफैक्ट घूमता है। एक ही कार्य के लंबे समय के लिए यह पूरी तरह से ठीक है।
यदि मैं perf
sysctl kernel.perf_event_paranoid = 0
(या perf
रूट के रूप में चल रहा है) सेट करने के बाद भाग गया , तो यह मापेगा 4.400GHz
। cycles:u
इंटरप्ट (या सिस्टम कॉल) में बिताए समय की गणना नहीं करता है, केवल उपयोगकर्ता-अंतरिक्ष चक्र। मेरा डेस्कटॉप लगभग पूरी तरह से निष्क्रिय था, लेकिन यह विशिष्ट है।
Your program must be fast enough for you to run it and verify its correctness.
स्मृति के बारे में क्या?