Closed brancomat closed 1 year ago
Ora in products.json
c'è un render_stats
:
"reftimes": {
"2022-10-28 00:00-00": {
"inputs": [
"t2m"
],
"steps": [
0,
1,
2
],
"legend_info": {…}
"render_stats": {
"time_ns": 74439917423
}
}
}
Il valore è in nanosecondi, ed è aggregato per (flavour, recipe, reftime). Visto che Python 3.6 non supporta i clock in nanosecondi (introdotti dal 3.7), ho approssimato moltiplicando il clock float per 10^9, e può essere che i risultati non siano accurati
C'è una ragione particolare per mostrare il tempo in nanosecondi e non un arrotondamento in secondi? Come unità di misura almeno per un colpo d'occhio sul rendering mi sembrava di lettura più immediata
C'è qualcosa che non capisco: questo è il file generato dalla produzione delle mappe ci cosmo_2I: products.json.txt
Nel prodotto wflags10m
il campo render_stats.time_ns
è 5488092151130 (oltre 90 minuti).
L'intera procedura è durata 46 minuti. La parallelizzazione incide su questo conteggio?
C'è una ragione particolare per mostrare il tempo in nanosecondi e non un arrotondamento in secondi? Come unità di misura almeno per un colpo d'occhio sul rendering mi sembrava di lettura più immediata
Le versioni piú recenti di python hanno versioni dei timer in nanosecondi, che sono utili perché non hanno arrotondamenti e permettono di fare conteggi piú accurati.
C'è qualcosa che non capisco: questo è il file generato dalla produzione delle mappe ci cosmo_2I: products.json.txt
Nel prodotto
wflags10m
il camporender_stats.time_ns
è 5488092151130 (oltre 90 minuti). L'intera procedura è durata 46 minuti. La parallelizzazione incide su questo conteggio?
Sí: è la somma del tempo misurato per il rendering di ogni singolo prodotto, quindi se la procedura è durata 46 minuti su 4 core, la somma può arrivare a 46*4=184 minuti di lavoro totali
Capisco che i dati cosí come sono non aiutino a fare considerazioni a colpo d'occhio. Faccio uno scriptino che legge il products.json e fa una presentazione piú human-readable orientata a un'analisi prestazionale?
Ah, e i tempi contano solo il rendering, ma al momento non tiene traccia del tempo passato a generare input intermedi
Capisco che i dati cosí come sono non aiutino a fare considerazioni a colpo d'occhio. Faccio uno scriptino che legge il products.json e fa una presentazione piú human-readable orientata a un'analisi prestazionale?
Tipo, per esempio (appena pushato):
$ ./analyze-run products.json
Flavour Recipe Total time Total steps Time per step
ita_small_tiles cape 07:30 73 6.2
ita_small_tiles hcc 11:06 73 9.1
ita_small_tiles hzero 14:01 73 11.5
ita_small_tiles lcc 12:23 73 10.2
ita_small_tiles mcc 11:00 73 9.0
ita_small_tiles mslp 07:24 73 6.1
ita_small_tiles rh2m 09:17 73 7.6
ita_small_tiles sf12h 00:46 6 7.7
ita_small_tiles sf1h 08:40 72 7.2
ita_small_tiles sf24h 06:09 49 7.5
ita_small_tiles sf3h 02:54 24 7.3
ita_small_tiles sf6h 01:28 12 7.4
ita_small_tiles sffraction12h 00:34 6 5.7
ita_small_tiles sffraction1h 06:42 72 5.6
ita_small_tiles sffraction24h 04:38 49 5.7
ita_small_tiles sffraction3h 02:14 24 5.6
ita_small_tiles sffraction6h 01:07 12 5.7
ita_small_tiles t2m 11:04 73 9.1
ita_small_tiles t2mavg 00:25 3 8.4
ita_small_tiles t500 08:24 73 6.9
ita_small_tiles t700 08:39 73 7.1
…
Nota che il tempo per step di un flavour tiled è molto piú lungo perché è il tempo di generazione di ogni tile per quello step
Grazie, va benissimo.
al momento non tiene traccia del tempo passato a generare input intermedi
Questo sarebbe interessante per capire il "peso" complessivo della generazione di un prodotto ma possiamo tenerlo come enhancement futuro.
Incidentalmente, dall'analisi del file che avevo allegato col nuovo tool, il prodotto wflags10m può essere un buon campo di prova per capire meglio le differenze nel benchmark di #126 :
$ analyze-run ~/Scaricati/products_cosmo_2I.json.txt
Flavour Recipe Total time Total steps Time per step
ita_small_tiles cape 26:06 49 32.0
ita_small_tiles hcc 08:50 49 10.8
ita_small_tiles hzero 13:02 49 16.0
ita_small_tiles lcc 10:45 49 13.2
ita_small_tiles mcc 08:49 49 10.8
ita_small_tiles mslp 06:16 49 7.7
ita_small_tiles rh2m 08:18 49 10.2
ita_small_tiles sf12h 00:43 4 10.8
ita_small_tiles sf1h 07:39 48 9.6
ita_small_tiles sf24h 04:08 25 9.9
ita_small_tiles sf3h 02:36 16 9.8
ita_small_tiles sf6h 01:18 8 9.8
ita_small_tiles sffraction12h 00:30 4 7.6
ita_small_tiles sffraction1h 05:49 48 7.3
ita_small_tiles sffraction24h 03:03 25 7.3
ita_small_tiles sffraction3h 01:55 16 7.2
ita_small_tiles sffraction6h 00:57 8 7.2
ita_small_tiles t2m 09:57 49 12.2
ita_small_tiles t500 07:17 49 8.9
ita_small_tiles t850 08:27 49 10.4
ita_small_tiles tcc 08:43 49 10.7
ita_small_tiles tp12h 00:36 4 9.1
ita_small_tiles tp1h 06:33 48 8.2
ita_small_tiles tp24h 03:54 25 9.4
ita_small_tiles tp3h 02:19 16 8.7
ita_small_tiles tp6h 01:08 8 8.6
ita_small_tiles vis 12:03 49 14.8
ita_small_tiles warrows10m 34:56 49 42.8
ita_small_tiles wflags10m 91:28 49 112.0
ita_small_tiles wflags250 37:57 49 46.5
ita_small_tiles wflags500 38:04 49 46.6
ita_small_tiles wflags700 38:07 49 46.7
ita_small_tiles wflags850 38:07 49 46.7
ita_small_tiles wmax 06:51 49 8.4
ita_small_tiles wspeed250 06:47 49 8.3
ita_small_tiles z250 06:39 49 8.2
ita_small_tiles z500 06:34 49 8.0
ita_small_tiles z850 06:27 49 7.9
Ho cambiato arkimaps per tenere la statistica del numero di PNG generati per step, e analyze-run per mostrarla
Ora c'è anche un inputs.json
che per ogni input usato dice in quale ricetta è usato, quali passi di computazione sono stati fatti per generarlo, e quanto tempo ci han messo
Direi che ora gli elementi per un'analisi di fino sulle tempistiche ci sono
Sarebbe utile avere la possibilità di consultare da qualche parte fra gli output (anche attivabile su opzione specifica, non ho preferenze) le tempistiche di produzione per ogni prodotto in modo da capire se esistono casistiche che potrebbero beneficiare di qualche ottimizzazione