|
|
|
![]() |
|
Strumenti |
![]() |
#41 | |
Senior Member
Iscritto dal: Dec 2000
Messaggi: 1311
|
Quote:
|
|
![]() |
![]() |
![]() |
#42 | |
Senior Member
Iscritto dal: Dec 2000
Messaggi: 1311
|
Quote:
Io non sono un esperto d'informatica, ho amici che lo sono e hanno posizioni diverse. Il tuo discorso è condivisisbile in parte, ma altre cose non mi convincono, io non credo che serva una montagna di lavoro in termini di ora per fare software e SO semplici, con le funzioni necessarie ed allo stesso tempo sicuri. Si può sacrificare un pò di grafica, ma credo che 65K colori siano già più che sufficienti. Quello che mi nuoce xeal è che tra poco tempo sarò costretto a cambiare il pc perché sul mio centrino 1.6 GHz 512MB ram Vista non girerà (è lento sul desktop di mia sorella), XP non verrà più sviluppato e dovrò "gettare" un pc perché non più sicuro. |
|
![]() |
![]() |
![]() |
#43 |
Senior Member
Iscritto dal: Jun 2003
Città: vivo in Sicilia (tra la prov. di AG e Palermo)
Messaggi: 956
|
Io invece ci credo
![]() Se i tuoi amici sono degli espertoni, ABILISSIMI nel programmare in assembly (l'ho scritto maiuscolo perchè devono essere proprio più bravi di un compilatore, il quale è già abilissimo con la "a" maiuscola), al punto di poter quasi programmare ad occhi chiusi in linguaggio macchina (che poi non è altro che assembly tradotto in binario - diciamo che l'assembly è un linguaggio mooolto elementare, in relazione biunivoca con il linguaggio macchina), e di creare dell'ottimo codice automodificante con estrema facilità, magari gli do ragione, ma che non vengano a dirmi che "ottimizzazione" (che può essere sinonimo di leggerezza e velocità) e "semplicità" sono due concetti che vanno a braccetto, a meno che per semplicità non si intenda essenzialità (nel senso di ridurre le cose all'osso, al minimo indispensabile, e neanche, perchè vale una regola empirica per cui circa il 10% del codice richiederà circa il 90% del tempo di esecuzione, quindi togliere quello che sta attorno, in genere, non da grossi vantaggi, e cercare di ottimizzarlo, oltre un certo limite, è uno spreco di tempo - ma quel 10% di solito è bello tosto da ottimizzare). In genere, in informatica, la semplicità si valuta in primis a livello di codice sorgente (che poi si compila per ottenere un programma eseguibile), e un codice semplice è un codice... che non cerca di fare cose complicate, per le quali ci si deve spremere le meningi sia per "inventarle", sia per capirle: è fondamentale che un programma sia semplice da leggere e da capire, sia per chi non lo ha scritto (e potrebbe lavorarci sopra in un momento successivo), sia per chi lo ha scritto (perchè, comunque, non si tratta di un linguaggio "naturale", e dopo mesi o addirittura anni, può risultare molto ma molto difficile capire che cavolo si voleva fare), perchè con l'aumentare della complessità del codice aumenta anche la probabilità di introdurre un bug (è già difficile evitarli con il codice più semplice e logicamente corretto di questo mondo, perchè basta farsi scappare una virgola in qualche centinaio o migliaio di righe per provocare una catastrofe - nel senso più letterario e catastrofico del termine). E i bug fanno perdere tanto, tanto tempo: i tuoi amici possono anche aver ragione nel dirti che non è difficile scrivere un programma, perchè la cosa veramente difficile è farlo funzionare bene, e l'ottimizzazione spinta non aiuta, perchè per ottimizzare molto, bisogna lavorare ad un livello molto basso, ma questo significa dover fare cose più complicate, con strumenti più potenti, perchè ti consentono di avere una maggiore libertà, ma avere tanta libertà significa da un lato poter realizzare le cose migliori (dal punto di vista delle prestazioni), dall'altro rischiare di compiere gli sbagli peggiori (perchè ogni cosa che farai potrebbe avere degli effetti collaterali di cui non ti accorgi finchè non provocano danni - e potrebbe succedere solo in casi particolari, frequenti nell'uso comune del programma ma difficili da prevedere nei test di laboratorio - e prevedere gli effetti collaterali è tanto più difficile quanto più complicate sono le cose che si cerca di fare, così diventa un circolo vizioso). Bisogna tener conto che non può esistere un software sicuramente esente da bug, perchè per avere una certezza assoluta in tal senso bisognerebbe testare tutte le possibili combinazioni di input in tutti i possibili scenari d'uso e di interazione con altri software, e questo richiederebbe un lavoro difficilmente compatibile con la durata della vita di una persona: alla fine, ci si accontenta di realizzare un software ragionevolmente sicuro, tirando fuori delle pezze per rattoppare qua e la dei problemi che spuntano (inevitabilmente) strada facendo, ma già questo dovrebbe dare l'idea di quanto possa essere lungo e complicato, nel complesso, l'iter di sviluppo di un qualsiasi software. E siccome fare cose complicate, per ottimizzare le prestazioni, significa aumentare il rischio di sbagliare e introdurre bug (non solo di sicurezza, ma proprio relativi al corretto funzionamento del programma), diventa evidente come ciò comporti un aumento del tempo necessario per completare lo sviluppo. E siccome il tempo è denaro, segue il mio ragionamento nell'altro post (poi, non dico che non ci si speculi sopra per niente, eh, anzi, è vero il contrario, e alla fine si deve cercare un compromesso che vada bene per tutti - e questo è dato dalla concorrenza, dall'elevata diffusione e dalla velocità nella realizzazione di nuovi prodotti). Provo a fare un esempio un po' più tecnico, cercando di mantenerlo semplice. Sicuramente conoscerai, a grandi linee, Java: si tratta di una piattaforma che consente di creare programmi per sistemi operativi e processori diversi con semplicità, basata su un linguaggio di programmazione omonimo, di altissimo livello. Un programma realizzato in java tenderà ad essere più lento di uno scritto con altri linguaggi e specifico per un sistema operativo e/o un particolare processore, e tenderà anche ad occupare più memoria. Di contro, rende più semplice e veloce scrivere applicazioni che girino bene su linux e windows (ad esempio), e rende praticamente impossibile (a meno di bug nell'implementazione della virtual machine) introdurre nel programma bug relativi, ad esempio, a: - buffer overflow: si ha quando si sbaglia o si omette il controllo di un limite di memoria, tipicamente per scambiare dei dati, fidandosi che verranno scritti entro i limiti massimi, e se questo non succede si sovrascrivono altre aree di memoria: si possono corrompere dei dati importanti o delle istruzioni, far "crashare" il programma o addirittura l'intero sistema, oppure consentire ad un virus di fare danni; - double delete: si cerca di cancellare due volte, per errore, una certa area di memoria, e possono succedere grossi casini (è piuttosto comune che succeda, soprattutto in grossi progetti a cui lavorano molte persone); - memory leakage: si libera male una porzione di memoria che non serve più, che rimane assegnata al programma ma non più accessibile, nè dal programma stesso, nè da altri programmi, fino alla terminazione del programma che lo ha provocato. Invece, con il C++, che è un linguaggio comunque di livello molto alto, è possibile realizzare programmi più veloci, che richiedono meno memoria (ma anche più specifici e legati alla piattaforma - a parte il caso dell'uso con .Net, ma si tratta di una piattaforma per certi versi simile a java), e consentono di fare molte cose che in java non si possono fare (come scrivere il driver di una periferica, o un sistema operativo), ma di contro è molto sucettibile agli errori/bug cui accennavo, che ti assicuro sono molto comuni e difficili da evitare, anche con tutta la buona volontà e la bravura di questo mondo (tant'è che si impiega molto tempo, durante lo sviluppo di un software di un certo livello, per dare letteralmente la caccia a double delete e leaks), e anche senza cercare di ottimizzare tutto il più possibile (cosa che renderebbe più grande il numero degli errori e dei bug, oltre a rendere necessario, in certi casi, scendere ad un livello più basso). Naturalmente, ci sono non pochi casi in cui l'ottimizzazione spinta serve e si fa, e senza neanche troppi problemi, perchè spesso si tratta di casi studiati per molti anni e quindi ben noti. Ma non credo che certi casi limite siano di particolare interesse nel nostro discorso. Per quanto riguarda i tuoi problemi, nello specifico so troppo poco per poter dire qualcosa di preciso. Se non ricordo male, il supporto ad xp dovrebbe terminare tra un paio d'anni per quanto riguarda le patch di sicurezza (dopo c'è il supporto a pagamento per le aziende); in ogni caso è un sistema abbastanza maturo, e se i tuoi software ti consentono di lavorare come utente limitato, facendo spesso il backup dei file importanti (per evitare rogne con virus guastafeste) potresti anche continuare ad usarlo con una certa tranquillità (soprattutto tenendoci su un antivirus aggiornato e magari anche un firewall). Al limite, potresti avere problemi con upgrade necessari ai tuoi software (che potrebbero non supportare più xp). Se non hai particolari problemi con le prestazioni, poi, potresti anche installare (facendoti aiutare da un amico esperto) una versione essenziale (ed aggiornata - e se si trovano driver buoni per le tue periferiche, chiaramente) di linux per far girare xp in una macchina virtuale: avresti già un tampone in mezzo che aumenterebbe la sicurezza, e se non devi lavorare connesso ad internet, cioè se i programmi che usi non lavorano online, allora puoi anche usare direttamente i programmi di linux per navigare, scaricare e gestire la posta; se poi avessi dei problemi di sicurezza (= virus che passano le barricate - comunque un po' difficile, ma niente è mai impossibile) che ti incasinassero xp in maniera irrecuperabile, per sbarazzarti del problema potrebbe bastare cancellare i file "contaminati" usati dalla macchina virtuale (contengono un hard disk virtuale con l'installazione di windows) e sostituirli con una copia di backup (corrispondente ad un formattone con reinstallazione fresca fresca di os e programmi). Se hai dello spazio libero per una partizioncina, comunque, un piccolo esperimento con linux e wine proverei a farlo, magari i tuo programmi girano bene. La macchina virtuale è comunque una soluzione più lenta e potenzialmente dovresti (comunque te lo consiglierei, specialmente se il tuo centrino usa una vga integrata) aumentare la ram del tuo note. Se si tratta di ddr2, comunque, non spenderesti molto, quindi potresti anche pensare di liberare gli slot e sostituire tutti i moduli (potresti avere solo due slot con 256MB ciascuno, e sostituirli anche con 2 da 1GB non dovrebbe essere una spesa esorbitante, anche se la sodimm costa più della ram per pc desktop). Ma aumentando la ram (specialmente fino a 2 GB), per quanto ho capito (non ho modo di verificare e fare test di persona) tendono a ridursi parecchio anche i problemi di pesantezza con Vista (a proposito, il pc di tua sorella quanta ram ha? e l'hd a quanti giri va? avete provato a disattivare aero, e magari qualche servizio superfluo? magari i tuoi amici potrebbero darti una mano a provare a configurarlo). Ma sui 65k colori dicevi sul serio? Io ormai a 16 bit non saprei tornare (sul pc), ma se tieni normalmente lo schermo con queste impostazioni, allora mi sa che recuperi anche un po' di performance con una virtual machine (il mio voleva essere solo un esempio su come il software degli smartphone sia più semplice e leggero perchè deve fare molto meno; forse avrei reso meglio l'idea dicendo che alcuni dei processorini usati non hanno neanche l'fpu, quindi non possono fare calcoli con i numeri reali - e questo dovrebbe bastare a intuire quanto quei programmi siano castrati e non confrontabili con quelli per pc). |
![]() |
![]() |
![]() |
#44 |
Member
Iscritto dal: Jan 2008
Messaggi: 55
|
Sarebbe meglio se sostituissero il Silicio con il Germanio, in questo modo l'energia di gap passerebbe da 1.12V a 0.66V. Con un tale abbassamento di voltaggio i chip starebbero ancora freshi per i prossimi 4 o 5 anni e nel frattempo i raffreddamenti ad acqua potrebbero diventare piu' popolari ed economici.
Il fatto di avere delle celle di Peltier nella CPU mi sembra una soluzione solo all'apparenza intelligente...senza considerare che con i processi di produzione sempre piu' orientati alla miniaturizzazione perche' guidati dalla multi-core-tendenza...mi sembra di difficile realizzazione. Celle di Peltier su un die a 45nm o ancora meglio a 32nm di cui gia' si parla? MAH! |
![]() |
![]() |
![]() |
#45 |
Senior Member
Iscritto dal: Jun 2003
Città: vivo in Sicilia (tra la prov. di AG e Palermo)
Messaggi: 956
|
E perchè no? In generale (questa è solo una implementazione) si parla di thin film prodotti con nanotecnologie, spessi 3-400 micron e con una superficie pari a quella del die del processore (mica si faranno processori da 32nm di lato
![]() |
![]() |
![]() |
![]() |
#46 |
Senior Member
Iscritto dal: Feb 2002
Messaggi: 7070
|
sarebbe un po' rumoroso, ma sarebbe anche una bella avventura ventilare il computer con un ventilatore mosso da un motore stirling con il lato caldo accoppiato al processore
![]() |
![]() |
![]() |
![]() |
Strumenti | |
|
|
Tutti gli orari sono GMT +1. Ora sono le: 23:12.