[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Curiosit? grep



Il giorno gio, 20/09/2007 alle 10.02 +0200, nextime@nexlab.it ha
scritto:

> > Secondo dubbio, esistono altri modi per parsare un
> > file di tali dimensioni senza aspettare tempi biblici e
> > nel mentre andare a prendersi un caff? molto molto lungo???

> 1- distribuire il lavoro:
> 
> Piu macchina (o piu processori) eseguono calcolo parallelo, quindi qualcosa distribuisce un
> "pezzettino" del file a diversi "grep" o diversi thread che "greppano"
> il loro pezzettino in parallelo.

Non porterebbe alcun vantaggio. Il lavoro pesante di un tale processo e`
la lettura dei dati da disco.
L'elaborazione in memoria e` circa 1000 volte piu` veloce della lettura
dal disco. Se ci aggiungi anche il trasferimento via rete arrivi
tranquillamente a 4-5000 volte.
L'unica cosa da fare sarebbe avere tale file su un RAID (0, 1, 5 o
combinazioni di questi) con diversi dischi, in modo da parallelizzare la
lettura del file. Anche cosi` non si saturerebbe mai la potenza di
elaborazione di una CPU moderna per il confronto tra caratteri.
Tra l'altro mi sembra che l'algoritmo di grep sia uno dei piu`
efficienti (non che ci voglia moltissimo, e` lineare :)

> 2- fare un pre-index
> 
> Quindi il lavoro lungo lo lasci magari in background ala updatedb per il
> locate, e poi tu non fai altro che andare a cercare nel tuo index quando
> hai bisogno il dato e non piu' a rifare il "grep" ogni volta. Questa e'
> la soluzione adattata dai vari beagle e simili ad esempio.

Questo avrebbe gia` piu` senso, ma avresti una hash table su disco che
occupa circa lo stesso spazio del file originale. E comunque dovresti
scriverti tu un software che lo faccia e che acceda al disco in modo
intelligente. Un motore di DB, in pratica. :)

Bye.


-- 
Alessandro Pellizzari




Reply to: