Il discorso, fatto così, è un po' semplicistico...
On 23/02/22 10:37, Leonardo Boselli wrote:
Riguardo al consumo elettrico occorrerebbe anche fare un distinguo, del
dove è dissipato.
Per intendersi: in questo momento, a casa mia, nella stanza dove ho il
computer, accesso 24/24 e il monitor, la energia che dissipano è tale
che se "lavorano sodo" non mi serve accendere il riscaldamanto, quindi
non è energia perduta.
Se sei in estate, o all'aperto o in un data center che devi raffreddare
allora sì che è uno spreco.
Quindi il consumo nel leggere gli headers e effettuare la compilazione
nella stanza del programmatore in inverno non sono spreco, mentre è
molto più importante il ridurre il consumo al run time.
Riduzione di consumi che peraltro porta sempre anche a una
velocizzazione delle esecuzione, quindi magari meno processori che girano.
Se parliamo di consumi energetici su scala globale, il fatto che il
programmatore si scaldi la stanzetta d'inverno o meno è una goccia
nell'oceano. Non ha neppure senso considerarla.
La formazione dei programmatori negli ultimi tempi (io ci lavoro dal
1979) è stata sempre mirata alla logica, alla gestibilità, insomma a
qualcosa di bello da vedersi e spiegarsi, ma tralasciando completamante
la efficienza del processo al run time.
Questo è vero quando il programma non deve girare troppo spesso e quindi
conta il tempo di sviluppo, ma si vedono applicazioni interpretate che
girano pressoché di continuo quando una versione ottimizzata per il
processore consumerebbe un centesimo delle risorse.
La tendenza è stata quella di astrarre ogni strato, ma facendo così si
perdono tutte le ottimizzazioni. I loinguaggi a oggetti sono belli d
avedere dal punto di vista logico, per qualcuno sono pure facili da
gestire, ma usano un quantitativo abnorme di risorse (specie di memoria)
rispetto alla versione procedurale.
Questo, ovviamente, dipende dal linguaggio. In generale le astrazioni
hanno un overhead di CPU e di memoria, è vero, ma è un overhead
_ottimizzato_. Non è detto che un programmatore "medio" ottenga per
forza un programma più efficiente lavorando con un linguaggio di basso
livello: utilizzare astrazioni ottimizzate potrebbe essere più
efficiente che non scriversi tutto (male) da zero.
Oltre a questo esistono anche linguaggi di alto livello con un costo
delle astrazioni praticamente nullo; un esempio per tutti: Rust.
Un altra fonte di spereco energetico sono i browser e tutte gli script
che ci giranao.
Dobrebbe ess4erci su ogni browser un bottone, facilmente raggiungibile,
e attivo (magari con una combinazione di tasti) che renda la pagina
statica, fermando tutti gli script, il reload, le animazioni e il resto,
abilitando solo i link e le scrollbar, se rimosse.
Gli script sono essenziali per applicazioni web molto interattive.
Possiamo discutere dell'utilità di queste applicazioni, ma se accettiamo
che esistano e che le persone le usino non possiamo lamentarci degli
strumenti utilizzati per svilupparle. A me va benissimo il concetto di
ipertesto anni '90 ma credo che il resto del mondo preferisca Facebook.
Vogliamo discutere di spreco energetico? Parliamo di quella gran m***a
che è il proof-of-work utilizzato da BitCoin e tutte le altre cosiddette
crypto-valute.
federico
--
Federico Di Gregorio federico.digrego...@dndg.it
DNDG srl http://dndg.it
The number of the beast: vi vi vi. -- Delexa Jones
