มาตรฐาน C ++ มีประสิทธิภาพต่ำสำหรับ iostreams หรือฉันแค่จัดการกับการนำไปใช้ที่ไม่ดี?

ทุกครั้งที่ฉันพูดถึงประสิทธิภาพที่ช้าของ C ++ ไลบรารีมาตรฐาน iostreams ฉันจะได้พบกับคลื่นแห่งความไม่เชื่อ แต่ฉันมีผลลัพธ์ของ profiler ที่แสดงเวลาจำนวนมากที่ใช้ในโค้ดไลบรารี iostream (การปรับให้เหมาะสมเต็มที่ของคอมไพเลอร์), และการสลับจาก iostreams ไปเป็น I / O API เฉพาะระบบปฏิบัติการและการจัดการบัฟเฟอร์แบบกำหนดเอง

สิ่งที่เป็นงานพิเศษคือห้องสมุดมาตรฐาน C ++ ทำมันเป็นสิ่งจำเป็นโดยมาตรฐานและเป็นประโยชน์ในการปฏิบัติ? หรือคอมไพเลอร์บางตัวมีการใช้งาน iostreams ที่สามารถแข่งขันกับการจัดการบัฟเฟอร์ด้วยตนเองได้หรือไม่?

มาตรฐาน

เพื่อให้เรื่องต่าง ๆ มีความเคลื่อนไหวฉันได้เขียนโปรแกรมสั้น ๆ สองข้อเพื่อออกกำลังกายการบัฟเฟอร์ภายใน iostreams:

• วางข้อมูลไบนารีลงในostringstream http://ideone.com/2PPYw
• ใส่ข้อมูลไบนารีลงในchar[]บัฟเฟอร์http://ideone.com/Ni5ct
• วางข้อมูลไบนารีลงในhttp://ideone.com/Mj2Fi ที่vector<char>ใช้back_inserter
• ใหม่ : ตัวvector<char>วนซ้ำอย่างง่ายhttp://ideone.com/9iitv
• ใหม่ : ใส่ข้อมูลไบนารีโดยตรงในstringbuf http://ideone.com/qc9QA
• ใหม่ : ตัวvector<char>วนซ้ำแบบง่ายพร้อมการตรวจสอบขอบเขตhttp://ideone.com/YyrKy

โปรดทราบว่าostringstreamและstringbufรุ่นต่างๆจะทำงานซ้ำน้อยลงเพราะมันช้ากว่ามาก

เมื่อวันที่ ideone ที่ostringstreamเป็นเรื่องเกี่ยวกับ 3 ครั้งช้ากว่าstd:copy+ back_inserter+ std::vectorและประมาณ 15 ครั้งช้ากว่าmemcpyเป็นบัฟเฟอร์ดิบ สิ่งนี้ให้ความรู้สึกที่สอดคล้องกับการทำโปรไฟล์ก่อนและหลังเมื่อฉันเปลี่ยนแอปพลิเคชันจริงเป็นการกำหนดบัฟเฟอร์เอง

สิ่งเหล่านี้เป็นบัฟเฟอร์ในหน่วยความจำดังนั้นความช้าของ iostreams จึงไม่สามารถถูกตำหนิบนดิสก์ช้า I / O, การล้างข้อมูลมากเกินไป, การซิงโครไนซ์กับ stdio หรือสิ่งอื่น ๆ ที่ผู้คนใช้ในการอ้างข้อสังเกตความช้าของไลบรารีมาตรฐาน C ++ iostream

มันจะเป็นการดีหากได้เห็นการวัดประสิทธิภาพของระบบอื่น ๆ และความเห็นเกี่ยวกับสิ่งที่การใช้งานทั่วไปทำ (เช่น gc's libc ++, Visual C ++, Intel C ++) และค่าใช้จ่ายที่กำหนดโดยมาตรฐาน

เหตุผลสำหรับการทดสอบนี้

ผู้คนจำนวนมากชี้ให้เห็นอย่างถูกต้องว่า iostreams ใช้กันอย่างแพร่หลายในรูปแบบเอาต์พุต อย่างไรก็ตามพวกเขายังเป็น API ที่ทันสมัยเท่านั้นที่มีให้โดยมาตรฐาน C ++ สำหรับการเข้าถึงไฟล์ไบนารี แต่เหตุผลที่แท้จริงสำหรับการทดสอบประสิทธิภาพในการบัฟเฟอร์ภายในนั้นใช้กับ I / O ที่จัดรูปแบบโดยทั่วไป: ถ้า iostreams ไม่สามารถเก็บดิสก์คอนโทรลเลอร์ที่ให้ข้อมูลดิบได้พวกเขาจะติดตามได้อย่างไรเมื่อพวกเขารับผิดชอบการจัดรูปแบบเช่นกัน?

กำหนดเวลาเกณฑ์มาตรฐาน

ทั้งหมดเหล่านี้เป็นแบบวนซ้ำของวงรอบนอก ( k)

บน ideone (gcc-4.3.4, ระบบปฏิบัติการที่ไม่รู้จักและฮาร์ดแวร์):

• ostringstream: 53 มิลลิวินาที
• stringbuf: 27 ms
• vector<char>และback_inserter: 17.6 ms
• vector<char> ด้วยตัววนซ้ำธรรมดา: 10.6 ms
• vector<char> ตรวจสอบตัววนซ้ำและขอบเขต: 11.4 ms
• char[]: 3.7 ms

บนแล็ปท็อปของฉัน (Visual C ++ 2010 x86,, cl /Ox /EHscWindows 7 Ultimate 64-bit, Intel Core i7, RAM 8 GB):

• ostringstream: 73.4 มิลลิวินาที, 71.6 มิลลิวินาที
• stringbuf: 21.7 ms, 21.3 ms
• vector<char>และback_inserter: 34.6 ms, 34.4 ms
• vector<char> ด้วยตัววนซ้ำธรรมดา: 1.10 ms, 1.04 ms
• vector<char> การวนซ้ำและการตรวจสอบขอบเขต: 1.11 ms, 0.87 ms, 1.12 ms, 0.89 ms, 1.02 ms, 1.14 ms
• char[]: 1.48 ms, 1.57 ms

Visual C ++ 2010 x86 กับโปรไฟล์-Guided Optimization cl /Ox /EHsc /GL /c, link /ltcg:pgiวิ่ง, link /ltcg:pgoวัด:

• ostringstream: 61.2 ms, 60.5 ms
• vector<char> ด้วยตัววนซ้ำธรรมดา: 1.04 ms, 1.03 ms

แล็ปท็อปเครื่องเดียวกันระบบปฏิบัติการเดียวกันโดยใช้ cygwin gcc 4.3.4 g++ -O3:

• ostringstream: 62.7 ms, 60.5 ms
• stringbuf: 44.4 ms, 44.5 ms
• vector<char>และback_inserter: 13.5 ms, 13.6 ms
• vector<char> ด้วยตัววนซ้ำธรรมดา: 4.1 ms, 3.9 ms
• vector<char> ตรวจสอบตัววนซ้ำและขอบเขต: 4.0 ms, 4.0 ms
• char[]: 3.57 ms, 3.75 ms

แล็ปท็อปเครื่องเดียวกัน Visual C ++ 2008 SP1 cl /Ox /EHsc:

• ostringstream: 88.7 ms, 87.6 ms
• stringbuf: 23.3 ms, 23.4 ms
• vector<char>และback_inserter: 26.1 ms, 24.5 ms
• vector<char> ด้วยตัววนซ้ำธรรมดา: 3.13 ms, 2.48 ms
• vector<char> ตรวจสอบตัววนซ้ำและขอบเขต: 2.97 ms, 2.53 ms
• char[]: 1.52 ms, 1.25 ms

แล็ปท็อปเครื่องเดียวกันคอมไพเลอร์ Visual C ++ 2010 64 บิต:

• ostringstream: 48.6 ms, 45.0 ms
• stringbuf: 16.2 ms, 16.0 ms
• vector<char>และback_inserter: 26.3 ms, 26.5 ms
• vector<char> ด้วยตัววนซ้ำธรรมดา: 0.87 ms, 0.89 ms
• vector<char> ตรวจสอบตัววนซ้ำและขอบเขต: 0.99 มิลลิวินาที, 0.99 มิลลิวินาที
• char[]: 1.25 ms, 1.24 ms

แก้ไข: ขับรถสองครั้งเพื่อดูว่าผลลัพธ์นั้นสอดคล้องกันเพียงใด IMO ที่สอดคล้องกันค่อนข้างสวย

หมายเหตุ: บนแล็ปท็อปของฉันเนื่องจากฉันสามารถสำรองเวลาของ CPU มากกว่าที่ ideone อนุญาตได้ฉันจึงกำหนดจำนวนการวนซ้ำเป็น 1,000 สำหรับวิธีการทั้งหมด ซึ่งหมายความว่าostringstreamและvectorจัดสรรซึ่งจะมีขึ้นเฉพาะในครั้งแรกผ่านควรมีผลกระทบเพียงเล็กน้อยเกี่ยวกับผลสุดท้าย

แก้ไข: อ๊ะพบข้อผิดพลาดในvector-with-common-iterator ตัววนซ้ำไม่ได้ก้าวหน้าดังนั้นจึงมีแคชจำนวนมากเกินไป ผมสงสัยว่าถูกดีกว่าvector<char> char[]มันไม่ได้สร้างความแตกต่างมากนัก แต่vector<char>ยังเร็วกว่าchar[]ภายใต้ VC ++ 2010

สรุปผลการวิจัย

การบัฟเฟอร์ของเอาต์พุตสตรีมจำเป็นต้องมีสามขั้นตอนในแต่ละครั้งที่มีการผนวกข้อมูล:

• ตรวจสอบว่าบล็อกขาเข้าเหมาะสมกับพื้นที่บัฟเฟอร์ที่มีอยู่
• คัดลอกบล็อกที่เข้ามา
• อัพเดตตัวชี้การสิ้นสุดข้อมูล

ข้อมูลโค้ดล่าสุดที่ฉันโพสต์ "การทำvector<char>ซ้ำง่าย ๆ และการตรวจสอบขอบเขต" ไม่เพียงแค่ทำเช่นนี้ แต่ยังจัดสรรพื้นที่เพิ่มเติมและย้ายข้อมูลที่มีอยู่เมื่อบล็อกขาเข้าไม่พอดี ดังที่ Clifford ระบุไว้การบัฟเฟอร์ในคลาส I / O ไฟล์ไม่จำเป็นต้องทำเช่นนั้นมันจะล้างบัฟเฟอร์ปัจจุบันและนำกลับมาใช้ใหม่ ดังนั้นนี่ควรเป็นขอบเขตบนของต้นทุนของเอาต์พุตบัฟเฟอร์ และเป็นสิ่งที่จำเป็นในการทำให้บัฟเฟอร์ในหน่วยความจำทำงาน

ดังนั้นทำไมstringbuf2.5x ช้าลงบน ideone และอย่างน้อย 10 ครั้งช้าลงเมื่อฉันทดสอบ มันไม่ได้ถูกใช้งานแบบ polymorphically ใน micro-benchmark แบบง่ายๆดังนั้นมันจึงไม่ได้อธิบาย

ไม่ตอบคำถามเฉพาะของคุณมากพอ ๆ กับชื่อเรื่อง: รายงานทางเทคนิคประจำปี 2549 เกี่ยวกับประสิทธิภาพของ C ++มีหัวข้อที่น่าสนใจบน IOStreams (หน้า 64) ส่วนใหญ่เกี่ยวข้องกับคำถามของคุณอยู่ในส่วน 6.1.2 ("ความเร็วการดำเนินการ"):

เนื่องจากลักษณะบางอย่างของการประมวลผล IOStreams มีการกระจายไปในหลายแง่มุมจึงปรากฏว่ามาตรฐานมีการใช้งานที่ไม่มีประสิทธิภาพ แต่นี่ไม่ใช่กรณี - โดยการใช้การประมวลผลล่วงหน้าบางรูปแบบสามารถหลีกเลี่ยงงานส่วนใหญ่ได้ ด้วยตัวเชื่อมโยงที่ชาญฉลาดกว่าปกติเล็กน้อยใช้เป็นไปได้ที่จะลบความไร้ประสิทธิภาพเหล่านี้ออก สิ่งนี้ถูกกล่าวถึงใน§6.2.3และ§6.2.5

นับตั้งแต่มีการเขียนรายงานในปีพ. ศ. 2549 เราหวังว่าจะมีการรวมเอาข้อเสนอแนะจำนวนมากไว้ในคอมไพเลอร์ปัจจุบัน แต่อาจไม่ใช่ในกรณีนี้

ในขณะที่คุณพูดถึง facets อาจไม่ปรากฏในwrite()(แต่ฉันจะไม่ถือว่าสุ่มสี่สุ่มห้า) ดังนั้นคุณสมบัติอะไร การใช้ GProf กับostringstreamโค้ดของคุณที่คอมไพล์ด้วย GCC จะทำให้เกิดการแยกย่อยดังต่อไปนี้:

• 44.23% ใน std::basic_streambuf<char>::xsputn(char const*, int)
• 34.62% ใน std::ostream::write(char const*, int)
• 12.50% ใน main
• 6.73% ใน std::ostream::sentry::sentry(std::ostream&)
• 0.96% ใน std::string::_M_replace_safe(unsigned int, unsigned int, char const*, unsigned int)
• 0.96% ใน std::basic_ostringstream<char>::basic_ostringstream(std::_Ios_Openmode)
• 0.00% ใน std::fpos<int>::fpos(long long)

ดังนั้นจำนวนมากของเวลาที่ใช้xsputnซึ่งในที่สุดโทรstd::copy()หลังจากตรวจสอบจำนวนมากและการปรับปรุงตำแหน่งเคอร์เซอร์และบัฟเฟอร์ (ดูc++\bits\streambuf.tccรายละเอียดใน)

สิ่งที่ฉันทำคือคุณได้มุ่งเน้นไปที่สถานการณ์ที่เลวร้ายที่สุด การตรวจสอบทั้งหมดที่ดำเนินการจะเป็นเพียงส่วนเล็กน้อยของงานทั้งหมดที่ทำถ้าคุณจัดการกับข้อมูลจำนวนมากพอสมควร แต่รหัสของคุณเปลี่ยนข้อมูลเป็นสี่ไบต์ในแต่ละครั้งและทำให้เกิดค่าใช้จ่ายเพิ่มเติมทุกครั้ง เห็นได้ชัดว่าใครจะหลีกเลี่ยงการทำเช่นนั้นในสถานการณ์จริง - พิจารณาว่าความสำคัญน้อยเพียงใดที่จะได้รับโทษหากwriteถูกเรียกใช้อาร์เรย์ 1 ล้าน int แทนที่จะเป็น 1 ล้านครั้งในหนึ่ง int และในสถานการณ์ในชีวิตจริงเราจะต้องชื่นชมคุณสมบัติที่สำคัญของ IOStreams นั่นคือการออกแบบหน่วยความจำที่ปลอดภัยและประเภทที่ปลอดภัย ประโยชน์ดังกล่าวเกิดขึ้นในราคาหนึ่งและคุณได้ทำการทดสอบซึ่งทำให้ค่าใช้จ่ายเหล่านี้มีอิทธิพลต่อเวลาดำเนินการ

ฉันค่อนข้างผิดหวังกับผู้ใช้ Visual Studio ที่ออกไปซึ่งมีความรู้สึกในเรื่องนี้:

• ในการดำเนินงานของ Visual Studio ostreamที่sentryวัตถุ (ซึ่งถูกต้องตามมาตรฐาน) เข้าสู่ส่วนที่สำคัญการปกป้องstreambuf(ซึ่งไม่จำเป็นต้องใช้) ดูเหมือนจะไม่เป็นตัวเลือกดังนั้นคุณจ่ายค่าใช้จ่ายในการซิงโครไนซ์เธรดแม้แต่สตรีมโลคัลที่ใช้โดยเธรดเดี่ยวซึ่งไม่จำเป็นต้องซิงโครไนซ์

รหัสนี้เจ็บที่ใช้ostringstreamในการจัดรูปแบบข้อความค่อนข้างรุนแรง การใช้ตัวstringbufหลีกเลี่ยงการใช้งานโดยตรงsentryแต่ตัวดำเนินการแทรกที่จัดรูปแบบแล้วไม่สามารถทำงานได้โดยตรงบนstreambufs สำหรับ Visual C ++ 2010 ส่วนสำคัญจะชะลอตัวลงostringstream::writeด้วยปัจจัยสามประการกับการstringbuf::sputnโทรพื้นฐาน

เมื่อดูที่ข้อมูลผู้แปลของ beldaz ใน newlibดูเหมือนว่า gcc sentryจะไม่ทำอะไรแบบนี้ ostringstream::writeภายใต้ gcc ใช้เวลานานกว่าประมาณ 50% stringbuf::sputnแต่stringbufตัวเองนั้นช้ากว่าภายใต้ VC ++ มาก และทั้งสองยังคงเปรียบเทียบที่ไม่พึงประสงค์อย่างมากกับการใช้การvector<char>บัฟเฟอร์ I / O แม้ว่าจะไม่เท่ากับระยะขอบเดียวกับใน VC ++

ปัญหาที่คุณเห็นคือทั้งหมดในค่าใช้จ่ายรอบการโทรแต่ละครั้งเพื่อเขียน () แต่ละระดับของสิ่งที่เป็นนามธรรมที่คุณเพิ่ม (อักขระ [] -> เวกเตอร์ -> สตริง -> ostringstream) เพิ่มการเรียก / ส่งคืนฟังก์ชันอีกสองสามครั้ง

ฉันแก้ไขสองตัวอย่างบน ideone เพื่อเขียนสิบ ints ในแต่ละครั้ง เวลา ostringstream เพิ่มขึ้นจาก 53 เป็น 6 ms (ปรับปรุงเกือบ 10 x) ในขณะที่ char loop ปรับปรุง (3.7 เป็น 1.5) - มีประโยชน์ แต่มีเพียงสองปัจจัยเท่านั้น

หากคุณกังวลเกี่ยวกับประสิทธิภาพคุณต้องเลือกเครื่องมือที่เหมาะสมสำหรับงาน ostringstream มีประโยชน์และยืดหยุ่น แต่มีบทลงโทษสำหรับการใช้วิธีที่คุณพยายามทำ char [] นั้นทำงานหนักขึ้น แต่ประสิทธิภาพที่เพิ่มขึ้นนั้นยอดเยี่ยม (โปรดจำไว้ว่า gcc อาจจะรวม memcpys ให้กับคุณเช่นกัน)

กล่าวโดยย่อว่า ostringstream ไม่ได้หัก แต่ยิ่งคุณเข้าใกล้โลหะมากเท่าไหร่รหัสของคุณก็จะยิ่งทำงานเร็วขึ้นเท่านั้น Assembler ยังคงมีข้อได้เปรียบสำหรับชาวบ้านบางคน

เพื่อให้ได้ประสิทธิภาพที่ดีขึ้นคุณต้องเข้าใจว่าคอนเทนเนอร์ที่คุณใช้นั้นทำงานอย่างไร ในตัวอย่างอาร์เรย์ char [] ของคุณอาร์เรย์ของขนาดที่ต้องการถูกจัดสรรล่วงหน้า ในตัวอย่างเวกเตอร์และ ostringstream ของคุณคุณกำลังบังคับให้วัตถุจัดสรรซ้ำและจัดสรรใหม่และอาจคัดลอกข้อมูลหลายครั้งเมื่อวัตถุเติบโต

ด้วย std :: vector นี่จะแก้ไขได้อย่างง่ายดายโดยเริ่มต้นขนาดของเวกเตอร์เป็นขนาดสุดท้ายเมื่อคุณทำชุดอักขระ char; แต่คุณค่อนข้างจะทำลายประสิทธิภาพการทำงานโดยไม่เป็นธรรมโดยปรับขนาดเป็นศูนย์! นั่นเป็นการเปรียบเทียบที่ไม่ยุติธรรมเลย

ด้วยความเคารพต่อ ostringstream การจัดสรรพื้นที่ล่วงหน้านั้นเป็นไปไม่ได้ผมขอแนะนำให้ใช้งานอย่างไม่เหมาะสม ชั้นมียูทิลิตีมากกว่าชุดคำสั่งถ่านแบบง่ายๆ แต่ถ้าคุณไม่ต้องการยูทิลิตี้ตัวนั้นอย่าใช้มันเพราะคุณจะจ่ายค่าโสหุ้ยในทุกกรณี แต่ควรใช้สิ่งที่ดีสำหรับ - จัดรูปแบบข้อมูลลงในสตริง C ++ ให้บริการบรรจุภัณฑ์หลากหลายและ ostringstram เป็นหนึ่งในสิ่งที่เหมาะสมที่สุดสำหรับวัตถุประสงค์นี้

ในกรณีของเวกเตอร์และ ostringstream คุณจะได้รับการป้องกันจากบัฟเฟอร์ที่มากเกินไปคุณจะไม่ได้รับสิ่งนั้นด้วยอาเรย์ถ่านและการป้องกันนั้นไม่ได้มาฟรี