[Talk-cz] Vizualizace aktivity v OSM

[BH]

On 07/10/2008, Petr Nejedly <Petr.Nejedly na sun.com> 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