Re: Dell'arte programmatoria Era: (RE: Installazione Etch su HP Vectra 486/33N)
Il giorno lun, 16/04/2007 alle 14.16 +0200, Premoli, Roberto ha scritto:
> Invece, chi come me ha qualche anno sulle spalle, si ricorda bene la fatica di programmare quando avevi a disposizione 40K (quaranta kylo bite) di ram su uno ZX spectrum o 38K (trent'otto kilobyte) su un Commodore 64... per avere la velocita' e/o meno ram occupata , passavi a migliorare il codice fino al massimo e poi passavi all'assembler.
> Quello si che era/e' codice ottimizzato... altrimenti, semplicemente non funzionava.
> Una volta ci si chiedeva: "come faccio a far il soft piu' veloce/piu' piccolo possibile?"
> Oggi ci si chiede: "perche' l'utente si ostina a usare un P2@400Ghz-128Mram? Con quel bidone non ci fai nulla, il mio soft ha requisiti minimi P4@3GHz 2Gram, compralo o fai ameno del mio soft".
>
> Mi spiace, ma le nuove generazioni di "scrittori di codice sorgente" NON sanno programmare, tutto qui.
Fino a qualche anno fa ero d'accordo con te. Ti parlo di tempi in cui i
computer andavano da 1 a 8-10 MHz.
Il problema e` che le richieste degli utenti sono aumentate e (nel
mercato) i tempi di sviluppo si sono ristretti.
Sul C64 non avevi multiutenza, rete, interfaccia grafica. Lo schermo era
320x200 a 4 colori (o, con tecniche strane, 16 colori, totale 32.000
bytes). Non c'erano pipeline sul processore da ottimizzare, cache a 2-3
livelli, colli di bottiglia sui bus. Niente multitasking, quindi niente
virus, trojan, protezione della memoria, ecc.
Se un utente inseriva un dato sbagliato, il programma spesso crashava
Oggi un PC medio ha uno schermo 1280x1024 a 16 milioni di colori, 512 Kb
solo di grafica da spostare sui vari bus, interrupt dei piu` vari,
attacchi che arrivano dappertutto, memoria protetta, software che
reagisce in modo quasi intelligente a dati errati, centinaia di software
che girano contemporaneamente, ecc.
Aggiungici che il mercato vuole ogni settimana qualcosa di nuovo. E in
questo mercato metto anche il software per Linux, visto che gli utenti
vogliono sempre l'ultima versione che deve fare di piu`.
Senza contare gli effetti 3D, anche solo l'automount delle periferiche,
le icone sul desktop, l'accesso trasparente a dischi di rete, il
ridimensionamento automatico delle finestre, i font anti-alias, le
applet sul desktop, i feed che si autoaggiornano via Internet, la
correzione ortografica automatica sull'instant messenger, le iconcine
animate, le web-application, ecc. ecc.
Questo ha portato alla necessita` di due cose: programmazione a oggetti
(per riciclare il lavoro e renderlo "stagno") e linguaggi ad alto
livello (per evitare di preoccuparsi delle gestione della memoria,
fondamentalmente), e quindi ad altri "sprechi" prestazionali
(allocazione di spazi preventiva, cicli di clock per la chiamata a
funzione con conseguente salvataggio e ripristino dello stack, garbage
collector, macchine virtuali e codice intepretato, ecc.)
Aggiungici che l'architettura dei PC non e` che sia un bijoux (pochi
registri, bus di sistema lenti su cui passa tutto, pochi IRQ, modalita`
compatibili dei processori, indirizzamento ormai "stretto" con solo 32
bit).
Inoltre non puoi programmare tutto in assembler, perche` le architetture
delle CPU sono troppo varie e rischi di perdere un sacco di tempo e di
scrivere brutto codice perche` lasci troppo vuote le pipeline, o
invalidi troppo la cache, o rendi inline codice troppo grande per la
cache L1, magari solo di 10 byte, o invalidi troppo spesso la branch
prediction, o usi istruzioni che in un processore sono hardware e in
un'altro sollevano eccezioni sulla CPU e vanno emulate in software, ecc.
Io non credo che i programmatori oggi non sappiano programmare, anzi, le
tecniche di programmazione sono raffinatissime, solo che sono
completamente diverse da 15-20 anni fa.
Bye.
--
Alessandro Pellizzari
Reply to: