टेस्ट, रिपोर्ट और बाकी साइट फ़िलहाल अंग्रेज़ी में हैं।
डेवलपर के लिए
बिल्ड धीमा है। कोड की वजह से या कूलिंग की?
कंपाइल और टेस्ट सूट मिनटों तक हर कोर को लोड करते हैं और मेमोरी लेटेंसी की सज़ा देते हैं। SystemCheck दोनों को दोहराने लायक तरीके से मापता है, ताकि धीमे बिल्ड का दोष सही चीज़ पर जाए।
रिपोर्ट आपको क्या बताती है
तीन आँकड़े, हर एक अपनी व्याख्या के साथ।
सस्टेन्ड ऑल-कोर
ops/s
हर लॉजिकल कोर पर एक वर्कर, पूरे रन की अवधि तक। यही आँकड़ा पैरलल बिल्ड देखता है, डिब्बे पर लिखा सिंगल-कोर बूस्ट नहीं।
मेमोरी लेटेंसी
ns
मेमोरी और कैश तक का राउंड ट्रिप। लिंकर, पैकेज मैनेजर और हर पॉइंटर-भारी चीज़ इसी गति से चलती है।
रिपीटेबिलिटी
%
CPU स्टेज दो बार चलाएँ और रिपोर्ट स्प्रेड बताती है। स्प्रेड के भीतर का बदलाव बदलाव नहीं है, बिल्ड टाइमर चाहे जो कहे।
निदान
कर्व का आकार, आपके मामले के हिसाब से पढ़ा गया।
01होल्ड
मशीन समस्या नहीं है। बिल्ड ग्राफ़, कैश और यह देखें कि और क्या चल रहा है।
02एक बार का स्टेप डाउन
पावर लिमिट, ज़्यादातर लैपटॉप पर सस्टेन्ड वॉटेज। लंबे बिल्ड स्टेप के बाद वाले लेवल पर चलते हैं, पहले वाले पर नहीं।
03अनियमित
कोई और चीज़ कोर पर है। एक इंडेक्सर, एक सिंक क्लाइंट, एक कंटेनर जो कभी खाली नहीं बैठता। रिपोर्ट का कोर-शेयर आँकड़ा स्टार्वेशन को तब नाम देता है जब वह उसे देख पाता है।
हर वर्ग के साथ एक बताया गया कॉन्फ़िडेंस और माप का अपना नॉइज़ फ़्लोर आता है। आकार कैसे पढ़ा जाता है
ब्राउज़र कहाँ रुक जाता है
जो यह आपको नहीं बता सकता।
- हर कोर की क्लॉक नहीं: ब्राउज़र थ्रूपुट देखता है, फ़्रीक्वेंसी नहीं। कर्व क्लॉक बदलने का असर दिखाता है, मेगाहर्ट्ज़ बताए बिना।
- एक रन के भीतर कंटेंशन की पहचान नहीं: जो प्रोग्राम चुपचाप कोर साझा करता है, वह धीमी मशीन से अलग नहीं दिखता। उसके लिए पहले/बाद की तुलना ही औज़ार है।
- कोर की संख्या वैसी जैसी बताई गई: Firefox उसे सीमित करता है, Safari उसे आठ पर सीमित करता है, और रिपोर्ट बताती है कि उसने कौन सी संख्या इस्तेमाल की।
कौन सा रन
स्टैंडर्ड, 3 मिनट।
दोहराने लायक बेसलाइन के लिए स्टैंडर्ड रन, बार-बार चलाकर, जल्दी स्प्रेड देता है। लैपटॉप पर सेटल्ड लेवल खोजने के लिए डीप रन एक बार चलाएँ।
दोनों तरह के रन मुफ़्त हैं। चुनाव सेट-अप स्क्रीन पर होता है।
सवाल
इन्हीं शब्दों में पूछे गए।
- मेरा बिल्ड बेंचमार्क के अनुमान से धीमा क्यों है?
- बिल्ड का समय सस्टेन्ड ऑल-कोर थ्रूपुट और मेमोरी लेटेंसी पर निर्भर करता है, उस सिंगल-कोर बूस्ट पर नहीं जिसे ज़्यादातर बेंचमार्क हेडलाइन बनाते हैं। टेस्ट दोनों बताता है, और कर्व दिखाता है कि मशीन बिल्ड की अवधि तक अपना ऑल-कोर लेवल बनाए रखती है या बूस्ट विंडो के बाद स्टेप डाउन करती है।
- क्या मैं इससे दो मशीनों की तुलना कर सकता हूँ?
- हाँ, मापे गए आँकड़ों पर: सस्टेन्ड थ्रूपुट, डिके, मेमोरी बैंडविड्थ और लेटेंसी, फ़्रेम टाइम। हर मशीन को दो बार चलाएँ ताकि रिपोर्ट स्प्रेड बता सके; स्प्रेड के भीतर का अंतर नॉइज़ है।
- क्या Docker या VM नतीजे पर असर डालता है?
- रन के दौरान कोर इस्तेमाल करने वाली कोई भी चीज़ थ्रूपुट घटाती है और नॉइज़ बढ़ाती है, और रिपोर्ट स्टार्व्ड वर्कर को तब फ़्लैग करती है जब वह उन्हें देख पाती है। बेसलाइन से पहले जो बंद कर सकते हैं करें, फिर सामान्य लोड के साथ दोबारा चलाकर उसकी कीमत मापें।