|
|
|
![]() |
|
Strumenti |
![]() |
#21 | |
Senior Member
Iscritto dal: Dec 2004
Città: IV Reich
Messaggi: 18593
|
Quote:
l'aumento del costo dell'energia è una mazzata per le fasce più deboli, gente che muore di fame, servizi sanitari quasi azzerati, non è un caso che lo stesso marx teorizzava l'abbassamento del costo dell'energia per il benessere del "popolo"
__________________
Wind3 4G CA |
|
![]() |
![]() |
![]() |
#22 |
Member
Iscritto dal: Aug 2001
Città: Basel
Messaggi: 169
|
Dai ragazzi... È ovvio che questo tipo di approccio non verrà adottato su computer normali, ci manca solo che mi sbagliono i conti sulla busta paga o la dichiarazione dei redditi.
Secondo me è una ricerca interessante. In ambito audio/video/foto in molti casi (non parliamo di analisi cliniche o cose simili) la qualità risulta accettabile. Se per esempio guardo un filmato, fosse anche in Blu-Ray, un errore dello 0.5% non è percepibile (non se non metto in pausa e mi avvicino alla TV per guardare un pixel alla volta!). Ho capito che la macchia sotto il balcone è leggermente diversa, ma l'informazione è la stessa: c'è una macchia di umido sotto il balcone. Su un lettore da salotto il risparmio energetico potrebbe non essere decisivo (per quanto comunque auspicabile in termini di calore sviluppato), ma su dispositivi mobili potrebbe fare la differenza. Per gli apparecchi acustici probabilmente vale lo stesso discorso: se la qualità cala leggermente non me ne accorgo perché c'è comunque il mio cervello a metterci una pezza. Però un'autonomia 2-3 volte superiore la noto eccome. Non stiamo parlando di ascoltare musica in mp3 a qualità alta o bassa, per molte persone si tratta di sentire quello che le circonda o non sentirlo.
__________________
Benchmarks are like sex: everyone wants it, everybody is sure they know how to do it, but nobody knows how to compare performance. [Jim Turley] |
![]() |
![]() |
![]() |
#23 | |
Member
Iscritto dal: May 2010
Messaggi: 145
|
Quote:
ad es avendo un algoritmo che impiega 100*n³ secondi con questo metodo, ipotizzando una riduzione di 3 volte si avrebbe un tempo di esecuzione 100/3*n³ s, quindi con un input grande, diciamo 1000, impiega 33333333333,333333333333333333333 secondi mentre usando un algoritmo meno preciso, ma che richiede solo 200*n²*log(2)n s, si ha 200*1000*1000*9,9657842846620870436109582884681 = 1993156856,9324174087221916576936 secondi, ovvero 16,7 volte più veloce! come inoltre già detto da LMCH, si hanno anche vari altri modi per velocizzare perdendo (a volte anche no) precisione nei calcoli, ad esempio usando calcoli in float (32bit) invece che in double (64bit) o ancora in half-float (16bit), oppure usare valori interi per rendere valori frazionari, come nelle foto e video dove i gradienti da 0 (nero) a 1(bianco) sono espressi da 0 a 255 (8bit) o da 0 a 65535 (16bit); oltretutto, programmando a basso livello (assembler) si possono scegliere arbitrariamente sia la precisione che il numero di bit da utilizzare nei calcoli (cosa che si può fare anche in c/c++ ma è meno efficiente e più complessa da gestire). ovviamente il tempo di esecuzione minore, con un assorbimento costante, implica un consumo ugualmente minore, o un'autonomia maggiore. (se la stessa cosa che su un processore da 1GHz va fluida, si può riuscire a farla andare fluida con un processore da 200MHz, consumando un quinto) |
|
![]() |
![]() |
![]() |
Strumenti | |
|
|
Tutti gli orari sono GMT +1. Ora sono le: 23:44.