Ahoj,
U posledniho skriptu, jeste by me zajimal pripad promenneho
poctu samotnych vlaken provadejici concatenaci
(vyrozumel jsem ze jich je 8, skript pocet vlaken nezadava).
Cili klidne i jenom jedno bezici "aplikacni" vlakno, ale 1..n
bezich paralelnich vlaken spravce pameti.
Bohuzel mam staricky 1-jadrovy processor :/, tak si sam moc
srandy neuziju.
Proc se na to ptam, jde mi o pripady kdy mate knihovnu treti strany
ktera nema "paralelni implementaci", dejme tomu nejakou dummy knihovnu
pro parsovani a vytvareni dom z xml pricemz ale mate k dispozici
x-jadrovy processor.
Btw. vubec priklad s vytvarenim dom stromu z velkeho ( >50 mb) xml by
byl zajimavy, je jednoduchy a takovy z praxe ;).
Hmm, zkousel jsem, jaky bude mit dopad pouziti paralelnich GC na jednovlaknovou aplikaci (resp. kazda aplikace ma jeste dalsi vlakna - pro RMI atd., ale ted myslim jedno vlakno vytvorene primo programatorem) a v mnoha pripadech to situaci nejak moc nezlepsilo, mnohdy spis zhorsilo, protoze paralelni GC obvykle potrebuje vetsi heap - vic si rekneme priste.
S tim DOM stromem je to zajimavy napad! Myslite pouziti standardnich knihoven z Java API? Musim se mkrnout na implementaci, jak to maji reseny...
Ano, mel jsem na mysli pouziti standardnich knihoven z API.
Nicmene jedna se jen o predpoklad, netusim jak to ma
implemetovano napriklad xerces apod.
Uprimne, prekvapilo by me kdyby nekdo nasel java implementaci
podporujici paralelni tvorbu dom. Co jsem pochopil jedna se
spise o "vyzkumnou" zalezitost (google -> "ParDOM" nebo "PXP").
Pokud nekdo vite o nejake java knihovne porporujci paralelni
tvorbu DOM tak se urcite podelte.