linux user group brescia

On Fri, 11 Jul 2003, Luca Giuzzi wrote:
> ??? Cosa vuoi dire ???

	Esempio:

p net 21 26 19 5 8
n 32 1600
n 128 7360
n 512 37120
n 2048 179200
n 8192 839680
a 1 2 100 10
a 1 3 100 10
a 2 3 190 19
a 2 4 60 6
a 2 8 90 9
a 3 6 100 10
a 4 5 100 10
a 5 6 50 5
a 6 7 90 9
a 6 11 120 12
a 7 8 90 9
a 8 9 60 6
a 8 10 150 15
a 9 12 100 10
a 10 15 140 14
a 11 16 130 13
a 12 13 60 6
a 13 14 60 6
a 13 17 60 6
a 14 15 30 3
a 15 16 60 6
a 16 18 60 6
a 17 19 60 6
a 18 20 60 6
a 19 21 100 10
a 20 21 100 10
d    1    6   10
d    1   17   18
d    1   18   18
d    4   14   19
d    5   18   82
d    6    3   93
d    6    8   80
d    9   13   82
d   10    1   10
d   10   11   30
d   12    5   48
d   14    2   44
d   14   21   56
d   15   21   59
d   17    3  167
d   17   16  104
d   18   19  150
d   18   20  173
d   19    4   48

	Questo e' il file piu' piccolo che devo analizzare. Sono 740 byte, 
che corrispondono ad un'istanza di problema di 56-57 kbyte (occhio al k).

> di solito si vuole fare il contrario: trasformare files binari in 
> testo (formattato) per poterlo meglio processare...
> usare files binari e' una brutta cosa(tm)

	Ti credo, ora occhio a questo caso: il file sopra corrisponde alla 
descrizione di una rete di telecomunicazioni. Io devo trovare dei percorsi 
all'interno di questa rete. Questi percorsi vengono memorizzati come un 
vettore lungo quanto il numero di nodi (numero che puo' raggiungere al 
massimo 65000, quindi 2 byte) quindi un percorso (comunque lungo) occupa 
in memoria 2 * Nnodi byte. Devo tenere in memoria 2 percorsi per ogni 
relazione di traffico, senza contare tutte le altre diverse correlazioni 
con dati che non sto a citare, tra cui esistono numerosi bitmap.
	Gia' il programma e' complesso di suo, se poi mi studio anche un 
formato testuale per salvare e ricaricare i dati buonanotte.

> > Il trattamento dovrebbe limitarsi a qualcosa del tipo
> > ordinamento/eliminazione/inserzione/controllo_consistenza.
> Di cosa? 

	Ad esempio che se esiste il link (2,5) non deve essere presente 
anche il link (5,2), e nel caso avvisare (perche' la linea con 'p' deve 
essere modificata).

> Sicuro che non ti serva un database?

	Piu che certo!

> > 	Se non ricordo male awk e' un linguaggio interpretato (tanto per
> > questa fase non ho assolutamente bisogno di velocita') pensato apposta per
> > questo lavoro. Mi sbaglio?
> 
> Senti... il discorso velocita' di esecuzione ha poco senso quando si parla
> di selezione del linguaggio per lo sviluppo di software.

	Sinceramente non credero' mai che un linguaggio interpretato sia 
piu' veloce (o simile) a uno compilato. Sono un fan dei linguaggi 
interpretati piu' che dei compilati, ma se mi metto a scrivere 
l'ottimizzatore in python (tanto di cappello, lo voglio imparare), sempre 
ammesso che il relatore non mi squarti, penso che ci metterebbe 
decisamente di piu' ad ottenere lo stesso risultato ottenibile con lo 
stesso algoritmo implementato in C (che a sua volta da risultati peggiori 
dell'ASM, es. sui DSP anche 8-9 volte...).
	Certo che se si tratta di programmi che devono interagire con 
l'utente le cose cambiano. Qui si tratta di roba che deve essere fatta 
partire e lavora DA SOLA (occupanto tutto il tempo di CPU) per diversi 
GIORNI. Non e' raro trovare su queste macchine processi in corso da 
6000-7000 minuti. Prego fare il conto... Dividere anche solo per 2 il 
tempo di esecuzione di un singolo ciclo di ottimizzazione fa passare da 4 
a 2 GIORNI (altrimenti sprecati).

> Controlla che gli algoritmi siano giusti e siano
> ben congeniati... possibilmente prevedi la possibilita' di parallelizzare
> le operazioni (in locale con threads, o su rete via mpi/pvm) ... poi
> l'overhead consistente nell'utilizzare un linguaggio interpretato e'
> praticamente nullo su moli di dati consistenti [anche perche' solitamente
> i linguaggi interpretati di questo tipo compilano le espressioni prima
>  di eseguirle... questo e' quanto fa' perl, in particolare, ma non solo]

	Ripeto: per il lavoro preliminare la velocita' non e' importante, 
potrei scriverlo anche col BASIC del C64, per il lavoro vero pero'la 
storia e' un'altra (ma il programma e' gia' pronto).

> Personalmente suggerirei il perl se devi fare anche dell'i/o binario, ma
> ripeto e ribadisco che non penso sia una buona idea.

	Perl lo sento nominare tantissimo, non ne conosco nulla, ma penso 
che a questo punto dovro' impararne un pochino...

> P.S.
>  L'idea di salvare a dei checkpoints per poter riprendere il calcolo in
>  caso di blocco della macchina e' buona... pero' nulla vieta di fare tali
>  dump in un formato leggibile (ed editabile) da un umano.

	Potrei farli in un formato "umano", ma data la mole di dati 
(ricordo 740 byte -> 56 kbyte) e le correlazioni da salvare assolutamente
tra questi a una persona fumerebbe il cervello per capirli. Figuriamoci 
editarli. A questo punto, visto che per un umano sono dati illeggibili, 
tanto vale fare in modo tale che sia facile farli leggere dal programma.

-- 
						Ciriciao
					LtC. Melkor?! B. Xapatan