<p>जंग स्कैन इटरेटर में क्लोजर को अनुकूलित नहीं करता है</p>

को निर्मित 20 दिस॰ 2013 · 28टिप्पणियाँ · स्रोत: rust-lang/rust

सुसंध्या। मैं एक छूटे हुए अनुकूलन में भाग गया, मैं std::result::collect को FromIteratator का उपयोग करने में परिवर्तित करने का प्रयास कर रहा था। मेरे प्रारंभिक संस्करण में iter::Scan , लेकिन यह मूल कार्यान्वयन की तुलना में --opt-level=3 तुलना में 2 गुना धीमा साबित हुआ। मैंने एक कस्टम इटरेटर भी बनाया है जिसमें बंद नहीं है, और यह मूल std::result::collect के समान गति से संकलित होता है। मुझे लगता है कि llvm किसी कारण से इनलाइन बंद करने में सक्षम नहीं है।

मैंने इस परीक्षण को एक सार के रूप में Scan1::size_hint() std::iter::Scan::size_hint() पद्धति से भिन्न है।

cc @thestinger

C-enhancement I-slow P-low

स्रोत

erickt

सबसे उपयोगी टिप्पणी

ठीक है, मुझे लगता है कि मैं देख रहा हूं कि यहां क्या हुआ, कम से कम प्रक्रियात्मक रूप से। (मेरे पास अभी तक मेरे द्वारा देखे जा रहे प्रदर्शन अंतर के लिए कोई स्पष्टीकरण नहीं है, लेकिन मैं पहले अपने द्वारा किए गए अवलोकनों के विवरण का दस्तावेजीकरण करना चाहता हूं, क्योंकि ऐतिहासिक प्रक्षेपवक्र दिलचस्प है।)

सबसे पहले, यहाँ मैंने क्या किया ( details ब्लॉक में):

मैंने डॉटडैश-बेंचमार्क लिया, और मैंने bench_from_iter_with_scan दो संस्करण बनाए: एक जो @dotdash के पास था वह है bench_from_iter_with_scan_passing_state , और मैंने एक वैरिएंट बनाया जो क्लोजर में एक फ्री-वेरिएबल का उपयोग करता है और पैरामीटर के लिए बस () करता है (सिर्फ इसलिए कि मैं देखना चाहता था कि क्या यह कभी मायने रखता है)। मैंने अपने परिणामों में कोई महत्वपूर्ण अंतर नहीं देखा, इसलिए मुझे नहीं लगता कि मुक्त-चर बनाम स्पष्ट-पैरामीटर शैली मायने रखती है।
यहाँ स्रोत कोड है जिसका मैंने उपयोग किया है: https://gist.github.com/pnkfelix/7cb66d32c3cd9e1f2ea1a61ef15a0a3a
मैंने प्रत्येक स्थिर कंपाइलर संस्करण पर 1.13 से 1.33 तक डॉटडैश-बेंचमार्क चलाया ( #![feature(test)] प्रतिबंध के आसपास पाने के लिए RUSTC_BOOTSTRAP=1 का उपयोग करके)।
मैंने इस शेल आमंत्रण के माध्यम से प्रत्येक बेंचमार्क निष्पादन योग्य पांच बार चलाया:

% for VERSION in 1.{13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33}.0 ; do (\
  echo $VERSION && rustup update $VERSION && rustc +$VERSION --version && \
  RUSTC_BOOTSTRAP=1 rustc +$VERSION -C opt-level=3  --test main-bench.rs && \
   ./main-bench --bench && ./main-bench --bench && ./main-bench --bench && ./main-bench --bench && ./main-bench --bench \
) ; done | tee version-bench.txt

पूरा लॉग इस सार पर है: https://gist.github.com/2db1e313af68ad6936a3da28c0c272f5
मैंने स्प्रैडशीट में संख्याओं का औसत निकाला (हो सकता है कि मुझे औसत के बजाय न्यूनतम लेना चाहिए था, लेकिन डेटा को स्किम करने से मुझे नहीं लगता कि यह मायने रखता है), और अंतर्निहित स्पष्ट-एडेप्टर की तुलना में भिन्न कार्यान्वयन के प्रदर्शन को देखा आधारित एक।
जबकि मैंने अपने विश्लेषण के लिए औसत लिया, नीचे दिए गए पाठ में मैंने केवल उस सार से प्रतिनिधि आउटपुट को पकड़ा जो मेरे द्वारा देखे गए औसत के समान है।

अवलोकन ( details ब्लॉक में):

मैं निश्चित रूप से देखता हूं कि 1.13 में प्रदर्शन स्पष्ट-एडाप्टर (यानी पुराना कार्यान्वयन) के लिए scan -आधारित कार्यान्वयन के लिए समान था (और filter_map लिए थोड़ा धीमा) . यह 2016 से @pmarcelll के निष्कर्षों का समर्थन करता है। यहां 1.33 (मेरे लिनक्स डेस्कटॉप पर) से एक नमूना चलाया गया है:

rustc 1.13.0 (2c6933acc 2016-11-07)

running 4 tests
test bench_from_iter                         ... bench:       1,691 ns/iter (+/- 9)
test bench_from_iter_with_filter_map         ... bench:       1,930 ns/iter (+/- 230)
test bench_from_iter_with_scan_passing_state ... bench:       1,682 ns/iter (+/- 10)
test bench_from_iter_with_scan_with_freevar  ... bench:       1,686 ns/iter (+/- 55)

1.14 और 1.15 के बीच, filter_map -आधारित कार्यान्वयन के सापेक्ष प्रदर्शन में गिरावट आई, लेकिन scan -आधारित कार्यान्वयन का सापेक्ष-प्रदर्शन प्रतिस्पर्धी बना रहा।
1.18 और 1.19 के बीच, स्पष्ट-एडेप्टर ( bench_from_iter ) और scan -आधारित कार्यान्वयन थोड़ा तेज हो गए। इसलिए scan -आधारित कार्यान्वयन का सापेक्ष प्रदर्शन अभी भी प्रतिस्पर्धी बना हुआ है।
लेकिन फिर 1.19 और 1.20 के बीच स्पष्ट-एडाप्टर बहुत पीछे चला गया, जिससे filter_map और scan -आधारित कार्यान्वयन अब स्पष्ट-एडाप्टर की तुलना में काफी तेज थे:

rustc 1.20.0 (f3d6973f4 2017-08-27)

running 4 tests
test bench_from_iter                         ... bench:       2,274 ns/iter (+/- 54)
test bench_from_iter_with_filter_map         ... bench:       1,793 ns/iter (+/- 14)
test bench_from_iter_with_scan_passing_state ... bench:       1,716 ns/iter (+/- 7)
test bench_from_iter_with_scan_with_freevar  ... bench:       1,716 ns/iter (+/- 26)

1.22 और 1.23 के बीच, scan -आधारित कार्यान्वयन का प्रदर्शन महत्वपूर्ण रूप से पीछे हट गया जबकि अन्य स्थिर रहे:

rustc 1.23.0 (766bd11c8 2018-01-01)

running 4 tests
test bench_from_iter                         ... bench:       2,238 ns/iter (+/- 2)
test bench_from_iter_with_filter_map         ... bench:       1,755 ns/iter (+/- 6)
test bench_from_iter_with_scan_passing_state ... bench:       3,506 ns/iter (+/- 6)
test bench_from_iter_with_scan_with_freevar  ... bench:       3,508 ns/iter (+/- 2)

फिर 1.23 और 1.24 के बीच, filter_map -आधारित कार्यान्वयन का प्रदर्शन उस बिंदु पर वापस आ गया जहां यह अब किसी भी महत्वपूर्ण डिग्री से bench_from_iter को पीछे नहीं छोड़ रहा था।

rustc 1.24.0 (4d90ac38c 2018-02-12)

running 4 tests
test bench_from_iter                         ... bench:       2,323 ns/iter (+/- 8)
test bench_from_iter_with_filter_map         ... bench:       2,535 ns/iter (+/- 4)
test bench_from_iter_with_scan_passing_state ... bench:       3,796 ns/iter (+/- 15)
test bench_from_iter_with_scan_with_freevar  ... bench:       3,792 ns/iter (+/- 11)

1.26 और 1.27 के बीच filter_map -आधारित कार्यान्वयन का प्रदर्शन फिर से वापस आ गया, काफी महत्वपूर्ण:

rustc 1.27.0 (3eda71b00 2018-06-19)

running 4 tests
test bench_from_iter                         ... bench:       2,442 ns/iter (+/- 5)
test bench_from_iter_with_filter_map         ... bench:       5,080 ns/iter (+/- 55)
test bench_from_iter_with_scan_passing_state ... bench:       3,594 ns/iter (+/- 12)
test bench_from_iter_with_scan_with_freevar  ... bench:       3,591 ns/iter (+/- 2)

तो: यह कदमों की एक श्रृंखला है जो यहां की बड़ी कहानी को मुखौटा बनाती है: ये बेंचमार्क 1.13 से नीचे गए:

rustc 1.13.0 (2c6933acc 2016-11-07)

running 4 tests
test bench_from_iter                         ... bench:       1,691 ns/iter (+/- 9)
test bench_from_iter_with_filter_map         ... bench:       1,930 ns/iter (+/- 230)
test bench_from_iter_with_scan_passing_state ... bench:       1,682 ns/iter (+/- 10)
test bench_from_iter_with_scan_with_freevar  ... bench:       1,686 ns/iter (+/- 55)

इसके लिए 1.27 के तहत:

rustc 1.27.0 (3eda71b00 2018-06-19)

running 4 tests
test bench_from_iter                         ... bench:       2,442 ns/iter (+/- 5)
test bench_from_iter_with_filter_map         ... bench:       5,080 ns/iter (+/- 55)
test bench_from_iter_with_scan_passing_state ... bench:       3,594 ns/iter (+/- 12)
test bench_from_iter_with_scan_with_freevar  ... bench:       3,591 ns/iter (+/- 2)

जो समय के साथ, किसी भी प्रकार के लिए, पूर्ण और सापेक्ष दोनों दृष्टि से एक अच्छा प्रक्षेपवक्र की तरह प्रतीत नहीं होता है।

(ध्यान दें कि गैर-शून्य मौका है कि मेरे बेंचमार्क उपकरण में कुछ अन्य भ्रमित कारक वास्तव में समय के साथ क्रमिक प्रदर्शन बदलाव के लिए जिम्मेदार हैं। मेरे पास इस पर विचार हैं लेकिन मैं यहां उन पर जाने के लिए बहुत थक गया हूं।)

pnkfelix 20 मार्च 2019

❤2

सभी 28 टिप्पणियाँ

क्या अनबॉक्स्ड क्लोजर इसे ठीक करते हैं?

SimonSapin 5 जन॰ 2015

क्या अनबॉक्स्ड क्लोजर इसे ठीक करते हैं?

पूरी तरह से नहीं, ऐसा लगता है। मैंने प्रदान किए गए मूल परीक्षणों को फिर से लिखा ।

मानक पुस्तकालय में कार्यान्वयन एडेप्टर इटरेटर का उपयोग करता है, इसलिए मैंने इसकी तुलना केवल scan का उपयोग करने वाले संस्करण से की। मैंने filter_map साथ एक भी जोड़ा, बस यह देखने के लिए कि यह कैसे चलेगा। मुझे उम्मीद नहीं थी कि वे अलग होंगे, लेकिन:

running 3 tests
test bench_from_iter                 ... bench:       6,991 ns/iter (+/- 941)
test bench_from_iter_with_filter_map ... bench:       8,324 ns/iter (+/- 1,320)
test bench_from_iter_with_scan       ... bench:       7,299 ns/iter (+/- 1,172)

तो ऐसा लगता है कि एडेप्टर इटरेटर अभी भी सबसे अधिक प्रदर्शन करने वाला है।

shepmaster 4 दिस॰ 2015

@shepmaster बेंचमार्क अपडेट करने के लिए धन्यवाद! दुर्भाग्य से वे मुख्य रूप से v स्रोत वैक्टर बनाने में लगने वाले समय को मापते हैं। परिणाम अत्यधिक अस्थिर हैं और बेंचमार्क को कई बार फिर से चलाने से हर बार एक अलग विजेता प्राप्त होता है, क्योंकि परिणाम अंतर के लिए पर्याप्त रूप से भिन्न होते हैं।

https://gist.github.com/dotdash/5ce3f0bfa2e652ca58b5 पर बेहतर बेंचमार्क - मैंने बस वेक्टर निर्माण को लूप से बाहर कर दिया और उपयोगकर्ता iter().cloned() बजाय into_iter() । चूंकि वैक्टर i32 मानों से बने होते हैं,

परिणाम:

test bench_from_iter                 ... bench:       2,304 ns/iter (+/- 23)
test bench_from_iter_with_filter_map ... bench:       4,996 ns/iter (+/- 122)
test bench_from_iter_with_scan       ... bench:       3,071 ns/iter (+/- 33)

dotdash 4 दिस॰ 2015

वे मुख्य रूप से v स्रोत वैक्टर बनाने में लगने वाले समय को मापते हैं

हाँ, मुझे उस पर ध्यान देना चाहिए था। मैंने मूल संस्करण के अनुरूप होने के लिए इस तरह छोड़ दिया, लेकिन मुझे यह भी लगा कि चूंकि प्रत्येक एक ही अधिक काम कर रहा था, इसलिए वे लगातार बाहर आएंगे। एक छोटी संख्या (~5) रनों में मेरे लिए समान विजेता थे, इसलिए मैंने इसे भेज दिया! :-)

इसे और भी बेहतर बनाने के लिए धन्यवाद!

shepmaster 4 दिस॰ 2015

रात में बेहतर बेंचमार्क के साथ परिणाम:

running 3 tests
test bench_from_iter                 ... bench:       2,158 ns/iter (+/- 24)
test bench_from_iter_with_filter_map ... bench:       2,474 ns/iter (+/- 89)
test bench_from_iter_with_scan       ... bench:       2,145 ns/iter (+/- 35)

pmarcelll 18 सित॰ 2016

इस मुद्दे से संबंधित एक FIXME है,
https://github.com/rust-lang/rust/blob/master/src/libcore/option.rs#L1092
https://github.com/rust-lang/rust/blob/master/src/libcore/result.rs#L1117
क्या यह अब हल हो गया है? यदि हां, तो क्या FIXME को ठीक किया जा सकता है, या अधिक विशिष्ट बनाया जा सकता है?

Eh2406 6 सित॰ 2017

इस मुद्दे को बंद किया जा सकता है, क्योंकि scan प्रदर्शन समस्या शून्य है।

हालांकि, चूंकि Scan अब state को उजागर नहीं करता है, ये FIXME s भी शून्य हैं - मुझे scan का उपयोग करके इन FromIterator कार्यान्वयन को फिर से लिखने का कोई तरीका नहीं दिखता है scan ।

ljedrz 31 जुल॰ 2018

मुझे लगता है कि मुझे scan का उपयोग करके उन्हें फिर से लिखने का एक तरीका दिखाई देता है। अगर मैं सही हूं तो मैं इसके साथ एक पीआर पोस्ट करूंगा; अगर मैं गलत हूं, तो मैं FIXME टिप्पणियों को हटाते हुए एक पीआर पोस्ट करूंगा।

एक कारण यह है कि scan का उपयोग करना मुश्किल हो सकता है कि कोई यह सोच सकता है कि बनाया जा रहा संचित मूल्य state पैरामीटर के स्वामित्व में होना चाहिए जो स्कैन के माध्यम से पिरोया गया है; लेकिन यह एक गलती होगी, क्योंकि स्कैन समाप्त होने के बाद उस state को पुनर्प्राप्त करने का कोई तरीका नहीं है, जैसा कि @ljedrz ने ऊपर उल्लेख किया है।
मैं क्या बता सकते हैं, कारण FIXME टिप्पणीकार उल्लेख scan यहाँ की वजह से पिरोया नहीं है state पैरामीटर, बल्कि इसलिए कि scan , के विपरीत जैसे fold , दिए गए iter से सभी तत्वों को लिए बिना जल्दी समाप्त हो सकता है, जो FromIterator लिए Option और Result लिए सही ढंग से लागू करने के लिए आवश्यक है।

अपडेट: पिछली टिप्पणियों को अधिक ध्यान से पढ़ते हुए, @erickt , @shepmaster और @dotdash ने सभी बेंचमार्क प्रदान किए हैं जो बताते हैं कि FromIterator लिए Result का उपयोग करके scan FromIterator को कैसे कार्यान्वित किया जाए। (और Option समान है।)

pnkfelix 20 मार्च 2019

❤1

~~(या शायद try_fold यहां scan तुलना में अधिक मुहावरेदार होगा)~~ ((नहीं जो काम नहीं करता))

pnkfelix 20 मार्च 2019

दिलचस्प बात यह है कि मेरे लिए @dotdash -provided बेंचमार्क पर 2x की मंदी

(और अब मुझे यह देखने की ज़रूरत है कि क्या मैं पिछले परिणामों को पुन: पेश कर सकता हूं जो दावा करते हैं कि कोई मंदी नहीं थी ...)

pnkfelix 20 मार्च 2019

सबसे पहले, यहाँ मैंने क्या किया ( details ब्लॉक में):

मैंने डॉटडैश-बेंचमार्क लिया, और मैंने bench_from_iter_with_scan दो संस्करण बनाए: एक जो @dotdash के पास था वह है bench_from_iter_with_scan_passing_state , और मैंने एक वैरिएंट बनाया जो क्लोजर में एक फ्री-वेरिएबल का उपयोग करता है और पैरामीटर के लिए बस () करता है (सिर्फ इसलिए कि मैं देखना चाहता था कि क्या यह कभी मायने रखता है)। मैंने अपने परिणामों में कोई महत्वपूर्ण अंतर नहीं देखा, इसलिए मुझे नहीं लगता कि मुक्त-चर बनाम स्पष्ट-पैरामीटर शैली मायने रखती है।
यहाँ स्रोत कोड है जिसका मैंने उपयोग किया है: https://gist.github.com/pnkfelix/7cb66d32c3cd9e1f2ea1a61ef15a0a3a
मैंने प्रत्येक स्थिर कंपाइलर संस्करण पर 1.13 से 1.33 तक डॉटडैश-बेंचमार्क चलाया ( #![feature(test)] प्रतिबंध के आसपास पाने के लिए RUSTC_BOOTSTRAP=1 का उपयोग करके)।
मैंने इस शेल आमंत्रण के माध्यम से प्रत्येक बेंचमार्क निष्पादन योग्य पांच बार चलाया:

% for VERSION in 1.{13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33}.0 ; do (\
  echo $VERSION && rustup update $VERSION && rustc +$VERSION --version && \
  RUSTC_BOOTSTRAP=1 rustc +$VERSION -C opt-level=3  --test main-bench.rs && \
   ./main-bench --bench && ./main-bench --bench && ./main-bench --bench && ./main-bench --bench && ./main-bench --bench \
) ; done | tee version-bench.txt

पूरा लॉग इस सार पर है: https://gist.github.com/2db1e313af68ad6936a3da28c0c272f5
मैंने स्प्रैडशीट में संख्याओं का औसत निकाला (हो सकता है कि मुझे औसत के बजाय न्यूनतम लेना चाहिए था, लेकिन डेटा को स्किम करने से मुझे नहीं लगता कि यह मायने रखता है), और अंतर्निहित स्पष्ट-एडेप्टर की तुलना में भिन्न कार्यान्वयन के प्रदर्शन को देखा आधारित एक।
जबकि मैंने अपने विश्लेषण के लिए औसत लिया, नीचे दिए गए पाठ में मैंने केवल उस सार से प्रतिनिधि आउटपुट को पकड़ा जो मेरे द्वारा देखे गए औसत के समान है।

अवलोकन ( details ब्लॉक में):

मैं निश्चित रूप से देखता हूं कि 1.13 में प्रदर्शन स्पष्ट-एडाप्टर (यानी पुराना कार्यान्वयन) के लिए scan -आधारित कार्यान्वयन के लिए समान था (और filter_map लिए थोड़ा धीमा) . यह 2016 से @pmarcelll के निष्कर्षों का समर्थन करता है। यहां 1.33 (मेरे लिनक्स डेस्कटॉप पर) से एक नमूना चलाया गया है:

rustc 1.13.0 (2c6933acc 2016-11-07)

running 4 tests
test bench_from_iter                         ... bench:       1,691 ns/iter (+/- 9)
test bench_from_iter_with_filter_map         ... bench:       1,930 ns/iter (+/- 230)
test bench_from_iter_with_scan_passing_state ... bench:       1,682 ns/iter (+/- 10)
test bench_from_iter_with_scan_with_freevar  ... bench:       1,686 ns/iter (+/- 55)

1.14 और 1.15 के बीच, filter_map -आधारित कार्यान्वयन के सापेक्ष प्रदर्शन में गिरावट आई, लेकिन scan -आधारित कार्यान्वयन का सापेक्ष-प्रदर्शन प्रतिस्पर्धी बना रहा।
1.18 और 1.19 के बीच, स्पष्ट-एडेप्टर ( bench_from_iter ) और scan -आधारित कार्यान्वयन थोड़ा तेज हो गए। इसलिए scan -आधारित कार्यान्वयन का सापेक्ष प्रदर्शन अभी भी प्रतिस्पर्धी बना हुआ है।
लेकिन फिर 1.19 और 1.20 के बीच स्पष्ट-एडाप्टर बहुत पीछे चला गया, जिससे filter_map और scan -आधारित कार्यान्वयन अब स्पष्ट-एडाप्टर की तुलना में काफी तेज थे:

rustc 1.20.0 (f3d6973f4 2017-08-27)

running 4 tests
test bench_from_iter                         ... bench:       2,274 ns/iter (+/- 54)
test bench_from_iter_with_filter_map         ... bench:       1,793 ns/iter (+/- 14)
test bench_from_iter_with_scan_passing_state ... bench:       1,716 ns/iter (+/- 7)
test bench_from_iter_with_scan_with_freevar  ... bench:       1,716 ns/iter (+/- 26)

1.22 और 1.23 के बीच, scan -आधारित कार्यान्वयन का प्रदर्शन महत्वपूर्ण रूप से पीछे हट गया जबकि अन्य स्थिर रहे:

rustc 1.23.0 (766bd11c8 2018-01-01)

running 4 tests
test bench_from_iter                         ... bench:       2,238 ns/iter (+/- 2)
test bench_from_iter_with_filter_map         ... bench:       1,755 ns/iter (+/- 6)
test bench_from_iter_with_scan_passing_state ... bench:       3,506 ns/iter (+/- 6)
test bench_from_iter_with_scan_with_freevar  ... bench:       3,508 ns/iter (+/- 2)

फिर 1.23 और 1.24 के बीच, filter_map -आधारित कार्यान्वयन का प्रदर्शन उस बिंदु पर वापस आ गया जहां यह अब किसी भी महत्वपूर्ण डिग्री से bench_from_iter को पीछे नहीं छोड़ रहा था।

rustc 1.24.0 (4d90ac38c 2018-02-12)

running 4 tests
test bench_from_iter                         ... bench:       2,323 ns/iter (+/- 8)
test bench_from_iter_with_filter_map         ... bench:       2,535 ns/iter (+/- 4)
test bench_from_iter_with_scan_passing_state ... bench:       3,796 ns/iter (+/- 15)
test bench_from_iter_with_scan_with_freevar  ... bench:       3,792 ns/iter (+/- 11)

1.26 और 1.27 के बीच filter_map -आधारित कार्यान्वयन का प्रदर्शन फिर से वापस आ गया, काफी महत्वपूर्ण:

rustc 1.27.0 (3eda71b00 2018-06-19)

running 4 tests
test bench_from_iter                         ... bench:       2,442 ns/iter (+/- 5)
test bench_from_iter_with_filter_map         ... bench:       5,080 ns/iter (+/- 55)
test bench_from_iter_with_scan_passing_state ... bench:       3,594 ns/iter (+/- 12)
test bench_from_iter_with_scan_with_freevar  ... bench:       3,591 ns/iter (+/- 2)

rustc 1.13.0 (2c6933acc 2016-11-07)

running 4 tests
test bench_from_iter                         ... bench:       1,691 ns/iter (+/- 9)
test bench_from_iter_with_filter_map         ... bench:       1,930 ns/iter (+/- 230)
test bench_from_iter_with_scan_passing_state ... bench:       1,682 ns/iter (+/- 10)
test bench_from_iter_with_scan_with_freevar  ... bench:       1,686 ns/iter (+/- 55)

इसके लिए 1.27 के तहत:

rustc 1.27.0 (3eda71b00 2018-06-19)

running 4 tests
test bench_from_iter                         ... bench:       2,442 ns/iter (+/- 5)
test bench_from_iter_with_filter_map         ... bench:       5,080 ns/iter (+/- 55)
test bench_from_iter_with_scan_passing_state ... bench:       3,594 ns/iter (+/- 12)
test bench_from_iter_with_scan_with_freevar  ... bench:       3,591 ns/iter (+/- 2)

pnkfelix 20 मार्च 2019

❤2

पिछली टिप्पणी में नोट किए गए मामलों में हमारे प्रदर्शन के साथ क्या हुआ है, इसका कम से कम निदान करने के लिए इसे पी-उच्च मुद्दा बनाना।

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

pnkfelix 20 मार्च 2019

@pnkfelix क्या आप अपने बेंचमार्क के लिए कोड साझा कर सकते हैं?

perf इसे मेरे पुराने bench_from_iter_with_scan बेंचमार्क के लिए हॉटस्पॉट के रूप में दिखाता है:

  0.09 │       movaps 0x20(%rsp),%xmm0
 34.33 │       movups %xmm0,(%r15)
  5.85 │       movups (%r15),%xmm0
 49.67 │       movaps %xmm0,0x20(%rsp)

जो काफी प्रफुल्लित करने वाला लगता है।

dotdash 21 मार्च 2019

😕1 😄1

rustc -O --test साथ संकलित:

running 3 tests
test bench_from_iter                 ... bench:       2,170 ns/iter (+/- 20)
test bench_from_iter_with_filter_map ... bench:       3,412 ns/iter (+/- 67)
test bench_from_iter_with_scan       ... bench:       4,416 ns/iter (+/- 40)

rustc -O --test -Ccodegen-units=1 साथ संकलित:

running 3 tests
test bench_from_iter                 ... bench:         977 ns/iter (+/- 18)
test bench_from_iter_with_filter_map ... bench:       3,296 ns/iter (+/- 36)
test bench_from_iter_with_scan       ... bench:       2,280 ns/iter (+/- 40)

dotdash 21 मार्च 2019

@dotdash यहाँ वह फ़ाइल है जिसे मैं अपने बेंचमार्क के लिए संकलित कर रहा हूँ: https://gist.github.com/pnkfelix/7cb66d32c3cd9e1f2ea1a61ef15a0a3a

pnkfelix 21 मार्च 2019

ठीक; मैं codegen-units लिए डिफ़ॉल्ट में परिवर्तन के बारे में भूल गया था। (हो सकता है -C opt-level=3 को codegen-units लिए डिफ़ॉल्ट को वापस 1 में बदलना चाहिए? बस एक विचार ...)

pnkfelix 21 मार्च 2019

--test -C opt-level=3 -C codegen-units= 1 के साथ मेरी linux मशीन के लिए परिणाम:

rustc 1.33.0 (2aa4c46cf 2019-02-28)

running 4 tests
test bench_from_iter                         ... bench:       1,432 ns/iter (+/- 44)
test bench_from_iter_with_filter_map         ... bench:       1,504 ns/iter (+/- 3)
test bench_from_iter_with_scan_passing_state ... bench:       2,088 ns/iter (+/- 4)
test bench_from_iter_with_scan_with_freevar  ... bench:       2,050 ns/iter (+/- 12)

rustc 1.13.0 (2c6933acc 2016-11-07)

running 4 tests
test bench_from_iter                         ... bench:       1,688 ns/iter (+/- 50)
test bench_from_iter_with_filter_map         ... bench:       1,953 ns/iter (+/- 10)
test bench_from_iter_with_scan_passing_state ... bench:       1,677 ns/iter (+/- 62)
test bench_from_iter_with_scan_with_freevar  ... bench:       1,683 ns/iter (+/- 17)

pnkfelix 21 मार्च 2019

एक अतिरिक्त चेतावनी मैं जोड़ूंगा: जब मैं यहां देखे गए कुछ प्रदर्शन अंतरों के बारे में चिंतित रहता हूं, तो मुझे बेंचमार्क हार्नेस द्वारा शुरू किए गए कारकों को नियंत्रित करने की भी चिंता है।

विशेष रूप से, मैंने bench_from_iter दो प्रकार बनाए (एक एडेप्टर-कार्यान्वयन लिखित इनलाइन ( bench_from_iter_using_adapter ) के साथ, और दूसरा जो stdlib कार्यान्वयन के लिए कॉल करना जारी रखता है जिसे से कॉपी किया गया था ( bench_from_iter_using_baseline )), स्रोत कोड यहाँ , और मैं वर्तमान में इसे देख रहा हूँ:

12-45-10 Mozilla/issue11084 % rustc +nightly-2019-03-20 -C opt-level=3 -C codegen-units=1 --test main-bench.rs -o main-bench
12-45-45 Mozilla/issue11084 % ./main-bench --bench

running 5 tests
test bench_from_iter_using_adapter____ ... bench:       1,531 ns/iter (+/- 6)
test bench_from_iter_using_baseline___ ... bench:       1,277 ns/iter (+/- 10)
test bench_from_iter_with_filter_map__ ... bench:       3,508 ns/iter (+/- 64)
test bench_from_iter_with_scan_freevar ... bench:       2,066 ns/iter (+/- 53)
test bench_from_iter_with_scan_param__ ... bench:       2,055 ns/iter (+/- 30)

test result: ok. 0 passed; 0 failed; 0 ignored; 5 measured; 0 filtered out

12-45-51 Mozilla/issue11084 % ./main-bench --bench

running 5 tests
test bench_from_iter_using_adapter____ ... bench:       1,514 ns/iter (+/- 6)
test bench_from_iter_using_baseline___ ... bench:       1,305 ns/iter (+/- 12)
test bench_from_iter_with_filter_map__ ... bench:       3,491 ns/iter (+/- 56)
test bench_from_iter_with_scan_freevar ... bench:       2,061 ns/iter (+/- 5)
test bench_from_iter_with_scan_param__ ... bench:       2,094 ns/iter (+/- 53)

test result: ok. 0 passed; 0 failed; 0 ignored; 5 measured; 0 filtered out

12-45-53 Mozilla/issue11084 % ./main-bench --bench adapter

running 1 test
test bench_from_iter_using_adapter____ ... bench:       1,574 ns/iter (+/- 12)

test result: ok. 0 passed; 0 failed; 0 ignored; 1 measured; 4 filtered out

12-45-57 Mozilla/issue11084 % ./main-bench --bench adapter

running 1 test
test bench_from_iter_using_adapter____ ... bench:       1,530 ns/iter (+/- 9)

test result: ok. 0 passed; 0 failed; 0 ignored; 1 measured; 4 filtered out

12-45-59 Mozilla/issue11084 % ./main-bench --bench baseline

running 1 test
test bench_from_iter_using_baseline___ ... bench:       1,569 ns/iter (+/- 9)

test result: ok. 0 passed; 0 failed; 0 ignored; 1 measured; 4 filtered out

12-46-01 Mozilla/issue11084 % ./main-bench --bench baseline

running 1 test
test bench_from_iter_using_baseline___ ... bench:       1,576 ns/iter (+/- 4)

test result: ok. 0 passed; 0 failed; 0 ignored; 1 measured; 4 filtered out

12-46-03 Mozilla/issue11084 %

विशेष रूप से ध्यान दें कि bench_from_iter_using_baseline लिए समय [1277, 1305] से बढ़कर [1569, 1576] हो गया है, केवल अन्य बेंचमार्क के क्रम के बजाय स्वयं को कॉल करने से। ये परिणाम लगातार दोहराए गए रनों पर काफी सुसंगत प्रतीत होते हैं।

इसका मतलब है कि कैश प्रभाव या मेमोरी-आवंटक समस्याएँ हो सकती हैं जो एक बेंचमार्क को दूसरे के निष्पादन में ब्लीड करने के प्रभावों का कारण बन रही हैं।

(इसके बदले में इसका मतलब है कि मुझे इस बारे में बहुत सावधान रहने की जरूरत है कि मैं प्रदर्शन के संबंध में कौन से निष्पादन को चिंताजनक मानता हूं। वह, या मुझे इस बारे में अधिक सावधान रहने की आवश्यकता है कि मैं बेंचमार्क कैसे चलाता हूं।)

pnkfelix 21 मार्च 2019

(उपरोक्त कुछ प्रभावों को नियंत्रित करने का एक तरीका इस बेंचमार्क को फिर से लिखना होगा ताकि यह Vec में जमा न हो; उस ऑपरेशन का प्रदर्शन वह नहीं है जो मूल कोड मापने की कोशिश कर रहा था, और यह निश्चित रूप से वह नहीं है जो अवरुद्ध होना चाहिए कि हम FromIterator को Result और Option लिए कैसे कार्यान्वित करते हैं, है ना? )

pnkfelix 21 मार्च 2019

ठीक है, तो यहाँ है कि एक नया लक्ष्य प्रकार जोड़ा गया है कोड का एक संशोधित संस्करण है Last<T> के लिए FromIterator । यह केवल पुनरावृत्ति में अंतिम तत्व को याद रखता है ( .last() माध्यम से), इसलिए बेंचमार्क चलने पर किसी भी ढेर प्रबंधन से कोई शोर नहीं होता है। (इसके अलावा, चूंकि कोई मेम-एमजीएमटी ओवरहेड नहीं है, इसलिए मैंने इनपुट आकार को थोड़ा बढ़ा दिया ताकि एनएस/इटर अभी भी बहुत बड़ा हो।)

https://gist.github.com/80fe57277434ef31f018c08fa8e21f84

उम्मीद है कि यह FromIterator कार्यान्वयन कलाकृतियों पर अतिरिक्त ध्यान प्रदान कर सकता है। (विशेष रूप से: Last<T> बेंचमार्क वेरिएंट के लिए मापा गया ns/iter स्थिर लगता है, भले ही मैं उन्हें स्वयं चलाऊं या समग्र सूट के हिस्से के रूप में; Vec<T> के मामले में ऐसा नहीं था।

इसके साथ, मुझे निम्नलिखित परिणाम मिलते हैं:

% RUSTC_BOOTSTRAP=1 rustc +1.13.0 -C opt-level=3 -C codegen-units=1 --test main-bench.rs -o main-bench  && ./main-bench --bench

running 10 tests
test bench__vec_from_iter_using_adapter____ ... bench:       1,692 ns/iter (+/- 8)
test bench__vec_from_iter_using_baseline___ ... bench:       1,692 ns/iter (+/- 67)
test bench__vec_from_iter_with_filter_map__ ... bench:       1,963 ns/iter (+/- 10)
test bench__vec_from_iter_with_scan_freevar ... bench:       1,692 ns/iter (+/- 11)
test bench__vec_from_iter_with_scan_param__ ... bench:       1,690 ns/iter (+/- 8)
test bench_last_from_iter_using_adapter____ ... bench:       2,156 ns/iter (+/- 10)
test bench_last_from_iter_using_baseline___ ... bench:       2,158 ns/iter (+/- 8)
test bench_last_from_iter_with_filter_map__ ... bench:       3,022 ns/iter (+/- 8)
test bench_last_from_iter_with_scan_freevar ... bench:       2,156 ns/iter (+/- 12)
test bench_last_from_iter_with_scan_param__ ... bench:       2,155 ns/iter (+/- 6)

test result: ok. 0 passed; 0 failed; 0 ignored; 10 measured

% RUSTC_BOOTSTRAP=1 rustc +1.33.0 -C opt-level=3 -C codegen-units=1 --test main-bench.rs -o main-bench  && ./main-bench --bench

running 10 tests
test bench__vec_from_iter_using_adapter____ ... bench:       1,211 ns/iter (+/- 3)
test bench__vec_from_iter_using_baseline___ ... bench:       1,280 ns/iter (+/- 4)
test bench__vec_from_iter_with_filter_map__ ... bench:       1,504 ns/iter (+/- 4)
test bench__vec_from_iter_with_scan_freevar ... bench:       2,088 ns/iter (+/- 61)
test bench__vec_from_iter_with_scan_param__ ... bench:       2,054 ns/iter (+/- 5)
test bench_last_from_iter_using_adapter____ ... bench:       2,186 ns/iter (+/- 5)
test bench_last_from_iter_using_baseline___ ... bench:       2,186 ns/iter (+/- 19)
test bench_last_from_iter_with_filter_map__ ... bench:       1,659 ns/iter (+/- 12)
test bench_last_from_iter_with_scan_freevar ... bench:       2,692 ns/iter (+/- 2)
test bench_last_from_iter_with_scan_param__ ... bench:       2,693 ns/iter (+/- 3)

test result: ok. 0 passed; 0 failed; 0 ignored; 10 measured; 0 filtered out

% RUSTC_BOOTSTRAP=1 rustc +nightly-2019-03-20 -C opt-level=3 -C codegen-units=1 --test main-bench.rs -o main-bench  && ./main-bench --bench

running 10 tests
test bench__vec_from_iter_using_adapter____ ... bench:       1,270 ns/iter (+/- 53)
test bench__vec_from_iter_using_baseline___ ... bench:       1,265 ns/iter (+/- 54)
test bench__vec_from_iter_with_filter_map__ ... bench:       3,469 ns/iter (+/- 7)
test bench__vec_from_iter_with_scan_freevar ... bench:       2,076 ns/iter (+/- 1)
test bench__vec_from_iter_with_scan_param__ ... bench:       2,128 ns/iter (+/- 47)
test bench_last_from_iter_using_adapter____ ... bench:       2,186 ns/iter (+/- 5)
test bench_last_from_iter_using_baseline___ ... bench:       2,185 ns/iter (+/- 57)
test bench_last_from_iter_with_filter_map__ ... bench:       2,650 ns/iter (+/- 13)
test bench_last_from_iter_with_scan_freevar ... bench:       2,678 ns/iter (+/- 12)
test bench_last_from_iter_with_scan_param__ ... bench:       2,674 ns/iter (+/- 15)

test result: ok. 0 passed; 0 failed; 0 ignored; 10 measured; 0 filtered out

इसलिए: जब आप scan -आधारित कार्यान्वयन की तुलना एडेप्टर-आधारित वाले के साथ करते हैं, तब भी कुछ प्रतिगमन होता है, यहां तक कि Last<T> बजाय Vec<T> , लेकिन यह है इतना स्पष्ट अंतर नहीं है: मंदी Last<T> लिए 1.22x का कारक है ( Vec<T> लिए 1.67x की तरह कुछ की तुलना में)।

pnkfelix 21 मार्च 2019

यहाँ @pnkfelix के मूल डेटा का एक ग्राफ है जो विचरण ( निर्माण स्क्रिप्ट ) दिखा रहा है।

graph

फिर किसी ने जाकर परीक्षण विधियों को बदल दिया, तो यह अब और उपयोगी नहीं हो सकता है ...

shepmaster 21 मार्च 2019

🎉1

फिर किसी ने जाकर टेस्टिंग के तरीके बदले

(ठीक है, मैंने जो कुछ किया वह नए रूपों को जोड़ रहा था; मूल बेंचमार्क अभी भी वहां हैं ...)

अपडेट: मैं स्वीकार करूंगा कि किसी को Vec -बिल्डिंग वेरिएंट की तुलना Last -बिल्डिंग वाले के साथ करने का प्रयास करने से पहले किसी प्रकार के सामान्यीकरण फ़ंक्शन का पता लगाने की आवश्यकता है; लेकिन हमें वैसे भी ऐसा करने की कोशिश नहीं करनी चाहिए, है ना?

pnkfelix 22 मार्च 2019

आह यहाँ एक आखिरी रन है: @eddyb के एक नोट ने कहीं और बताया कि कोडजेन-यूनिट्स = 1 का उपयोग लिंक-टाइम ऑप्टिमाइज़ेशन को अक्षम करता है।

आइए -C lto=... माध्यम से लिंक-टाइम ऑप्टिमाइज़ेशन को स्पष्ट रूप से नियंत्रित करें और देखें कि क्या होता है:

lto=off (कोडजन-इकाइयों के साथ डिफ़ॉल्ट के समान = 1)

% RUSTC_BOOTSTRAP=1 rustc +nightly-2019-03-20 -C opt-level=3 -C codegen-units=1 --test main-bench.rs -o main-bench -C lto=off  && ./main-bench --bench

running 10 tests
test bench__vec_from_iter_using_adapter____ ... bench:       1,260 ns/iter (+/- 6)
test bench__vec_from_iter_using_baseline___ ... bench:       1,306 ns/iter (+/- 48)
test bench__vec_from_iter_with_filter_map__ ... bench:       3,467 ns/iter (+/- 3)
test bench__vec_from_iter_with_scan_freevar ... bench:       2,082 ns/iter (+/- 12)
test bench__vec_from_iter_with_scan_param__ ... bench:       2,087 ns/iter (+/- 52)
test bench_last_from_iter_using_adapter____ ... bench:       2,186 ns/iter (+/- 6)
test bench_last_from_iter_using_baseline___ ... bench:       2,187 ns/iter (+/- 21)
test bench_last_from_iter_with_filter_map__ ... bench:       2,650 ns/iter (+/- 3)
test bench_last_from_iter_with_scan_freevar ... bench:       2,683 ns/iter (+/- 4)
test bench_last_from_iter_with_scan_param__ ... bench:       2,688 ns/iter (+/- 8)

test result: ok. 0 passed; 0 failed; 0 ignored; 10 measured; 0 filtered out

एलटीओ = वसा

% RUSTC_BOOTSTRAP=1 rustc +nightly-2019-03-20 -C opt-level=3 -C codegen-units=1 --test main-bench.rs -o main-bench -C lto=fat  && ./main-bench --bench

running 10 tests
test bench__vec_from_iter_using_adapter____ ... bench:       1,289 ns/iter (+/- 19)
test bench__vec_from_iter_using_baseline___ ... bench:       1,232 ns/iter (+/- 9)
test bench__vec_from_iter_with_filter_map__ ... bench:       3,481 ns/iter (+/- 19)
test bench__vec_from_iter_with_scan_freevar ... bench:       1,273 ns/iter (+/- 20)
test bench__vec_from_iter_with_scan_param__ ... bench:       1,273 ns/iter (+/- 8)
test bench_last_from_iter_using_adapter____ ... bench:       1,680 ns/iter (+/- 18)
test bench_last_from_iter_using_baseline___ ... bench:       1,683 ns/iter (+/- 21)
test bench_last_from_iter_with_filter_map__ ... bench:       3,047 ns/iter (+/- 2)
test bench_last_from_iter_with_scan_freevar ... bench:       1,793 ns/iter (+/- 81)
test bench_last_from_iter_with_scan_param__ ... bench:       1,773 ns/iter (+/- 49)

test result: ok. 0 passed; 0 failed; 0 ignored; 10 measured; 0 filtered out

एलटीओ = पतला

% RUSTC_BOOTSTRAP=1 rustc +nightly-2019-03-20 -C opt-level=3 -C codegen-units=1 --test main-bench.rs -o main-bench -C lto=thin  && ./main-bench --bench

running 10 tests
test bench__vec_from_iter_using_adapter____ ... bench:       1,263 ns/iter (+/- 8)
test bench__vec_from_iter_using_baseline___ ... bench:       1,238 ns/iter (+/- 49)
test bench__vec_from_iter_with_filter_map__ ... bench:       3,702 ns/iter (+/- 32)
test bench__vec_from_iter_with_scan_freevar ... bench:       1,248 ns/iter (+/- 3)
test bench__vec_from_iter_with_scan_param__ ... bench:       1,248 ns/iter (+/- 13)
test bench_last_from_iter_using_adapter____ ... bench:       1,616 ns/iter (+/- 6)
test bench_last_from_iter_using_baseline___ ... bench:       1,612 ns/iter (+/- 6)
test bench_last_from_iter_with_filter_map__ ... bench:       3,024 ns/iter (+/- 7)
test bench_last_from_iter_with_scan_freevar ... bench:       1,427 ns/iter (+/- 7)
test bench_last_from_iter_with_scan_param__ ... bench:       1,427 ns/iter (+/- 11)

test result: ok. 0 passed; 0 failed; 0 ignored; 10 measured; 0 filtered out

विशेष रूप से, lto (वसा या पतला) का उपयोग करने से scan -प्रदर्शन उस आधार रेखा के अनुरूप होता है जो हम वर्तमान में प्रदान करते हैं (या इसमें सुधार करते हैं)।

मुझे लगता है कि मुझे विश्वास हो गया है कि विशेष रूप से इस मामले के बारे में हमें बहुत कुछ नहीं करना चाहिए (लिंक-टाइम ऑप्टिमाइज़ेशन और/या कोडजेन-यूनिट विभाजन के साथ व्यापक मुद्दों को हल करने की कोशिश करने के अलावा)।

और मैं इस जांच के परिणामों को जोड़ने के लिए FromIterator लिए Option और Result के सरलीकृत कार्यान्वयन के साथ आगे बढ़ने जा रहा हूं और एक पीआर तैयार करूंगा।

pnkfelix 22 मार्च 2019

ठीक है, ठीक है, निष्पक्ष होने के लिए, मुझे एहसास हुआ कि मुझे एक समान प्रयोग करना चाहिए, लेकिन इस बार परिणाम दिखाएं जब आप lto बदलते हैं लेकिन आपके पास codegen-units ≠ 1 है:

lto=ऑफ कोडजन-इकाइयाँ=16

11-54-00 Mozilla/issue11084 % RUSTC_BOOTSTRAP=1 rustc +nightly-2019-03-20 -C opt-level=3 -C codegen-units=16 --test main-bench.rs -o main-bench -C lto=off  && ./main-bench --bench

running 10 tests
test bench__vec_from_iter_using_adapter____ ... bench:       6,830 ns/iter (+/- 66)
test bench__vec_from_iter_using_baseline___ ... bench:       6,848 ns/iter (+/- 30)
test bench__vec_from_iter_with_filter_map__ ... bench:       5,547 ns/iter (+/- 20)
test bench__vec_from_iter_with_scan_freevar ... bench:       5,592 ns/iter (+/- 84)
test bench__vec_from_iter_with_scan_param__ ... bench:       5,322 ns/iter (+/- 12)
test bench_last_from_iter_using_adapter____ ... bench:       9,820 ns/iter (+/- 216)
test bench_last_from_iter_using_baseline___ ... bench:      14,730 ns/iter (+/- 116)
test bench_last_from_iter_with_filter_map__ ... bench:       9,869 ns/iter (+/- 16)
test bench_last_from_iter_with_scan_freevar ... bench:      11,351 ns/iter (+/- 131)
test bench_last_from_iter_with_scan_param__ ... bench:      10,593 ns/iter (+/- 51)

test result: ok. 0 passed; 0 failed; 0 ignored; 10 measured; 0 filtered out

lto=वसा कोडेजन-इकाइयाँ=16

11-54-19 Mozilla/issue11084 % RUSTC_BOOTSTRAP=1 rustc +nightly-2019-03-20 -C opt-level=3 -C codegen-units=16 --test main-bench.rs -o main-bench -C lto=fat  && ./main-bench --bench

running 10 tests
test bench__vec_from_iter_using_adapter____ ... bench:       1,914 ns/iter (+/- 12)
test bench__vec_from_iter_using_baseline___ ... bench:       1,914 ns/iter (+/- 2)
test bench__vec_from_iter_with_filter_map__ ... bench:       3,406 ns/iter (+/- 10)
test bench__vec_from_iter_with_scan_freevar ... bench:       1,354 ns/iter (+/- 4)
test bench__vec_from_iter_with_scan_param__ ... bench:       1,340 ns/iter (+/- 7)
test bench_last_from_iter_using_adapter____ ... bench:       1,648 ns/iter (+/- 17)
test bench_last_from_iter_using_baseline___ ... bench:       1,607 ns/iter (+/- 11)
test bench_last_from_iter_with_filter_map__ ... bench:       8,309 ns/iter (+/- 23)
test bench_last_from_iter_with_scan_freevar ... bench:       1,648 ns/iter (+/- 8)
test bench_last_from_iter_with_scan_param__ ... bench:       1,648 ns/iter (+/- 14)

test result: ok. 0 passed; 0 failed; 0 ignored; 10 measured; 0 filtered out

lto=पतली कोडजन-इकाइयाँ=16

11-55-02 Mozilla/issue11084 % RUSTC_BOOTSTRAP=1 rustc +nightly-2019-03-20 -C opt-level=3 -C codegen-units=16 --test main-bench.rs -o main-bench -C lto=thin  && ./main-bench --bench

running 10 tests
test bench__vec_from_iter_using_adapter____ ... bench:       2,076 ns/iter (+/- 82)
test bench__vec_from_iter_using_baseline___ ... bench:       2,076 ns/iter (+/- 3)
test bench__vec_from_iter_with_filter_map__ ... bench:       3,792 ns/iter (+/- 11)
test bench__vec_from_iter_with_scan_freevar ... bench:       6,046 ns/iter (+/- 21)
test bench__vec_from_iter_with_scan_param__ ... bench:       6,064 ns/iter (+/- 46)
test bench_last_from_iter_using_adapter____ ... bench:       1,429 ns/iter (+/- 12)
test bench_last_from_iter_using_baseline___ ... bench:       1,501 ns/iter (+/- 21)
test bench_last_from_iter_with_filter_map__ ... bench:       8,945 ns/iter (+/- 91)
test bench_last_from_iter_with_scan_freevar ... bench:      15,404 ns/iter (+/- 15)
test bench_last_from_iter_with_scan_param__ ... bench:      15,385 ns/iter (+/- 17)

test result: ok. 0 passed; 0 failed; 0 ignored; 10 measured; 0 filtered out

के लिए प्रतिगमन scan आधारित इटरेटर जब आप codegen इकाइयों है = 16 और LTO = पतली सुंदर डरावना है (और यह डेस्कटॉप मशीन के लिए, codegen-units=16 डिफ़ॉल्ट है) ... चाहिए कि ब्लॉक लैंडिंग प्रस्तावित परिवर्तन?

pnkfelix 22 मार्च 2019

अपडेट: @michaelwoerister ने मुझे सूचित किया है कि जब आप कुछ भी निर्दिष्ट नहीं करते हैं तो एलटीओ के लिए डिफ़ॉल्ट एलटीओ बंद नहीं होता है। (जो, ऊपर दिए गए नंबरों को देखते हुए, समझ में आता है, क्योंकि शायद कुछ ऐसा चल रहा है जो बेसलाइन और स्कैन-आधारित कार्यान्वयन को प्रतिस्पर्धी बना रहा है, जब कोडजन-इकाइयाँ = 16 जब एलटीओ के बारे में कुछ भी नहीं कहा जाता है)। (उपरोक्त संख्या इस मामले को कैप्चर नहीं करती है, क्योंकि मुझे पता नहीं था कि इसमें स्पष्ट -C lto एन्कोडिंग नहीं है।)

विशेष रूप से, यदि आप -C lto _and_ निर्दिष्ट नहीं करते हैं, तो आप एकाधिक कोडजन इकाइयों के साथ संकलित करते हैं, तो "स्थानीय थिनएलटीओ" नामक कुछ का उपयोग किया जाएगा।
यदि आप केवल एक कोडजन इकाई के साथ संकलित करते हैं और -C lto निर्दिष्ट नहीं करते हैं, तो किसी भी एलटीओ का उपयोग नहीं किया जाता है।

-C lto ध्वज के माध्यम से "स्थानीय ThinLTO" में स्पष्ट रूप से ऑप्ट इन करने का कोई तरीका नहीं है। मैं उन प्रणालियों के लिए अधिक अभ्यस्त हूं जहां किसी सेटिंग को स्पष्ट रूप से एन्कोड करने का कोई तरीका है जो डिफ़ॉल्ट से मेल खाता है, यही कारण है कि मैं जो हो रहा था उसके बारे में उलझन में था, और ऊपर मेरे डेटा में कुछ शीर्षक भ्रमित हो सकते हैं या कम से कम भ्रमित हो सकते हैं .

pnkfelix 1 अप्रैल 2019

पिछली टिप्पणी में नोट किए गए मामलों में हमारे प्रदर्शन के साथ क्या हुआ है, इसका कम से कम निदान करने के लिए इसे पी-उच्च मुद्दा बनाना।

ठीक है, मैं अपनी जांच के परिणामों से संतुष्ट हूं।

इसलिए मैं इसे अभी के लिए तुरंत पी-लो के रूप में चिह्नित करने जा रहा हूं।

लेकिन इसके अलावा, मुझे नहीं लगता कि इस विशिष्ट मुद्दे पर कार्रवाई करने योग्य और कुछ है।

मैंने एक पीआर पोस्ट किया है जो impl FromIterator में परिवर्तन को प्रदर्शित करता है जिसने यहां मूल मुद्दे को प्रेरित किया, साथ ही इसके लिए बेंचमार्क भी। वह पीआर #59605 में है।

और मुझे आश्चर्य है कि क्या हमें कंपाइलर कमांड UI के लिए अपने कुछ डिफ़ॉल्ट को संशोधित करने की आवश्यकता है, विभिन्न एलटीओ सेटिंग्स को कैसे निर्दिष्ट किया जाता है या कम से कम प्रलेखित किया जाता है, और -C opt-level=3 अर्थ को बदलने के संदर्भ में भी (उदाहरण के लिए) मुझे लगता है कि कोडजेन-इकाइयों = 1 को इंगित करना चाहिए यदि उपयोगकर्ता ने पहले से ही कोडजेन-इकाइयों के लिए कुछ अन्य सेटिंग निर्दिष्ट नहीं की है)। लेकिन यह इस मुद्दे से संबंधित नहीं है जैसा कि लिखा गया है।

इसलिए, मैं वास्तव में इस मुद्दे को बंद करने का इच्छुक हूं। लेकिन मुझे लगता है कि जब तक मुझे पीआर #59605 पर कुछ प्रतिक्रिया नहीं मिलती है, तब तक मैं ऐसा करना बंद कर दूंगा।

pnkfelix 1 अप्रैल 2019

@pnkfelix क्या आप अपने बेंचमार्क के लिए कोड साझा कर सकते हैं?
perf इसे मेरे पुराने bench_from_iter_with_scan बेंचमार्क के लिए हॉटस्पॉट के रूप में दिखाता है:
  0.09 │       movaps 0x20(%rsp),%xmm0
 34.33 │       movups %xmm0,(%r15)
  5.85 │       movups (%r15),%xmm0
 49.67 │       movaps %xmm0,0x20(%rsp)
जो काफी प्रफुल्लित करने वाला लगता है।

इसकी संभावना है कि हम इस घटना के बारे में कुछ करने के लिए सक्षम हो सकता है। यह अनुकूलन के लिए कम लटका हुआ फल हो सकता है, हो सकता है।

pnkfelix 1 अप्रैल 2019

पिछली टिप्पणी में मेरे सारांश के आधार पर, और पीआर #59605 से अनिर्णायक परिणामों के आधार पर, मैं इसे बंद करने जा रहा हूं।

pnkfelix 17 मई 2019

क्या यह पृष्ठ उपयोगी था?

0 / 5 - 0 रेटिंग्स

<p>जंग स्कैन इटरेटर में क्लोजर को अनुकूलित नहीं करता है</p>

सबसे उपयोगी टिप्पणी

सभी 28 टिप्पणियाँ

lto=off (कोडजन-इकाइयों के साथ डिफ़ॉल्ट के समान = 1)

एलटीओ = वसा

एलटीओ = पतला

lto=ऑफ कोडजन-इकाइयाँ=16

lto=वसा कोडेजन-इकाइयाँ=16

lto=पतली कोडजन-इकाइयाँ=16

संबंधित मुद्दों