[ Mikky @ 06.05.2003. 03:48 ] @
imam rekurzivnu funkciju koja pretrazuje sve direktorijume svih "fixed volumes"-a tj hard diskova
e sad program mora da pretrazi sve fixed drajvove sto je brze moguce, naravno ovde je usko grlo brzina hard diska, pa mi na pamet padaju dve ideje kako ovo izvesti naj efektnije

1. enumerisati sve fixed drajvove i poceti od c:\ pa kad rutina zavrsi sa c: onda pocne pretraga na d: itd... znaci jedan po jedan

2. za svaki fixed volume napraviti po jedan thread i pretraga ce se izvrsavati paralelno na svakom drajvu istovremeno

sad 2. nacin je definitivno bolji od prvog kada imamo dva fizicka hard diska, medjutim mene zanima da li je to isto slucaj i kada imamo jedan hdd a vise particija na njemu? onda ce jedan hdd da paralelno izvrsava pretragu
(posto znamo da windows prepoznaje particije na hardu kao posebne hard diskove)
[ Mihailo @ 06.05.2003. 04:11 ] @
Ako imaš više particija sa više thread-ova možeš samo da usporiš posao. Možda bi to i koristilo kada bi jedna ploča bila jedna particija, pa da svaka glava bistri svoj deo. Ali nije tako već jedna particija je na svim pločama, znači kad radiš tako samo cimaš glave tamo-vamo. Potraži sliku na googlu da pa će ti biti jasno.
[ Rapaic Rajko @ 06.05.2003. 09:36 ] @
Vise thread-ova koji rade na jednom hard disku (setu glava za citanje)...

Pre vise godina sam radio multithread konverziju fajlova (nije tesko, samo dosledan OOP) za mog tadasnjeg poslodavca. Radi, sve je to OK, mada suma ucinka vise thread-ova iznosi koliko i ucinak jednog thread-a (ili manje). E, a cemu onda multithreading? Postoji dobar razlog, a to je ocuvanje (vremenskog) redosleda - kako fajlovi pristizu u target folder(e), tako se i obradjuju (istim redom).

Ali, jedno upozorenje: (nov) hard disk na kome sam to razvijao, testirao i optimizovao riknuo je posle 15 meseci; otisla mu je mehanika, samo je skljocao. Da li zbog ovakvih vratolomija sa thread-ovima, ili je u pitanju losa serija, to ne bih znao. Samo znam da na mom kucnom kompjuteru nisam hteo ni da instaliram taj softver...
Pozdrav

Rajko
[ Gojko Vujovic @ 06.05.2003. 15:40 ] @
Ako je Quantum bio u pitanju, definitivno je problem do te serije, ja sam 2 diska tako izgubio! Samo počnu da škljocaju..
[ tOwk @ 06.05.2003. 16:52 ] @
Citat:
Mihailo:
Ako imaš više particija sa više thread-ova možeš samo da usporiš posao. Možda bi to i koristilo kada bi jedna ploča bila jedna particija, pa da svaka glava bistri svoj deo. Ali nije tako već jedna particija je na svim pločama, znači kad radiš tako samo cimaš glave tamo-vamo. Potraži sliku na googlu da pa će ti biti jasno.


Meni se čini da moderni diskovi imaju vezane glave, pa ni u slučaju da su particije na odvojenim pločama ne bi bilo ubrzanja pošto se sve glave zajedno kreću, a samo jedna čita. Možda bi bilo moguće naterati diskove da svaka glava tada čita, ali to je korisno samo za pretragu „sirovih“ podataka sa diska, pošto nijedan fajlsistem nije tako zgodno organizovan.

Znači, kao što Mihailo već reče, upotreba više niti na jednom disku može samo usporiti posao, a nikako ubrzati (u najboljem slučaju bi se dobila ista brzina).

Ukoliko želiš da praviš ekstra brzu pretragu, preporučujem da se osloniš na „keš“ mehanizam operativnog sistema. Znači, bitno je da znaš kako on radi, i da pregledaš prvo fajlove koji su već u kešu.

Znači, najbolja rešenja za brzu pretragu su indeksiranje i keširanje. Ako za to nemaš mogućnosti, onda preporučujem čitanje „raw“ diska u velikim blokovima (što više može da stane u memoriju, npr. 64MB), i onda pretraga deo po deo. Ovo ima negativnu stranu da moraš da znaš strukturu fajl-sistema, ali performanse mogu biti odlične (neka se spojeni komad diska od 64mb učita za 6 sekundi na sporim diskovima, imaćeš fulltext pretragu za ispod 20 sekundi, naravno zavisi od procesora i memorije, ali suštinski eliminišeš disk kao usko grlo).
[ Mikky @ 07.05.2003. 22:19 ] @
ok tako sam i mislio, znaci koristicu samo jedan thread

inace moja funkcija koristi win32 api FindFirstFile/FindNextFile
tako da nemam tih mogucnosti da direktno pristupam kesu, direktno citanje sa hdd itd

[ leka @ 19.05.2003. 17:09 ] @
Opet tema nema veze sa teorijom programiranja :( Ovo je diskusiona grupa sa NAJVISE PROMASENIH tema! Definitivno!

Evo da sada na primeru objasnim kako bi ova tema mogla (eventualno) da zaista "pripada" ovde.

Ja bih citavu stvar odradio totalno drugacije, mada nisam bas najbolje razumeo Mikija, mozda je on to zapravo tako i odradio. Ja bih lepo indeksirao sve, u prevodu bih sve diskove, sve fajlove na njima (particijama) indeksirao. Na C++ forumu je skoro jedna devojka spomenula AVL stabla, generalno se mogu iskoristiti bilo kakva stabla i/ili hash tabele. Naravno pozeljno je koristiti sto razgranatija stabla i obezbediti sto manje nivoa, samim tim sto manji broj sekvencijalnih/slucajnih upisa/citanja, jer to je najbitnija stvar u celoj prici!

Naravno, za ovu stvar covek moze da iskoristi i neku bazu, da se ne muci (ako ne zna) da napravi indeksiranje sam. Preporucujem SQLite (http://www.sqlite.org).

Kad se sve lepo izindeksira (informacije o svim fajlovima "upadnu" u bazu) covek ima gotov search.

Ljudi iz GNU sveta bi se dosetili "lukavstva" i rekli "e, a sto ne bismo samo nasli kod i preradili onu famoznu 'locate' komandu?" - ideja je zapravo resenje problema i ja upravo ovo preporucujem! Skines kod od findutils i ucis iz njega. Najzanimljivije od svega je da findutils postoji vec za windows i radi kao sat.

Druga varijanta findutils vec postoji u samom Windows-u mislim, to je ono Microsoftovo indeksiranje koje znacajno ubrzava pretrazivanje diskova...
[ tOwk @ 19.05.2003. 19:52 ] @
Nažalost Dejane, ipak se retko ko od nas bavi pravom teorijom programiranja, i još ređe nailaze na probleme pronalaženja odgovarajućeg algoritma za složene probleme.

Zato se slažem da naziv foruma nije prigodan („Art of Programming“ ili u prevodu „Veština programiranja“), i više bi odgovaralo nešto kao „uopšteni problemi programiranja“, gde se radi o svemu i svačemu što se tiče istog.

Što se samog problema tiče, ja sam već ponudio indeksiranje i keširanje kao najbolje rešenje. Veliki problem sa istim je „full-text“ pretraga, a za nju zaista mislim da je najbolje čitati „raw“ disk, osim ukoliko se radi o „indeksiranom full-text pretraživanju“ (tj. pretraga je ograničena na samo određeni format fajla, ili na samo neke reči).

A ako smo već kod „reciklaže“ koda, zašto ne bi iskoristio žurnal postojećeg fajlsistema?
[ leka @ 21.05.2003. 05:21 ] @
Odgovor je - zasto da ne - ako je FS "zurnalizovan" :)
[ Reljam @ 21.05.2003. 23:15 ] @
Nije me bilo na forumu dosta dugo, ali evo zavrsila se guzva na poslu, shippovali smo novu verziju, i ja rekao ajde da vidim sta se desava na forumu, kako sada to izgleda...

Sudeci po programerskom delu foruma, izgleda gore. Neki koji su imali dosta da doprinesu diskusiji su u medjuvremenu otisli, ceo forum je vise presao na satelit/GSM, a i dalje se dobijaju 'zanimljivi' odgovori od ljudi koji bi trebali da znaju bolje (citaj ceo disk i sam parsiraj FS - 'ajde!).

Ono sto je meni u sustini zao je to koliko je SNR gori ovde u poredjenju sa mailing listama koje se bave ovom tematikom. Ako je ovo vec jedan od retkih resursa na nasem jeziku o programiranju, ajde barem da ga ucinimo kvalitetnim i relevantnim.

Dobro, dosta sam rantovao, morao sam malo. Da ne bude da ovo nema bas nikakve veze sa originalnim pitanjem, evo i mog odogovora:

U opstem slucaju, vise slova = vise diskova. Znaci napravi vise threadova i pusti ih da rade.
[ Mihailo @ 22.05.2003. 02:11 ] @
Offtopic

Reljam, Gojko je odvano odlučio da forsira kvantitet (broj poseta i komentara) a ne kvalitet odogovora, tako da danas ima 11k članova i 300 poruka dnevno, od kojih vredi pročitati 5. Da ne spominjem diskriminaciju Windows-a (koga koristi 90% članova/posetilaca, a vam foruma 95% ljudi). Nijem mi namera da njega napadam (njegov forum, njegov problem) već samo da pojasnim stanje, koje će uskoro da dovede ES do yu.comp.software. Kada sam ja došao na ovaj forum bilo je 10 ljudi koji su pisali po jedan kvalitetan odgovor na dan, a danas sto ljudi piše 1000 glupih odgovora. I sam sam počeo da pišem bespotrebne komentare, jer kad vidiš deponiju, baci još jednu konzervu na vrh... Da ne pričam o prvaopisu, izražavanju, konstantom ponvaljanju tema, čak i potpuno neboluznim postovima koje više niko i ne briše, jer nema svrhe.
[ tOwk @ 22.05.2003. 02:51 ] @
Reljam, čini mi se da se radi o jednom disku, a tada više niti sigurno neće ubrzati postupak, a lako ga mogu usporiti (čitaj: context-switch, ma koliko bio lagan između niti, ipak postoji, a još kada dodamo mrdanje glave diska koje je mnogo značajnije).

Dalje, pošto si gotovo direktno uputio zamerku na moj predlog o neposrednom čitanju diska za full-text pretragu, želiš li možda da isto osporiš? Svakako, kako se ipak radi o javnoj raspravi, rad sam da čujem šta je to što bi ti mogao da izvedeš brže od tog postupka, bez obzira na složenost.

Ne zaboravi da je ovo (i dalje) forum „art of programming“, pa složenost implementacije ne diktira uslove, već vremenska složenost algoritma.

Usput, dobrodošao nazad :-)
[ Reljam @ 22.05.2003. 03:35 ] @
Hvala, hvala!

U opstem slucaju ne radi se o jednom disku, ali to je nebitno.

Vise se radi o pomoci coveku: covek radi pod windowsom, treba mu da nadje fajl, pita jednostavno pitanje, treba ga uputiti na pravu stranu, i to je to. Svi znamo da ime ovog foruma nema blage veze sa onim o cemu se ovde pise (uostalom, vrlo je diskutabilno da li je uopste i moguce imati takav forum na nasem ili bilo kom drugom manjem jeziku).... Moje misljenje je, kao sto sam gore napisao, da treba pomoci coveku - znaci napraviti ovaj resurs relevantnim. U tu svrhu bih se manuo akademskih resenja i presao na prakticna. Moja 'filozofija' tu bi bila: daj odgovore drugima onakve kakve bi voleo da neko meni da.

A u diskusiju o citanju raw diska necu ni da ulazim.... :)
[ tOwk @ 22.05.2003. 04:09 ] @
Koliko poznajem Mikija i njegove prethodne poruke, on ne traži obavezno (samo) „praktično“ rešenje. No, valjda čovek sebi uz pominjanje praktičnog, možda da dozvoli i pominjanje idealnog slučaja (npr. zamisli da je onome koji traži potreban „kontekst“ u kom se pojavljuje neki tekst, a ne ime fajla ili neka druga struktura koja postoji samo fajlsistemu) full-text pretrage: pokreneš glave diska, napuniš memoriju do vrha učitanim podacima (npr. digneš od jednom 100MB podataka, time dobijajući maksimalnu brzinu diska), i onda je pregledaš. Zatim sledeći korak, itd.

Ih, bre, ima li bolje optimizacije ;-)

I otkud ti to da je „srpski“ jezik „manji jezik“? Pa preko 40% Gnoma je prevedeno na srpski, a osnovnog Gnoma 2.2 desktopa preko 95% :-P
[ Gojko Vujovic @ 22.05.2003. 04:44 ] @
Šta predlažete da se uradi po pitanju kvaliteta foruma?

Ja sam omogućio ignorisanje GSM i svih ostalih foruma koji ne zanimaju određene posetioce, pa sam očekivao da tu mogućnost i iskoriste.

Ako imate nekih ideja za poboljšanje, samo napred.
[ Reljam @ 22.05.2003. 05:45 ] @
Gojko, poruka ti je OT; moderatori, brisite mu poruku! :D

Da pojasnim ono sa 'manjim jezikom': problem je u tome sto ce oni kojima je stvarno potreban odgovor na neko bitno programersko pitanje da se okrenu odgovarajucim mailing listama ili forumima koji su naravno mnogo veci od ESa. Jer ako postoji 11000 korisnika, a od njih 1% programira, to obicno nije dovoljno da se napravi kriticna masa za odgovore. Nije tu nista lose, ali samo treba imati to u vidu i znati ko je 'klijentela'.

Sto se tice poboljsanja foruma, Gojko, potpuno si u pravu - postoji ignorisanje, i to je sasvim ok. Ako bi moderatori mogli da pokrenu neki community projekat to bi bilo super, ali naravno to je jako zahtevno. Ne krivim te ni zasta :)

Dobro, de, da pricamo o citanju diska.

Postoje akademske i postoje akademske diskusije. Cini mi se, tOwk, da je dvoje resenje vrlo akademsko jer zanemaruje probleme kao sto je parsiranje FSa (kog FSa? Ima ih vise), mreznih diskova, ACLova, pristupa raw disku, implementacije, maintenance costs, neuniverzanolsti resenja (nece cak raditi ni na svim windowsima, a kamoli sire). Ok je neke stvari apstraktovati, ali ovo je stvarno suvise.
Medjutim, moja zamerka tom resenju je u stvari da je suboptimalno jer je mnogo bolje resenje koje je leka (otkud ti opet ovde?! dobrodosao) predlozio: koristiti indexiranje. Ako smo vec sve ostalo apstraktovali, onda slobodno mozemo i korak dalje i da kazemo da je FS indexiran i onda je to bolje resenje od citanja sa diska. Naravno, nista od toga ne pomaze Mikiju :)
[ tOwk @ 22.05.2003. 05:58 ] @
Reljam, evo ti citat iz moje prve poruke na temu (http://www.elitesecurity.org/poruka/150067):
Citat:

[ponešto o „običnoj“ pretrazi...]

Znači, najbolja rešenja za brzu pretragu su indeksiranje i keširanje. Ako za to nemaš mogućnosti, onda preporučujem čitanje „raw“ diska u velikim blokovima...


Znači, i ja sam isto ponudio kao prvo rešenje, ali kao što svi znamo, indeksiranje ne može da radi u mnogim slučajevima (šta indeksirati ako se ne radi o tekstualnim podacima, već ja želim da tražim niz bajtova? Postoji mnogo slučajeva kada je teško napraviti odgovarajući indeks zato što on nije namenjen svim slučajevima [da jeste, ne bi bio manji od podataka na disku, a znamo zašto je to loše ;-)])

Takođe, rešenje je vrlo praktično, i za određene probleme sigurno će dati bolji rezultat od drugih ponuđenih rešenja. No, neću više da insistiram, ali zaista mislim da je to u odgovarajućoj klasi problema vrlo dobro rešenje (najverovatnije i najbolje). Kako nije navedena vrsta pretrage (po imenu, po osobinama fajla, po sadržaju — samo tekst, po proizvoljnom sadržaju), red je da se i ono pomene.