ข้ามรายการเทียบกับแผนภูมิการค้นหาแบบไบนารี

ฉันเพิ่งมาข้ามโครงสร้างข้อมูลที่รู้จักกันเป็นรายการเฮี๊ยบ ดูเหมือนว่าจะมีพฤติกรรมที่คล้ายกันมากกับแผนภูมิการค้นหาแบบไบนารี

ทำไมคุณถึงต้องการใช้รายการข้ามข้ามแผนภูมิการค้นหาแบบไบนารี

รายการข้ามมีความสอดคล้องกับการเข้าถึง / การแก้ไขพร้อมกันมากขึ้น Herb Sutter เขียนบทความเกี่ยวกับโครงสร้างข้อมูลในสภาพแวดล้อมพร้อมกัน มันมีข้อมูลเชิงลึกมากขึ้น

การดำเนินงานที่ใช้บ่อยที่สุดของต้นไม้ค้นหาแบบทวิภาคเป็นต้นไม้แดงดำ ปัญหาที่เกิดขึ้นพร้อมกันเกิดขึ้นเมื่อต้นไม้มีการปรับเปลี่ยนบ่อยครั้งจำเป็นต้องปรับสมดุล การดำเนินการ rebalance สามารถส่งผลกระทบต่อส่วนใหญ่ของต้นไม้ซึ่งจะต้องมีการล็อก mutex บนโหนดของต้นไม้จำนวนมาก การแทรกโหนดลงในรายการข้ามจะมีการแปลที่ไกลกว่านั้นเฉพาะโหนดที่เชื่อมโยงโดยตรงกับโหนดที่ได้รับผลกระทบจะต้องถูกล็อค

อัปเดตจากความคิดเห็น Jon Harrops

ผมอ่านเฟรเซอร์และแฮร์ริสกระดาษล่าสุดการเขียนโปรแกรมพร้อมกันโดยไม่ต้องล็อค สิ่งที่ดีจริงๆถ้าคุณสนใจโครงสร้างข้อมูลที่ไม่ล็อค กระดาษมุ่งเน้นไปที่หน่วยความจำของทรานแซคชันและการดำเนินการทางทฤษฎี MCSE แบบหลายคำเปรียบเทียบและสลับ ทั้งสองแบบจำลองเป็นซอฟต์แวร์เนื่องจากไม่มีฮาร์ดแวร์รองรับ ฉันค่อนข้างประทับใจว่าพวกเขาสามารถสร้าง MCAS ในซอฟต์แวร์ได้เลย

ฉันไม่พบสิ่งที่หน่วยความจำทรานแซคชันที่น่าสนใจเป็นพิเศษเพราะมันต้องมีตัวรวบรวมขยะ นอกจากนี้ยังมีซอฟแวร์หน่วยความจำในการทำธุรกรรมเป็นโรคที่มีปัญหาเรื่องประสิทธิภาพ อย่างไรก็ตามฉันจะตื่นเต้นมากถ้าหน่วยความจำทรานแซคชันของฮาร์ดแวร์กลายเป็นเรื่องปกติ ในที่สุดก็ยังคงวิจัยและจะไม่ใช้รหัสการผลิตอีกสิบปีหรือมากกว่านั้น

ในส่วนที่ 8.2 พวกเขาเปรียบเทียบประสิทธิภาพของการนำต้นไม้ไปใช้งานพร้อมกันหลายแห่ง ฉันจะสรุปสิ่งที่ค้นพบ มันคุ้มค่าที่จะดาวน์โหลด pdf เนื่องจากมันมีกราฟข้อมูลบางอย่างในหน้า 50, 53 และ 54

• การล็อกรายการข้ามอย่างรวดเร็วอย่างบ้าคลั่ง พวกมันมีขนาดที่ดีอย่างเหลือเชื่อด้วยจำนวนการเข้าถึงพร้อมกัน นี่คือสิ่งที่ทำให้ข้ามรายการพิเศษโครงสร้างข้อมูลล็อคอื่น ๆ มักจะบ่นภายใต้ความกดดัน
• รายการข้ามที่ล็อคฟรีนั้นเร็วกว่าการล็อครายการข้ามอย่างสม่ำเสมอ แต่แทบจะไม่
• รายการข้ามธุรกรรมจะช้ากว่าการล็อกและไม่ล็อคอย่างสม่ำเสมอ 2-3 เท่า
• ล็อคต้นไม้สีแดงดำภายใต้การเข้าถึงพร้อมกัน ประสิทธิภาพของพวกเขาลดลงเป็นเส้นตรงกับผู้ใช้งานใหม่พร้อมกันแต่ละราย ของทั้งสองรู้จักการล็อคการใช้งานต้นไม้สีแดงสีดำหนึ่งเป็นหลักมีการล็อคระดับโลกในระหว่างการปรับสมดุลต้นไม้ ส่วนอีกอันใช้การเพิ่มระดับการล็อคแฟนซี (และซับซ้อน) แต่ก็ยังไม่สามารถทำการล็อคได้ในระดับโลก
• ไม่มีต้นไม้สีแดงสีดำล็อค (ไม่มีจริงอีกต่อไปให้ดูอัปเดต)
• ต้นไม้สีแดงสีดำของธุรกรรมเทียบเคียงได้กับรายการข้ามธุรกรรม นั่นเป็นเรื่องที่น่าประหลาดใจและมีแนวโน้มมาก หน่วยความจำของทรานแซคชันแม้ว่าจะเขียนช้ากว่า สามารถค้นหาได้ง่ายและรวดเร็วแทนที่เวอร์ชันที่ไม่ทำงานพร้อมกัน

ปรับปรุง
นี่คือกระดาษเกี่ยวกับต้นไม้ล็อคฟรี: ล็อคฟรี Red-Black ต้นไม้ใช้ CAS
ฉันไม่ได้มองลึกลงไป แต่บนพื้นผิวมันดูแข็งแรง

ขั้นแรกคุณไม่สามารถเปรียบเทียบโครงสร้างข้อมูลแบบสุ่มกับโครงสร้างที่ให้การรับประกันในกรณีที่เลวร้ายที่สุด

รายการเฮี๊ยบเทียบเท่ากับต้นไม้ค้นหาสมดุลสุ่มไบนารี (rBST) ในทางที่จะมีการอธิบายในรายละเอียดในคณบดีและโจนส์'สำรวจคู่ระหว่างรายการข้ามและค้นหาแบบไบนารีต้นไม้'

อีกวิธีหนึ่งคุณสามารถมีรายการข้ามที่กำหนดได้ซึ่งรับประกันประสิทธิภาพของกรณีที่แย่ที่สุด cf มันโรและคณะ

ในทางตรงกันข้ามกับสิ่งที่มีการอ้างสิทธิ์ข้างต้นคุณสามารถมีการใช้งานของต้นไม้ค้นหาแบบทวิภาค (BST) ที่ทำงานได้ดีในการเขียนโปรแกรมพร้อมกัน ปัญหาที่อาจเกิดขึ้นกับ BST ที่มุ่งเน้นพร้อมกันคือการที่คุณไม่สามารถรับสิ่งเดียวกันได้อย่างง่ายดายโดยมีการรับประกันเกี่ยวกับการสร้างสมดุลย์อย่างที่คุณต้องการจากต้นไม้สีแดงดำ (RB) (แต่ "มาตรฐาน" คือการสุ่มแบบสุ่มรายการข้ามไม่ได้รับประกันสิ่งเหล่านี้) มีการแลกเปลี่ยนระหว่างการรักษาสมดุลตลอดเวลาและการเข้าถึงที่ดี (และง่ายต่อการโปรแกรม) พร้อมกันดังนั้นต้นไม้ RB ที่ผ่อนคลายจึงมักจะใช้ เมื่อต้องการพร้อมกันที่ดี การพักผ่อนประกอบไปด้วยการไม่ปรับสมดุลต้นไม้ในทันที สำหรับวันที่ค่อนข้าง (1998) สำรวจดูฮานเค่ของ '' ประสิทธิภาพการทำงานของพร้อมกันสีแดงสีดำทรีอัลกอริทึม '' [ps.gz]

หนึ่งในการปรับปรุงล่าสุดของต้นไม้เหล่านี้คือต้นไม้สี (โดยทั่วไปคุณมีน้ำหนักบางอย่างเช่นสีดำจะเป็น 1 และสีแดงจะเป็นศูนย์ แต่คุณก็อนุญาตค่าได้ด้วย) และต้นไม้ค่ารงค์กับรายการข้ามอย่างไร ลองดูว่าบราวน์และคณะ "เทคนิคทั่วไปสำหรับต้นไม้ที่ไม่มีการบล็อก" (2014) ต้องกล่าวว่า:

ด้วย 128 เธรดอัลกอริทึมของเรามีประสิทธิภาพเหนือกว่า skiplist ที่ไม่บล็อกของ Java 13% ถึง 156% ต้นไม้ AVL แบบล็อคที่ใช้งานได้ของ Bronson et al เพิ่มขึ้น 63% ถึง 224% และ RBT ที่ใช้หน่วยความจำ transactional ซอฟต์แวร์ (STM) 13 ถึง 134 ครั้ง

แก้ไขเพื่อเพิ่ม: รายการข้ามล็อคของ Pugh ซึ่งได้รับการเปรียบเทียบใน Fraser and Harris (2007) "Concurrent Programming Without Lock"ซึ่งใกล้เคียงกับเวอร์ชั่นล็อคฟรีของพวกเขา (จุดที่ยืนยันอย่างชัดเจนในคำตอบที่ดีที่สุดที่นี่) มีการปรับแต่งเพื่อการทำงานพร้อมกันที่ดีเช่นกัน Pugh's "การบำรุงรักษาข้ามรายการที่เกิดขึ้นพร้อมกัน"แม้ว่าจะค่อนข้างรุนแรง อย่างไรก็ตามบทความใหม่ / 2009 ฉบับหนึ่ง "อัลกอริธึมการข้ามรายการแบบง่ายในแง่ดี"โดย Herlihy et al. ซึ่งเสนอการดำเนินการตามล็อคแบบง่าย ๆ (มากกว่าของพัคห์) ของรายการข้ามพร้อมกันวิพากษ์วิจารณ์พัคห์สที่ไม่ได้พิสูจน์ความถูกต้องที่น่าเชื่อถือเพียงพอสำหรับพวกเขา ปล่อยให้เรื่องนี้เฉื่อยชา (อาจจะอวดอ้าง), Herlihy และคณะ แสดงให้เห็นว่าการใช้งานแบบล็อคที่ง่ายกว่าของพวกเขาในรายการข้ามนั้นล้มเหลวในการปรับขนาดเช่นเดียวกับการใช้งานล็อคฟรีของ JDK แต่สำหรับการโต้แย้งสูง (แทรก 50%, ลบ 50% และค้นหา 0%) ... ที่ Fraser และแฮร์ริสก็ไม่ได้ทดสอบเลย เฟรเซอร์และแฮร์ริสทดสอบการค้นหา 75% เท่านั้นแทรก 12.5% ​​และลบ 12.5% ​​(ในรายการข้ามที่มีองค์ประกอบ ~ 500K) การนำ Herlihy และคณะมาใช้ง่ายกว่า ยังใกล้เคียงกับโซลูชันล็อคฟรีจาก JDK ในกรณีที่มีการช่วงชิงต่ำที่พวกเขาทดสอบ (การค้นหา 70%, การแทรก 20%, การลบ 10%); พวกเขาเอาชนะโซลูชันล็อคฟรีสำหรับสถานการณ์นี้เมื่อพวกเขาทำให้รายการข้ามของพวกเขามีขนาดใหญ่พอเช่นจากองค์ประกอบ 200K ถึง 2M เพื่อให้ความน่าจะเป็นของการโต้แย้งในการล็อกใด ๆ นั้นน้อยมาก คงจะดีถ้า Herlihy และคณะ ได้รับการแฮงค์ของพวกเขามากกว่าการพิสูจน์ของพัคห์และทดสอบการใช้งานของเขาด้วยแต่ทว่าพวกเขาไม่ได้ทำเช่นนั้น

EDIT2: ฉันพบ Motherlode (เผยแพร่เมื่อปี 2558) ของมาตรฐานทั้งหมด: Gramoli ของ"มากกว่าที่คุณเคยต้องการรู้เกี่ยวกับการซิงโครไนซ์ Synchrobench การวัดผลกระทบของการซิงโครไนซ์กับอัลกอริทึมพร้อมกัน" : นี่เป็นภาพที่คัดลอกมา

"Algo.4" เป็นสารตั้งต้น (เก่ากว่ารุ่น 2011) ของ Brown et al. ดังกล่าวข้างต้น (ฉันไม่รู้ว่าเวอร์ชั่น 2014 ดีกว่าหรือแย่กว่านี้มากเพียงใด) "Algo.26" คือคำกล่าวของ Herlihy; อย่างที่คุณเห็นว่ามันได้รับการทิ้งลงถังขยะในการอัปเดตและยิ่งแย่กว่าในซีพียู Intel ที่ใช้ที่นี่มากกว่าบนซีพียู Sun จากเอกสารต้นฉบับ "Algo.28" คือ ConcurrentSkipListMap จาก JDK; มันไม่ได้ทำไปอย่างที่คาดหวังเอาไว้เมื่อเปรียบเทียบกับการใช้งานข้ามรายการอื่น ๆ ของ CAS ผู้ชนะภายใต้ข้อพิพาทสูงคือ "Algo.2" อัลกอริทึมแบบล็อค (!!) ที่อธิบายโดย Crain และคณะ ใน"ช่วงชิง-Friendly ค้นหาแบบไบนารีทรี"และ "Algo.30" คือ "หมุน skiplist" จาก"โครงสร้างข้อมูลลอการิทึมสำหรับ multicores" ". โปรดทราบว่า Gramoli เป็นผู้เขียนร่วมให้กับเอกสารชนะทั้งสามชุดนี้ "Algo.27" เป็นการใช้งาน C ++ ของรายการข้ามของ Fraser

ข้อสรุปของ Gramoli นั้นง่ายกว่ามากที่จะทำให้การติดตั้งต้นไม้ที่ใช้ CAS พร้อมกันได้ง่ายกว่าการใช้วิธีข้ามรายการข้ามที่คล้ายกัน และจากตัวเลขแล้วมันก็ยากที่จะไม่เห็นด้วย คำอธิบายของเขาสำหรับความจริงข้อนี้คือ:

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

การเอาชนะความยากลำบากนี้เป็นข้อกังวลหลักในงานล่าสุดของ Brown และคณะ พวกเขามีทั้งกระดาษ (2013) ที่แยกต่างหาก"Pragmatic Primitives สำหรับ Non-blocking Data Structures" ในการสร้าง LLT / สารประกอบ LL / SC หลายระเบียนแบบบันทึกซึ่งเรียกว่า LLX / SCX ซึ่งถูกใช้งานด้วย CAS ระดับเครื่อง บราวน์และคณะ ใช้ Building Block LLX / SCX นี้ในปี 2014 (แต่ไม่ได้อยู่ใน 2011) การติดตั้งแผนผังพร้อมกัน

ฉันคิดว่ามันอาจจะคุ้มค่าที่จะสรุปความคิดพื้นฐานของรายการ"ไม่มีจุดร้อน" / การข้ามเนื้อหาที่เป็นมิตร (CF). มันเพิ่มความคิดที่สำคัญจากต้นไม้ RB ที่ผ่อนคลาย (และโครงสร้างข้อมูลที่คล้ายกันอย่างคร่าว ๆ คล้ายกัน): หอคอยไม่ได้ถูกสร้างขึ้นอีกต่อไปทันทีเมื่อมีการแทรก แต่ล่าช้าจนกว่าจะมีความขัดแย้งน้อยลง ในทางกลับกันการลบหอคอยสูงสามารถสร้างความขัดแย้งมากมาย นี่เป็นข้อสังเกตที่ไกลที่สุดเท่าที่ Pugh's 1990 กระดาษ skip-list ที่เกิดขึ้นพร้อมกันซึ่งเป็นเหตุผลที่ Pugh แนะนำการย้อนกลับของตัวชี้เมื่อมีการลบ รายการการข้าม CF ใช้ขั้นตอนนี้ต่อไปและเลื่อนระดับชั้นบนของหอคอยสูงออกไป การดำเนินการล่าช้าทั้งสองประเภทในรายการข้ามของ CF นั้นดำเนินการโดยเธรด (แยกตาม CAS) แยกกันซึ่งผู้เขียนเรียกว่า "การปรับเธรด"

รหัส Synchrobench (รวมถึงขั้นตอนวิธีการทดสอบทั้งหมด) มีอยู่ที่: https://github.com/gramoli/synchrobench Brown et al ล่าสุด การนำไปใช้งาน (ไม่รวมอยู่ในข้างต้น) มีให้บริการที่http://www.cs.toronto.edu/~tabrown/chromatic/ConcurrentChromaticTreeMap.javaมีใครบ้างที่มีเครื่อง 32+ คอร์? J / K ประเด็นของฉันคือคุณสามารถวิ่งได้ด้วยตัวเอง

นอกจากนี้นอกเหนือจากคำตอบที่ให้ (ความง่ายในการใช้งานรวมกับประสิทธิภาพที่เทียบเท่ากับต้นไม้ที่สมดุล) ฉันพบว่าการใช้การข้ามผ่านตามลำดับ (ไปข้างหน้าและข้างหลัง) นั้นง่ายกว่ามากเพราะการข้ามรายการมีประสิทธิภาพมีรายการที่เชื่อมโยงในการนำไปใช้

ในทางปฏิบัติฉันพบว่าประสิทธิภาพแบบ B-tree ในโครงการของฉันนั้นดีกว่าการข้ามรายการ ข้ามไปรายการดูเหมือนง่ายต่อการเข้าใจ แต่การดำเนินการ B ต้นไม้ไม่ได้เป็นที่ยาก

ข้อดีอย่างหนึ่งที่ฉันรู้ก็คือคนฉลาดบางคนคิดวิธีการใช้รายการข้ามพร้อมกันที่ไม่ล็อคที่ใช้เฉพาะการทำงานแบบปรมาณู ตัวอย่างเช่น Java 6 มีคลาส ConcurrentSkipListMap และคุณสามารถอ่านซอร์สโค้ดได้ถ้าคุณบ้า

แต่มันก็ไม่ยากเกินไปที่จะเขียนตัวแปร B-tree ที่เกิดขึ้นพร้อมกันเช่นกัน - ฉันเคยเห็นมันทำโดยคนอื่น - ถ้าคุณแยกและผสานโหนด "ในกรณี" ไว้ล่วงหน้าในขณะที่คุณเดินไปตามต้นไม้คุณจะไม่ต้อง กังวลเกี่ยวกับการหยุดชะงักและเพียงแค่ต้องล็อคในสองระดับของต้นไม้ในเวลา โอเวอร์เฮดการซิงโครไนซ์จะสูงขึ้นเล็กน้อย แต่ทรี B อาจเร็วกว่า

จากบทความWikipedia ที่คุณยกมา:

operations (n) การดำเนินการซึ่งบังคับให้เราเยี่ยมชมทุก ๆ โหนดตามลำดับจากน้อยไปหามาก (เช่นการพิมพ์รายการทั้งหมด) ให้โอกาสในการดำเนินการลดขนาดฉากหลังของโครงสร้างระดับของรายการข้ามในวิธีที่เหมาะสมที่สุด นำรายการข้ามไปที่เวลาค้นหา O (บันทึก n) [... ] รายการข้ามซึ่งเราไม่ได้ดำเนินการ [ใด ๆ ] Θ (n) เมื่อเร็ว ๆ นี้ไม่ได้ให้ผลการปฏิบัติงานที่เลวร้ายที่สุดแน่นอนเหมือนกันกับการรับประกันโครงสร้างต้นไม้แบบดั้งเดิมที่สมดุลเพราะมันเป็นไปได้เสมอ (แม้ว่าจะมีโอกาสน้อยมาก) ที่การโยนเหรียญที่ใช้สร้างรายการข้ามจะสร้างโครงสร้างที่ไม่สมดุล

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

รายการข้ามจะดำเนินการโดยใช้รายการ

มีโซลูชันล็อคฟรีสำหรับรายการที่เชื่อมโยงเดี่ยวและสองครั้ง - แต่ไม่มีโซลูชันล็อกฟรีซึ่งใช้ CAS สำหรับโครงสร้างข้อมูล O (logn) โดยตรงเท่านั้น

อย่างไรก็ตามคุณสามารถใช้รายการที่ใช้ CAS เพื่อสร้างรายการข้ามได้

(โปรดทราบว่า MCAS ซึ่งสร้างขึ้นโดยใช้ CAS อนุญาตให้มีโครงสร้างข้อมูลโดยพลการและมีการสร้างทรีสีแดง - ดำโดยใช้ MCAS)

ดังนั้นแปลกที่พวกเขาพวกเขากลายเป็นประโยชน์มาก :-)

ข้ามรายการมีข้อดีของการลอกล็อค แต่เวลา runt ขึ้นอยู่กับวิธีการตัดสินใจระดับของโหนดใหม่ โดยปกติจะใช้การสุ่ม () ในพจนานุกรมที่มีความยาว 56000 คำข้ามรายการใช้เวลามากกว่าต้นไม้สเปรย์และต้นไม้ใช้เวลามากกว่าตารางแฮช สองคนแรกไม่สามารถจับคู่รันไทม์ของตารางแฮช นอกจากนี้อาเรย์ของตารางแฮชยังสามารถปลดล็อคได้ในเวลาเดียวกัน

รายชื่อข้ามและรายการที่เรียงลำดับคล้ายกันจะใช้เมื่อจำเป็นต้องใช้ตำแหน่งอ้างอิง ตัวอย่างเช่น: ค้นหาเที่ยวบินถัดไปและก่อนวันที่ในแอปพลิเคชัน

แผนภูมิ splay search แบบ inmemory นั้นยอดเยี่ยมและใช้บ่อยกว่า

ข้ามรายการ Vs Splay Tree Vs Hash Table Runtime ใน op ค้นหาพจนานุกรม