Portál AbcLinuxu, 30. dubna 2025 11:26
Ještě mazánílaskavy ctenar si to uz dodela sam.
dost mne překvapilo, jak jednoduchá ta implementace je...taky jsem na to cumel jak puk. ;-]
typedef struct rb_node { struct rb_node * left; struct rb_node * right; int color; int key; char * value; } rb_node;Je to jen drobná změna, která by měla zmenšit celkovou velikosti struktury, pokud je int 32bitový a ukazatel 64bitový o 8 bytů (pokud je pro vás teda paměťová efektivita důležitá).
Ono, psát kód který má být tuším čistě jen ukázkou datové struktury jako smetí v Céčku se dá taky hodnotit všelijak.
psát kód který má být tuším čistě jen ukázkou datové strukturyten kod jsem psal, abych si vyzkousel jestli to opravdu funguje... dal jsem to sem proto, ze kdosi ve vedlejsi diskuzi mel pripominku, ze by bylo dobre se o to podelit, protoze by se to nekomu mohlo hodit... nic vic, nic min. zadne vetsi ambice jsem s timto konkretnim kusem kodu opravdu nemel
jako smetí v Céčkuted nevim jak si to mam vylozit. tim smetim jste mel na mysli: a) ze to neni zoptimalizovane pro 64bitovou architekturu ... viz vyse nebo b) protoze to je v cecku ,,ktere neni prehledne'' ... schvalne si prepiste ten kod treba do javy, c# nebo jineho ,,moderniho jazyka'' ... uvidime jak moc se bude lisit... btw. i v nejakem meta jazyku by to asi nevypadalo o moc jinak
Tak uvádět jako „moderní jazyk“ další a další s C-like zápisem, žejo.
(Ale tak jako jo, nebylo by to jinde nějak zásadně lepší. Leč na věci se toho tolik nemění.)
Implementace je to hezká, ale mě se to stejně moc nepozdává. Oproti normálním nebalancovaným i balancovaným BST je to pořád dost komplikovaný kód, a výhoda že růst uzlů částečně požerou RED linky a bude se o trošku mín rebalancovat mi to nevaváží. To už můžu rovnou místo lepení uzlů těmi horizontálními RED linky vzít nějaký vhodný násobek cacheline, uzly BST do něj skládat jako do vektoru, a budu mít B-strom s relativně malou velikostí stránky. Tahle struktura bude fakticky speciálním případem RB stromu, takže bude mít všechny jejich výhody, a navíc mnohem menší overhead (ušetří se ty červené pointery, a r/b bit).
Bohužel nemám, jen mě to napadlo, když jsem si všiml že ty 2-3-4 stromy jsou fakticky jen B-stromy s fanoutem 4, kde jsou jednotlivé bloky implementovány dalším "červeným" stromem. Poníženě přiznávám že dotěď jsem o RB stromech nic nevěděl a myslel si že jde o něco úplně jiného. Ale hlavně bych zkusil přímé indexování. Ukousnout 12 bitů, indexovat 1k tabulku, ukousnout dalších 12 bitů, indexovat další 1k tabulku, a zbylých 8 bitů použít jako finální index. Začít s prázdnou kořenovou tabulkou, a L2 a L3 tabulky alokovat podle potřeby. Myslím že tohle je ověřeno jako nejvíce efektivní metoda. Problém je jen když poslední bity mají minimální lokalitu, tak to děsně nabobtná. Ale jestli jde o pointery, tak by to mělo fungovat slušně, ne?
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.