Porovnání výkonu různých variant splay stromů

Gymnázium J. S. Machara Brandýs nad Labem Stará Boleslav Porovnání výkonu různých variant splay stromů ročníková práce Autor práce: Vojtěch Káně Vedoucí práce: Mgr. Martin Mareš, Ph.D. Obor: Informační a komunikační technologie Třída: sexta Brandýs nad Labem 2018

Prohlašuji, že jsem předkládanou ročníkovou práci vypracoval samostatně za využití zdrojů uvedených v seznamu použité literatury. V Brandýse nad Labem Staré Boleslavi dne 9. 2. 2018 Podpis...

Anotace Tato práce si klade za cíl porovnat rychlost operací nad různými variantami splay stromů a některými dalšími podobnými datovými strukturami. Klíčová slova binární vyhledávací stromy, splay stromy

Annotation This paper compares the speed of some operations on various splay trees variants and possibly some other simmilar data structures. Keywords binary search trees, splay trees

Obsah Úvod 6 1.1 Co jsou to stromy............................... 6 1.1.1 Vyhledávání............................. 7 1.1.2 Vkládání............................... 7 1.1.3 Mazání................................ 7 1.1.4 Rotace................................ 8 1.1.5 Časová složitost........................... 8 1.1.6 Amortizace.............................. 9 1.2 Co jsou to splay stromy............................ 9 1.2.1 Operace splay............................. 10 1.2.2 Varianty................................ 11 1.2.3 Nevýhody............................... 12 2 Měření 12 2.1 Technika.................................... 12 2.1.1 Nedostatky.............................. 13 2.2 Výsledky................................... 13 2.2.1 Poznámky k výsledkům....................... 14 3 Závěr 16 Seznam použité literatury 17 Přílohy 18

Úvod Svou prací bych rád navázal na pány Daniel Dominic Sleator a Robert Endre Tarjan, kteří v roce 1985 ve své práci Self-Adjusting Binary Search Trees 1 popsali tzv. Splay stromy. Jedná se o samovyvažovací binární stromy, jež slibují amortizovaný čas O(log N) na nalezení, přidání i smazání prvku. Ve své práci popisují několik různých variant, jak splay stromy realizovat. Jednotlivé možnosti se příliš neliší z pohledu teoretické informatiky, avšak jejich výsledky budou v praxi nejspíše odlišné. Rozhodl jsem se některé z nich naimplementovat a proměřit, na následujících stranách představím výsledky. Začnu rychlým přiblížením několika pojmů; pokusím se je shrnout co možná nejstručněji, a to i za cenu menších nepřesností. Pro podrobný výklad doporučuji si přečíst Průvodce labyrintem algoritmů 2 Martina Mareše a Tomáše Vally, kteří navíc všechna svá tvrzení poctivě dokazují, což se do mé práce už nevešlo. 1.1 Co jsou to stromy Pro nás budou nejdůležitější binární vyhledávací stromy (BVS), popíšu je tedy jako celek, pochopení jednotlivých pojmů v tuto chvíli není důležité. Já zde budu pracovat s BVS, jejichž prvky jsou unikátní, usnadní to přemýšlení nad krajními případy, avšak případně rozšíření definice o možnost duplicitních prvků není složité. Každý BVS, není-li prázdný, má svůj kořen a dva podstromy, levý a pravý, jež od sebe striktně rozlišuje. Navíc platí, že všechny prvky levého podstromu jsou menší než kořen a všechny prvky pravého podstromu jsou větší než kořen. Kořenu levého podstromu říkáme levý syn, pro pravý to platí analogicky. Opačný vztah je otec (tedy má-li vrchol v syna s, je v otcem s). Povšimněme si, že jediným prvkem, který nemá otce, je kořen. 1 SLEATOR, Daniel Dominic a Robert Endre TARJAN. Self-adjusting binary search trees. AT&T Bell Laboratories, Murray Hill, NJ, 1958. 2 MAREŠ, Martin a Tomáš VALLA. Průvodce labyrintem algoritmů. Praha: CZ.NIC, z.s.p.o., 2017. CZ.NIC, 15. publikace. ISBN 978-80-88168-19-5. 6

Důležitá je ještě podmínka, že strom neobsahuje cyklus. Tu lze zformulovat tak, že každý syn má nejvýše jednoho otce a že žádný vrchol nemá obsaženého svého otce ve stromu, jehož je sám kořenem. Strom, jehož oba podstromy jsou prázdné, nazýváme list. 1.1.1 Vyhledávání Výše popsaná definice BVS nám umožňuje velmi efektivně (při správném tvaru dokonce optimálně 3 ) vyhledávat. Začneme v kořeni, odpovídá-li prvek v něm tomu hledanému, máme hotovo. V opačném případě podle definice rozhodneme, ve kterém podstromu by měl být (menší prvky jsou v levém, větší v pravém) a hledání zopakujeme v něm. Přejdeme-li takto do prázdného podstromu, můžeme si být jisti, že hledaný prvek neexistuje. 1.1.1.1 Minimum a maximum Minimum je nejlevější prvek BVS. Půjdeme-li od kořene vždy vlevo, první prvek, který nemá levý podstrom, je minimum. Hledání maxima je podobné, nachází se naopak nejvíce vpravo. 1.1.2 Vkládání Prvek se nejprve pokusíme najít. Podaří-li se to, skončíme, v našem stromě může být každý jen jednou. Neúspěch vyhledávání jsme poznali přechodem do prázdného podstromu; to je místo, kam patří, kde by byl, kdyby ho strom obsahoval. Přidáme jej tam, víme, že případné hledání nás přesně na toto místo dovede. 1.1.3 Mazání Znovu se prvek nejprve pokusíme najít. Nenajdeme-li ho, můžeme skončit. V opačném případě: Jedná-li se o list, smažeme ho. 3 Průvodce labyrintem algoritmů. s. 177. 7

Má-li jen jednoho syna, umístíme jej místo mazaného prvku. Ten pak již můžeme smazat. Posledním případem je prvek v oběma podstromy. Najdeme si minimum pravého podstromu (určitě nemá levého syna). Tímto prvkem přepíšeme mazaný a na závěr smažeme nalezené minimum. Také bychom mohli postupovat nalezením maxima levého podstromu (nemá pravého syna). 1.1.4 Rotace V BVS lze provádět tzv. rotace, tedy měnit strukturu stromů tak, aby vlastnosti BVS zůstaly zachovány. Rotace hrany mezi vrcholem v a jeho rodičem p, proběhne v závislosti na jejich vztahu viz příloha Je-li v levým synem p, jako pravý podstrom v umístíme p, jako levý podstrom p umístíme pravý podstrom v. Jinak (v je pravým synem p) jako levý podstrom v umístíme p, jako levý pravý podstrom p umístíme levý podstrom v. Obě dvě operace rotace musí proběhnou atomicky. Dále je třeba upravit rodiče p (existuje-li), aby jako svého nového syna měl v namísto p. Ukládáme-li si i ukazatele na rodiče, je třeba je odpovídajícně upravit. 1.1.5 Časová složitost Všechny výše uvedené operace mají jedno společné, konstanta-krát vyhledají prvek (hledání minima si můžeme představit jako hledání ) a nakonec provedou konstantně mnoho operací. Protože konstanty při měření časové asymptotické složitosti zanedbáváme, je složitost všech z nich závislá pouze na vyhledávání. Víme, že BVS neobsahuje cykly, nejhůře tedy každý prvek navštívíme jen jednou. To nám dává horní odhad časové složitosti O(N), kde N je počet prvků. Takový případ ale nastane, jen tvoří-li náš strom dlouhou nudli. Co kdybychom si ho však mohli libovolně 8

přeskládat, aby časová složitost byla co nejmenší? Takovému stromu říkáme dokonale vyvážený a vyhledávání v něm trvá Ω(logN) 4. 1.1.6 Amortizace Zatím jsme se časovou slořitostí zabývali jen z pohledu jedné operace, ptali jsme se např. Jak dlouho trvá vložení jednoho prvku v závislosti na počtu všech prvků ve stromu?. Takové otázky jsou celkem běžné a jsou velmi důležité pro pochopení rychlosti dané datové struktury. Někdy však můžeme tímto způsobem vyloučit i velmi dobré kousky, protože otázka, která nás zajímá častěji, je spíše Jak dlouho poběží celý tenhle program?. Mějme například pole. Pole je datové struktura tvořená N očíslovanými pamět ovými chlívečky, kam lze ukládat data. Přidat prvek na konec ještě nenaplňeného pole je triviální operace - přečtení a zapsání toho prvku. Jakmile se však naplní, je třeba vytvořit nové, větší pole, my zvolíme velikost 2N, a následně prvky jeden po druhém překopírovat. Informatici samozřejmě uvažují o nejhorších případech a operaci přidejnakonec přiřadí horní odhad časové složitosti O(log N). To je zcela nepochybně pravda, avšak reálné rychlosti pole bychom velmi křivdili. Ke zvětšování pole dochází jen jednou za čas a s rostoucí složitostí jednoho zvětšení (rostoucím N) klesá jeho četnost. Provedeme-li dostatek operací, můžeme mezi ně čas na zvětšování rozpočítat tak, aby čas na jednu operaci byl konstantní. Struktura je pořád stejná, ale my si na ni ceníme jiných kvalit. Stále se může stát, že jedno přidání vyvolá dlouhé zvětšování, ale při pohledu na celkový čas série operací nebudeme schopni popřít tvrzení, že jedna operace trvá její amortizovaný čas. Toho využijeme při následující analýze 1.2 Co jsou to splay stromy Je patrné, že mají-li BVS v něčemu být, musíme je udržovat co nejvyváženější. Bohužel ani vkládání, ani mazání prvku tyto požadavky nerespektuje. Na druhou stranu, vkládání přidá prvek přesně na to místo, kam patří, kdekoli jinde bychom ho nenašli a porušili tím jednu ze základních vlastností BVS. 4 Průvodce labyrintem algoritmů. s. 177-183. 9

Datovým strukturám, které vycházejí z BVS, avšak zavádějí ještě další podmínky a operace, aby udežely co nejlepší tvar, říkáme samovyvažovací. Myšlenek kolem nich je více, např. ukládat více klíčů v jednom kořeni (červeno-černé stromy), nebo udržovat strom téměř dokonale vyvážený (AVL stromy).my se však zaměříme na splay stromy, jež každé hledání, vkládání, nebo mazání zakončí operací splay. Více o ní v následující kapitole. Časová složitost na jednu operaci je stále O(N), avšak amortizovaná už O(log N). Operaci splay je možné přiúčtovat předcházející operaci, a protože se následující operace urychlují, je možné pomalé popárovat v rychlými tak, aby vyšla zmíněná amortizovaná složitost. 1.2.1 Operace splay Pro úplnost ještě popíšu, jak vlastně zmíněné splayování probíhá. Cílem je dostat splayovaný prvek do do kořene. Postupnými rotacemi prvku se svým rodičem jej lze dostat do kořene. K této metodě uvádí Allan B. a Munro následující komentář Unfortunately, neither of these heuristics is efficient in an amortized sense: for each, there are arbitrarily long access sequences such that the time per access is O(N) Sleator a Tarjan navrhují jinou metodu, taktéž založenou na rotacích: dokud není prvek kořenem, opakujeme: Je-li rodič daného prvku kořenem, zrotujeme hranu mezi ním a jeho rodičem Jinak, je-li daný prvek levým synem svého rodiče a ten je levým synem svého rodiče, nebo opačně (daný prvek je pravým synem svého rodiče a ten je pravým synem svého rodiče), zrotujeme nejprve hranu mezi rodičem a jeho rodičem, následně mezi daným prvkem a jeho rodičem. (tato varianta je v textu označována jako zig-zig) Jinak zrotujeme hranu mezi prvkem a jeho rodičem a následně znovu v novým rodičem (tato operace je v textu označována jako zig-zag) 10

1.2.2 Varianty Výše popsané provedení operace splay je pouze tím prvotním a, dle mého názoru, nejjednodušším na pochopení. Autoři ve své práci popisují různé obměny v cílem splayování zrychlit a zároveň to nejméně nabourat vlastnosti splay stromů. V této podkapitole zmíním ty, jež zahrnu do porovnávání. 1.2.2.1 Normální splayování Splayování tak, jak jsem ho popsal. Nejprve proběhne požadovaná operace, následně splay. Dle autorů je pomalejší než splayování shora dolů, ale je jednodušší na implementaci. 1.2.2.2 Splayování shora dolů Velmi blízké normálnímu splayování, ale rotujeme hrany již v průběhu provádění požadované operace v zatímco se zanořujeme do stromu. Autoři předpokládají pozitivní dopad na efektivitu, avšak své tvrzení nijak nedokazují. Naopak jako nevýhodu uvádějí větší složitost implementace. 1.2.2.3 Poloviční splayování (semisplaying) Abychom vyvažováním stromu netrávili příliš času, zrotujeme pouze polovinu hran, čímž se splayovaný prvek nestane kořenem, ale posune se ve stromu vzhůru. Košatění stromu samozřejmě probíhá pomaleji, ale splayování je rychlejší. 1.2.2.4 Splayování pouze dlouhých cest Splayujeme pouze neobvykle dlouhé cesty. Definice dlouhé cesty vyžaduje dle mého názoru hlubší vhled do splay stromů a navíc využívá mnoho pojmů definovaných ve zmíněném dokumentu. Proto ji zde neuvedu. 1.2.2.5 Splayování pouze několika prvních přístupů Zde se vychází z předpokladu, že struktura se po většinu času nachází v docela dobrém stavu, takže stačí, když budeme splayovat pouze prvních j 1 přístupů a následně se v ní stavět, jako v obyčejnému BVS. 11

1.2.3 Nevýhody Pro úplnost ještě uvedu velkou nevýhodu splay stromů. Zatímco na klasickém BVS může probíhat neomezeně mnoho paralelních vyhledávání a jednoduchým zamykáním i neomezeně mnoho vkládání, splay stromy mění v průběhu operací svou strukturu, proto by musel být veškerý přístup serializován. Neznám žádný způsob paralelního mazání z BVS, pro mnoho použití to však nemusí být překážka. Splay strom paralelní mazání taktéž nepodporuje. Dále se může stát, že v našem použití splay stromů (at už co se týče pravidelností přístupů, nebo dat, se kterými pracujeme) trávíme restrukturalizací zbytečně mnoho času, přičemž naplno nevyužíváme její přínos. 2 Měření V čase vyhrazeném na zpracování práce se mi nepodařilo naimplementovat všechny předpokládané varianty. Měřil jsem tedy pouze Normální splayování a Splayování pouze několika prvních přístupů, a pro srovnání ještě obyčejný BVS. 2.1 Technika Jako jazyk pro implementaci jsem zvolil Go. Umožňuje mi psát dostatečně nízkoúrovňově pro dosažení přijatelného výkonu, avšak v garbage collectingem a pamět ovou bezpečností, což velmi usnadňuje předcházení chybám a jejich případné hledání. Všechny potřebné algoritmy jsem implementoval iterativně, rekurzivní implementace jsou pomalejší, navíc splayování mění tvar stromu, čímž rekurzivní algoritmy významně komplikuje. Až na uvedené výjimky byly všechny testy provedeny se stejným, na začátku náhodně vygenerovaným vstupem. Ten je vždy nejprve celý načten do operační paměti, takže přístupové časy k disku nehrají roli. 12

V případě Splayování pouze několika prvních přístupů jsem j zvolil 1 % z celkového množství operací. Toto si v praxi často nemůžeme dovolit, protože předem nevíme, kolik operací provedeme. 2.1.1 Nedostatky Vhodnější implementací operace splay (zdola nahoru i shora dolů) lze ušetřit jednu rotaci v případě zig-zag 5. Pro plné prozkoumání možností splay stromů by bylo potřeba otestovat mnohem více různých vzorů přístupů, obzvláště s ohledem na jejich vlastnosti a na specifika různých reálných uplatnění. 2.2 Výsledky BenchmarkSimpleBST_Insert BenchmarkSimpleBST_OrderedInsert BenchmarkSimpleBST_Get BenchmarkSimpleBST_OrderedGet BenchmarkSimpleBST_RepeatedGet BenchmarkSimpleBST_SequenceInsert BenchmarkSplayTree_Insert BenchmarkSplayTree_OrderedInsert BenchmarkSplayTree_Get BenchmarkSplayTree_OrderedGet BenchmarkSplayTree_RepeatedGet BenchmarkSplayTree_SequenceInsert 18371398341 ns/op ( 18.4 s/op) 15915333869 ns/op ( 15.9 s/op) 16337181860 ns/op ( 16.3 s/op) 15946855820 ns/op ( 15.9 s/op) 17344792292 ns/op ( 17.3 s/op) 26191078216 ns/op ( 26.2 s/op) 27110106574 ns/op ( 27.1 s/op) 23849462981 ns/op ( 23.8 s/op) 29003807108 ns/op ( 29 s/op) 29241069638 ns/op ( 29.2 s/op) 28943090911 ns/op ( 28.9 s/op) 22275826 ns/op ( 22.3 ms/op) 5 Self-Adjusting Binary Search Trees s. 667 13

BenchmarkSplayTreeFixed_Insert BenchmarkSplayTreeFixed_OrderedInsert BenchmarkSplayTreeFixed_Get BenchmarkSplayTreeFixed_OrderedGet BenchmarkSplayTreeFixed_RepeatedGet BenchmarkSplayTreeFixed_SequenceInsert 18649018685 ns/op ( 18.6 s/op) 16493115278 ns/op ( 16.5 s/op) 17849848084 ns/op ( 17.8 s/op) 17329320855 ns/op ( 17.8 s/op) 17845391719 ns/op ( 17.3 s/op) 25467689379 ns/op ( 25.5 s/op) Měření *_Insert a *_Get vkládají, či hledají již vložená data, v originálním pořadí, tedy náhodně vygenerovaná. Měření *_OrderedInsert a *_OrderedGet nejprve vstupní data vzestupně seřadí (řazení se nepočítá do stráveného času). Měření *_RepeatedGet vždy najde jeden prvek a následně se zeptá na sto předchozích od prvku, na který se přistoupilo naposledy, po ten před 100 iteracemi. Měření *_SequenceInsert je zmíněnou výjimkou, která nepracuje nad náhodnými vstupními daty, ale pracuje s čísly 0; 100000 Z ve vzestupném pořadí. 2.2.1 Poznámky k výsledkům BST (z anglického Binary Search Tree) odpovídá mnou používanému BVS Velmi překvapivě mohou půsomit měření *_SequenceInsert, kdy najednou splay strom, jež ve všech ostatních měřeních vychází hůře, než BVS, oba soupeře překoná ±1000, avšak vysvětlení je snadné. V takto specifickém případě totiž do splay stromu vždy přihazujeme prvek, který je větší, než všechny již obsažené. Stačí, když si vzpomeneme, že každé vkládání je zakončeno splayováním, které vytáhne prvek do kořene. Vzhledem k tomu, že se zároveň jedná o maximum, nemá pravý podstrom. Následující vkládání vkládá prvek, který je určite větší, než kořen, proto jej hledá v pravém podstromu, který je prázdný. Vloží jej tedy a provede jedinou rotaci. Takto se cyklus opakuje, takže každé vkládání trvá zaručeně konstantní čas (O(log N)), proto celá sekvence trvá O(log N). Naopak pro BVS se jedná o nejhorší možný případ, protože, vzhledem k tomu že nedochází k rotacím, jsou všechny prvky jediným (pravým) synem svého rodiče, čímž se nám ze stromu stává prakticky spojový seznam. Přidání jednoho prvku musí projít všechny předchozí, trvá tedy O(N). Celá sekvence pak skončí jako O(N 2 ). 14

Důležitá může být také role procesorové cache, bylo by však třeba dalšího zkoumání k určení jejího skutečného vlivu 15

3 Závěr Obecně se ukázalo, že ačkoli amortizovaná asymptotická složitost splay stromů je lepší než asymptotická složitost BVS, pro měřené operace pří počtu prvků 13 10 6 vycházejí lépe BVS. Předpokládám, že to je způsobeno tím, že konstanty zanedbané při určování asymptotické složitosti jsou příliš velké na to, aby při tomto počtu prvků vyhrálo asymptoticky lepší řešení. Toto tvrzení podporuje i článek When to use splay trees 6. Dokončením mé práce v plném rozsahu by mohlo splay stromům přilepšit (i zmíněný dokument používá variantu splayování shora dolů) avšak je velmi nepravděpodobné, že by rozdíl byl tak markantní, aby při stejném měření překonaly BVS. 6 LEE, Eric K. a Charles U. MARTEL. When to use splay trees. Department of Computer Science, University of California at Davis, Davis, CA 95618, U.S.A. 16

Seznam použité literatury LEATOR, Daniel Dominic a Robert Endre TARJAN. Self-adjusting binary search trees. AT&T Bell Laboratories, Murray Hill, NJ, 1958. MAREŠ, Martin a Tomáš VALLA. Průvodce labyrintem algoritmů. Praha: CZ.NIC, z.s.p.o., 2017. CZ.NIC, 15. publikace. ISBN 978-80-88168-19-5.. LEE, Eric K. a Charles U. MARTEL. When to use splay trees. Department of Computer Science, University of California at Davis, Davis, CA 95618, U.S.A. 17

Přílohy Příloha 1 b a c a je kořenem stromu d,e, f jsou listy b je levým synem a, d je levým synem b e je pravým synem b, c je pravým synem a, f je pravým synem c d e f 18