Left-Leaning Red-Black tree (diskuse)

[Ladicek]

Ještě mazání

Ne, když jsem dneska viděl prvně ten paper (iniciativně jsem si ho vyhledal po zmínce v té předchozí diskusi), dost mne překvapilo, jak jednoduchá ta implementace je. I like this!

[deda.jabko]

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. ;-]

[AltOS]

Absolutne k veci (TM):

...je prosta, jak bulharska stripterka...

Plati to jeste dnes?

[Deleted [8409]]

Nebylo by lepší reorganizovat ten uzel takto?

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á).

[deda.jabko]

v tomto pripade to pomuze... v realnem kodu to mam stejne delane uplne jinak...

jinak resit takove veci v ukazkovem prikladu pro deset polozek imho patri do kategorie ,,premature optimization'' a mozna i ,,immature'' ;-]

[thingie]

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.

[deda.jabko]

psát kód který má být tuším čistě jen ukázkou datové struktury

ten 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éčku

ted 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

[thingie]

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í.)

[zde]

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).

[deda.jabko]

mas to nekde naimplementovane? rad bych to srovnal v realu...

[zde]

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?