Newsgroup: it.scienza.informatica
Titolo: ... risc vs vliw vs epic vs multiprocessor, e... che fine hanno fatto i transputers?

allo scopo di movimentare un po' le acque :) (e' un'impressione o il
gruppo e' un po' "anemico"? ;) ) mi piacerebbe far ripartire
l'interessante discussione che era sorta mesi fa su ich.cpu
riguardante pregi e difetti delle suddette architetture...
in pratica vorrei sapere se effettivamente lo stato attuale dei
compilatori vliw e' in grado di sfruttarne il potenziale, se secondo
voi i vliw sono adatti all'uso nei pc su applicazioni "normali"
(quindi senza calcoli in virgola mobile ripetuti sempre nello stesso
modo, etc...), e dove si possono avere i vantaggi maggiori rispetto al
risc.
inoltre: allo stato attuale secondo voi quanti processori (ovviamente
in un sistema multiprocessor) si possono sfruttare contemporaneamente
in media su un sistema "general purpose", dove quindi non ci sono
particolari informazioni "statiche" sul lavoro da fare poi a run-time?
e sul lungo termine, e' meglio un single processor vliw o un
multiprocessor con processori non troppo "ambiziosi"??
e per ultimo, una curiosita': ma la Inmos, i Transputer li fa ancora
:-?
ok, io l'argomento (anche se un po' "tamarro" :D ) l'ho lanciato, a
voi la parola!!! :)
grazie e ciao,
gabriele.

(se disturbo ditelo che mi rimetto solo a guardare ^_____^ )
 :) i VLIW (o epic come intel pretende di chiamarli ;) ) sono
processori che si distinguono perche hanno una Very Long Instruction
Word, cioe' una "superistruzione" che e' in realta' un pacchetto di
mini-istruzioni ogniuna delle quali puo' andare in esecuzione su una
"propria" unita' di esecuzione senza preoccuparsi di eventuali
dipendenze logiche con altre miniistruzioni della superistruzione,
perche' l'assenza di dipendenze e' garantita a tempo di
_compilazione_. In pratica, e' come spingere all'estremo il concetto
di processore superscalare, in quanto questi chips hanno molte unita'
di esecuzione indipendenti e non hanno transistors "sprecati" nel
tentativo di riorganizzare il codice prima che arrivi alle u. di
esecuzione nella speranza di evitare che piu' istruzioni dipendenti
l'una con l'altra finiscano contemporaneamente sulle unita' di
esecuzione (non rispettando quindi la semantica originale del
programma sequenziale).
In pratica quindi un programma non e' piu' una sequenza di istruzioni
che al loro interno possono avere una qualche forma di parallelismo (a
livello firmware) ma una sequenza di superistruzioni che al loro
interno sono set di istruzioni parallele e indipendenti l'una con
l'altra che a loro volta possono avere parallelismo interno a livello
firmware.
In questo caso, una eventuale riorganizzazione dinamica del codice
avrebbe senso solo nel caso si usi una pipeline per le
superistruzioni, per evitare o limitare gli arresti della pipeline
stessa nel caso di dip. logiche fra "superistruzioni".... ma visto che
il compilatore e' molto "potente", e' da vedersi se non convenga
limitare queste dipendenze (nel senso di allontanare il piu' possibile
superistruzioni dipendenti l'una dall'altra) gia' a tempo di
compilazione.
la fregatura di questi sistemi e' proprio il grosso peso del
compilatore, che deve essere per forza eccellente per minimizzare i
possibili degradi dell'architettura (per esempio nel senso di riuscire
a "riempire" il piu' possibile le superistruzioni nonostante i salti
condizionati, etc...). la cosa e' difficile perche' staticamente (aka
a tempo di compilazione) molte cose per un'applicazione generica _non_
sono disponibili... e' per questo che i vliw sono diffusi in ambiente
di calcolo massiccio e di dsp (l'applicazione fa sempre la stessa
cosa) e poco in ambiente general purpose...
inoltre, nel momento si switch di tecnologie (es. si passa da n unita'
e quindi n istruzioni per "pacchetto" a n + 3..... ), bisogna
ricompilare il codice per non avere degradi, o quantomeno dargli una
"passata" con il backend nel senso di riottimizzare il codice per la
nuova architettura...
spero di non aver detto vaccate :)
ciao,
gabriele.

 multiprocessor con processori non troppo "ambiziosi"??
Il VLIW e' un processore semplice...
Comunque, se hai accesso a IEEE Computer, ti consiglio la lettura
dell'intero numero di Dicembre 1997.
Ciao
 
-- 
Andrea Vettori
------------------------
vet...@computer.org
http://www.dei.unipd.it/~vettori

parte dei gruppi it.comp....
wee, miticoooo, senza di te mi sentivo un po' orfano da queste parti
;)
(il resto delle risposte o piu' che altro delle domande le posto piu'
tardi, offline...)
ciao e (tanto per stare sicuri) auguro anticipatamente a tutti buona
pasqua ;)
gabriele.


Figurati che poi la gente si chiederebbe : Ma con windows 95 come
 gira?
 
Ciao.
Giorgio.

Il VLIW e' un processore semplice...
io infatti non dicevo "complesso" ma "ambizioso", nel senso che se
vuoi tante unita' di esecuzione ti ci vogliono un bel po' di
transistors, altrimenti se ci metti poche u.e. non c'e' un gran
vantaggio.... ma si sa quante unita' avra' il merced? ed e' trapelato
qualcosa sull'architettura del suo successore, che pare sia gia' in
lavorazione (a livello di disegno) presso la hp??
anyway, insomma, meglio un set di processori (cardinalita' maggiore di
due, altrimenti non c'e' gusto :)... 4? 8? 16?) costruiti su un die
piccolino e molto semplici (niente register renaming, out of order
exec., etc...) ma con un supporto nativo per le architetture
multiprocessor (es. i transputers, appunto...) oppure un unico chip
VLIW "tosto" con molte unita' di esecuzione? questo nell'ottica di un
uso general purpose, perche' altrimenti in settori critici il vliw ha
gia' dimostrato di essere "quasi imbattibile" (es. l'ultima famiglia
di dsp texas instruments).
rispetto al problema del porting del sw? e a quello economico
(economie di scala, costo del die, etc.)? e a quello del mercato (dove
la maggior richiesta e' per i processori molto portati a giochi.... e
qui mi sa che vince a mani basse il vliw ;))?
insomma, per semplificare, quale e' l'architettura migliore fra le due
e secondo quale "metrica"? e quale secondo voi vincera' sul mercato
(che, come hanno dimostrato molti casi, premia l'architettura peggiore
;) )?
su su :), siamo TUTTI invitati a partecipare a questa discussione, non
solo Andrea ed io... senno' che gusto c'e'? ;P :) (nel senso che vince
lui...)
dimenticavo, tre domandine in chiusura che sono in qualche modo
"relate" all'argomento principale ma non perfettamente integrabili:
1. qual e' il s.o. che "scala" meglio su architetture multiprocessor?
e, se sopratutto, perche' :) ?
2. c'e' gia' stato un porting di uno unix-like su un vliw? insomma, un
antesignano di Solaris e Ultrix per il merced?
3. vorrei qualche informazione sulle implementazioni intel ia32
(insomma per i386) del multiprocessing. Per quel che ne so la versione
implementata per i pentium e' "pittosto grezzina" nel senso che a
spanne dal comportamento del sistema deduco che l'arbitraggio della
memoria comune e' fatto a polling (un ciclo a te, un ciclo a me....) e
quindi si capirebbe perche' non esistono mobo basate sulla specifica
intel con piu' di due processori.... fino a due p. il degrado e'
abbastanza trascurabile, con piu' chip.... continuerebbero a lavorarne
solo due ;)... e' vero tutto cio'? e per il p2 (in particolare per lo
slot2) le cose sono fatte in modo diverso?
ciao e grazie anticipatamente,
  gabriele.



:D
mi sa che finche' non faranno il porting delle directx 6 per il merced
non avra' seccesso... ;)
ciao,
gabriele.

 slot2) le cose sono fatte in modo diverso?
Dunque...
credo che parlare di arbitraggio un po' triste e darne la colpa ai processori
non sia corretto;
il caro Pentium, quando ha bisogno di accedere alla memoria, fa una pregevole
richesta al gestore della stessa - ma lui non sa nulla di quanti suoi compari ha
accanto.
Il difetto del Pentium - anche del pII se non ricordo male - è che non fa lo
"snurfing", ovvero non è in grado di intercettare dati scambiati tra un altro
processore ed il controllore della memoria nel caso che interessino anche a lui.
A parte questo, il sistema di Snoop implementato sul pentium non è malaccio.
Riguardo al perchè si trovino quasi solo realizzazioni bi-processor per la
famiglia Pentium credo sia dovuto al mercato caotico e "ludico" dei PC odierni.
* alla Intel conviene la corsa agli armamenti (cioè processori sempre più
spinti) perchè i livelli di investimenti nella ricerca che le fa non sono
possibili ad altri (leggi AMD...); se spendessero molto per progettare un ottimo
chipset pluri-processore si tirerebbero la zappa sui piedi. Come venderebbero il
Pentim 3, 4, 5, ... se per migliorare le prestazioni bastasse aggiungere altri
processori in parallelo?
* un sistema multiprocessor è potente SE hai un software che lo utilizzi.
Non potendo contare su un SO suff. diffuso decente (anche con NT il guadagno
avendo un bi-processor è ridicolo) occorrerebbe che le ditte soft. realizzassero
versioni specifiche - con incremento di costi sicuramento non gradito.
Non vedo comunque problemi tecnici nel realizzare arbitri per sistemi
multi-processor.
Con il P2 il protocollo del Bus si è notevolmente evoluto (lo scambio è a
pacchetti) e quindi è più facile "generalizzare" il gestore per n processori.
A dire il vero un problema con il Pentium c'era: dove li mettevi più di 2
processori?!?
Già in una scheda singol-processore ti ritrovi che tra alette di raffreddamento,
ventoline e fronzoli vari fai fatica ad infilargli una scheda più lunga del
solito!
Con il P2 hanno pensato di metterli in verticale, ma ugualmente un processore
ingombra come una bistecchiera (e scalda molto di più) quindi non credo che
vedremo molte realizzazioni commerciali com più di 2 processori.
Sigh! A volte riprendo in mano la cara vecchia scheda 386sx. Fai fatica a
trovarlo. E' un quadratino di 2x2 cm, con piedinatura solo ai lati ed ovviamente
saldato. Fa così tenerezza... il Bios è più grande.
...f orse ho divagato troppo... scusate!
debrando

...f orse ho divagato troppo... scusate!
secondo me no, anzi ti ringrazio delle risposte.. l'idea era quella di
poter "chiaccherare" liberamente in modo da imparare l'uno
dall'altro...
ciao!
gabriele
--
Gabriele Zugliani - Student at Pisa University (Dept. of Computer Science)
NOTE: THE EMAIL ADDRESS IN THE HEADER IS MODIFIED, PLEASE REMOVE "NZPM".
Linux infos: 
http://www.linux.org
 
http://sunsite.unc.edu/LDP
http://pluto.linux.it
 
http://ildp.psy.unipd.it
 
http://www.linux.it

 della Inmos ;)
Scusami, cosa sono i transputer?  Mi posteresti l'indirizzo di questa
Inmos, per favore? O forse è 
www.inmos.com
?
Grazie :-)
Ciao!

Inmos, per favore? O forse è 
www.inmos.com
?
sono una implementazione di chips anni 80 con le primitive del CSP in
firmware. inmos purtroppo e' fallita, ma credo che la sgs-thompson li
faccia ancora:
http://www.st.com
 
ciao!
  gabriele
--
gabriele zugliani - student at pisa univ. (dept. of computer science)
linux docs: 
http://ildp.psy.unipd.it
 
http://sunsite.unc.edu/LDP
==> NOTE: TO REPLY PLEASE REMOVE "NZPM" FROM THE ADDRESS.

 dall'altro...
Grazie del supporto morale, sono nuovo dei ng. e non ne conosco bene l'etica.
ciao,
debrando

Grazie del supporto morale, sono nuovo dei ng. e non ne conosco bene l'etica.
in realta' mi pare che sei gia' ben addentro allo spirito del gruppo.
grazie delle info datemi, sono molto preziose (almeno adesso so cosa
posso dire e non dire a chi mi chiede se l'architettura intel e'
veramente cosi' pessima come si dice ;) ).
thanks again...
