On 07/10/2008, Petr Nejedly <[EMAIL PROTECTED]> wrote: > BH napsal(a): > > > U nodu skladuju jako klic ID (zatim se do 32bitu vejde :) a jako > > hodnotu prepocitane souradnice v obrazku (coz se narozdil od 2x double > > vejde s prehledem do 32 bitu). > > Tak jsem to myslel... > > > > Teoreticky min. 8 bajtu/nod, ale je to > > ... ale tady se rozchazime ;-)
Zavisi na velikosti vysledneho obrazku. Pokud generuju neco "rozumne" velikeho, tak se sice do 3 bajtu vejdu, ale zase zadny tribajtovy typ neni (=opruz s posouvanim bitu mezi byte a word = pomale) a 2 bajty jsou malo (256x256 obrazek je moc mrnavy) Nebo kde by se dalo usetrit, krome prime indexace IDckem? > > nejaky overhead u pouzitych datovych struktur. Takze udelat to pro > > planet by asi slo po mensi optimalizaci i na 4gb ram (neco sezere i > > vystupni obrazek, ktery by mel byt pro planet asi velky, aby bylo neco > > videt) > > Moc bitu se uz usetrit neda, pro cely planet a vetsi obrazky se to u > > obou k tem 32 bitm celkem dost blizi (takze 300M nodes=min 2.4gb ram) > > > Vzhledem k tomu, ze set ID je vcelku huste populovany (pokud se bavime > o celem world), nema smysl IDcka drzet a hashovat. ID je samo nejlepsim > "hashem", nody jsou pak jen jednoduchym polem 32bit hodnot prepocitanych > souradnic. > Co node, to jeden int. Chci node 227321453, sahnu na [227321453]. > Spotreba 1.2GB RAM. > > Ale je to hack tak na rok, dva, pak uz zase tech nodu asi bude moc.... To je pravda, to by slo. Mohlo by to vydrzet i dele, vzdyt mame 64bit architektury (na rozumne provozovani vice nez 2 gb ram je stejne tech 64bit potreba), proste se dokoupi pamet :) Ted je ale otazkou jestli budou data v OSM rust rychleji, nez budou klesat ceny pameti .... Ale na mensi kusy zase bude lepsi klasicky hash :) Asi to prepisu do C++, tady zacina perl trochu ztracet dech :) Martin _______________________________________________ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz