Newsgroup: it.comp.programmare
Titolo: GOOGLE non usa PYTHON

Salve a tutti!
Allora, sono andato a vedermi, a questo punto spinto dalla curiosita',
questo famigerato apporto di Python in Google. Ho visto sul sito di Python
(
http://www.python.org/psa/Users.html
) che il linguaggio e' utilizzato per
realizzare alcuni componenti in uso per gli spider, e alcune componenti del
motore di ricerca. Sono andato sul sito dela slashdot
(
http://slashdot.org/articles/99/02/19/0833230.shtml
) ma non viene
menzionato alcun uso di Python.
Allora ho cercato su Google stesso qualche notizia a riguardo, ma non ne ho
trovate. In compenso ho trovato un paper molto interessante,
http://www7.scu.edu.au/programme/fullpapers/1921/com1921.htm
 (_The Anatomy
of a Large-Scale Hypertextual Web Search Engine_), che spiega
dettagliatamente come Google sia stato implementato ed ESCLUDE che Python
venga utilizzato per il motore di ricerca. Cito,
    "Running a web crawler is a challenging task. There are
    tricky performance and reliability issues and even more
    importantly, there are social issues. Crawling is the most
    fragile application since it involves interacting with
    hundreds of thousands of web servers and various name
    servers which are all beyond the control of the system.
    In order to scale to hundreds of millions of web pages,
    Google has a fast distributed crawling system. A single
    URLserver serves lists of URLs to a number of
    crawlers (we typically ran about 3). Both the URLserver
    and the crawlers are implemented in Python."
e cito:
    "Most of Google is implemented in C or C++ for efficiency and
    can run in either Solaris or Linux "
Quindi Python viene utilizzato per il crawling (che sarebbe, in pratica,
SOLO il recupero del contenuto dei siti per la successiva indicizzazione), e
non certo per la parte piu' pesante del lavoro.
Saluti!
*** Azimuth ***

 non certo per la parte piu' pesante del lavoro.
Anche nella ns. ditta, come ho già detto, lo usiamo per solo in alcune 
operazioni 'batch' di secondo piano.
Python è ottimo per far ciò, sicuramente meglio dell'odioso Perl... Ma 
nulla di più.
-- 
Luc.

 nulla di più.
Forse e' il target dei lavori di Alex Martelli... <g>
*** Azimuth ***

Forse e' il target dei lavori di Alex Martelli... <g>
io direi di darci un taglio con questo "dare addosso" ad Alex e ad
altri tanto non si fa altro che aumentare il contatore del numero di
post in questo NG...
--
Rhymes (
rhymes_...@myself.com
)
http://www26.brinkster.com/rhymes
http://bw-crema.blogspot.com

 post in questo NG...
Non ho resistito.
Devi pur ammettere che tra me ed Alex non corra buon sangue, e non per colpa
mia...
*** Azimuth ***

 
Il "SOLO" recupero del contenuto dei siti non mi sembra un aspetto 
marginale del funzionamento di un motore di ricerca e, per quello che  
posso capire del funzionamento di un motore di ricerca, è sicuramente 
critico sia dal punto di vista dell'affidabilità (deve trovare tutte le 
pagine accessibili), che da quello delle performances (deve recuperarle 
in un tempo ragionevole, magari "scalando" bene in un architettura 
molto distribuita).
Comunque il tuo post è utile perchè dimostra che in un progetto ben 
fatto si sceglie il tool (linguaggio, in questo caso) giusto per 
sviluppare ognuna delle componenti, mentre qualcuno continua a cercare 
di costruire le case usando solo il cacciavite... (o il cacciavite++)
-- 
Valter Minute
vmi...@inwind.it
 (the reply address of this message is invalid)

 di costruire le case usando solo il cacciavite... (o il cacciavite++)
Sara'...
*** Azimuth ***
[1] Se pero' ci pensi, cosa viene fatta piu' spesso, la ricerca o
l'indicizzazione?
[2] Risparmiando sicuramente nel TOC, Total Ownership Cost.

"Many components of the Google spider and search engine are written in
Python."
Google USA Python, ti sei contraddetto da solo.
E' tipico degli imbecilli (..ops... Valter, non lo faccio piu' :)).
--------------------------------
Inviato via 
http://usenet.libero.it

 Google USA Python, ti sei contraddetto da solo.
Si', in effetti il subject traeva in inganno... ma, d'altra parte, ti sei
limitato a leggere quello.
*** Azimuth ***

 limitato a leggere quello.
E tu d'altra parte, ti limiti a scrivere, tenendo spento il cervello (ti
avevo gia' consigliato di tacere, se non erro), nella foga di dimostrare il
falso, cioe' che Python non venga usato o venga usato poco. Questa e'
diventata la tua ragione di vita e finora sei stato massacrato. Sospettavo
che tu fossi masochista, ma ora ne ho la certezza. Quasi quasi ti killo, ma
no dai, leggiamo le altre stronzate :)


 mia...
E' vero, non per colpa tua, i malati di mente sono vittime della loro stessa
malattia.


 MOLTO Python.
"Many" significa "molto", "Most" significa "la maggior parte".
La maggior parte di Google e' scritta in C++ (affermazione citata dal
documento). Il che significa che la parte C++ puo' variare dal 50% sino al
99%. Al contrario, la parte rimanente (in cui annoveriamo PYTHON), rientra
tra il 50% fino all'1%. Il termine "many", da questo punto di vista, non ci
aiuta.
D'altra parte, abbiamo nello stesso articolo che ho citato il riferimento al
fatto che il Python venga usato esclusivamente per il crawling. Questo ci
porta a due conclusioni incontrovertibili:
a) Python NON E' USATO nel motore di ricerca (C++ a quota 100%)
b) Python E' USATO nel motore di indicizzazione (con le quote di cui sopra).
Siccome pero' sappiamo che la parte di ricerca e' quella dove e' stato speso
maggior tempo e quindi prodotte maggior numero di righe di codice, ecco che
il "molto" si ridimensiona nettamente.
[snip su altre cazzate che non ritengo valga la pena di riportare]
*** Azimuth ***


E' difficile parlare con Alex se non si decide a scendere dal suo
piedistello e portare la sua luce tra i comuni mortali.
E comunque a me pare che non faccia altro che dire ciň che altri hanno
detto...allora tanto vale parlare con gli altri :-)
Kiuhnm

 detto...allora tanto vale parlare con gli altri :-)
:-D
Un saluto!
*** Azimuth ***

 documento).
Tu stai dicendo cazzate su cazzate, nel tentativo di portare acqua ad un
mulino che ad ogni post che scrivi perde una pala in piu', a furia di
ricevere colpi. Stai zitto, e' meglio per te, e' un consiglio quello che ti
do': hai esordito con un subject "Google non usa Python", tutto le stronzate
aggiuntive che scrivi per riparare la baggianata che hai scritto sono
irrilevanti, renditene conto, Google fa un uso "esteso" di Python e questo
e' un dato di fatto che non puoi contrastare, taci, e' meglio per te, torna
nel cassonetto :)


 l'indicizzazione?
Se non cambia mai nessun dettaglio relativo all'indicizzazione,
viene ovviamente fatta piu` spesso la ricerca: infatti il numero
di ricerche e` il numero di indicizzazioni (ogni pagina che viene
indicizzata deve precedentemente essere stata recuperata) PIU` quelle 
ricerche che servono solo ad informare che un tot di pagine non sono 
cambiate dall'ultima volta (ognuna di queste richiede almeno una
richiesta-e-risposta col relativo server, nel caso ottimale in
cui il server risponda correttamente alle richieste che indicano
di avere una pagina gia` "in cache"; purtroppo alcuni server, o
per errori o magari per avere la scusa di contare un hit in piu`
nelle statistiche, non si comportano a norma di standard e quindi
obbligano a carico ridondante anche per pagine non modificate).
In realta` Google cambia ogni tanto gli internals della propria
indicizzazione, magari anche solo nei dettagli, e allora ripete 
l'indicizzazione, in tutto o in parte, anche su pagine gia`
recuperate in precedenza.  Non sapendo con quale frequenza si
presentino questi cambiamenti strutturali, e quanto spesso invece
si eseguano ricerche che non richiedono la re-indicizzazione, e`
impossibile stimare accuratamente la frequenza relativa dei
due tipi di operazioni.
Alex

 [MEGA-CUT]
Ma quanto scrivi???? Si vede che sei un consulente... ;-PPP
 
-- 
Luc.

 nel cassonetto :)
Sei proprio alla frutta... Non hai notato che il "Fronte Azimuth" sul NG 
č in continuo aumento???
Ti suggerisco l'unsubscribe.
-- 
Luc.

 Tu stai dicendo cazzate su cazzate, nel tentativo di portare acqua ad un
[snip su altre cazzate di Andrea "Cazzaro" La Forgia]
*** Azimuth ***

 Ti suggerisco l'unsubscribe.
Non ne vedo il motivo, onestamente.


 [snip su altre cazzate di Andrea "Cazzaro" La Forgia]
Certo, tu snippi, tagli, ti metti le mani davanti agli occhi, non leggi cio'
che dovresti, leggi solo cio' che vuoi, non vuoi guardare. Fai pure, accusi
gli altri di essere "cazzari" quando l'unico cazzaro sei tu (stendo un velo
pietoso su Luc, poveretto...).
E' che non ti firmi nome e cognome (ti capisco, le cazzate si posson dire
solo dietro nick anonimi), mi piacerebbe salutarti mettendo un "Deficiente"
tra il tuo nome ed il tuo cognome ;))


 due tipi di operazioni.
Direi comunque che non e' difficile pensare che sia la ricerca l'operazione
piu' richiesta.
*** Azimuth ***
[1] Ovviamente, se realizzi un piccolo straterello di astrazione, si tratta
di portare tale straterello sulle primitive del medesimo.

 e non certo per la parte piu' pesante del lavoro.
SOLO per la parte piu` delicata ('most fragile'), 'challenging',
con 'tricky performance and reliability issues' inerenti alla
natura del compito -- e permette di realizzare un sistema oltre
tutto RAPIDO oltre che affidabile ecc ecc.
Oltre tutto hai citato anche un numero importante: normalmente
Google (al tempo in cui fu scritto il paper) usava circa tre
crawler (presumibilmente dunque tre macchine, non si dice di
che taglia o con che OS) e dunque li considerava sufficienti a
saturare tutta la banda passante che intende dedicare ai
compiti di crawling.  Con buona pace delle tue fantasie malate,
scritte su altri post, di un ipotetico crawler scritto invece
in C che succhierebbe due volte piu` in fretta di quello scritto 
in Python consentendo chissa` quali risparmi di hardware.
Verissimo che Google non usa *SOLO* Python: ho piu` volte
postato che la soluzione ottimale per un sistema complesso
e con esigenze di prestazioni coinvolge tipicamente piu` di
un linguaggio.  In particolare, e` appropriato ottimizzare
al massimo i colli di bottiglia: ad esempio se vuoi usare
un pochino di SQL per comodita` ma le sue prestazioni non
sono importanti per il tuo programma puoi anche usare
Gadfly, il motore relazionale/SQL scritto in Python; se
vuoi un poco piu` di prestazioni, agganci a Gadfly un singolo
modulino ottimizzato in C che gestisce il suo collo di
bottiglia (gestione di insiemi: Gadfly fu scritto per
versioni di Python precedenti alla 2.3, che quindi non
avevano ancora come intrinseca la gestione degli insiemi
[Sets] -- e comunque i Sets di Python 2.3 non curano
l'ordine degli elementi, quindi dovendo supportare la
clausola ORDER BY dell'SQL occorrono insiemi differenti)
e le prestazioni possono magari raddoppiare con questa
sostituzione di circa il 5% dei codici sorgenti.  Ma se
(come spesso accade) il DB e` il tuo collo di bottiglia,
fai meglio ad adottare un motore RDBMS veramente spinto,
come PostgreSQL, o SAP/DB [Adabas] o magari Oracle (se
puoi permettertelo, anche come stipendi di _buoni_ DB
administrator) -- la tua APPLICAZIONE puo` benissimo
restare in Python, i bassi livelli che fanno da colli
di bottiglia per le prestazioni usano invece (anche "a
scatola nera") un intero sottosistema -- probabilmente
molto piu` grosso della tua *applicazione* in quanto
tale!-) -- separatamente e pesantemente ottimizzato da
specialisti di quel dato settore.
Usare gli strumenti giusti per i vari compiti e` una delle
capacita` fondamentali di un ingegnere.  Google e` fatta
anzitutto di (ottimi) ingegneri: quindi usa Python dove
gestisce problematiche difficili e ha bisogno di ottima
affidabilita` pur in un sistema "fast", C/C++ dove deve a
tutti i costi ottimizzare al massimo certe operazioni.
Alex

 Non ne vedo il motivo, onestamente.
Beh, miglioramento della qualita' dell'aria.
*** Azimuth ***

 Certo, tu snippi, tagli, ti metti le mani davanti agli occhi, non leggi
cio' [...]
[snip su altre stronzate]
Guarda, non lo faccio per te, lo faccio per risparmiare banda quindi
elettricita' e quindi per non inquinare riportando le tue stronzate.
Comunque, cazzaro rimani.
*** Azimuth ***

 Beh, miglioramento della qualita' dell'aria.
C'e' modo e modo di raggiungere lo stesso risultato: basterebbe operarti e
spostare la tua bocca ;)


 Guarda, non lo faccio per te, lo faccio per risparmiare banda
Si', certo, come no... ah ah ah....
Dio mio, che pena !!!


 capacita` fondamentali di un ingegnere.
Questo punto non lo capisco: C++ e C mi sembrano strumenti adatti a
risolvere tutte le tipologie possibili di problematiche. Se poi si e'
davvero *bravi* ingegneri, si strutturano le cose in maniera da riutilizzare
il piu' possibile cio' che e' stato fatto (= librerie, che NON fanno parte
del linguaggio). Fare quello che suggerisci ("sostituire il collo di
bottiglia") potrebbe non essere una soluzione praticabile, in quanto e'
l'intera infrastruttura ad inserire una pessimizzazione delle performance. A
quel punto che fai, butti tutto il codice Python e riscrivi in C++? Meglio,
a questo punto, partire col piede giusto.
*** Azimuth ***

 le 5 pagine/sec
Vorrei avere dei numeri che confermino questa tua ipotesi.


 progetti. 
Il fatto è che Alex documenta e spiega le sue "assunzioni"...


 Vorrei avere dei numeri che confermino questa tua ipotesi.
Se vuoi posso parlarti di un progetto dove, senza C++, non si andava molto
lontani.
*** Azimuth ***

 Il fatto è che Alex documenta e spiega le sue "assunzioni"...
Documenta? Con dati approssimati?
*** Azimuth ***

 Documenta? Con dati approssimati?
No, documenta, con argomenti che non comprendi. E' diverso.


 in C++? Meglio, a questo punto, partire col piede giusto.
E` meglio in generale partire con la soluzione piu` ad alto
livello che appaia _potenzialmente_ fattibile in sede di
analisi preliminare.  Se ci sono sostanziali dubbi, e` sempre
meglio partire con un prototipo, realizzato con la massima
rapidita` e quindi nel linguaggio piu` ad alto livello che
sia compatibile con i vincoli HW identificati relativamente
alla piattaforma: l'esperienza sviluppata in breve tempo col
prototipo e` come minimo un'OTTIMA base per il successivo
sviluppo del sistema "vero".
Ricorda il principio fondamentale di quel testo cardine
della programmazione "in grande" che e` "The Mythical
Man-Month" di Brooks: "Plan to throw one away -- you
will, anyway".  Ovviamente Brooks parla di sistemi al
limite delle capacita` tecnologiche, non di semplici
applicazioni che non spingono i limiti dell'hardware o
delle nostre conoscenze, per le quali e` probabile che
si possa fare un buon lavoro anche senza un prototipo
come fase iniziale.
A volte (sono casi complessi ma non puoi escluderli a priori)
non SAI neppure se stai sviluppando solo un prototipo, se sei
ancora in fase di studio di fattibilita`, o se quel (omissis)
del cliente (o del tuo management se sei un dipendente) non
prendera` invece il codice che tu ritieni NON pronto per
entrare in produzione e si mettera` a venderlo o usarlo a
piu` non posso.  Gestire questi casi delicati e` piu` un
problema di "ingegneria umana": uno dei suggerimenti piu`
divertenti in merito e` di usare un linguaggio di altissimo
livello che SAI sara` considerato inaccettabile per la
consegna di un prodotto -- a seconda delle idiosincrasie del
management, puo` essere Smalltalk, Lisp, Erlang, Perl, Icon,
Snobol, dipende... ma attenzione a essere CERTO che sara`
giudicato inaccettabile, se no rischi di trovarti a dover
manutenere il pacco il questione per anni a venire:-)
Alex

 Che deduzione fantastica ! suppongo abbia richiesto anni di studio !
Andrea, guarda, facciamo cosi':
<plonk>
*** Azimuth ***

 poca complessita'. Due o tre concetti, ed hai imparato il C.
Scusate, ho letto male, nel senso che ho inteso una cazzata di gran lunga
meno grave della cazzata reale contenuta nelle due righe, di cui sopra.
Analizziamo: meno costrutti == meno complessita'.
Suppongo che in virtu' di questo principio sia molto piu' semplice, per un
newbie, capire che cosa fa questo codice:
#include <stdio.h>
#include <stdlib.h>
int main()
{
     char *p;
     p = malloc(50);
     if (p)
     {
        strcpy(p, "hello world");
        printf("%s\n", p);
        free(p);
     }
     return 0;
}
rispetto a:
p = "hello world"
print p
Ora, meno complessita' significa che, per fare le stesse cose, hai bisogno
di "costruire" di piu' e questo non e', di certo, un fattore
*oggettivamente* positivo.


 <plonk>
Guarda che se e' un modo per ammettere che hai torto, a me sta bene :)


 sviluppo del sistema "vero".
Si', pero' non ti permette di dimensionare il sistema.
Ciao.
*** Azimuth ***

 l'operazione piu' richiesta.
Pensarlo non e` difficile: puo` essere GIUSTO, o SBAGLIATO,
a seconda della frequenza delle riorganizzazioni degli indici
&c, ma immagino che questo non ti interessi -- a te basta
che non sia "DIFFICILE PENSARE", poi se quel che pensi e`
sbagliato, errore piu`, errore meno, che importa -- giusto?
Alex

 sbagliato, errore piu`, errore meno, che importa -- giusto?
No, non e' giusto -- ma tu non credo sia in grado di comprenderlo.
*** Azimuth ***

 Si', pero' non ti permette di dimensionare il sistema.
Con una buona analisi, te lo permette molto meglio di quanto
non te lo permetta l'ASSENZA di un prototipo.
Alex

 C o Assembler.
Il C è contenuto nel C++ quindi col C non puoi fare più cose!
Con l'asm ovviamente sì.
Kiuhnm

 memoria) comunque tu poi li processi.
Direi questa e' una affermazione quantomeno superficiale. Facciamo che tra
strutture dati DELL'INTERPRETE, le MIE STRUTTURE DATI e i DATI stiamo sui
3-4 Mb per sessione, abbiamo da 90 a 120 Mb da mettere da qualche parte...
considerando che anche il S.O. vorra starci, in memoria... ti servono 256 Mb
minimo...
*** Azimuth ***
[1] Purtroppo non posso dare esattamente numeri, ma considera che l'ho
dovuto implementare in altri linguaggi interpretati.

 C++ , che tipo di programmi sviluppi?
Integrazione di software per apparati telefonici con alta densita' di porte.
*** Azimuth ***

 piattaforme.
Che differenza puo` mai fare?  Vai su tre piattaforme, e` solo
il tripo del codice -- hai gia` pagato un fattore ben superiore
per usare linguaggio macchina invece che C++, quindi, che
vuoi mai che sia?
Alex

 vuoi mai che sia?
Che in C++ posso avere la discreta sicurezza di essere poco meno di
efficiente rispetto all'ASM.
*** Azimuth ***


ho dato una guardatina al thread....e posso dire che almeno alex usa dati
approssimati, e non strampalati come i tuoi....
non mi pronuncio sulla diatriba tra python e c, dato che imho hanno scopi
diversi, e come tutte le cose fatte per compiti di versi, non sono
paragonabili. sarebbe come confrontare il cacciavite a croce con quello a
taglio, fatti tutti e due per avvitare viti, ma non le stesse (anche se qui
si potrebbe dire che il cacciavite a taglio a volte va bene pure con quelle
a croce...)
anyway, il mondo č bello perchč č variable, immaginatevi fosse const....
Raffaele

 piattaforme.
ma soprattutto se avessi un paio di eternità a tua completa
disposizione.....
namarie
Raffaele

 l'80% degli investimenti economici.
come al solito, in base a cosa sono stati determinati questi numeri? dal tuo
spannometro?
namarie
Raffaele

 anyway, il mondo č bello perchč č variable, immaginatevi fosse const....
Pensavo che fosse bello perche' avariato...
*** Azimuth ***

 spannometro?
Rileggiti attentamenteil thread e capirai.
*** Azimuth ***
[1] Questi dati, verosimili per CD musicali, si possono utilizzare anche per
il CD informatici, dato che al piu' i guadagni aziendali (il markup) e' DI
MOLTO MAGGIORE rispetto ai CD musicali.

 disposizione.....
Mi sa che non hai mai programmato in vita tua.
*** Azimuth ***

 di dati reali, mica di fesserie.
i dati reali non cambiano nel giro di un paio di post...
namarie
Raffaele

 Mi sa che non hai mai programmato in vita tua.
beh, non ho mai programmato a livello professionale, ma so quali sono le
caratteristiche di alcuni linguaggi. e credo che non sia molto "veloce"
programmare...che so...un word processor interamente in assembler. se mi
parli di progetti relativamente "piccoli" ti dò ragione, ai tempi dello Z80
si andava tutto di asm, così come su certi sistemi di piccole dimensioni ma
dai compiti critici, ma al giorno d'oggi non è umanamente realizzabile un
intero progetto di grosse dimensioni in asm, come un os.
certo, su quella specifica architettura il tuo sarebbe il migliore os sul
mercato, forse, se non fosse per il fatto che quando l'avrai finito quella
piattaforma non esisterà più!
Raffaele

 piattaforma non esisterà più!
Mah, sai: io ho avuto un paio di successi in questo che purtroppo non posso
riportare per motivi di riservatezza.
Ciao!
*** Azimuth ***
[1] Sul mio case c'e' scritto "GPL inside"! ;-)

 riportare per motivi di riservatezza.
beh...se non lo dici non lo posso sapere...che genere di successi?
Raffaele

 beh...se non lo dici non lo posso sapere...che genere di successi?
Commerciali.
Tipo: installare un apparato e scordarmi che esiste.
*** Azimuth ***
[1] Hint: quanto turnover hanno quelle aziende di cui parli?